B2B SaaS scaleup cuts AWS run-rate by ~30% while doubling workloads
B2B SaaS · ~180 employees, Series B · DACH (Switzerland / Germany) · First savings in week 3; ~30% run-rate reduction within 4 months
Short answer
A ~180-person B2B SaaS scaleup reduced its AWS run-rate by around 30% in about four months by combining right-sizing, commitment restructuring and per-team cost ownership, while its workload volume roughly doubled over the same period.
~30%
reduction in monthly AWS run-rate
~2x
workload volume over the same period
<10%
forecast error after two quarters
~400h
engineering hours saved per year on manual cost work
The challenge
- Cloud spend was growing about twice as fast as revenue, and nobody could explain the delta month to month.
- Roughly 70% of the invoice was unallocated: no consistent tagging, so no team saw its own cost.
- Commitments had been bought once, eighteen months earlier, and never revisited against actual usage.
- Engineering treated cost reviews as an interruption, so recommendations were raised and then quietly ignored.
What bluebill did
- Built a cost allocation model first — tagging standards enforced in Terraform, so every resource had an owning team within three weeks.
- Ran continuous waste detection across idle compute, oversized instances, unattached storage and forgotten non-production environments.
- Right-sized Kubernetes requests against observed p95 usage instead of defaults, then consolidated node pools.
- Restructured commitments (reserved capacity and savings plans) against the corrected baseline rather than historical peaks.
- Installed a weekly variance ritual: each team sees its own spend, owns its own forecast, and explains its own deltas.
“We had the dashboards before. What we didn't have was anyone who owned the number. That's what changed.”
— VP Engineering, anonymised B2B SaaS scaleup
What changed afterwards
- Cloud cost per customer became a tracked unit-economics metric reported to the board each month.
- Savings held: twelve months later the run-rate was still below the pre-engagement level despite continued growth.
- Finance stopped treating cloud as an unpredictable line item and started planning against it.
Environment: AWS · Kubernetes (EKS) · Datadog · Terraform
Questions this engagement answers
How long before a scaleup sees cloud savings?
In this engagement the first structural savings landed in week three, and the full ~30% run-rate reduction was in place within about four months. Quick wins such as idle resources and oversized instances come first; commitment restructuring and unit economics follow once allocation is trustworthy.
Does cutting cloud cost slow down engineering?
It did not here. Workload volume roughly doubled during the same period. The savings came from waste and mis-sized capacity, not from capping what teams were allowed to run.
Why start with tagging and allocation instead of savings?
Without allocation nobody owns a cost, so recommendations get ignored. Allocation is what turns a one-off cleanup into a run-rate that stays down.
Client names are withheld by agreement. Engagement profiles are anonymised; figures are the measured results of the engagement described and are consistent with bluebill's aggregate programme results. Individual results vary with environment, scale and starting maturity.