Kubernetes Cost Optimization Checklist

A Kubernetes bill is opaque in a specific way a plain EC2 bill isn’t: it tells you the total cost of the nodes running your cluster, but not which of the dozens or hundreds of pods scheduled across them are actually using the resources they’ve been allocated. That gap is where Kubernetes cost waste tends to accumulate — quietly, and without anyone making an obviously bad decision.

Where the Waste Actually Hides

Over-requested resources are the single most common source. When a pod’s CPU and memory requests are set generously “to be safe” during initial deployment — which is a completely reasonable instinct under deadline pressure — the cluster reserves that capacity for the pod whether it’s actually consumed or not. A pod requesting 2 CPU cores and using 200m of it isn’t just wasting its own allocation; it’s often forcing the cluster to run additional nodes to accommodate reservations that will never be used.

Static replica counts with no autoscaling compound the problem in the other direction — a deployment sized for peak traffic and left there permanently, rather than scaling down during the long stretches of lower demand most workloads actually experience.

Node pools sized for peak load and never revisited are the infrastructure-level version of the same issue: a cluster autoscaler that isn’t configured, or is configured too conservatively, means paying for peak-capacity nodes around the clock instead of only when peak load actually occurs.

Orphaned persistent volumes are a quieter but real cost — storage left behind by decommissioned workloads, still billing monthly, with no running pod referencing it and no alert flagging that fact.

The Checklist

A structured pass through a cluster’s cost profile should cover:

• Resource request accuracy — compare actual usage (via metrics) against configured requests and limits for every workload, and right-size the gap. This is the highest-leverage single item on this list for most clusters.
• Horizontal Pod Autoscaler (HPA) coverage — confirm workloads with variable load actually scale replica count with demand, rather than running a static count sized for the worst case.
• Vertical Pod Autoscaler (VPA) where appropriate — for workloads where request sizing itself should adapt over time based on observed usage, not just replica count.
• Node pool and cluster autoscaler configuration — verify the cluster can actually scale node count down during low-demand periods, not just up during spikes.
• Orphaned resource cleanup — persistent volumes, load balancers, and other resources left behind by decommissioned workloads that continue billing with nothing depending on them.
• Spot/preemptible instance usage for fault-tolerant, interruption-safe workloads, where the cost difference against on-demand nodes is substantial.

Why This Requires Real Visibility, Not Just a Checklist

Every item above depends on having actual observability into what a cluster is doing — which is why cost optimization and cluster health work tend to go together rather than being separate projects. A cluster with no Prometheus/Grafana observability stack deployed has no reliable way to know whether a given resource request is accurate, because there’s no data on actual consumption to compare it against. The same audit process that reveals security gaps — CIS Kubernetes Benchmark review, RBAC and network policy assessment — is also what surfaces the utilization data cost optimization depends on.

What This Looked Like in Practice

An e-commerce platform running 80 production pods on EKS had gone 18 months without a cluster upgrade — two major versions behind — with no network policies restricting pod-to-pod traffic and no pod security standards enforced. While the primary engagement was security hardening (CIS Benchmark controls, a phased upgrade from 1.24 to 1.30 completed without downtime, network policy enforcement), deploying Prometheus and Grafana as part of that same work gave the team, for the first time, real visibility into resource utilization across the cluster — the same visibility that makes accurate right-sizing possible going forward, rather than guesswork.

Getting Started

If pod resource requests have never been compared against actual usage data, or the cluster autoscaler’s minimum node count hasn’t been revisited since it was first configured, there’s very likely real savings available without touching application code at all. Kubernetes support and operations covers resource optimization as a standard part of ongoing cluster management, not a separate initiative.