Kubernetes Cost Optimization: Cutting Your Cloud Bill Without Cutting Performance

The industry average Kubernetes cluster runs at about 35% CPU and 40% memory utilization. That means more than half of your Kubernetes compute spend is, at any given moment, not doing useful work.

Understanding Where the Waste Is

Resource request overprovisioning: Kubernetes schedules pods based on resource requests (what the pod claims it needs), not actual usage. Teams set high requests to ensure availability; the cluster fills up with reserved but unused capacity. Start by comparing resource requests to actual usage — the p95 CPU and memory usage for each service.

Node over-sizing: Running workloads on large instance types when smaller ones would suffice. Each node has fixed overhead (system pods, kubelet, OS) that represents a higher fraction of a small node’s capacity.

Always-on non-production environments: Dev and staging clusters that run 24/7 but are used 8 hours a day. Implement cluster scale-down on schedules (kube-downscaler, KEDA scheduled scaling) to shut down non-production environments outside working hours.

The Autoscaling Stack

Horizontal Pod Autoscaler (HPA): Scales the number of pod replicas based on CPU/memory metrics. Configure this on all production deployments.

Vertical Pod Autoscaler (VPA): Automatically adjusts resource requests based on actual usage. Run in recommendation mode first before enabling automatic changes.

Karpenter: Developed by AWS, now CNCF — significantly more responsive and cost-effective than the original Cluster Autoscaler, particularly for workloads with variable resource shapes.

Spot/Preemptible Instances

Running stateless workloads on spot instances typically reduces compute costs by 60-80% compared to on-demand pricing. With proper pod disruption budgets and graceful shutdown handling, the interruption risk is manageable.

Why Default Resource Requests Are Almost Always Wrong

Most Kubernetes deployments inherit resource requests from initial guesses made during early development, values that are rarely revisited once a service is in production even as its actual traffic and resource usage patterns evolve significantly. Building automated tooling that continuously compares actual resource consumption against configured requests, flagging significant mismatches for review, catches the gradual drift between configured and actual resource needs that accumulates silently across a growing service fleet over time, preventing the common pattern where a handful of legacy services with wildly oversized resource requests quietly consume a disproportionate share of cluster capacity that newer, more accurately-sized services then compete for.

The Hidden Cost of Inter-Zone and Inter-Region Traffic

Kubernetes cost optimization discussions frequently focus on compute costs while underweighting network transfer costs, which can become substantial in multi-zone or multi-region cluster topologies, particularly for data-intensive workloads with significant inter-service communication. Cloud providers typically charge for traffic crossing availability zone boundaries, and a cluster topology that doesn’t account for this — services communicating heavily across zones without deliberate co-location of frequently-communicating services — can accumulate meaningful unexpected network costs that don’t show up in standard compute cost dashboards but appear as a separate, easily overlooked line item in the broader cloud bill.

Building Cost Visibility Into Developer Workflows

The most effective Kubernetes cost optimization programs make cost visible to the engineers actually making resource allocation decisions, rather than treating cost optimization as a separate platform team responsibility disconnected from day-to-day development work. This means surfacing estimated cost impact directly in pull requests that modify resource requests or replica counts, providing self-service cost dashboards scoped to each team’s own services, and building cost awareness into the same review processes already used for code quality and security, connecting to the broader FinOps cultural practices that the most cost-conscious engineering organizations have adopted across their infrastructure decisions, not just Kubernetes specifically.

---

This article is part of our ongoing coverage of Cloud & DevOps. For related reading, see FinOps in practice and platform engineering.