Posted on Jun 23, 2026 · Updated Jun 23, 2026 · 13 min read
The State of Kubernetes Costs 2026: 70% of Requests Are Waste
Kubernetes now runs production workloads at 96% of organizations that have adopted it (CNCF Annual Survey, 2024) — and almost all of them are overpaying. The median cluster runs at roughly 10% CPU utilization and 23% memory utilization, and 70% of the CPU and memory that teams request is never used (CAST AI, 2025 Kubernetes Cost Benchmark, analyzing 4,000+ clusters). On a $10,000/month cluster bill, that is $6,000–$7,000 paying for capacity that does nothing.
This post is a research asset meant to be cited. Every figure is sourced. Where we have synthesized or extrapolated across reports, we say so. The goal is to give platform engineers, FinOps practitioners, and founders one place to understand the true anatomy of Kubernetes spend, why it is structurally hard to control, and how to benchmark their own cluster against the field.
TL;DR
Kubernetes clusters average 10% CPU utilization and waste 70% of requested resources (CAST AI, 2025). Compute is only 31% of true K8s total cost of ownership — platform engineering salaries, networking, and idle capacity drive the rest. 49% of organizations saw K8s costs spike unexpectedly in the past year (CNCF, 2024). The fix is right-sizing requests, not buying a bigger cluster.
Key finding
CAST AI's 2025 benchmark of 4,000+ clusters found that across all cloud providers, provisioned CPU is utilized at just 10% and provisioned memory at 23%. The gap between what pods request and what they use is the single largest source of Kubernetes waste — and it has barely moved in three consecutive annual reports.
Table of contents
Executive summary
Kubernetes adoption is effectively universal among cloud-native teams — 96% of organizations use or evaluate it (CNCF Annual Survey, 2024) — but cost discipline has not kept pace with adoption. Three patterns define the 2026 picture: chronically low utilization, costs that surprise teams, and a near-total absence of cost accountability at the namespace or team level.
The headline number is utilization. CAST AI's analysis of more than 4,000 clusters puts average CPU utilization at 10% and memory at 23% (2025). That figure aligns with CNCF's own FinOps for Kubernetes survey, which found median CPU utilization in the 10–15% range. When utilization is this low, the cluster is mostly billing you for idle headroom that engineers requested defensively and never reclaimed.
| Metric | Value | Source |
|---|---|---|
| Average cluster CPU utilization | 10% | CAST AI 2025 |
| Average cluster memory utilization | 23% | CAST AI 2025 |
| Requested resources that go unused | 70% | CAST AI 2025 |
| Orgs with unexpected K8s cost spikes (past year) | 49% | CNCF 2024 |
| Orgs that don't monitor K8s spend or use estimates | 68% | CNCF 2024 |
| Orgs practicing K8s chargeback | 14% | CNCF 2024 |
The second pattern is surprise. 49% of organizations reported that Kubernetes costs went up unexpectedly in the prior year (CNCF, 2024). That is not a budgeting failure so much as a visibility failure — 68% of teams either do not monitor Kubernetes spend at all or rely on monthly estimates rather than real allocation data. You cannot control a number you only see after the bill arrives. For the foundational walkthrough, see our guide to understanding your Kubernetes costs.
Where Kubernetes spend actually goes
Raw compute is only 31% of the true total cost of ownership for Kubernetes — the rest is platform engineering labor, networking, storage, and the management overhead the control plane hides (SpendArk analysis, cross-referenced with CNCF 2024). Teams that benchmark only their node bill systematically undercount what Kubernetes really costs them. The instance line item is the part you can see; it is rarely the part that hurts.
The breakdown below synthesizes CNCF's 2024 FinOps for Kubernetes survey, CAST AI's 2025 benchmark, and SpendArk customer account analysis. Where sources disagreed, we used the median. The single most underestimated line is people: the median platform engineer salary sits near $199,000 fully loaded, and most clusters need more than one.
True Kubernetes total cost of ownership by component (% of TCO)
Sources: CNCF FinOps for Kubernetes 2024, CAST AI 2025, SpendArk analysis.
Compute (nodes) — 31% of TCO
Worker nodes are the visible cost: EC2, Azure VMs, or GCE instances running your pods. This is where the 10% utilization problem lives. A node provisioned for a pod that requests 4 vCPUs but uses 0.4 is billing you for 3.6 idle vCPUs around the clock. Right-sizing requests, covered below, is the highest-ROI lever in this category.
Platform engineering — 28% of TCO
Kubernetes is operationally expensive in human terms. Someone has to manage upgrades, CNI plugins, ingress, RBAC, and the long tail of cluster maintenance. At a fully loaded median of roughly $199,000 per platform engineer, two or three engineers can quietly cost more than the entire infrastructure bill for a small-to-mid cluster. This is the cost most node-focused dashboards ignore entirely — the theme of our deeper dive on the hidden cost of Kubernetes.
Networking — 16% of TCO
Load balancers, NAT gateways, cross-AZ pod-to-pod traffic, and egress add up fast in a microservice architecture. Services chatting across availability zones when same-zone routing would suffice is a recurring, invisible drain. A single NAT gateway costs about $32/month before processing a byte, and inter-AZ traffic is billed in both directions.
Storage — 13% of TCO
Persistent volumes, their snapshots, and registry storage accumulate the same way orphaned disks do everywhere else. When a StatefulSet is deleted, its persistent volumes frequently outlive it. Snapshot policies that create but never expire are the usual culprit behind slow storage-cost creep.
Control plane and tooling — 12% of TCO
The managed control plane fee (EKS, GKE Standard) plus observability, security, and cost tooling. Individually small, collectively meaningful — and it is the part teams most often forget to count when they compare Kubernetes against simpler compute options.
The utilization crisis: 10% CPU, 70% wasted requests
The core driver of Kubernetes waste is the gap between requested and used resources: pods reserve capacity through resource requests, the scheduler provisions nodes to satisfy those requests, and 70% of what was reserved is never consumed (CAST AI, 2025). This is structural, not anecdotal — it shows up across thousands of clusters and every major provider.
The mechanism is simple and human. Engineers set requests defensively to avoid OOM kills and CPU throttling. A pod that needs 400MB gets a 2GB request "to be safe." 68% of pods request three to eight times more memory than they actually use (CAST AI, 2025). The scheduler honors the request, not the reality, so nodes fill up with reserved- but-empty capacity long before real load arrives.
Provisioned vs. actually used cluster capacity (% utilized)
Sources: CAST AI 2025 Kubernetes Cost Benchmark, CNCF FinOps for Kubernetes 2024.
The fix is right-sizing requests against observed usage, not buying bigger nodes. Vertical Pod Autoscaler in recommendation mode, Goldilocks for visualization, and Kubernetes 1.33+ in-place pod resize make this safer than it used to be — you can now adjust requests without a disruptive restart. Teams that right-size systematically typically recover 40–60% of node cost. Our full method is in the guide to Kubernetes request sizing.
GPU clusters deserve a special callout. AI and ML teams provision expensive GPU nodes for training and leave them running between experiments. GPU utilization averages around 23%, and a single high-end GPU node left idle over a long weekend can burn thousands of dollars before anyone notices. GPU idle time is now the fastest-growing Kubernetes waste category.
Waste by cluster size and team maturity
Small clusters waste a higher percentage; large clusters waste more dollars — the same inverse pattern that holds for cloud waste generally. A 5-node startup cluster might run at 8% utilization but only cost a few hundred dollars a month wasted. A 500-node platform at 15% utilization wastes six figures annually (SpendArk analysis, cross-referenced with CNCF 2024).
| Cluster scale | Typical spend | Est. waste rate | Annual waste |
|---|---|---|---|
| Small (<10 nodes) | $500–$3K/mo | 50–70% | $3K–$25K |
| Mid (10–50 nodes) | $3K–$25K/mo | 40–60% | $14K–$180K |
| Large (50–500 nodes) | $25K–$250K/mo | 30–50% | $90K–$1.5M |
| Platform (500+ nodes) | $250K+/mo | 22–35% | $660K+ |
Source: SpendArk analysis of customer clusters (anonymized), cross-referenced with CNCF 2024 size-segmented data.
Smaller clusters have higher waste rates for the same structural reasons startups waste more cloud spend overall: tiny teams, no dedicated FinOps function, and a rational bias toward overprovisioning because an outage costs more than idle capacity. Large platforms claw the rate back down with autoscalers, bin-packing, and reserved capacity — but their absolute waste dwarfs anything a startup will see. A 30% waste rate on a $3M/year cluster is $900,000, which funds a whole platform team.
The accountability gap explains why the rate barely improves at any scale. Only 14% of organizations practice Kubernetes chargeback, and just 30% even do showback (CNCF, 2024). Without per-namespace or per-team cost attribution, no engineer feels the cost of their own requests, so defensive overprovisioning never gets challenged. The fix is allocation before optimization — covered in our guide to Kubernetes cost allocation.
Provider economics: EKS vs AKS vs GKE
The managed control plane fee is the smallest part of the bill but the most-debated number: EKS charges $0.10/hour (~$73/month) per cluster, GKE charges $0.10/hour for Standard mode, and AKS gives the control plane away free on its standard tier. For a single cluster the difference is rounding error against node spend — but it shapes how teams architect multi-cluster setups.
Managed control plane cost per cluster ($/month)
Control plane fees only; node, networking, and storage costs are separate and dominate the bill. Sources: AWS, Azure, and Google Cloud pricing pages, 2026.
The control plane fee is a distraction from where providers actually differ: node pricing, load balancer charges, NAT gateway economics, and egress. EKS clusters pay AWS NAT gateway and inter-AZ data transfer that can exceed the control plane fee many times over. GKE Autopilot removes node management entirely but bills per pod resource request — which is great until the 70% over-request problem inflates the very metric you are billed on. AKS's free control plane is genuinely free, but its node and networking costs sit in the same range as the others. The full side-by-side is in our EKS vs AKS vs GKE pricing comparison.
The practical takeaway: choosing a provider on control plane price alone optimizes the smallest variable in the equation. Utilization and networking decide your Kubernetes bill far more than which managed service prints it.
Why Kubernetes costs are so hard to control
Kubernetes cost discipline lags adoption because the platform was designed for resilience and density, not for cost visibility — and the abstractions that make it powerful are the same ones that hide spend. Four structural factors keep waste rates stuck.
1. The request/limit abstraction hides reality
Kubernetes bills you for nodes, but engineers think in pods. The translation layer — resource requests — is set by humans guessing at future load and almost never revisited. The scheduler trusts the request, so a cluster can look "full" at 12% real utilization. Standard cloud billing dashboards see only the node, never the empty space reserved inside it.
2. Shared infrastructure resists attribution
A single node runs pods from many teams. Splitting its cost fairly requires a cost-allocation method — namespace labels, pod-level metering, idle-cost distribution — that most teams never implement. With only 14% practicing chargeback (CNCF, 2024), the cost of a wasteful deployment lands on a central budget nobody owns.
3. Native tooling shows spend, not waste
Cost Explorer and its peers report what a node cost, not whether the pods on it needed that node. Correlating billing data with utilization metrics requires stitching together CloudWatch or Prometheus with billing exports — real engineering work that competes with shipping features. 68% of teams skip it and run on estimates (CNCF, 2024).
4. Autoscaling masks the problem
Cluster Autoscaler and Karpenter add nodes when pods are pending, which feels like efficiency. But they scale to satisfy requests, not usage. Over-requesting pods trigger new nodes that are immediately underutilized, and the autoscaler rarely scales back as aggressively as it scales up. The result is a cluster that grows smoothly and shrinks reluctantly.
How to benchmark your cluster waste
Your real Kubernetes waste rate requires comparing requested resources to actually used resources — node spend alone will not show it. Here is a repeatable method that works on any cluster regardless of provider, in four steps.
Step 1: Pull requested vs. used per workload
From Prometheus (or your metrics provider), comparekube_pod_container_resource_requestsagainst actual usage over a 14-day window. Do this for CPU and memory separately. The ratio of used to requested is your utilization. Below 25% is typical; below 15% is heavy waste.
Step 2: Identify idle and orphaned resources
Flag deployments with zero traffic, completed Jobs that left pods around, persistent volumes not bound to any pod, and load balancers pointing at nothing. These are 100% waste with no performance judgment required — the safest first cut.
Step 3: Quantify the right-sizing gap
For each workload, calculate the request you would set at the 95th-percentile of observed usage plus a safety margin. The difference between current requests and right-sized requests, multiplied by node cost, is your recoverable spend. Apply a confidence discount for spiky workloads that genuinely need headroom.
Step 4: Compute your cluster waste rate
Add idle resource cost (100%) plus the right-sizing gap, then divide by total cluster spend. Compare against the benchmarks below. The CAST AI field average implies most clusters sit well above 50% — if you are under 30%, you are already doing better than most.
Cluster waste benchmarks
- >60%: Severe — no right-sizing in place, likely default requests
- 40–60%: Field average — consistent with CAST AI 2025 median
- 20–40%: Good hygiene — some right-sizing, room to improve
- <20%: Top tier — active VPA/autoscaling and allocation in place
For the full set of remediation tactics ranked by effort and savings, see our Kubernetes cost optimization guide and our roundup of Kubecost alternatives for tooling.
To estimate cluster and node costs before you provision, SpendArk's free cloud cost calculator compares AWS, Azure, and GCP for the same workload, so you can model right-sizing and discount scenarios up front. It's free and needs no account.
Frequently asked questions
Why do Kubernetes clusters run at only 10% CPU utilization?
Because engineers set resource requests defensively. A pod that needs 0.4 vCPU is often requested with 2–4 vCPUs to avoid throttling, and the scheduler provisions nodes to satisfy the request, not the real usage. CAST AI's 2025 benchmark of 4,000+ clusters found 70% of requested CPU and memory goes unused, pinning average CPU utilization near 10%.
How much can right-sizing Kubernetes requests actually save?
Teams that systematically right-size requests against observed usage typically recover 40–60% of node cost (CAST AI, 2025). On a $10,000/month cluster, that is $4,000–$6,000. Vertical Pod Autoscaler in recommendation mode and Kubernetes 1.33+ in-place pod resize make this achievable without disruptive restarts.
Is EKS, AKS, or GKE cheapest for Kubernetes?
On control plane fees, AKS is cheapest (free standard tier) versus $0.10/hour for EKS and GKE Standard. But the control plane is a tiny fraction of the bill — node pricing, networking, NAT gateways, and egress dominate. Utilization decides your real cost far more than provider choice. Most teams should pick on ecosystem fit, then optimize utilization aggressively.
Why do Kubernetes costs spike unexpectedly?
49% of organizations saw unexpected Kubernetes cost increases in the past year (CNCF, 2024), usually because autoscalers add nodes to satisfy over-requested pods, new workloads ship with default requests, or GPU nodes sit idle between jobs. With 68% of teams running on estimates rather than allocation data, the spike is only visible after the bill arrives.
What is a good Kubernetes cost allocation rate?
Aim to attribute at least 80% of cluster spend to a team, namespace, or service. Only 14% of organizations practice chargeback and 30% do showback (CNCF, 2024), so even basic namespace-level allocation puts you ahead of most. Allocation is the prerequisite for optimization — engineers only challenge over-requests when they can see the cost of their own workloads.
Sources
- CAST AI, Kubernetes Cost Benchmark Report 2025 — cast.ai/kubernetes-cost-benchmark
- CNCF, FinOps for Kubernetes Survey 2024 — cncf.io/reports/finops-for-kubernetes-2024
- CNCF, Annual Survey 2024 — cncf.io/reports/cncf-annual-survey-2024
- Flexera, State of the Cloud Report 2025 — flexera.com/blog/cloud/state-of-the-cloud-report
- Harness, State of Cloud Cost Management 2025 — harness.io/resources/state-of-cloud-cost-management
- AWS, Azure, and Google Cloud Kubernetes pricing pages (EKS, AKS, GKE), 2026
- SpendArk customer cluster analysis (anonymized, 2024–2025)
Estimate your cloud costs — for free
Compare AWS, Azure, and GCP pricing side by side with our free calculator, and dig into the guides to learn how to cut cloud waste. No sign-up required.