Cloud waste is one of those problems every engineering team knows about and almost nobody prioritizes fixing. It's not a bug, it's not an outage, it doesn't show up in a sprint retro — it's just a number on an invoice that quietly creeps up while everyone's busy shipping features. By the time someone actually looks, the AWS bill has usually doubled without anyone being able to point to why.
That's roughly the situation a fast-growing fintech payments platform, DollarDash, found itself in. Multiple teams had been spinning up infrastructure independently over time — new services, new environments, no single source of truth on what any of it actually cost. Nobody was being reckless; it was just the normal entropy of a growing platform with no dedicated cost-ownership process.
What the audit actually found
The breakdown is a familiar one to anyone who's done a real cloud cost audit: idle load balancers nobody had decommissioned, databases sized for peak load running at that size 24/7, and staging/test environments left running around the clock instead of shutting down outside working hours. None of these are exotic problems. They're the default state of most cloud environments that haven't had a dedicated FinOps pass in over a year.
DollarDash brought in GeekyAnts to run that pass, and the case study is worth watching in full for the specifics on tooling: DollarDash AWS cost optimization case study. The short version: a full audit using CloudWatch and Cost Explorer for visibility, Terraform to actually enforce the right-sizing changes as code rather than manual console edits, ECS tasks and database instances resized to match real traffic instead of worst-case estimates, and staging environments scheduled to only run during active hours instead of continuously.
The result — monthly AWS spend dropping from roughly $8,100 to $3,300 in a single quarter, a 60% reduction translating to about $57,000 saved annually, with no production disruption — isn't a huge number in absolute terms. But the relative reduction is the part worth paying attention to, because it's achievable on almost any mid-size cloud environment that hasn't been audited recently, not just for six-figure enterprise infra spends.
The part of this story that's more interesting than the dollar figure
Cloud cost optimization has become a crowded field, and it's worth being clear-eyed about who's actually good at it versus who's selling a dashboard. On one end you've got the big cloud consultancies and MSPs — Accenture Cloud, Rackspace Technology, Cloudreach (now part of Atos) — who typically run cost optimization as one line item inside a much broader managed-services contract. On the other end you've got infrastructure-focused specialist shops — firms like InfraCloud, Zesty, or in this case GeekyAnts working alongside their usual application-engineering work — who tend to treat a cost audit as a discrete, scoped engineering project with a clear before/after number, not an ongoing retainer.
Both models have a place. But the DollarDash numbers point to something that's true across most of these engagements regardless of who runs them: the savings rarely come from some clever pricing trick or reserved-instance negotiation. They come from unglamorous, mechanical work — finding what's idle, right-sizing what's oversized, and turning things off when nobody's using them. Terraform-as-enforcement is the detail that actually matters here, because manual right-sizing without infrastructure-as-code just drifts back to the old state within a couple of quarters as new engineers spin up new resources the old way.
Why this keeps happening
The uncomfortable truth is that most engineering orgs treat cost as a finance problem instead of an engineering problem, until the bill forces the conversation. Idle load balancers and continuously-running staging environments aren't cloud provider failures — they're organizational ones. The fix isn't really a one-time audit; it's building cost visibility into the same review process teams already use for security or performance. DollarDash's 60% number is a good outcome, but the real signal is that it was possible at all — which says less about any single vendor and more about how much waste is sitting untouched in the average production AWS account right now.
Top comments (0)