Week 7 review + AWS Bill Shock

The Week-7 muscle: a safe account, a running box, and a bill you can read

Section 1 of 5 · ~3 min

Phase 3 opened the cloud. Week 7 was about earning the right to use it without getting burned — three days that turn “I have an AWS account” into “I can run something in AWS and know exactly what it costs.”

The model. Day 46 drew the map: AWS runs in regions, each split into availability zones so a single data-center failure doesn’t take you down, and the shared responsibility model splits the work — AWS secures the cloud itself, you secure what you put in it. That split has a cost twin: AWS charges fairly for what runs; you are responsible for what you leave running.

The hygiene. Day 47 locked the account down before you built anything on it: MFA on the root user, then stop using root; real IAM users or Identity Center identities with least-privilege permissions; a budget with alerts; and cost-allocation tags so every resource says who owns it and why. None of that is glamorous, and all of it is what stands between you and a surprise invoice.

The compute. Day 48 launched your first EC2 instance — a t3.micro inside the free tier — connected over SSH, and opened exactly the ports you needed with a security group. You also learned the difference today’s mission turns on: stopping an instance keeps its disk and pauses compute charges; terminating deletes it and stops the bill for good.

Put those together and week 7’s real lesson emerges: in the cloud, cost is a first-class operational skill, not an afterthought. A forgotten instance doesn’t crash or page you — it just quietly bills you every hour until someone reads the invoice. Reading the bill is the job.

Real world: A cloud bill is a taxi meter you can’t see from the back seat. The ride feels free while you’re talking — the meter just ticks. A forgotten p3.2xlarge GPU box is a taxi you climbed out of but never told to stop: still parked at the curb, meter running, all month. Cost Explorer is you finally walking around to the front and reading the number.

A named example makes it concrete. AWS Cost Explorer and AWS Budgets exist precisely because bill shock is universal — every team, from a solo learner to a FAANG-scale org, eventually launches something big and forgets it. Cost Explorer lets you group spend by service, region and tag to find what jumped; Budgets fires an alert before the month closes, so the next spike pages a human instead of ambushing finance.

That’s why today is a mission, not a lecture. Reading about a tripled bill doesn’t build the reflex — hunting one down does. AWS Bill Shock drops you into an account whose monthly spend just tripled, hands you Cost Explorer and the EC2 console, and asks the only question that matters on call: what is burning money, and can I safely turn it off?

What this costs: ₹0. AWS Bill Shock runs entirely in your browser — it touches no real AWS account and can’t bill you. The one place real money hides this week is the t3.micro you launched on day 48: if it’s still running, stop or terminate it now (EC2 console → Instances), because a forgotten free-tier box is exactly the habit this mission trains you to break.

Hands-On Lab

Section 2 of 5 · ~2 min

Today the lab is the mission. No AWS account to touch, nothing to launch, nothing that can bill you — AWS Bill Shock runs entirely in your browser.

This is your Week-7 boss fight, and it closes the account-hygiene half of Phase 3. Last month’s AWS invoice tripled — no new features shipped, no new team, just a number that jumped from ordinary to alarming, and finance is asking why. Somewhere in the account a resource is quietly burning money. Everything you need is something you already learned in days 46–48, so play it as the walk from the diagram:

• See the spike — open Cost Explorer and group by service. One line, EC2, dwarfs everything else. That grouping is the fastest way to turn a scary total into a single suspect (days 46–47).
• Find the resource — regroup EC2 by usage type or by cost-allocation tag. The entire jump is one instance type: a p3.2xlarge GPU box someone spun up to test a machine-learning model and never shut down (day 47’s tags).
• Name the box — the instance carries the tag ml-experiment-DELETEME, about the loudest cry for help a resource can make, and the EC2 console shows it running in a region you don’t normally use — which is why nobody noticed it (day 48).
• Kill the bill — confirm it’s safe (a scratch experiment, no data worth keeping), grab its real instance ID, and terminate it:

# The move that stops the bleeding: terminate the runaway GPU box by its ID.
# (yours will differ — copy the real i-… from the cost report / console first)
aws ec2 terminate-instances --instance-ids i-0abc123def
# Output:
# {
#     "TerminatingInstances": [
#         {
#             "CurrentState": {
#                 "Code": 32,
#                 "Name": "shutting-down"
#             },
#             "InstanceId": "i-0abc123def",
#             "PreviousState": {
#                 "Code": 16,
#                 "Name": "running"
#             }
#         }
#     ]
# }

