Kubernetes Cost Optimization: Save 40% Without Sacrificing Scale

Why K8s Costs Spiral Out of Control

Kubernetes promises efficient resource utilization through containerization and orchestration. In practice, most organizations running Kubernetes overspend by 40-60% due to a combination of over-provisioning, lack of visibility, and misaligned incentives between development and finance teams.

The pattern is predictable: a developer deploys a new service and requests 2 CPU cores and 4GB RAM because they are unsure of actual requirements and want to avoid performance issues. Nobody reviews these requests. The pod runs at 15% CPU utilization and 30% memory utilization. Multiply this by 50-200 services across development, staging, and production environments, and you are burning tens of thousands of dollars monthly on idle compute.

According to the 2025 CNCF FinOps Survey, the average Kubernetes cluster runs at just 35% resource utilization. That means 65% of your cloud spend on compute is effectively wasted. For a company spending $50,000/month on Kubernetes infrastructure, that represents $32,500 in potential savings — every single month.

At 9ance, we have optimized Kubernetes costs for 20+ clients across AWS EKS, Google GKE, and Azure AKS. Our systematic approach consistently delivers 30-50% cost reduction without any degradation in performance or reliability. Here are the five strategies we implement.

Strategy 1: Right-Sizing with Vertical Pod Autoscaler (VPA)

Right-sizing is the single highest-impact optimization you can make. It addresses the root cause of overspending: resource requests that do not match actual usage.

The Vertical Pod Autoscaler continuously monitors actual CPU and memory consumption for each pod and recommends (or automatically applies) optimal resource requests and limits.

Implementation Approach

We never enable VPA in auto-apply mode immediately. Our phased approach prevents disruptions:

Phase 1 — Observation (Week 1-2): Deploy VPA in recommendation-only mode across all namespaces. This collects usage data without making any changes. We configure Prometheus to store granular resource metrics with 30-second resolution.

Phase 2 — Analysis (Week 3): Review VPA recommendations against actual usage patterns. We look for pods where recommended CPU is less than 50% of current requests — these are the quick wins. We also identify pods with high variance (batch jobs, cron tasks) that need different handling.

Phase 3 — Gradual Application (Week 4-6): Apply recommendations starting with non-critical services in staging, then production. We reduce requests by no more than 30% per iteration, monitoring for OOMKills and CPU throttling after each change.

Phase 4 — Continuous Optimization (Ongoing): VPA continues monitoring and adjusting. We set up alerts for pods where actual usage exceeds 80% of requests (potential under-provisioning) or drops below 20% (over-provisioning creeping back).

Typical Results

• 30-50% reduction in total requested CPU across the cluster
• 25-40% reduction in requested memory
• Node count reduction of 20-35% (fewer nodes needed when pods request less)
• Zero increase in error rates or latency when done correctly

Common Pitfalls

• Applying VPA to Java applications without understanding JVM heap behavior (memory requests must account for heap + metaspace + native memory)
• Right-sizing pods that have legitimate burst requirements (use Burstable QoS class instead of Guaranteed)
• Forgetting to exclude system pods (kube-system, monitoring) from aggressive right-sizing

Strategy 2: Spot and Preemptible Instances

Spot instances (AWS), Preemptible VMs (GCP), and Spot VMs (Azure) offer 60-80% discounts compared to on-demand pricing. The tradeoff is that the cloud provider can reclaim these instances with 2 minutes notice (AWS) or 30 seconds (GCP).

For stateless, fault-tolerant workloads — which represent 60-80% of typical Kubernetes deployments — this tradeoff is excellent.

Workload Classification

We classify every workload into three tiers:

Tier 1 — Spot-Ready (60-80% of workloads): Stateless web servers, API gateways, background workers, batch processing jobs, CI/CD runners, development/staging environments. These can tolerate interruption with graceful shutdown.

Tier 2 — Mixed (10-20% of workloads): Services that can run on spot but need careful handling — long-running data pipelines, ML training jobs, services with expensive initialization. We use spot with longer grace periods and checkpointing.

Tier 3 — On-Demand Only (10-20% of workloads): Databases, message queues, stateful services, single-replica critical services. These stay on on-demand or reserved instances.

Implementation Details

• Configure multiple node pools: on-demand (Tier 3), spot (Tier 1 and 2)
• Use node affinity and taints/tolerations to schedule workloads on appropriate pools
• Implement PodDisruptionBudgets to ensure minimum availability during spot reclamation
• Add graceful shutdown handlers to all applications (handle SIGTERM, drain connections, complete in-flight requests within 25 seconds)
• Use diversified spot allocation (multiple instance types) to reduce interruption frequency
• Set up Cluster Autoscaler with spot instance support for automatic capacity management

Cost Impact

For a typical 50-node cluster where 35 nodes can run spot workloads:

• On-demand cost: 35 nodes × $150/month = $5,250/month
• Spot cost: 35 nodes × $45/month = $1,575/month
• Monthly savings: $3,675 (70% reduction on eligible workloads)

