How do you reduce Kubernetes costs?
You reduce Kubernetes costs by paying less per unit of compute, running fewer idle nodes, and sizing Pod requests to what workloads actually use. Nodes are the largest line item on most Kubernetes bills, so the biggest savings come from cheaper capacity (instance type, architecture, provider, spot) and from packing Pods onto fewer nodes. Network, storage and control plane fees come after that.
Where a Kubernetes bill comes from
Kubernetes itself is free. The bill is the infrastructure underneath it and the fees of a managed service.
| Line item | What drives it |
|---|---|
| Nodes | Number, size and price of the virtual machines or servers. You pay for a whole node whether Pods fill it or not. |
| Storage | Persistent volumes, snapshots and backups. Volumes with a Retain reclaim policy keep billing after their claim is deleted. |
| Network | Traffic between availability zones, NAT gateways, load balancers, public IPv4 addresses and internet egress. |
| Control plane | Managed service fees. Amazon EKS charges USD 0.10 per cluster per hour on a supported Kubernetes version and USD 0.60 per hour on extended support, about USD 73 and USD 438 per month (as of November 2026). |
The fee comparison across providers is in how much managed Kubernetes costs. Staying on a supported version avoids the extended support charge; see the Kubernetes version support lifecycle.
Measure before you cut
Most clusters pay for far more than they use. Datadog’s State of Cloud Costs 2024 found that 83% of container costs went to idle resources: 54% to cluster idle (node capacity no Pod requested) and 29% to workload idle (requests above usage). Cast AI’s 2026 State of Kubernetes Optimization Report, based on 2025 data from tens of thousands of clusters on AWS, Google Cloud and Azure, puts average CPU utilization at 8% and memory at 20%. Both are vendor data, but they point the same way.
Start by splitting your own spend the same way. OpenCost, a CNCF incubating project, combines Pod requests and usage with node prices to show cost per namespace, workload and label, plus the share of each node that nothing uses. Compare three numbers per workload: what it requests, what it uses at the 95th percentile, and what node capacity it leaves stranded.
Cost levers, largest saving first
| Lever | What changes | Who can do it |
|---|---|---|
| Cheaper capacity | Newer or cheaper instance families, ARM instances, a cheaper provider or region, spot instances | Platform team, with app teams for ARM images and spot tolerance |
| Fewer idle nodes | Node autoscaling, bin packing and consolidation, scaling non-production clusters down at night | Platform team alone |
| Right-sized requests | CPU and memory requests set from measured usage | App teams, or automation the platform team runs |
| Network | Same-zone routing, NAT and load balancer layout, endpoints for cloud services | Platform team, with app teams for chatty service pairs |
| Storage | Delete orphaned volumes and old snapshots, pick cheaper storage classes | Platform team |
Cheaper capacity
The price of the same vCPU and GiB varies by instance generation, CPU architecture, region and provider. ARM instances often cost less per vCPU than comparable x86 instances, provided your images are built for arm64. Spot capacity costs up to 90% less than on-demand on AWS in exchange for interruptions; which Kubernetes workloads can run on spot instances covers the mechanics. Choosing between owned hardware and several clouds is a placement decision, covered in how to optimize Kubernetes costs across clouds.
Fewer idle nodes
The scheduler places Pods by their requests, and a node stays billed as long as one Pod runs on it. The default scheduler spreads Pods across nodes, and nothing moves them back together after a scale-down, so nodes stay half empty. Bin packing and consolidation explains how to fix that. Node autoscaling removes empty nodes; how Kubernetes autoscaling works covers the layers.
Right-sized requests
Requests, not usage, decide how many nodes you need. A Pod that requests 2 vCPU and uses 0.2 still blocks 2 vCPU on its node. Kubernetes resource requests and limits explains the mechanics, and rightsizing explains how to measure and adjust them. CPU limits do not lower the bill, which is one reason whether to set CPU limits is a separate question.
Rightsizing only saves money when the freed capacity leads to fewer or smaller nodes. Pair it with node autoscaling or consolidation, or the cluster keeps the same nodes with more empty space.
Network and storage
Multi-zone clusters pay for traffic between zones, and every LoadBalancer Service on a hyperscaler creates its own billed load balancer. Kubernetes network costs lists the line items and the fixes. For storage, look for persistent volumes with no Pod attached, snapshots past their retention period, and premium storage classes on workloads that do not need the IOPS.
Changes a platform team can make alone
Several levers need no change to application deployments: instance and provider choice, node autoscaling, consolidation, network layout, storage cleanup and control plane version upgrades. Rightsizing requests, moving to ARM images and making workloads tolerate spot interruptions touch application manifests or builds, so they need the owning team or automation that changes requests for them. Start with the platform-only levers, because they need no coordination, then use per-team cost reports to make the case for the rest.
How Cloudfleet handles it
Cloudfleet Kubernetes Engine (CFKE) includes node auto-provisioning, which picks the cheapest instance type that satisfies each Pod’s requests and constraints, deletes nodes that are no longer needed and replaces nodes lost to spot preemption. Auto-provisioning profiles control how aggressively it consolidates Pods onto fewer nodes. See Kubernetes cost optimization for an overview.