Terminate, not stop: a stopped p3 you keep “just in case” is next month’s shock. Then watch the meter stop — the mission shows the projected daily spend flatten once the instance is gone. Type help in the terminal to see the supported commands, and hint if you stall — it nudges without solving. There’s no penalty for poking around; the whole point is to run the spike → service → resource → terminate walk with your hands until it’s reflex, and to feel why a forgotten instance costs money in total silence.

When the projected bill drops back to normal, come back and note below which step you’d have missed under real pressure — that reflection is where the lesson sticks.

Common Errors & Fixes

Section 3 of 5 · ~3 min

These are the mistakes that trip people up when they run this hunt for real on an account with the AWS CLI v2 — the same links the mission rehearses. Read the error text slowly; parsing it is the skill.

Common error: Running an aws command on a fresh machine before credentials are configured:

Unable to locate credentials. You can configure credentials by running "aws configure".

Why: The AWS CLI is only a client — it has no idea who you are until you give it credentials. With nothing in ~/.aws/credentials, no AWS_ACCESS_KEY_ID in the environment, and no SSO session, it can’t sign a single API request, so it refuses before it ever reaches AWS.

Fix: Run aws configure and paste the access key and secret for a least-privilege IAM user (from day 47), or aws configure sso / aws sso login if the account uses IAM Identity Center. Confirm it worked with aws sts get-caller-identity, which prints the account and identity you’re acting as.

How you’d spot it in prod: A CI job or deploy script that dies on its very first aws call with “Unable to locate credentials” almost never has a bad command — the runner has no role attached or no credentials injected. Check the environment, not the CLI.

Common error: Trying to terminate the instance with an IAM user that can read costs but not change compute:

An error occurred (UnauthorizedOperation) when calling the TerminateInstances operation: You are not authorized to perform this operation.

Why: This is least-privilege working exactly as designed. The identity can list instances and read Cost Explorer, but its IAM policy never granted ec2:TerminateInstances, so AWS refuses the destructive call. The account isn’t broken — the permission boundary is doing its job.

Fix: Attach a policy that grants ec2:TerminateInstances (ideally scoped to the region or a resource tag), or assume a role that already has it, then retry. Grant the narrowest permission that unblocks the task — don’t hand the user AdministratorAccess to kill one box.

How you’d spot it in prod: UnauthorizedOperation on a destructive call is usually good news — it means IAM is stopping an action the caller shouldn’t casually perform. Read the operation name in the message, grant that one permission deliberately, and move on.

Common error: Terminating with the right instance ID but from the wrong region:

An error occurred (InvalidInstanceID.NotFound) when calling the TerminateInstances operation: The instance ID 'i-0abc123def' does not exist

Why: EC2 instances are regional, and the CLI targets whatever default region is configured. The runaway GPU box is running in a region you don’t normally use — the whole reason it went unnoticed — so a terminate-instances aimed at your default region genuinely can’t find that ID there.

Fix: Pass the region the instance actually lives in: aws ec2 terminate-instances --instance-ids i-0abc123def --region us-east-1. Find the right region from the Cost Explorer breakdown or the EC2 console’s region switcher before you run the command.

How you’d spot it in prod: InvalidInstanceID.NotFound for an ID you’re staring at in the console almost always means a region mismatch, not a deleted instance. Check the region selector in the console against the --region (or default) the CLI is using.

AWS Cost Interview Questions

Section 4 of 5 · ~1 min

The “the bill tripled — find it” hunt and the stop-versus-terminate basics below are among the most common Phase-3 cloud screening questions — a calm, methodical answer that names Cost Explorer, tags and budgets beats a clever one every time. The answer bank renders right after this note. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it stick for interview day.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~40 more minutes:

• 5 min — Replay AWS Bill Shock and find the runaway box in as few steps as you can — Cost Explorer → tag → terminate, cold. Speed here is just knowing the hunt walk by heart.
• 10 min — In your own account (from day 47), open Cost Explorer and switch the group-by from Service to a cost-allocation tag. Reading your own spend is free, and it’s the exact skill the mission drills.
• 10 min — Create an AWS Budget with an 80% email alert on a small monthly amount. Budgets are free, and this is the alarm that turns silent bill shock into a same-day nudge.
• 15 min — Read the Cost Optimization pillar of the AWS Well-Architected Framework for the vocabulary — right-sizing, tagging, purchase options — behind everything week 7 practised.