What a FinOps Review Finds: A Worked Example on an $80,000 AWS Bill
By Motti Dadison · October 13, 2026 · 4 min read
A step-by-step example of a FinOps review for a typical 60-engineer SaaS company: what we look at first, the four places the money goes, and how an $80,000 monthly AWS bill can drop by about 35% without downtime.
This is an illustrative example, not a specific client. The company is a composite of the accounts we usually review, and the numbers come from the same model as our cloud cost calculator . Your own results depend on your setup.
Clients often ask us what a FinOps review actually involves, and what it finds. This article follows one typical example from start to finish.
The starting point
The example company:
A B2B SaaS company with about 60 engineers
AWS bill: $80,000 per month , growing faster than revenue
Workloads on EKS, RDS PostgreSQL, S3 and CloudFront
Production, staging and several development environments, all running 24 hours a day
No Savings Plans - everything at on-demand prices
No cost tags, so nobody can say which team or product spends what
This is a very common picture. Nothing is badly broken. The company grew quickly, and cost was nobody's job.
Week 1: make the cost visible
You cannot reduce what you cannot see, so the first week is about visibility:
Turn on the Cost and Usage Report and send it to S3.
Add cost allocation tags for team , environment and service , and enforce them in Terraform.
Build a simple dashboard: cost per team and per environment, compared with last month.
In an account like this one, the first useful result usually appears at once: about 30% of the bill is non-production - development, test and staging environments that nobody uses at night or at the weekend.
Week 2: where the money goes
With the data visible, the savings fall into four groups. The numbers below are monthly estimates for this example.
A realistic range for an account like this is $24,100 to $32,700 per month , or about $340,000 per year .
Weeks 2-3: quick wins
We start with changes that are low risk and easy to undo:
Schedules for non-production. Stop development and staging environments outside working hours. A working week is about 50 of the 168 hours, so this alone removes most of their compute cost.
Storage clean-up. Delete unattached EBS volumes (after a final snapshot), move gp2 volumes to gp3, and set a retention period on every CloudWatch log group.
VPC endpoints for S3 and ECR, so that this traffic stops going through NAT Gateways.
Weeks 3-5: the deeper changes
Rightsizing with real data. After two weeks of metrics, resize instances and RDS databases one step at a time, and watch latency after each change.
Better autoscaling on EKS. Replace fixed node groups with Karpenter, so that nodes match the pods that actually run, and move stateless workloads to Spot.
Graviton where the software supports ARM, for about 20% lower price at the same performance.
Last: commit to what is left
Savings Plans come after the waste is gone. Buying a commitment first would lock the waste in for one or three years. In this example, a 1-year Compute Savings Plan covers about 75% of the new, smaller steady baseline.
Keeping the savings
Savings do not last if nobody owns them. Before the review ends:
AWS Budgets alerts per team
A monthly 30-minute cost review with the team leads
A cost check in the pull request template for infrastructure changes
What the example shows
Visibility comes first. Tags and a per-team view change behaviour more than any single technical fix.
Remove waste before you commit. Otherwise the commitment makes the waste permanent.
Most of the saving needs no new architecture. Schedules, rightsizing and clean-up are configuration changes.
What would this look like for your bill?
Put your own numbers into our cloud cost calculator - it uses the same model as this example. For exact figures, book a free review: we go through your real billing data and send you a list of what to fix first. More about our FinOps service .
Topics: FinOps, AWS, Cost Optimization