Your Kubernetes Cluster Is 90% Idle: A Kubernetes Cost Optimization Playbook

The number that should stop every engineering leader mid-scroll comes from Cast AI's 2025 Kubernetes cost benchmark: across the clusters it analysed, average CPU utilisation sat at around 10% and memory at 23%, with the overwhelming majority of clusters overprovisioned relative to what they actually consumed (Cast AI, Cloud Cost Optimization). Flexera's State of the Cloud work has repeatedly put self-reported cloud waste in the region of 27–30%. Put plainly: you are provisioning for a peak that rarely arrives, and paying for the headroom every hour of every day.

The instinct when the bill lands is to reach for a tool — a new autoscaler, a cost dashboard, a rightsizing plugin. That instinct is why the problem persists. The clusters in the Cast AI benchmark were not short of tooling. They were short of a decision-making unit that connects spend to what the business actually ships. Kubernetes cost optimization is a visibility problem before it is an infrastructure problem.

Finding one: idle capacity is a requests-and-limits problem, not a demand problem

The 10% average utilisation figure is not telling you that your workloads are quiet. It is telling you that your requests values — the amount of CPU and memory Kubernetes reserves for each pod — are set far above real consumption. The scheduler packs nodes based on requests, not usage. If every team pads its requests "to be safe", the cluster reserves capacity that no pod ever touches, and the autoscaler dutifully spins up nodes to honour reservations against thin air.

The FinOps Foundation's analysis is consistent with this: a large share of cloud waste traces to lack of visibility rather than genuinely bad architecture. Engineers set conservative requests because they have no feedback loop telling them what a workload really needs.

Action this week: pull actual CPU and memory usage for your top ten workloads by cost over a 14-day window (the Kubernetes metrics API plus Prometheus is enough — you do not need a purchase order). Compare P95 usage against the configured requests. Anywhere requests exceed P95 usage by more than 2x, you have found idle capacity you are paying for. Do not change anything yet — just quantify the gap. Most teams are shocked by the size of it.

Finding two: the metric your FinOps team isn't tracking is cost per unit of work

Total cloud spend is a board-level number that engineers cannot act on. "The bill went up 18%" produces anxiety, not decisions. The metric that produces decisions is spend divided by something the business cares about: cost per request, cost per build, cost per deployment, cost per tenant.

This reframing matters because absolute spend can rise for a perfectly good reason — you served more traffic, ran more CI, onboarded more customers. Unit economics separate healthy growth from waste. A cluster whose total cost rose 18% while cost per request fell 12% is a cluster getting more efficient. Without the denominator, you cannot tell the two apart, and you end up either cutting capacity you need or tolerating waste you don't.

CloudZero's cost-optimization work makes the same argument from the finance side: the organisations that defend their cloud spend to a CFO are the ones that can attribute it down to a unit of business value (CloudZero, Cloud Cost Optimization Strategies).

Action this week: pick one unit metric that maps to how your product makes money and instrument it. For a SaaS API, cost per thousand requests is a good start; for a build-heavy org, cost per CI minute. Tag workloads by team and service so the denominator is attributable. You are not trying to boil the ocean — one well-chosen unit metric, visible on a shared dashboard, changes how engineers reason about the trade-offs they make.

Finding three: the fix has to survive the next sprint

Here is the trap. A weekend of rightsizing can shave 30% off a bill. Three months later the savings have evaporated, because the pressure that created the padding — engineers under deadline choosing safe-but-wasteful defaults — never went away. Optimisation that lives in a one-off audit decays. Optimisation that lives in the CI/CD pipeline and in default manifests persists.

The durable version looks like: sensible request defaults baked into your Helm charts or Kustomize bases; a policy check in the pipeline that flags requests set more than Nx above observed usage; and the unit-cost metric surfaced in the same place engineers already look at deployment health. The goal is to make the efficient choice the path of least resistance, so the next engineer under deadline lands in a good place without thinking about it.

This is where a lot of cost programmes stall, because it requires senior engineers who can move between the cluster, the pipeline, and the application code without needing to be told which layer the problem lives in. A qualified engineering pod approaches this by instrumenting the unit metric first, then rightsizing against evidence, then wiring the guardrails into the delivery flow so the numbers hold after the engagement ends — rather than leaving behind a dashboard nobody owns.

A 90-day shape for the work

What this looks like in practice, rather than as a slide:

• Weeks 1–2: instrument usage and one unit-cost metric; produce the attributable spend picture your FinOps team currently lacks.

• Weeks 3–6: rightsize the top-cost workloads against P95 evidence, validate that latency and error budgets hold, and set defaults in the manifest templates.

• Weeks 7–12: move the guardrails into CI/CD, transfer ownership to the internal team, and leave the unit metric running where engineers already work.

The reason to bound it at a quarter is that cost work has a natural half-life. Beyond a rightsizing exercise, the compounding return comes from the discipline sticking — and discipline sticks when it is embedded in tooling your team already uses, not in a consultant's departing recommendations deck.

Two cautions

First, do not rightsize latency-sensitive workloads on CPU averages alone. Bursty request patterns need burst headroom; the P95 window protects you here, but validate against your error budget before you trim. Aggressive rightsizing that trips your SLOs will cost more in incident response than it ever saved on compute.

Second, resist buying the platform before you understand the shape of your waste. The Cast AI benchmark and the FinOps Foundation data both point at the same conclusion: the dominant cause is missing visibility, and visibility is cheap to establish with tools you likely already run. A commercial autoscaler may earn its place later — but only once you can measure what it is actually saving you in unit terms.

Anystack works as a senior pod delivering into your codebase and infrastructure, offshore from India for UK-first clients, with test-effectiveness measurement and adversarial review built into delivery so changes to production workloads are evidenced against your reliability bar rather than shipped on hope. On platform reliability and cloud cost work, that means instrumenting unit economics, rightsizing against real usage, and leaving the guardrails inside your pipeline — with ownership transferred to your team, not retained as a dependency.