Introduction
EKS compute cost optimization is the practice of matching paid compute to consumed compute across four dimensions: pod resource requests, node capacity, capacity type, and commitment coverage. For most organizations running Amazon Elastic Kubernetes Service (EKS), EC2 compute dominates the bill, typically 70-90% of total spend, which makes it the highest-leverage place to start a cost program. The failure mode is rarely a lack of awareness. Teams know Spot exists, know rightsizing exists, know Savings Plans exist. The real failure is working one lever in isolation and stopping, or working the right levers in the wrong sequence, which caps the savings each lever could have delivered and sometimes cancels them out entirely.
Why EKS Compute Costs Drift Upward on Their Own
Four mechanisms push EKS compute spend higher even when nobody changes a line of code.
Static requests, dynamic workloads. Pod resource requests get set once, often copied from a template or padded for safety, and rarely adjusted after. Real workload demand fluctuates by time of day, release cycle, and traffic pattern. The gap between what’s requested and what’s used becomes permanent Kubernetes waste, and median CPU utilization against requests is commonly reported in the 10-30% range, though this varies significantly by cluster maturity and workload type.
Node granularity you cannot fill. Nodes come in fixed sizes. As pods are scheduled and rescheduled, clusters fragment into nodes that are each partially full but collectively hold far less workload than their combined capacity suggests, and no single node can be safely emptied.
Commitment drift. Savings Plans and Reserved Instances are purchased against a snapshot of usage. Six months later the workload mix has changed, some purchased capacity sits unused, and new capacity runs uncovered at full price.
Capacity type mismatch. Workloads that could tolerate interruption keep running on-demand because nobody classified them, leaving Spot’s discount unclaimed on jobs it was built for.
| Waste Source | Typical Share of Compute Spend | Layer That Fixes It |
| Overprovisioned pod requests | 30-50% | Layer 1: Rightsizing |
| Node fragmentation | 15-25% | Layer 2: Consolidation |
| Uncovered or on-demand-only spend | 10-20% | Layer 3-4: Capacity type |
| Stranded or expired commitments | 5-15% | Layer 5: Commitment coverage |
Ranges vary by cluster maturity and workload mix; treat these as directional, not universal.
The 5-Layer Stack: Why the Order Matters More Than the Levers
Most cost optimization strategy content lists five or six levers and lets you pick your favorite. The order in which you apply them determines whether the savings add or multiply, and multiplication is where the real number comes from.
Consider a cluster spending $100,000 a month on EC2 compute for EKS. Rightsizing pod requests to actual usage cuts that spend by roughly 35%, leaving $65,000. Consolidating the freed-up capacity onto fewer, fuller nodes removes another 20% of what’s left, down to $52,000. Shifting eligible workloads to Spot and Graviton reduces the remaining spend by another 30%, to about $36,400. Buying Savings Plans against that new, smaller, stable baseline saves a further 15%, landing near $30,940, a total reduction of roughly 69%.
That final number only holds because each layer was applied to the output of the one before it, not to the original $100,000. Rightsizing before consolidation means there’s less waste to consolidate around. Consolidating before choosing capacity type means the Spot and Graviton decision is being made against a smaller, denser footprint. Buying commitments last means you’re covering what you actually need, not what you used to need. Optimize usage before you optimize price: reversing that order caps savings at addition instead of multiplication.
| Layer | Lever | Typical Savings | Prerequisite |
| 1 | Pod rightsizing | 20-40% | Usage data (7+ days) |
| 2 | Node consolidation | 15-25% | Rightsizing complete |
| 3 | Capacity type (Spot/Graviton) | 20-40% | Workload classified for interruption tolerance |
| 4 | Non-prod scheduling | 30-50% (non-prod only) | Environment tagging |
| 5 | Commitment coverage | 10-20% | Stable post-rightsizing baseline |
Zesty applies this sequencing automatically, continuously rightsizing pods and consolidating nodes before commitment decisions are ever made, which is the structural reason automated environments hold their savings while manually managed ones drift back toward the original baseline.
Layer 1 and 2: Rightsizing Pods, Then Consolidating Nodes
Pod rightsizing is where the largest single chunk of waste lives, and it starts with per-container requests, including sidecars, which are frequently left at default values long after the main container’s requests have been tuned. Tools like Goldilocks, Robusta KRR, and Kubecost analyze usage and recommend requests, but most of them stop at analysis. The Vertical Pod Autoscaler (VPA) has the same gap in its most common configuration: run in audit mode, it produces accurate recommendations and leaves a human to apply them, which means the analysis is automated and the action is not.
Running VPA in an automated mode alongside the Horizontal Pod Autoscaler (HPA) introduces a second problem: both systems can react to the same CPU signal, VPA adjusting requests while HPA adjusts replica count, and the two can enter a feedback loop where a resize triggers a scaling event that triggers another resize. The common workaround is a custom metric that decouples the two signals so each autoscaler reacts to something the other doesn’t touch. Zesty’s Multi-Dimensional Autoscaling (MDA) solves this differently: it treats pod-level CPU and memory rightsizing and HPA-driven replica counts as one continuously coordinated decision rather than two independently tuned systems, which is why the combination delivers savings that neither rightsizing alone nor HPA alone can reach.
Node Consolidation and Bin-Packing
Once pods are rightsized, node consolidation is the second lever. Karpenter’s consolidation feature actively looks for opportunities to move pods onto fewer nodes and terminate the ones left empty:
apiVersion: karpenter.sh/v1
kind: NodePool
spec:
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 30s
Cluster Autoscaler takes a more conservative approach, governed by two defaults worth knowing: scale-down-utilization-threshold (50% by default) and scale-down-unneeded-time (10 minutes by default), meaning a node has to sit below half utilization for ten straight minutes before it’s considered for removal. The descheduler adds a third option, actively repacking pods on a schedule. Ten nodes each running at 60% utilization can often be consolidated to six nodes at full capacity, but only if nothing is blocking the move.
Three configuration traps routinely block that move:
- Restrictive PodDisruptionBudgets. A deployment with 6 replicas and
minAvailable: 4leaves only 2 pods evictable at once, which can prevent a node from ever being fully drained. - Blanket do-not-evict annotations. Marking pods
safe-to-evict: falseas a default safety measure, rather than for the specific pods that need it, blocks consolidation across the entire workload. - Pods without controllers. Standalone pods with no Deployment or ReplicaSet behind them can’t be rescheduled, so they anchor a node in place indefinitely.
Layer 3 and 4: Choosing How You Pay for Compute
| Capacity Type | Discount | Interruption Risk | Best Fit | Overhead |
| Spot Instances | Up to 90% | 2-minute notice | Stateless, fault-tolerant, batch | Requires interruption handling |
| On-Demand | None | None | Baseline, stateful, low-tolerance | None |
| Compute Savings Plans | Up to 66% | None | Stable, cross-instance-family usage | 1 or 3-year commitment |
| EC2 Instance Savings Plans | Up to 72% | None | Stable usage on a fixed instance family | 1 or 3-year commitment |
| Fargate | Varies | None | No node management, small/simple workloads | Per-pod billing, no bin-packing |
| Graviton | ~20% cheaper | None | Multi-arch-compatible workloads | Requires multi-arch builds |
Spot needs instance diversity, not luck. A two-minute interruption notice is enough time to act on, but only if the workload can shift to another instance type immediately. Karpenter and managed node groups handle Spot interruptions natively; older setups relying on the Node Termination Handler need to confirm it’s still configured correctly. AWS’s price-capacity-optimized allocation strategy, which weighs both price and available capacity rather than price alone, reduces interruption frequency meaningfully compared to lowest-price-only strategies.
Fargate cannot be bin-packed. Each pod gets its own node-equivalent, with no DaemonSets and no sharing, and resource requests round up: a pod requesting 1 vCPU and 0.5 GiB of memory is billed as 1 vCPU and 2 GiB. That per-pod isolation is a feature for teams that don’t want to manage nodes, but it also means the consolidation gains available to EC2-backed clusters running Zesty’s Adaptive Pod Placement (APP), which continuously improves bin-packing density across nodes, simply aren’t available to Fargate workloads. The comparison isn’t only about per-unit pricing; it’s about what each model can and can’t optimize.
Graviton is the cheapest lever nobody pulls. At roughly 20% cheaper than equivalent x86 instances and around 60% more energy efficient, Graviton is often left unused not because of cost but because of multi-arch build requirements that teams haven’t gotten around to.
Layer 3, the overlooked one, is schedule-based: non-production clusters commonly sit idle for roughly 128 of 168 hours a week, meaning a scale-to-zero or scheduled-shutdown policy on dev and staging environments can eliminate the majority of their compute cost with no rightsizing or capacity-type changes required at all.
Layer 5: Commitment Coverage Without Getting Stranded
Commitments come last in the stack for a structural reason: they lock in a shape of usage, and that shape isn’t stable until the first four layers have already reduced and settled it. A commitment purchased against pre-rightsizing usage locks in the waste you were about to eliminate.
Once the baseline is stable, a coverage ladder works well:
- Commit to the floor. Cover 60-80% of steady-state usage with Savings Plans, the portion of the cluster that reliably runs every hour of every day.
- Spot the middle. Use Spot Instances for the variable capacity above the floor, workloads that scale up and down but can tolerate interruption.
- On-demand the peak. Leave the top, unpredictable spikes above normal variability, on-demand rather than trying to cover it with commitments.
The stranding trap is what happens when this ladder is built backward: a 1 or 3-year commitment purchased for today’s cluster shape meets a cluster that reshapes monthly, and the commitment ends up covering instance types or quantities the workload no longer needs. Zesty’s AWS Commitment Optimization addresses this by managing coverage through micro-Savings Plans with daily adjustment. Instead of making long-term, fixed commitments, coverage decisions are made based on the cluster’s actual state daily.
The Trade-Off Nobody Budgets For: Bin-Packing vs. Startup Latency
Tighter bin-packing is not free. As nodes fill up and headroom shrinks, new pods increasingly have to wait for a new node to become available rather than landing on existing capacity. Karpenter typically brings a new node to Ready in roughly 40-90 seconds, and by the time the container image pulls and the pod itself becomes ready, the total wait can run 1-3 minutes.
That delay is the hidden cost of Layer 2. It shows up as missed latency targets during traffic spikes, and the common response, adding headroom back as a buffer, directly undoes the consolidation gains that Layer 2 was supposed to lock in.
There are three legitimate ways to close that gap without giving the savings back: placeholder pods that reserve capacity ahead of demand, predictive scaling that anticipates spikes before they hit, or provisioning that’s simply fast enough that the wait stops mattering. Zesty’s FastScaler takes the third approach, using hibernated node pools with preloaded container images to bring capacity online up to 5x faster than a cold node boot, which is what makes it possible to run leaner on headroom without missing a spike. Fast, reliable node provisioning is what makes tight bin-packing durable rather than a bet you eventually lose during a traffic spike.
What Best-Practice Guidance Leaves You to Do Manually
| Layer | What Tooling Gives You | What a Human Still Does |
| Pod rightsizing | Usage analysis, recommendations | Applying changes, monitoring for regressions |
| Node consolidation | Detection of consolidation opportunities | Auditing PodDisruptionBudgets and eviction annotations |
| Capacity type | Interruption handling, allocation strategy | Classifying workloads for Spot eligibility |
| Commitment coverage | Usage forecasting | Purchase timing, term length decisions, monitoring drift |
Every row in that right-hand column is recurring engineering time, not a one-time setup task, and every row drifts the moment attention moves somewhere else, which is exactly what happens as workloads change and priorities shift. Zesty closes that gap by running each of these as continuous automation instead of a recurring manual review: Multi-Dimensional Autoscaling (MDA) and Adaptive Pod Placement (APP) handle rightsizing and consolidation, while AWS Commitment Optimization handles coverage, together delivering the 50-80% compute savings figure without a standing review cycle behind it.
Conclusion: A 90-Day EKS Compute Cost Optimization Plan
Days 1-30: Baseline. Tag nodes consistently, whether through launch templates or Karpenter’s spec.tags, and label workloads with matching Kubernetes labels so cost data can actually be attributed. Run VPA in audit mode across the cluster to start collecting rightsizing recommendations before touching anything in production.
Days 31-60: Usage optimization. Rightsize the top 10 highest-spend workloads first, since that’s where the concentration of waste usually sits. Enable node consolidation, audit PodDisruptionBudgets and eviction annotations for the traps described above, and schedule non-production environments to scale down outside business hours. Expect 30-50% compute savings by the end of this phase.
Days 61-90: Price optimization. Classify workloads for Spot eligibility and move eligible ones over, complete multi-arch builds so Graviton becomes usable, and only then buy commitments, against the new, post-optimization baseline rather than the original one.
Every one of those 90 days is a manual task that has to be repeated as the cluster changes, which is the structural argument for automating it rather than re-running the plan quarterly. Zesty’s platform runs this exact sequence continuously: Multi-Dimensional Autoscaling (MDA) and Adaptive Pod Placement (APP) run rightsizing and node consolidation continuously, FastScaler keeps that consolidation durable during traffic spikes, and AWS Commitment Optimization keeps coverage matched to whatever the cluster looks like this week. Automate it, or watch it drift back toward the original baseline within a few months, which is what happens to most manually run cost programs after the initial cleanup.
Book a Demo with Zesty to see how much of this can run without a standing review cycle.
FAQs
What drives most EKS compute costs?
EC2 compute typically accounts for 70-90% of total EKS spend, driven primarily by overprovisioned pod requests and node fragmentation rather than by capacity-type choices. That’s why compute, and specifically rightsizing, is the highest-leverage starting point for a cost program.
