Cutting a SaaS startup's AWS bill by 41% with no downtime
An early-stage SaaS company watched its cloud bill grow for eight months while traffic stayed flat. A two-week audit found oversized databases and idle staging environments nobody was using.
- Client
- An early-stage B2B SaaS company
- Industry
- Software, 11 staff
- Engagement
- 2-week audit, then 4 weeks of changes
- Published
Note.Client name is anonymized and figures are illustrative until publication is approved.
- 41%
- Monthly AWS bill reduction, from $18,400
- 9%
- Share of spend on non-production, from 27%
- 0
- Production incidents during the change window
Business context
An early-stage B2B SaaS company with 11 staff had built its product on AWS. The engineering team of four moved fast and shipped often, which was the right call early on.
By early 2025, the monthly cloud bill had grown for eight months in a row while traffic stayed flat. The founders could see the number but not what caused it. They asked us for an AWS cost optimization review before the next funding conversation.
The problem
The bill had climbed from $7,400 to $18,400 a month. No single line explained it. The database had been sized for a launch spike that never happened. Three staging environments ran all weekend, every weekend, even when nobody was testing. Application logs were kept forever because the default was set to never expire. No cost alerts existed, so a bad deploy could run unchecked for a week.
The team was busy, and cost work had no owner. Every engineer assumed someone else would deal with it.
The founders had tried a tagging exercise themselves, but without a baseline it produced more questions than answers. They needed someone to read the bill and name the cause.
What we built
The first two weeks were an audit, and nothing changed on the infrastructure. We read the billing file line by line and grouped spend by service, environment, and owner. That gave a short list of changes, each with an estimated saving and a risk note.
Next we right-sized the database and the largest application instances, using two weeks of real utilization data. We scheduled non-production environments to shut down outside working hours. We set log retention to 30 days for application logs and 90 days for audit logs. We added a cost alert for each service so a surprise would arrive within a day.
Every change went into Terraform, so it stays in place and can be reviewed. We made the changes in small steps and watched for problems after each one.
We also removed two idle snapshots and an unused network gateway left over after a migration. None of them carried customer traffic.
Rollout
- Weeks 1 to 2: Billing audit, with no changes to the running systems.
- Week 3: Right-sized the database and the largest application instances.
- Week 4: Scheduled staging shutdowns and set log retention.
- Weeks 5 to 6: Put every change into Terraform and added per-service cost alerts.
Before and after
| Area | Before | After |
|---|---|---|
| Monthly bill | $18,400 | $10,800 |
| Database size | Sized for a launch spike | Sized to two weeks of real use |
| Staging use | Always on | Off outside working hours |
| Log retention | Forever | 30 days, 90 days for audit |
| Cost alerts | None | One per service |
Results
The monthly bill fell from $18,400 to $10,800, a 41% reduction with no change to what customers experienced. Non-production spend, which was 27% of the total, dropped to about 9%.
There were zero incidents in production during the change window. The database resize was the riskiest step, and the utilization data made it a routine change rather than a guess. The cost alerts have since caught two quiet expenses: an unused load balancer and a data transfer pattern from one new feature.
We also left a monthly routine behind: one engineer reviews the savings list and the alerts for about 20 minutes at the start of each month. The savings were larger than the audit predicted, because the staging shutdowns removed spend the team had never counted as avoidable.
Managing a bill this way overlaps with the discipline behind our CI/CD pipeline build for a small team, where small reviewed changes replaced one risky manual step. We used the same approach here through our cloud optimization work.
Lessons learned
- Most of the saving came from things nobody was using, not from clever architecture. The database and the idle environments were the story.
- The team assumed the bill was caused by traffic. It was caused by defaults nobody had revisited.
- Our first rehearsal of the database resize failed and took the staging environment down. Fixing the runbook there is the only reason the production change ran smoothly.
- Cost work needs an owner. We left written notes on what to check each month so the saving does not drift back.