The bill that grows without a villain
When a client asks us to look at a growing AWS bill, we're rarely looking for a single wasteful resource. We're looking at a dev environment that mirrors production sizing, a database instance sized for a traffic spike that happened once and was never scaled back down, log retention set to keep everything indefinitely by default, and a few abandoned resources still running from a project that shipped and moved on without a teardown step.
Why this happens on every team, not just disorganized ones
Cloud infrastructure makes provisioning easy and deprovisioning invisible. Spinning up a new resource takes one command and shows up immediately in a sprint demo. Turning it off later requires someone to remember it exists, decide it's safe to remove, and actually do it — a task with no natural trigger and no one's name attached to it. That asymmetry is the actual root cause behind almost every surprisingly large cloud bill, far more often than any single wasteful decision.
What a real cost review looks for
Right-sizing: instances provisioned for peak load that sit idle at a fraction of capacity the rest of the time
Orphaned resources: storage volumes, snapshots, and load balancers left behind after the instance that used them was terminated
Data transfer costs, one of the most commonly underestimated line items until a bill makes them impossible to ignore
Reserved or savings-plan pricing left unused on workloads stable enough to qualify, running instead at full on-demand rates
Making it someone's job
The actual fix isn't a one-time audit — it's assigning clear architectural ownership so infrastructure decisions get reviewed on a cadence, the same way code does. When we take on infrastructure work, one of the first deliverables is usually a cost and ownership map: what's running, why it's sized the way it is, and who signs off the next time something new gets provisioned.