Your AWS bill isn't a mystery - it's a receipt for decisions nobody revisited

Most AWS bills I've looked at aren't expensive because AWS is expensive. They're expensive because someone made a reasonable decision eighteen months ago and nobody's looked at it since.
Here's a pattern I see often enough that it's worth walking through - a composite of the kind of setup that shows up again and again when a team asks me to take a look at their infrastructure costs.
The setup
A small SaaS product, steady but modest traffic. Somewhere back at launch, someone picked an EC2 instance size and an RDS database tier that felt safe — a little bigger than they thought they'd need, "just in case." Reasonable call for a launch, when nobody yet knows what real usage looks like.
Eighteen months later: traffic has grown, but not evenly. There's a clear daily pattern — busy during business hours, quiet overnight. And the instance sizes picked at launch? Still exactly the same. Nobody revisited them, because nothing was broken. The app worked fine. The bill just quietly kept climbing.
Where the money was actually going
Three things, and none of them are exotic:
Running peak capacity, all day, every day. The instance was sized for the busiest hour of the busiest day — and then billed at that size around the clock, including the eight hours a night when almost nobody was using it.
No auto-scaling. Because there was nothing in place to scale down during quiet periods, "big enough for the peak" simply became the permanent, fixed cost of every single hour.
Resources nobody remembered existed. An old staging database. A test instance spun up for a migration eight months ago. A couple of snapshots nobody had a reason to keep. None of these cost much individually — but they'd been quietly billing every month since whoever created them moved on to the next task.
None of this is a story about bad engineering. It's what happens by default when infrastructure decisions get made once, under launch pressure, and then nobody's job is to revisit them.
What actually gets fixed
When I go through a setup like this, it's rarely dramatic:
Right-size the instances to actual usage, not to the peak-safety margin someone picked a year and a half ago
Turn on auto-scaling so capacity — and cost — flexes with real traffic instead of sitting at "biggest we might ever need"
Audit for orphaned resources — the staging environments, old snapshots, and test instances that outlived the task they were created for
None of these require rebuilding anything. They're closer to a cleanup than a redesign — which is exactly why they get skipped. There's no ticket for "go check if we still need this," so it never gets written.
The takeaway
An AWS bill isn't a fixed cost of doing business — it's a running record of every infrastructure decision your team has ever made, still being charged at whatever rate made sense the day it was made. If nobody's specific job is to revisit those decisions, they don't get revisited, and the bill just becomes something people sigh at once a month instead of something anyone actually looks into.
That review usually takes an afternoon. It's one of the more satisfying things to hand someone an actual number for.
Note: the setup above is a composite, built from patterns I've seen across multiple projects — not a single client engagement. If your infrastructure bill has crept up and nobody's fully sure why, that's usually a short conversation, not a long one. I'm easy to find.





