Kubernetes Cost Optimization: Cut Cloud Bills Without Cutting Corners

Cloud costs going sideways is one of the most predictable problems in engineering. Teams move fast, ship features, and don't think much about resource allocation — until someone senior pulls up the AWS or GCP bill and asks hard questions.

The good news: Kubernetes gives you extraordinary leverage for cost management. The bad news: it doesn't give you that leverage automatically.

Start with visibility

You cannot optimize what you cannot see. Before you change a single resource limit, get cost visibility down to the namespace and workload level.

Kubecost is the go-to tool here. It integrates with your cloud provider's cost APIs and breaks down spend by namespace, deployment, pod, and even PVC. Free tier covers most small-to-medium clusters.

What you're looking for immediately:

• Which namespaces are consuming the most cost
• What percentage of allocated CPU and memory is actually being used (utilization vs request)
• Any abandoned or idle workloads still running

Most teams find 20-40% of allocated resources are unused on first audit. That's not waste you introduced recently — that's accumulated over-provisioning from "just to be safe" request values set during initial deployment and never revisited.

Right-size your resource requests

Resource requests in Kubernetes are what the scheduler uses to place pods. If you request 2 CPU cores but only use 0.3, you're paying for 2 and getting utilization out of 0.3.

The starting point is analyzing actual usage vs requests across your workloads. Kubecost shows this, as does the built-in kubectl top command for spot checks.

Once you have the data, the work is methodical: reduce requests to match observed usage with a reasonable buffer (typically 20-30% headroom above p99 utilization).

Vertical Pod Autoscaler (VPA)

VPA automates this process. It observes actual resource usage and adjusts requests and limits accordingly. It has three modes:

• Off — only generates recommendations, doesn't apply them
• Initial — sets requests at pod creation time, doesn't update running pods
• Auto — updates requests and restarts pods as needed

Start with Off mode to get recommendations without risk. Review them for a week before switching to Initial. Use Auto mode selectively for workloads that can tolerate restarts.

Spot / preemptible instances

For workloads that can tolerate interruption — batch jobs, background workers, non-critical services — spot instances offer 60-80% cost savings over on-demand.

Karpenter (AWS) and GKE's node auto-provisioning make this practical at scale. Karpenter can automatically provision spot nodes when available, fall back to on-demand when not, and deprovision nodes when load drops.

The key question is workload tolerance. Anything stateless and easily restartable is a candidate for spot. Stateful workloads, databases, and anything with tight SLOs should stay on on-demand.

Scale to zero with KEDA

For workloads that aren't needed 24/7, scaling to zero when idle eliminates their cost entirely. KEDA (Kubernetes Event-Driven Autoscaling) scales deployments based on external metrics — queue depth, Pub/Sub backlog, cron schedule, custom metrics.

Common patterns:

• Background processors that scale to zero when the queue is empty
• Batch workloads that run on schedule only
• Development and staging environments that scale down overnight

A staging environment running 24/7 might cost $800/month. Scaled down to zero on nights and weekends, the same environment runs $300-400/month.

Storage cost audit

Storage is often an afterthought. Check:

• PersistentVolumeClaims that have been detached from pods but still exist (and bill)
• Snapshot proliferation — automated backup schedules that retain snapshots indefinitely
• Storage class mismatches — workloads using high-performance SSD storage when standard storage would suffice

For read-heavy workloads that don't need SSD latency, downgrading from premium to standard storage class often cuts storage costs in half.

Cluster consolidation

Multiple small clusters cost more than one appropriately-sized cluster with proper namespace isolation. If you're running separate clusters for reasons other than hard security boundaries or geographic distribution, consolidation is worth evaluating.

The math usually works out significantly in favor of consolidation once you factor in the control plane cost, node pool overhead, and the operational burden of managing multiple cluster upgrades.

Building cost awareness into the team

The biggest driver of cloud waste isn't misconfiguration — it's culture. Teams that never see their costs don't think about their costs.

Practical changes that help:

• Surface per-namespace cost data in engineering dashboards
• Include cloud cost impact in code review for infra changes
• Set up Kubecost budget alerts that notify the team owner, not just the platform team
• Add cost to your quarterly engineering metrics alongside velocity and reliability

When engineers see that their service costs $4,000/month instead of the expected $1,200, they become naturally motivated to investigate and fix it.

---

Kubernetes cost optimization isn't a one-time project. It's an ongoing practice — right-sizing as workloads evolve, revisiting spot coverage as new services launch, and keeping visibility tooling up to date.

The teams that do it well make it part of the engineering culture, not a quarterly fire drill.

We help engineering teams implement cost visibility and optimization practices across GCP and AWS. Get in touch to talk through your specific situation.