When a Series A fintech came to us, their AWS bill had crossed $40,000 a month, and nobody on the team could explain why. The product hadn't changed much. Traffic was steady. But the bill climbed anyway, the way cloud bills quietly do when no one owns them.
Thirty days of focused work later, that bill was $12,000. Here is exactly how, and what you can borrow from it.
Where the money was actually going
The first finding won't surprise anyone who has audited an AWS account: there was no map of the spend. No cost-allocation tags, no per-team or per-service breakdown, no budget alerts. The bill was one large number, and large numbers are easy to ignore until they aren't.
Once we broke it down in Cost Explorer, three categories accounted for most of the waste: over-provisioned EKS node groups, idle resources that were never cleaned up, and RDS instances sized for a traffic peak that never came.
Step 1: Make the spend visible
Before changing anything, we made the spend legible. We applied a cost-allocation tagging policy, covering environment, team, and service, and enforced it through AWS Config so new resources couldn't slip through untagged. We set budget alerts that fire on anomalies, not just month-end totals.
This step saves no money on its own. It does something more important: it turns 'the AWS bill' into a set of decisions someone can actually own.
Step 2: Replace static node groups with Karpenter
The single biggest line item was the EKS cluster. Its node groups were statically provisioned with generous instance sizes, a rational choice made months earlier to avoid scheduling failures, and never revisited. The cluster was paying, around the clock, for capacity it used for a few hours a day.
We replaced the static node groups with Karpenter, which provisions nodes in response to actual pending pods and consolidates workloads onto fewer nodes when demand drops. It right-sizes to the workload instead of to a worst-case guess.
Karpenter alone accounted for roughly $18,000 of the monthly savings. If you run EKS on static node groups and you have not measured your real utilization, this is the first place to look.
Step 3: Right-size everything else
With the cluster handled, the rest was unglamorous cleanup: RDS instances rightsized against their actual CloudWatch metrics, more than forty unused Elastic IPs released, idle load balancers deleted, and old EBS snapshots expired on a lifecycle policy.
None of these are clever. They add up because nobody had the time, or the mandate, to do them.
The result
Monthly AWS spend went from $40,000 to $12,000 in eight weeks, a 70% reduction. The cost-optimization work paid for itself inside the first week. More durably, the team now runs a monthly FinOps review, so the bill stays a managed number instead of a recurring surprise.
What you can do this week
- Open Cost Explorer and group by service. If the top line item is EC2 or EKS, that is your starting point.
- Check whether your Kubernetes nodes are statically provisioned. If they are, measure real CPU and memory utilization over a week.
- List every Elastic IP, load balancer, and unattached EBS volume. Anything not in use is pure waste.
- Turn on a budget alert today. You cannot manage a number you only see once a month.
Most of the 70% wasn't a clever trick. It was visibility, one structural fix, and a week of disciplined cleanup. That is the good news: the savings are usually already there, waiting for someone to go and get them.