Guides · Guide · 9 min read · Jul 9, 2026

Kubernetes Cost Optimization Checklist: 24 Checks That Cut Your Bill

This is the checklist we run against every cluster we audit — 24 checks across six areas, each with the one-line reason it matters and how to do it. Work it top to bottom: the areas are ordered by typical savings, so right-sizing comes first and commitment discounts come last. For the full reasoning behind each item, see the complete Kubernetes cost optimization playbook; this page is the version you can actually work through in a week.

Right-sizing (biggest savings, do first)

  1. Measure the requests-versus-usage gap — node count tracks requests, not usage, so this gap is your waste baseline. Compare Prometheus usage history against requests per pod, or install OpenCost and read it off a dashboard.
  2. Run VPA in recommendation-only mode — it does the statistics for you without evicting anything. Deploy with updateMode: "Off" on your largest deployments and read the recommendations after a week of real traffic.
  3. Set CPU requests near p95 usage, memory at p99 plus headroom — CPU over-runs throttle (survivable); memory over-runs OOMKill (a crash loop). Be aggressive on CPU, careful on memory.
  4. Give every container a memory limit; skip or relax CPU limits — memory limits make failure predictable; tight CPU limits cause invisible throttling latency for no cost benefit on most workloads.
  5. Roll out right-sizing one service at a time — watch OOMKill and throttle metrics for a few days per service — a crash loop erases the credibility of the whole effort.

Autoscaling

  1. Enable HPA on every scalable service — on a metric that moves — an HPA scaling on flat CPU is decoration. Use request rate, queue depth or latency via custom metrics for services where CPU is not the real signal.
  2. Run a consolidating node autoscaler — scaling out without consolidation only grows the fleet. Karpenter (AWS) actively replaces several underutilized nodes with one right-sized one; enable its consolidation policy.
  3. Scale event-driven workers to zero with KEDA — a consumer on an empty queue should be zero pods, not three idle replicas. KEDA scales on SQS, Kafka lag, RabbitMQ and Redis natively.
  4. Set PodDisruptionBudgets before enabling consolidation or Spot — PDBs make node churn safe by guaranteeing minimum available replicas during drains — without them you will trade cost for outages.

Compute pricing

  1. Move fault-tolerant workloads to Spot / preemptible capacity — 60–90% cheaper than on-demand. Start with CI runners, queue workers and batch; keep a small on-demand baseline for critical services.
  2. Diversify Spot across instance types and zones — one dried-up Spot pool should not take out your capacity; Karpenter and managed node groups both support wide diversification natively.
  3. Evaluate ARM (Graviton and equivalents) — typically ~20–40% better price-performance; most runtimes ship multi-arch images, so the cost is usually a --platform linux/arm64 rebuild plus testing.
  4. Prefer fewer, larger nodes — every node pays fixed overhead (kubelet, system daemons, OS reserve) and small nodes fragment; the same capacity in bigger nodes packs more pods.
  5. Buy commitments only after right-sizing — Savings Plans / RIs / CUDs lock in your current shape — commit to the post-optimization baseline, not the pre-cleanup waste.

Storage and network

  1. Delete orphaned PersistentVolumes — deleting a Deployment does not delete its PVCs; sweep for Released and unbound volumes — they bill until removed.
  2. Migrate AWS gp2 volumes to gp3 — ~20% cheaper for equal or better baseline performance; a pure win most clusters still have not taken.
  3. Remove idle load balancers — a forgotten Service: LoadBalancer keeps a cloud LB billing hourly forever; list services with no healthy backends and delete them.
  4. Enable topology-aware routing for chatty services — cross-zone traffic is billed on most clouds; same-zone routing cuts that toll where the availability trade-off is acceptable.
  5. Cap log and metric retention — debug logs shipped to a managed service and high-cardinality metrics nobody queries can out-cost the workloads; set retention and drop noisy labels deliberately.

Housekeeping

  1. Scale non-production to zero out of hours — nights and weekends are ~70% of the week; a CronJob that scales dev/staging to zero cuts those environments' compute by more than half with zero user impact.
  2. Audit namespaces by traffic and delete the dead ones — last quarter's proof-of-concept and the departed teammate's test env bill forever until someone looks.
  3. Clean old images and snapshots — registries and snapshot stores grow monotonically; set lifecycle policies so they cannot.

Governance (keeps it from coming back)

  1. Enforce ResourceQuota and LimitRange per namespace — quotas turn "requests are free" into a per-team budget; LimitRanges give unspecified containers sane defaults and cap the "16 CPU to be safe" reflex.
  2. Put cost per namespace on team dashboards with a spend-jump alert — every optimization above decays without feedback — teams that see their own spend keep it down; teams that do not re-inflate within a quarter.

How to run this without boiling the ocean

Do not assign all 24 items at once. The pattern that works: spend day one on measurement only — items 1, 15, 17 and 21 are pure discovery and produce a ranked list of waste with dollar figures attached. Take the top five findings to a single owner with a two-week window. Most teams land 30%+ savings from items 1–9 alone, and the rest of the list compounds from there. Item 24 is the one that decides whether you are still saving money in six months: every check above it is a cleanup, and cleanups regress unless a dashboard is watching. Measure the bill before you start, screenshot it, and compare after 30 days — the before/after is also how you get budget for the deeper work.

Score yourself before you start

Run your numbers through the free calculator to see roughly how much this checklist is worth for your cluster — or have us run the audit and hand you the checklist pre-filled with your actual findings.

Estimate your waste →Get a free audit →

Frequently asked questions

How do I audit Kubernetes costs?

Start by measuring the gap between requested and used resources: install OpenCost or Kubecost for cost allocation per namespace, and query Prometheus for requests minus actual usage per pod. Rank workloads by that gap, then sweep for orphaned volumes, idle load balancers and namespaces with no traffic. The ranked gap list plus the orphan sweep is 90% of a cost audit.

How often should I review Kubernetes costs?

Monthly for the workload review (top ten over-requested pods — about an hour), weekly for automated spend-jump alerts per namespace, and quarterly for the bigger levers: commitment coverage, instance family choices and non-production environment sprawl. Anything less frequent and the requests-versus-usage gap quietly reopens.

What single change saves the most on Kubernetes?

Right-sizing resource requests. Engineers typically set CPU and memory requests 2–5× above real usage, and node count tracks requests, not usage — so closing that gap alone commonly recovers 20–30% of the bill. Node consolidation (Karpenter on AWS) is the change that turns freed capacity into actual node reductions.

Working through this on AWS? The EKS bill-cutting playbook goes deeper on Karpenter, Graviton, Savings Plans and the NAT-gateway and cross-AZ traps specific to Amazon's platform. And if you want the reasoning behind every item here, the complete cost optimization playbook is the long version.

Related: Kubernetes cost

KubernetesCostFinOpsChecklist

Need this done, not just read about?

Deplyra builds, ships and runs exactly this in production — as code, with GitOps, handed over documented.

Start a project →
Keep reading

Let's build something that stays up.

One message. We'll reply with questions, not a sales pitch — then a plan you can hold us to.

Start nowGitHub ↗

REMOTE WORLDWIDE · FREELANCE / CONTRACT · START: IMMEDIATE