Cut a SaaS startup's AWS bill by ~42%
A Series-A SaaS team's AWS bill had tripled in a year and nobody could say why. A focused FinOps pass cut it ~42% without touching reliability.
The problem
A fast-growing SaaS company's AWS bill had grown 3x in twelve months while traffic only doubled. Finance was alarmed, engineering was too busy shipping to investigate, and nobody could explain the line items.
The approach
- ▸Pulled Cost Explorer and CUR data to map spend by service, environment, and workload. About 60% was compute, and a lot of it sat idle.
- ▸Rightsized over-provisioned EKS node groups and workload requests and limits against 30 days of real usage, keeping sane headroom.
- ▸Brought in Karpenter for bin-packing and moved fault-tolerant batch and staging workloads onto spot instances.
- ▸Bought savings plans for the steady production baseload, then deleted orphaned volumes, idle load balancers, and dev environments that ran all weekend for no reason.
The result
- ✓~42% reduction in monthly AWS spend, visible on the next invoice
- ✓No measurable impact on latency or availability
- ✓Cost dashboards and budget alerts so the savings actually hold
- ✓Paid for itself in under three weeks
stack: AWS · EKS · Karpenter · Terraform
The shape of the waste
None of this was exotic. The bill had grown because nobody owned cost. Node groups were sized for a launch spike that never came back, Kubernetes requests were padded “to be safe,” and three dead dev environments ran around the clock. The biggest single lever was rightsizing requests and node groups against actual usage. Spot and savings plans built on that, and the cleanup mopped up whatever was left.
The cut on the next invoice is nice, but the part that lasts is the dashboards and budget alerts. Cost went from an invisible creep to a number the team checks.
Done by Harshit Luthra, an independent infrastructure and AI engineering consultant. Bring me a similar problem →
Questions about this work
How much can a FinOps pass realistically cut an AWS bill?+
For a team that hasn't done a focused pass, 20-50% is normal. Here it was ~42% in three weeks. Most of it came from rightsizing over-provisioned compute and Kubernetes requests against real usage, then spot and savings plans on top. The savings showed on the next invoice, not after a long project.
Does cutting cloud cost hurt reliability?+
It didn't here, and it shouldn't if it's done from real usage data with sane headroom rather than aggressive guesses. Latency and availability were unchanged. Any change with a tradeoff gets flagged before it ships.
How long did the engagement take?+
About three weeks end to end, and it paid for itself inside that window. The quick wins (idle cleanup, rightsizing) landed first, then the structural pieces (Karpenter, savings plans, dashboards) locked the savings in.