Industry surveys consistently find that the majority of provisioned Kubernetes capacity goes unused - teams request far more CPU and memory than their workloads ever consume, and pay for the difference every hour. Cloud cost is now an engineering responsibility, not a finance afterthought. The good news: most of the waste can be removed without touching reliability, if you do it in the right order.
01Start by seeing where the money goes
You cannot optimize what you cannot attribute. Before changing anything, get cost visibility down to the namespace, workload and team level. Tag everything, turn on a cost-allocation tool, and publish the numbers. The simple act of making spend visible to the teams that create it tends to remove a surprising amount of waste on its own.
The biggest single source of waste is the gap between requested and actually-used resources. Measure that gap first - it tells you exactly how much headroom you're paying for and never using.
02The levers, in order of payoff
Apply these roughly in sequence. Right-sizing usually delivers the fastest, safest win; spot and commitment discounts come later, once your workloads are stable and well-understood.
| Lever | What it does | Typical saving | Reliability risk |
|---|---|---|---|
| Right-size requests/limits | Match requests to real usage | 20-40% | Low |
| Horizontal autoscaling (HPA) | Scale pods to demand | 10-30% | Low |
| Cluster autoscaler / Karpenter | Scale nodes to pods | 15-35% | Low-medium |
| Spot / preemptible nodes | Cheap interruptible compute | 50-80% on eligible workloads | Medium |
| Committed-use discounts | Prepay steady baseline | 20-55% | None (financial only) |
| Scale-to-zero (dev/staging) | Idle environments cost nothing | Up to 100% off-hours | None for non-prod |
03Spot without the scares
Spot instances are the biggest discount on the menu and the one teams fear most, because they can be reclaimed at short notice. The trick is to use them where interruption is cheap: stateless services behind a load balancer, batch jobs, and CI runners - never your stateful databases. Spread across instance types and availability zones, set pod disruption budgets, and keep a small on-demand baseline for the workloads that must never blink.
- Good for spot: stateless web tiers, async workers, batch, CI.
- Keep on-demand: databases, stateful singletons, anything with long startup.
- Always set pod disruption budgets and diversify instance types.
04Make it stick with FinOps habits
One-off optimization drifts back within a quarter. What lasts is process: a recurring cost review with the engineering teams, automated alerts on anomalies and idle resources, and cost as a visible metric on the same dashboard as latency and uptime. Treat a runaway bill the way you'd treat a latency regression - as an engineering signal that something changed.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.