We pointed Claude at our AWS bill and cut it 59%

Engineering · Cloud Cost

StandardCode · ~6 min read

−59%
Lower monthly AWS spend
Same products, same customers, same uptime.

We cut our AWS bill by 59%.

No products retired, no features cut, no change for customers. Same products, same customers, same uptime. We just stopped paying for things we didn't need.

The interesting part isn't the number. It's that most of the savings had been sitting in plain sight for over a year, in a bill nobody could read.

The problem with cloud bills

Cloud spend is easy to grow and hard to audit. Ours grew the normal way: a database gets provisioned for a project, the project ends, the database stays. A reporting copy gets added for an analytics tool, the tool moves on, the copy keeps billing. Someone turns on debug logging to chase a bug, and it stays on for months.

None of this is negligence. It's just that reviewing it properly is genuinely tedious work. AWS Cost Explorer will happily tell you what you spent on databases last month. Turning that into “and this specific slice of it is a penalty you could eliminate this week” means breaking the bill down by usage type, cross-referencing every line against your live inventory, and knowing which of the resulting resources are actually load-bearing.

That's a few days of unglamorous work for an engineer who has a product to ship. So it doesn't get done — which is exactly the kind of task an AI agent is good at.

Step one: look, don't touch

We pointed Claude Code at our AWS environment with a hard constraint: read-only. No modifying, no deleting, no tagging. Just describe every resource, pull the actual billing data, and report.

This constraint matters more than it sounds. It meant we could run a genuinely thorough audit — everything, down to individual snapshots — without any risk of an agent “helpfully” deleting something load-bearing. The output was a report, not an action.

We formalized it as a reusable audit that checks the things that reliably rot: unattached disks, orphaned snapshots and machine images, idle IP addresses, long-stopped servers, load balancers with no traffic, over-provisioned databases, log groups with no retention policy, and databases running past end-of-life.

That last one turned out to be where the money was.

The find: ~$1,500 a month for databases we'd already paid for

Two of our production databases were running on engine versions that had passed end of standard support. Both still worked fine. That's the trap.

When an engine version reaches end of standard support, AWS doesn't shut it off. It keeps running and starts charging Extended Support fees — a per-vCPU-per-hour surcharge on top of your normal instance cost. It's a deliberate nudge to upgrade, and if you don't notice it, it just becomes part of your bill.

Roughly $18,000 a year, purely for the privilege of not upgrading.
No extra performance, no extra capacity, no extra reliability. A late fee.

Worse — and this is the part worth checking on your own bill — the rate escalates the longer you wait. We only found the true figure by pulling the exact billed line items rather than trusting a pricing estimate. It was materially higher than our first guess.

Step two: change things, carefully

Reading the bill is safe. Upgrading production databases is not. This is where an AI agent needs a human, and where we were deliberate about the division of labor.

The agent did the analysis, the sequencing, and the verification. A human approved every irreversible step. Nothing that deleted, upgraded, or cut over ran without an explicit go.

The upgrades themselves followed the boring, correct playbook:

1. Validate on a clone first. Both upgrades were rehearsed against restored copies and staging before production was touched.
2. Ship application compatibility fixes ahead of the database change, not alongside it.
3. Cut over with Blue/Green deployments — the new version is built and kept in sync alongside the old one, then promoted. The switchover is measured in seconds.
4. Keep a rollback at every step. Pre-upgrade snapshots plus, briefly, the old database left running as an instant fallback.

Total production write downtime across both database cutovers: about one minute. Zero data loss.

Alongside the upgrades came the less dramatic savings: an over-provisioned database right-sized, a reporting copy nobody queried any more removed, a storage tier switched to match actual usage, and a runaway debug-logging stream switched off at the source.

Then the cleanup: roughly 60 database backups, 68 disk snapshots, 58 machine images, 27 idle IP addresses, 12 leftover database instances, and 9 stopped servers removed. Over 3 TB of orphaned storage reclaimed.

What it costs to keep

Cutting a bill once is a project. Keeping it cut is a habit, and this is the part we care about most going forward.

The audit is now tooling, not a heroic effort — three read-only checks we can run any time:

• Waste — idle and orphaned resources, over-provisioned databases, the things that accumulate.
• Infrastructure — security posture, reliability, and drift: what changed since last time.
• Deadline radar — the one that would have caught this whole thing a year earlier. It tracks what has a clock on it: database engines approaching end of standard support, deprecated runtimes, expiring certificates, pending maintenance. Every finding is a countdown with the upgrade path and the dollar impact attached.

All three are read-only by design. They produce a report; a human decides what to do about it.

The deadline radar is the real lesson. That ~$1,500/month Extended Support bill wasn't a mystery — AWS publishes those end-of-support dates years ahead. We just had nothing watching the calendar. Now we do, and the next engine reaching end-of-life shows up as “X days remaining, here's the upgrade path, here's what it costs if you don't” instead of as a line item nobody reads.

We also check the actual bill against the baseline monthly, rather than assuming savings persist. They mostly do — but “mostly” is why you check.

What we'd tell you to do tomorrow

If you run anything on AWS, three things are worth an hour of your time:

1. Check whether you're paying Extended Support on any database. It's a specific line item in your Cost Explorer usage-type breakdown. If it's there, it's probably your single best-value fix, and the rate goes up the longer you wait.
2. Break your bill down by usage type, not just by service. A service-level total tells you nothing actionable. The usage-type view is where the penalty lines, the redundancy you're not using, and the storage tier you're overpaying for actually show up.
3. Put a clock on your end-of-life dates. Everything expensive about this was avoidable with a calendar entry.

The AI agent didn't do anything a careful engineer couldn't have done. It made it cheap enough that we actually did it — and turned a several-day audit into something we now run on a schedule. That's the real change: not that the work got smarter, but that the tedious, high-value work stopped being too expensive to bother with.

One more change is still to land. When it does, we'll be roughly 68% below where we started. We'll keep watching.

standardco.de