Pull the utilization report for your busiest production cluster and brace yourself. Across the industry, average cluster CPU utilization sits near 10–13% of requested capacity — meaning most enterprises pay for roughly eight cores to use one. In practitioner surveys, around 70% name overprovisioning as the single biggest driver of Kubernetes overspend, and organizations without FinOps discipline waste an estimated 32–40% of their cloud bill versus 15–20% for mature teams. This guide walks through where that waste actually hides in 2026 — including the newest failure mode, four autoscalers silently fighting each other in the same cluster — and what AWS, Google Cloud, and Red Hat each give you to fix it.
The waste numbers, quantified
Before touching a single autoscaler, benchmark yourself. These are the thresholds I use when a VP asks whether their Kubernetes spend is normal.
| Wasteful | Typical | Disciplined | |
|---|---|---|---|
| CPU utilization vs. requests | Under 15% | 15–35% | 40–60% |
| Memory utilization vs. requests | Under 25% | 25–50% | 50–70% |
| Cloud spend wasted | 32–40% | 20–30% | 15–20% |
| Spot / preemptible share of eligible workloads | 0% | 10–30% | 50%+ |
The diagnostics are simple. If CPU utilization against requests is below 15%, your problem is requests, not node pricing — no reserved-instance negotiation will save you from an engineer who asked for 4 cores and uses 200 millicores. If you are between 15% and 35%, you have a right-sizing backlog worth real money. Above 40%, shift attention to purchase commitments and workload placement, because the easy waste is gone. And remember that compute is not the whole bill — data transfer stacks on top, which is why we benchmarked cloud egress fees across the big three separately.
Why is overprovisioning so universal? Because the incentives run one way. The engineer who under-requests gets paged at 2 a.m. for OOMKills; the engineer who over-requests gets nothing but a quiet cluster. Requests get copied from a template written three years ago, load-tested never, and inflated after every incident. The takeaway for the meeting: overprovisioning is a management problem wearing a YAML costume. About 70% of practitioners agree it is the top overspend driver, and it will not fix itself.
The 2026 failure mode: four autoscalers fighting each other
The new waste pattern I see in 2026 audits is not missing automation — it is too much of it. A mature cluster now commonly runs four scaling systems at once: Cluster Autoscaler or Karpenter managing nodes, the Horizontal Pod Autoscaler scaling replica counts, and the Vertical Pod Autoscaler adjusting requests. Each is fine alone. Together, unconfigured, they fight.
The classic loop: VPA raises a deployment’s CPU request, HPA — which scales on CPU utilization relative to that same request — suddenly sees utilization drop and scales replicas down, latency climbs, HPA scales back up, and the node autoscaler churns instances underneath the whole argument. Every cycle provisions capacity someone pays for. The symptoms are node counts that oscillate hourly without traffic changes, and consolidation that never converges.
- Never point HPA and VPA at the same metric on the same workload — use VPA for request correction on steady services, HPA for genuinely elastic ones.
- If you run Karpenter alongside a legacy Cluster Autoscaler node group, fence them to disjoint workloads or one will strand the other’s capacity.
- Set consolidation policies deliberately — aggressive consolidation plus slow pod disruption budgets equals thrash.
AWS: Karpenter and EKS Auto Mode
Karpenter remains the strongest single cost lever on AWS. Instead of scaling fixed node groups, it provisions exactly the instances pending pods need, picks from the full EC2 catalog including Spot, and actively consolidates — repacking workloads onto fewer, cheaper nodes and terminating the rest. Since the v1 API (NodePool and EC2NodeClass replaced the old Provisioner objects), configuration is cleaner, and AWS has kept shipping meaningful speed improvements to scale-out and consolidation through 2025–26. Teams moving from Cluster Autoscaler to a well-tuned Karpenter setup routinely report double-digit percentage compute savings; the flexible-instance Spot story is where most of it comes from.
EKS Auto Mode, introduced in late 2024, runs Karpenter as a managed component — AWS operates the controller, patches it, and handles node lifecycle. That is genuinely useful for teams that do not want to own autoscaler operations, and as of mid-2026 it has matured steadily, adding observability into scheduling decisions and zonal-failure handling. The honest downside: Auto Mode carries a management premium on top of EC2 pricing, and you give up some low-level tuning. If you have platform engineers who know Karpenter, self-managed is cheaper. If you do not, Auto Mode’s premium is usually smaller than the waste it removes. Where EKS sits against the other platforms overall is a bigger question — see our OpenShift vs. EKS vs. GKE comparison for that verdict.
Google Cloud: Autopilot changes the unit of waste
Google Cloud’s GKE Autopilot takes a different position: stop billing for nodes at all. You pay per pod for the CPU, memory, and ephemeral storage your pods request, in one-second increments, plus a cluster management fee of roughly $0.10 per hour — list pricing varies by region. That eliminates two entire waste categories, unused node headroom and bin-packing loss, because Google absorbs them.
But notice what it does not eliminate: request inflation. Under Autopilot you pay for exactly what you request, so a service requesting 4 cores and using 200 millicores wastes money at 100% efficiency of billing. Autopilot converts the overprovisioning problem from an infrastructure problem into a pure right-sizing problem — which is progress, because right-sizing is measurable per team. Google’s per-vCPU Autopilot rates carry a premium over equivalent raw Compute Engine capacity, so well-utilized Standard-mode clusters (above roughly 50–60% utilization) often beat Autopilot on price. Below that, Autopilot usually wins. Spot Pods at up to around 60% off and flexible committed-use discounts sweeten it further for fault-tolerant and steady workloads respectively.
Red Hat OpenShift: right-sizing inside the platform
Red Hat’s angle is different again: OpenShift customers already pay for the platform, so cost tooling ships as part of the subscription rather than as a separate product. Red Hat Insights cost management aggregates spend across OpenShift clusters — on-prem and cloud — and its resource optimization service generates per-container right-sizing recommendations from observed usage. For enterprises running OpenShift on-prem or hybrid, that visibility matters more than any autoscaler, because on-prem waste hides in hardware refresh cycles instead of a monthly bill.
The strengths: one cost view across hybrid estates, tight integration with cluster and machine autoscaling on supported clouds, and recommendations that account for OpenShift’s own overhead. The weaknesses are equally real — OpenShift subscription costs are themselves a significant line item, typically priced per core, so the platform raises your baseline even as its tooling trims usage. Red Hat fits organizations that have already committed to OpenShift for other reasons; nobody should buy it as a cost-optimization play. If that describes your shop, turning on cost management is free money you are currently leaving on the table.
GPU workloads break bin-packing
Every assumption above degrades when GPUs enter the cluster. Autoscalers optimize by treating CPU and memory as divisible commodities; GPUs are lumpy, expensive, and — without extra work — allocated whole. A pod that needs 20% of an accelerator strands the other 80%, and at current accelerator prices that stranded slice can cost more than an entire CPU node. Consolidation logic makes it worse: repacking a GPU workload means minutes of model reload, so disruption budgets block the very moves that save money elsewhere.
The mitigations exist but require deliberate setup: fractional GPU sharing (time-slicing or MIG partitioning on supported NVIDIA hardware), separate node pools with their own scaling policies, and queue-based scheduling for batch inference and training. All three vendors are investing here — AWS via Karpenter GPU-aware provisioning, Google Cloud via Autopilot accelerator classes, Red Hat via OpenShift AI scheduling — but as of mid-2026 none of them makes fractional GPU economics automatic. Budget engineering time or budget stranded silicon.
What to do about it
Sequence matters. Right-size first, then automate, then commit — commitments made against inflated baselines lock waste in for one to three years.
- Weeks 1–2: measure utilization against requests per namespace. Publish the league table internally. Shame is an underrated FinOps tool.
- Month 1: right-size the top 20 offenders using VPA recommendations (recommendation mode, not auto mode, on HPA-scaled services).
- Month 2: deploy or tune the node layer — Karpenter or Auto Mode on EKS, Autopilot evaluation on GKE, cost management plus autoscaling on OpenShift. Audit autoscaler interactions explicitly.
- Month 3: move fault-tolerant workloads to Spot or Spot Pods, then buy commitments against the now-honest baseline.
The takeaway for the meeting: a typical enterprise cluster runs near 10–13% CPU utilization, and getting to 40% is not heroic — it is three months of unglamorous work that usually returns 25–35% of the Kubernetes bill.
Frequently asked questions
How do I reduce Kubernetes costs quickly?
Right-size resource requests first — that is where 70% of practitioners say the waste lives. Then enable node consolidation (Karpenter on AWS, Autopilot on GKE), move fault-tolerant workloads to Spot capacity, and only then buy committed-use discounts against the corrected baseline.
Is Karpenter better than Cluster Autoscaler for cost savings?
For most AWS workloads, yes. Karpenter’s instance-flexible provisioning, Spot integration, and active consolidation typically beat fixed node groups by a double-digit percentage. Cluster Autoscaler remains reasonable for small, stable clusters where churn is rare.
Is GKE Autopilot cheaper than Standard mode?
It depends on your utilization. Autopilot’s per-pod rates carry a premium over raw node capacity, so a Standard cluster running above roughly 50–60% utilization is usually cheaper. Below that — which is most clusters — Autopilot tends to win because you stop paying for idle headroom.
What is a good CPU utilization target for Kubernetes?
Aim for 40–60% of requested CPU actually used, measured over a week. Higher invites throttling and noisy-neighbor incidents; lower means you are funding idle cores. Memory targets run higher, around 50–70%, because memory exhaustion fails harder than CPU contention.
Do I need a FinOps team to control Kubernetes spend?
You need FinOps practices more than a FinOps org chart. The data is blunt: organizations with no cost discipline waste 32–40% of cloud spend versus 15–20% for mature teams. One engineer with showback dashboards and executive backing captures most of that gap.
Enterprise Techie publishes vendor-honest analysis like this daily — get the brief by email, free.