Every few months a familiar meeting happens somewhere in every company that runs on AWS. Finance forwards the bill, someone senior asks why it went up again, and the engineering answer is a shrug dressed up as a roadmap. The truth is usually less dramatic than either side fears: nothing is broken, nothing was hacked, and no single service ran away. The bill climbed the way most cloud bills climb: quietly, in small increments, because no one owned the number.
I’ve spent enough time inside enterprise AWS accounts to be suspicious of exciting explanations. The expensive problems are almost always boring. So rather than another list of clever architectural rewrites, here are the unglamorous fixes that reliably move the number, the ones I reach for before anyone starts a migration.
Start with attribution, not architecture
You cannot manage what you cannot attribute. The first question is never “how do we spend less”; it’s “who is spending what, and why.” In practice that means a tagging policy that is actually enforced, not aspirational. Cost allocation tags on every resource: owner, environment, and cost centre at minimum. A resource with no owner tag is a resource nobody will ever turn off.
Enforce it with a service control policy or an automated check that flags untagged resources within a day of creation, and make the flag visible to the team that created them, not buried in a report finance reads once a quarter. The goal is a bill you can slice by team and by environment. Once you have that, the outliers announce themselves.
The three line items that are usually wrong
When I open an unfamiliar account, three things are wrong far more often than not:
- Idle and oversized compute. Instances provisioned for a launch that happened two years ago, running at three percent CPU. Non-production environments running twenty-four hours a day for a team that works eight. Right-sizing and a simple nightly shutdown schedule on dev and staging often takes a double-digit percentage off compute with zero risk.
- Storage that never gets cleaned up. Orphaned EBS volumes from terminated instances, snapshots with no lifecycle policy, and S3 buckets full of data that should have moved to a cheaper tier, or been deleted, long ago. Storage is cheap per gigabyte, which is exactly why it accumulates unwatched until it isn’t cheap anymore.
- Data transfer and NAT. The line items nobody understands until they read the fine print. Cross-AZ chatter, traffic routed through a NAT gateway that could have used a VPC endpoint, and egress that a small architectural change would have avoided. This is where “it’s just a bit of traffic” becomes a five-figure surprise.
None of these require a redesign. They require someone to look, which is a different and rarer thing.
Commit to what you actually run
Once the waste is gone, buy down what’s left. Savings Plans and Reserved Instances exist because AWS would rather have your predictable baseline locked in than watch you shop around, and they’ll discount meaningfully for the privilege. The mistake enterprises make is committing before they’ve cleaned up, locking in a one- or three-year commitment on top of workloads they haven’t right-sized yet.
Do it in the right order: eliminate the obvious waste, establish your true steady-state baseline, then commit against that baseline conservatively. Cover the floor you’re certain of and leave the peaks on-demand. A commitment you can’t fully use is just a more expensive way to pay full price.
Make cost a signal, not a quarterly autopsy
The organisational fix matters more than any single technical one. If the bill is something finance discovers after the fact, cost will always be a lagging surprise. The teams who keep it under control treat spend as a first-class operational signal, the same way they treat latency or error rate.
That means budgets with alerts that fire before the month closes, anomaly detection that pings the owning team (not a central inbox), and a short, regular review where engineering and finance look at the same dashboard. Not to assign blame, but so the people who can actually turn things off are the ones seeing the number. When the engineer who launched a resource is the one who gets the alert, waste tends to have a short life.
The boring conclusion
Cloud cost control is not a project you finish. It’s a habit you maintain: attribute clearly, clean up relentlessly, commit conservatively, and put the number in front of the people who move it. None of that is exciting, and that’s rather the point. The exciting fixes make good conference talks. The boring ones make the bill go down.
Leave a Reply