Almost every SaaS team we talk to describes the same pattern: revenue grows in a straight line, and the AWS bill grows in a curve above it. Nobody made one bad decision. The bill grew the way sediment builds up — one forgotten instance, one "just for testing" environment, one default setting nobody revisited.
The fix isn't a heroic one-time cleanup. It's recognizing the handful of places cost actually accumulates, and building the habit of checking them.
Idle and oversized compute
The single biggest line item on most accounts is compute that's sized for a peak load that rarely happens, or that's simply running when nothing is using it. Staging and QA environments left on 24/7. An m5.2xlarge chosen because someone wasn't sure what the app needed, never revisited once real usage data existed. Auto-scaling groups with a minimum count set high "to be safe."
None of these are wrong decisions in isolation. They're just decisions nobody scheduled a follow-up for. A monthly pass through Cost Explorer's compute breakdown, sorted by cost, usually surfaces two or three instances that are quietly oversized for what they do.
Orphaned storage and network resources
EBS volumes left behind after an instance is terminated. Snapshots that were useful during a migration and never got a retention policy. Elastic IPs allocated and then unassigned — AWS charges for those the moment they stop being attached to anything running. None of these show up as "compute," so they don't get looked at when someone eyeballs the biggest line items — they just accumulate in the background.
Data transfer nobody accounted for
Cross-AZ traffic, NAT gateway data processing, and public data transfer are often invisible in the architecture diagram and very visible on the invoice. A service that calls another service across availability zones a few million times a day adds up fast, and it's the kind of cost that's genuinely hard to predict from the console — it only shows up once you're paying for it.
What a real audit looks for
When we start a cost engagement, we're not looking for one big villain. We're building a short list, ranked by dollars, of exactly this kind of accumulation: idle resources, oversized instances, orphaned storage, and transfer patterns that don't match the architecture's intent. Then we decide, resource by resource, whether to right-size it, decommission it, or move it to a cheaper tier — and we put tagging and a lightweight review cadence in place so the list doesn't grow back.
That's what we did for AIESEC Brasil, a non-profit running its main website on an oversized AWS environment. We audited the account, decommissioned what wasn't being used, and migrated to a right-sized setup — cutting infrastructure costs by ~95%, eliminating roughly US$484 a month in AWS spend, with zero downtime during the change.
The number that matters isn't 95% on its own — it's that the bill had drifted that far from what the workload actually needed, and nobody had looked closely enough to notice.
Where to start this week
If you don't have time for a full audit, start with Cost Explorer filtered to the last 30 days, grouped by service, then by resource. Ninety percent of the time, the top five line items explain most of the bill — and at least one of them will surprise you.
If that first look turns up more than you expected, an AWS cost optimization engagement is built exactly for this: a focused audit, a prioritized list, and a right-sized setup that doesn't creep back up six months later.