Strategy 3: Horizontal Pod Autoscaler (HPA) Tuning

Default HPA settings are designed for safety, not efficiency. Out-of-the-box configurations lead to over-scaling (too many replicas during minor load spikes) and slow scale-down (keeping excess capacity long after traffic subsides).

Optimized HPA Configuration

We tune these parameters based on actual traffic patterns:

• Scale-up CPU threshold: 70% (default 80% is too conservative — by the time you hit 80%, latency is already degraded)
• Scale-down stabilization window: 5 minutes (default 5 minutes is fine, but some teams set it to 15+ minutes out of fear, wasting resources)
• Scale-down rate: Maximum 1 pod per 60 seconds (prevents aggressive scale-down from causing cascading failures)
• Custom metrics: Scale on business-relevant metrics (request queue depth, active connections, message backlog) rather than just CPU. CPU-based scaling is reactive; queue-based scaling is predictive.
• Minimum replicas: 2 for high-availability services (not 3 "just in case"), 1 for non-critical services during off-peak hours

Advanced: Scheduled Scaling with KEDA

For workloads with predictable traffic patterns (business hours, batch processing windows), we implement KEDA (Kubernetes Event-Driven Autoscaling) with cron-based scaling:

• Scale to minimum replicas during nights and weekends (if traffic drops 80%+)
• Pre-scale before known traffic spikes (marketing campaigns, batch job windows)
• Scale to zero for development and staging environments outside business hours

Cost Impact

Proper HPA tuning typically reduces average replica count by 25-35% while maintaining the same latency SLAs. For a cluster running 200 pods average, this means 50-70 fewer pods — translating to 3-5 fewer nodes.

Strategy 4: Namespace Quotas and LimitRanges

Without organizational controls, Kubernetes costs grow linearly with team size. Every new developer, every new service, every new experiment adds resources without accountability.

Implementation

ResourceQuotas per namespace/team:

• Set hard limits on total CPU and memory requests per namespace
• Limit the number of pods, services, and PVCs per namespace
• Separate quotas for different environments (production gets more, development gets less)

LimitRanges with sensible defaults:

• Default CPU request: 100m (not 500m or 1000m)
• Default memory request: 128Mi (not 512Mi or 1Gi)
• Maximum CPU per pod: 4 cores (prevents single pods from consuming entire nodes)
• Maximum memory per pod: 8Gi (same reasoning)

Alerting at 80% quota utilization: Teams get notified before hitting limits, allowing them to optimize existing workloads rather than requesting quota increases.

Strategy 5: FinOps Culture and Governance

Technical optimizations deliver one-time savings. Cultural changes deliver continuous savings. Without FinOps practices, costs creep back to pre-optimization levels within 6-12 months.

Practices We Implement

• Weekly cost review: 5-minute agenda item in engineering standup showing per-team cloud spend trends
• Resource tagging: Every pod, namespace, and node tagged with team, service, environment, and cost center
• Showback reports: Monthly reports to team leads showing their team's cloud spend vs. budget
• Cost-aware CI/CD: Pipeline checks that flag resource requests exceeding team averages
• Gamification: Monthly leaderboard recognizing teams that reduce costs without incidents
• Idle resource detection: Automated alerts for pods with less than 10% utilization for 7+ consecutive days
• Environment lifecycle: Automatic shutdown of preview/feature-branch environments after 48 hours of inactivity

Results: Client Case Study

For a US-based logistics company running 120 pods across 3 EKS clusters (production, staging, development):

Before Optimization:

• Monthly AWS bill (EKS + EC2 + related): $18,000
• Average cluster utilization: 28%
• 45 on-demand nodes across all clusters
• No resource quotas or cost visibility

After Optimization (8-week engagement):

• Monthly AWS bill: $10,800 (40% reduction)
• Average cluster utilization: 62%
• 28 nodes (18 spot + 10 on-demand)
• Full cost attribution and weekly reporting

Breakdown of savings:

• Right-sizing (VPA): $2,400/month saved
• Spot instances: $3,200/month saved
• HPA tuning + scheduled scaling: $1,100/month saved
• Dev/staging environment optimization: $500/month saved

Additional benefits:

• Zero downtime during the entire optimization process
• P99 latency actually improved by 12% (right-sized pods = less noisy neighbor effects)
• Development team velocity unchanged (no workflow disruptions)

Start Today: Quick Assessment

Run these commands to assess your optimization potential:

1. Check actual vs requested resources: Run kubectl top pods across all namespaces and compare with resource requests in your deployments
2. Identify idle workloads: Look for pods consistently below 20% CPU and memory utilization
3. Count on-demand nodes running stateless workloads: These are immediate spot candidates
4. Review HPA configurations: Check if minimum replicas are set higher than necessary

If actual usage is below 30% of requests across your cluster, you are likely overspending by 40% or more. We offer a free Kubernetes cost assessment — share read-only access to your cluster metrics, and we will deliver a detailed optimization roadmap within 48 hours.