"Our cloud bill keeps climbing, but our user growth doesn't justify it."
We've heard this more than once. Every time, the founder says it with the same mix of frustration and confusion — like they've done something wrong but can't figure out what.
They usually haven't done anything wrong. They've just done what every fast-moving SaaS team does: built quickly, shipped constantly, and let the infrastructure figure itself out. The problem is that cloud infrastructure doesn't figure itself out. It accumulates. Quietly. Expensively.
This is the story of how our engineering team at MicrocosmWorks helped one such team cut their cloud costs by 40% — not by switching providers or downgrading their product, but by looking honestly at what their infrastructure was actually doing versus what they were paying for it to do.
The Setup: A Product Doing Well. An Infrastructure Bill Doing Better.
The client was a growing SaaS platform. Revenue was up, users were happy, the team was shipping at a solid pace. But the cloud bill had developed a mind of its own — climbing month after month, faster than the user base, faster than revenue, faster than any reasonable explanation could account for.
The team had done the right things early: prioritised reliability, moved fast, kept deployment frequency high. But several product iterations later, the infrastructure had evolved the way most SaaS infrastructure does — organically, not strategically. When we came in, here's what the audit found.
The Audit: Five Problems Hidden in Plain Sight
Overprovisioned compute running well below capacity. Instances sized for anticipated growth that hadn't arrived, billing at full rate around the clock.
Idle development and staging environments permanently online. Every environment spun up for a feature build or QA cycle was still running — never explicitly shut down, never explicitly kept.
Storage growing without any cleanup routine. Outdated backups, old container images, temporary build artefacts, volumes attached to instances that no longer existed.
Scaling policies that added resources fast and removed them slowly. Technically auto-scaling, but built around caution rather than data. Infrastructure stayed expanded long after traffic normalised.
No visibility into which services were driving costs. Without proper tagging, the billing dashboard showed a number — not a story. Nobody could say with confidence which part of the infrastructure owned which slice of the bill.
None of these were disasters in isolation. Together, they were quietly consuming budget that could have been funding product development.
The Fix: Five Levers, Eight Weeks
Rightsizing Instances Against Real Usage Data
Before touching anything, we pulled two weeks of actual utilisation data — CPU, memory, network. Infrastructure decisions made from assumptions are almost always wrong. Decisions made from CloudWatch data are almost always right.
Several core services were provisioned two to three sizes larger than their workload required. We downsized in staging first, ran load tests, then rolled to production in batches. Compute costs dropped immediately. Performance metrics didn't move.
Making Auto Scaling Actually Scale Down
The client's scaling policies added resources quickly under load and removed them slowly afterward — essentially slow overprovisioning with extra steps. We rebuilt the policies around actual workload metrics rather than static CPU thresholds. Infrastructure now expanded when traffic demanded it and contracted when it didn't. Costs dropped and operational overhead along with them.
Cleaning Up What Nobody Was Using
The audit surfaced outdated database backups, old container images, EBS volumes attached to nothing, and development environments not accessed in over 60 days. We cleaned house, then implemented automated cleanup schedules and a tagging policy: every resource gets an owner, environment, and review date. Untagged resources trigger an alert. A simple habit that prevents the problem from rebuilding itself over the next twelve months.
Streamlining Deployment Pipelines
Long-running build pipelines and redundant environments consume cloud resources invisibly. We consolidated overlapping environments and streamlined the deployment automation. Builds got faster, CI/CD infrastructure usage dropped, and the engineering team got back time that had been absorbed by slow release cycles.
Switching Stable Workloads to Reserved Pricing
For workloads running at consistent, predictable load for months — production database, core API services, background processors — we moved from on-demand to reserved instances and AWS Savings Plans. Reserved capacity typically reduces compute costs by 30–40% with no performance trade-off. The only requirement is committing to a usage level you're already running at anyway.
The Numbers
Eight weeks after starting the engagement, the results were measurable across every dimension we'd targeted:
- 40% reduction in total infrastructure costs
- Faster deployment cycles from streamlined pipelines
- Improved scalability behaviour during traffic spikes
- Clear cost attribution by service and environment for the first time
- A cleanup and governance framework that would prevent costs from creeping back
The engineering team didn't lose any capabilities. Users didn't notice any changes. What changed was the relationship between what the infrastructure was doing and what it was costing.
The Bigger Lesson
Cloud cost overruns almost never happen because of one catastrophically bad decision. They happen because a series of small, individually reasonable decisions compound over time without anyone reviewing whether they still make sense.
Overprovisioning for anticipated growth that didn't arrive. Leaving an environment running because deleting it felt risky. Skipping the storage cleanup because there were more urgent things to ship. Each decision was defensible in isolation. Together, across twelve months of billing, they added up to 40% more than necessary.
The fix followed the same logic in reverse: targeted improvements, each individually modest, that together produced a significant reduction. No dramatic re-architecture. No feature trade-offs. Just a clear-eyed look at what the infrastructure was actually doing, and the discipline to align it with what the product actually needed.
What Your Team Can Do This Week
Start with visibility before you start with action. Pull utilisation data for your most expensive instances. Tag everything that isn't tagged. Map your non-production environments and ask which ones are genuinely active.
That audit will tell you most of what you need to know. The savings usually follow quickly after.
If you'd rather have a team with hands-on experience in cloud infrastructure and SaaS application optimisation run the engagement end-to-end, get in touch with us — we'll tell you honestly what's recoverable and what it will take.
MicrocosmWorks is an AI and cloud development agency helping startups and enterprises build, ship, and optimise production-grade infrastructure.
Top comments (0)