{"id":4488,"date":"2026-02-01T21:04:01","date_gmt":"2026-02-01T15:34:01","guid":{"rendered":"https:\/\/www.itsupportwale.com\/blog\/mastering-amazon-aws-a-complete-guide-for-beginners\/"},"modified":"2026-02-17T15:57:00","modified_gmt":"2026-02-17T10:27:00","slug":"mastering-amazon-aws-a-complete-guide-for-beginners","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/mastering-amazon-aws-a-complete-guide-for-beginners\/","title":{"rendered":"Mastering Amazon AWS: A Complete Guide for Beginners"},"content":{"rendered":"

json
\n{
\n “Version”: “2012-10-17”,
\n “Statement”: [
\n {
\n “Sid”: “ExplicitDenyAllExceptVPC”,
\n “Effect”: “Deny”,
\n “Principal”: ““,
\n “Action”: “s3:<\/em>“,
\n “Resource”: [
\n “arn:aws:s3:::critical-prod-assets\/“,
\n “arn:aws:s3:::critical-prod-assets”
\n ],
\n “Condition”: {
\n “StringNotEquals”: {
\n “aws:SourceVpc”: “vpc-0a1b2c3d4e5f6g7h8”
\n },
\n “Bool”: {
\n “aws:PrincipalIsAWSService”: “false”
\n }
\n }
\n },
\n {
\n “Sid”: “AllowAppRoleAccess”,
\n “Effect”: “Allow”,
\n “Principal”: {
\n “AWS”: “arn:aws:iam::123456789012:role\/application-server-role”
\n },
\n “Action”: [
\n “s3:GetObject”,
\n “s3:PutObject”
\n ],
\n “Resource”: “arn:aws:s3:::critical-prod-assets\/<\/em>”
\n }
\n ]
\n}<\/p>\n

The snippet above is why I haven't slept. Someone\u2014probably a "Senior Architect" who hasn't touched a terminal since 2018\u2014decided to enforce VPC-only access to our primary S3 bucket. They forgot that the `Deny` evaluation logic in **amazon aws** is absolute. It doesn't matter if the `Allow` block is there. It doesn't matter if the IAM role has `AdministratorAccess`. The moment that `StringNotEquals` condition failed because a Lambda function was executing outside the VPC or a CloudFront distribution tried to fetch an origin object, the entire frontend went dark. 403 Forbidden. Everywhere. \n\nI\u2019ve been staring at this for 72 hours. My eyes feel like they\u2019ve been rubbed with sandpaper. The bridge call has 45 people on it, 40 of whom are "Project Managers" asking for an ETA every six minutes. \n\n## Ticket #9902: The Cascading Failure of the "Cost-Optimized" Tier\n\nThe incident started at 03:00 UTC. We were running our worker nodes on `t3.medium` instances. Marketing decided to launch a "flash sale" without telling Engineering. The burst credits on those `t3` instances? Gone in fifteen minutes. When a `t3` runs out of credits, it doesn't just stop; it throttles you to a baseline performance that is essentially a digital paperweight. \n\nI tried to pull the metrics. The console was timing out because the control plane was under heavy load. I had to drop to the CLI.\n\n```bash\naws cloudwatch get-metric-statistics \\\n    --namespace AWS\/EC2 \\\n    --metric-name CPUCreditBalance \\\n    --dimensions Name=InstanceId,Value=i-049f8234567890abcdef \\\n    --start-time 2023-10-24T03:00:00Z \\\n    --end-time 2023-10-24T04:00:00Z \\\n    --period 300 \\\n    --statistics Average\n<\/code><\/pre>\n
The output was a string of zeros. The nodes were pinned at 100% CPU utilization but were only actually processing at 20% of their capacity because of the credit exhaustion. The Auto Scaling Group (ASG) saw the 100% CPU and tried to spin up more instances. But because the existing instances were so throttled, they couldn’t even finish their cloud-init<\/code> scripts to report as InService<\/code>. <\/p>\n
We had a graveyard of “zombie instances” that were costing us money but doing zero work. The amazon aws<\/strong> ASG logic kept killing them for failing health checks, then starting new ones, which then failed. A death spiral in real-time.<\/p>\n
\n
Table of Contents<\/p>\n