The cloud bill grows a little every month while the product does not. Nobody
can say what several line items are for. Cost Explorer's service breakdown
shows steady charges from services the team "stopped using ages ago": a demo
App Runner service, S3 buckets nobody can name, EBS volumes in state
available, an Elastic IP attached to nothing, a NAT gateway in a dev VPC
with zero traffic. In the reported case the quiet total reached ₹58,000
before anyone audited it.
A small team (or one developer) built fast for six months: hackathon demos, proof-of-concept services, test buckets, experiment volumes. Each experiment ended, but its resources did not — the cloud's default is on, and deleting was always someone-else's-someday job. Nothing was tagged, so no resource named an owner who could be asked "is this still needed?". The 4.7 teardown ritual existed as personal habit for one person, but never became a team practice. Linked modules: 4.9 (Scaling & cost control), 4.7 (Cloud deployment).
A zombie resource is a cloud resource nobody uses that is still billing, and
zombies accumulate wherever creation is easy and ownership is unrecorded.
The bill grows slowly — a few hundred rupees per zombie per month — so no
single month triggers alarm; the damage is the integral, not the spike.
Diagnose with a read-only sweep, in every region the team ever touched
(strays hide in us-east-1, per WR-111): list running services and check last
request; list buckets and check last read; list volumes filtering state
available; list unattached Elastic IPs; list NAT gateways against their
VPC's traffic. Three tells settle most rows: no tags (no owner), no activity
for months (no user), and attached-to-nothing (no purpose).
Stop the meter in money order, same as the 4.7 teardown: hourly billers first (services, NAT gateways, databases), then storage (buckets, volumes, old ECR images), then free scaffolding (roles, log groups via retention policies). For anything uncertain, stop rather than delete, wait one week for screams, then delete — and snapshot volumes before removing them if the data has any claim to life. Recover what billing allows: AWS support sometimes grants goodwill credit for clear first-time cleanup cases. Then record the saving in rupees per month; that number is what turns a cleanup into a policy.
Make ownership mechanical: every resource carries owner and env tags at
creation, enforced by policy, so "whose is this?" always has an answer. Run
a monthly zombie hunt from a read-only script that prints KEEP, RESIZE or
KILL with evidence — one intern-hour that routinely pays four figures.
Auto-stop what dev leaves running: schedules that stop dev databases and
instances outside office hours, lifecycle policies that keep only the last
few images, log retention instead of never-expire. And keep the personal 4.7
rule alive at team scale: the session is not over until the teardown ran.
Q: "You join a startup and the AWS bill has doubled in a year with flat
traffic. First week — what do you do?" Strong answer: run a read-only audit
before touching anything — per-service cost breakdown, then the zombie
tells: untagged resources, months-idle services, available volumes,
unattached IPs, idle NAT gateways, every region checked. Kill in money
order, stop-then-delete for anything doubtful, and report the saving in
rupees per month. Close with prevention — mandatory owner tags, a monthly
hunt, auto-stop schedules — because interviewers are hiring the habit, not
the one-time cleanup.