One Sprint, 45% Savings

Most cost optimization projects are long, drawn-out affairs. Months of analysis. Committees. Prioritization meetings. Tickets that sit in a backlog. Changes that need three approvals and a maintenance window.

This one took approximately one sprint.

The client's total AWS bill dropped by about 45%. Annualized savings: roughly $150,000 a year.

Here's what happened.

The infrastructure side was my work. RDS databases rightsized based on actual metrics. ElastiCache clusters rightsized - they'd been overprovisioned by 10x. Some resources converted to Graviton, though most RDS and ElastiCache were already on Graviton before I got involved. Most EBS volumes converted from GP2 to GP3. And one unused database deleted - a developer experiment that had been forgotten.

That last one is a recurring theme in my work. Someone spins something up to test an idea. The idea doesn't go anywhere. The resource keeps running. Nobody remembers it's there. It just bills.

The infrastructure changes alone accounted for $2,250 a month - about $27,000 annualized.

But that's not the whole story. While I was working on the infrastructure, I found things in the application code that were costing money too. The client's team fixed those in parallel. Their application changes - informed by what I found in the metrics - added another $8,500 a month, or about $101,000 annualized.

Together: roughly $150,000 a year.

What made this work in one sprint wasn't speed. It was knowing what to touch and what not to touch. I handle the infrastructure changes - the safe configuration changes, the rightsizing, the GP2-to-GP3 conversions, the obvious waste removal. I implement those myself. The customer's involvement was limited to onboarding, being present for production database changes, and sync calls.

The application-level wins were bigger in dollar terms, but they required the customer's engineering team. I found them. The team implemented them. By the end of the sprint, the team was still working on additional changes I'd pointed out.

No massive re-architecture. No risky migrations. Mostly: measurements, rightsizing, storage tier changes, and deleting things that shouldn't have been running. The kind of work that everyone agrees should happen but nobody ever has time for.

One more thing: the Graviton instances they migrated to have roughly 2.5x lower carbon emissions than the x86 instances they replaced.