HomeFind your caseOur cloud bill grows faster than our usage
Case · Enterprise
A common situation · not a client storyOur cloud bill grows faster than our usage.
Teams on AWS, Google Cloud or Azure, often running Kubernetes, whose monthly bill keeps climbing while nobody can say which line would move it.
What you're probably seeing
If this sounds familiar, you're in the right place.
- The bill climbs every month, but traffic and customers don't climb as fast.
- Nodes sit half empty, because workloads request far more CPU and memory than they use.
- Old cluster versions have slipped past standard support, and extended-support fees appear on the bill.
- Traffic between availability zones and through NAT gateways shows up as surprisingly large lines.
- Commitments (Savings Plans, reserved instances, committed-use discounts) cover the wrong things, or renew without anyone checking.
- Leftovers keep billing: unattached volumes, old snapshots, idle load balancers, forgotten test environments.
The usual ways out
What teams usually try. Each works somewhere. None works everywhere.
| The way | Works when | The catch |
|---|---|---|
| Buy more commitments | Usage is steady and well understood | Locks in today's waste for one to three years |
| Right-size requests and limits | Requests sit far above real usage | Needs usage data per workload, and a way to stop it drifting back |
| An autoscaler like Karpenter, with Spot capacity | Workloads tolerate interruption and node types are flexible | Without disruption budgets and fallbacks, Spot interruptions reach your users |
| Consolidate clusters | Many small clusters with low use | Changes the blast radius and team boundaries |
| Re-platform the one heavy component | One line dominates the bill, such as analytics | A migration project, with its own risks |
| Move to colocation or bare metal | Load is large, steady and predictable | Egress, hiring and operations. Only if the numbers say so |
What other companies did. Their published results, not ours.
We read each company's own write-up and asked one question: would our diagnostic's tests have led to the same call? We judge the approach, not the result.
| Company | What they did | What they published | Source |
|---|---|---|---|
| GrabSoutheast Asian superapp. Its shared Kafka platform runs on AWS in one region across three availability zones. Cross-AZ traffic was about half of the Kafka platform's cost. | Upgraded Kafka to 3.1 and turned on rack awareness, with one rack per AZ. Changed their Go SDK, Flink pipelines and Kafka Connect so consumers read from the closest replica instead of the partition leader. | After about three months, cross-AZ traffic was 25% below the December average, with consumption volume roughly stable. No dollar figure stated.They noted: End-to-end latency rose by up to 500 ms, so the most latency-sensitive cases stayed on leader reads. Broker load now follows where consumers sit. That skewed CPU across brokers, and brokers in quieter AZs could not safely be removed. | Zero traffic cost for Kafka consumersJul 2023 |
| AutoScout24Pan-European online car marketplace with 170+ engineers. Its Kubernetes cluster on AWS EC2 used cluster-autoscaler before the change. | Moved the cluster from cluster-autoscaler to Karpenter so pods are packed onto fewer nodes. The post does not mention Spot or right-sizing requests. | After more than three months, the cluster's EC2 costs were down almost 50%, against a goal of about 15%. The node count fell by a similar share.They noted: Consolidation caused frequent pod evictions, which hurt slow-starting apps. They added NodePool disruption budgets (one node at a time) and longer health-check delays. Karpenter's per-node tag created many Datadog custom metrics and raised monitoring cost. | Boosting Kubernetes Efficiency with Karpenter: 3-Month Performance InsightsSep 2024 |
| DatadogInternal platform team serving 1,800+ services and 20,000+ Kubernetes deployments. CPU and memory sizes had been set by hand. | Replaced hand-set requests and per-service autoscaler configs with Datadog's own autoscaler. It sets both replica counts and CPU/memory requests from observed usage, with conservative policies against short spikes. | More than 50% cost reduction in an initial rollout in one smaller data centre (no timeframe given). More than $3 million in annualised idle compute removed company-wide. About 30,000 deployments now use it.They noted: Some pods were pinned at 100% CPU because their requests were too low. Raising those requests increased cost for those services. VPA could not run alongside their existing autoscaler. | How we saved over $3 million in idle compute costs with Datadog Kubernetes AutoscalingJun 2026 |
| 37signalsMaker of Basecamp and HEY. Reported cloud charges of $3,201,564 'a couple of years' before the article, a large chunk of it on AWS. The period is not stated. | Bought about $700,000 of Dell servers that fit existing rack space and power. Moved seven apps, including HEY, off AWS in summer 2023. Left about 10 PB of S3 storage on a four-year contract, to move later. | Almost $2 million saved in 2024, the first full year. The remaining cloud bill is about $1.3 million, all S3. The CTO projects well over $10 million saved over five years from the 'combined cloud exit'. These are company claims, not independently verified.They noted: Savings only began as cloud contract commitments expired through the end of 2023. The CTO says the comparison is never apples-to-apples, and the hardware fit racks and power they already had. Team size did not change. | Developer pockets $2M in savings from going cloud-freeOct 2024 |
Our read
Same call. Each company found one large cost driver and picked the lever that fits it, which is what our tests aim at.
Grab measured that cross-AZ traffic was about half its Kafka cost before it changed how consumers fetch. 37signals moved its compute off AWS, but savings only began as its cloud commitments expired, and it left S3 on contract to move later, which matches our test of commitment coverage and renewal dates. AutoScout24 and Datadog went after node and request waste with autoscaling. We would still check requested versus used per workload, because Datadog found starved pods as well as idle ones, and AutoScout24 needed disruption budgets once evictions hit slow-starting apps.
What we would test first: List your ten largest cost lines and what drives each one.
What the diagnostic would test
The tests that rule the wrong ways out.
On your own systems and data, read-only first. The number of tests sets the diagnostic's price, quoted before it starts.
- 1
Your ten largest cost lines, and what drives each one.
- 2
Requested versus used CPU and memory, per workload, over a few weeks.
- 3
Every cluster with its version and support dates.
- 4
Traffic between zones and through NAT gateways.
- 5
Commitment coverage, and the date of the next renewal.
- 6
Leftovers: resources that nothing uses.
This week, without us
Three things you can do yourself.
- 1
Export the last three months of the bill grouped by service and usage type, and sort it by cost.
- 2
List every cluster's version next to your provider's support calendar.
- 3
Find the date of your next commitment renewal and put it in a calendar.
Sound like you? Bring it to a 30-minute call. We'll tell you which tests your case needs, and what they cost.
This page describes what teams in this situation commonly face. It is not a client story.