A card statement (or a parent's card statement) shows an AWS charge of a few thousand rupees — ₹4,600 in the reported case — for an account that was "only used once, for a college demo". No email warned anyone. Inside the console, Cost Explorer shows a flat daily charge ticking every single day since the demo, including nights, weekends and the exam week when nobody logged in.
First personal AWS account, opened for a project demo. An App Runner service (or an EC2 instance, a SageMaker notebook, a NAT gateway — any hourly biller) was created for the demo and worked perfectly. The demo ended, the laptop closed, and the account was never opened again. No budget or billing alarm was ever created; the account was still being used as root. Linked modules: 4.7 (Cloud deployment), 4.3 (Docker for ML).
Two independent failures multiplied. First, the cloud's default is ON: an
hourly-billed service runs, and bills, until someone deletes it — closing the
laptop, ending the demo, even forgetting the password changes nothing.
App Runner at roughly ₹6 per hour is about ₹150 a day; three quiet weeks is
₹3,000–5,000. Second, nothing was watching: with no budget alarm, the first
notification anyone received was the card statement — the most expensive
monitoring system in the world. Confirm the shape in two places: Cost
Explorer's daily view shows the flat daily amount starting on demo day, and
the service list (aws apprunner list-services, or the EC2/SageMaker console)
shows the forgotten resource still in a running state.
Stop the meter first, argue later: delete or stop the running service the moment the charge is discovered — hourly billing ends within the hour, and teardown order is money-first (hourly services, then storage, then the free scaffolding like roles). Then check every region's console for strays, because scattered resources hide (WR-111). Then open a support case: AWS routinely grants a one-time goodwill credit to students who explain a first-account mistake, but only after the resource is stopped. Finally build the guardrails that were missing: a monthly cost budget with email alerts at 50/80/100%, MFA on root, and an IAM user for all future work.
Alarm first is the rule: the budget exists before the first bucket, because it must predate the first mistake. Treat teardown as part of every session — the 4.7 ritual ends with three empty list commands and a next-day Cost Explorer check reading zero. Know your hourly billers by name (App Runner, EC2, SageMaker, NAT gateways) and never let one outlive the session that created it. Alerts are smoke detectors, not brakes: AWS keeps serving and billing after every email, so only deletion stops the meter.
Q: "A junior on your team left a demo service running for three weeks on an unmonitored account. Walk me through your response and what you change." Strong answer: stop the biller immediately (name the money-first teardown order), sweep all regions for strays, raise the goodwill support case, then install the guardrails — budget alarms before resources, MFA on root, IAM users, and a teardown checklist in the repo. Naming the deeper principle — cloud defaults to on, so absence of attention costs money — signals you have actually run cloud accounts, not read about them.