EKS Cost Optimization: The Engineer’s Guide for 2026

Average CPU utilization across Amazon Elastic Kubernetes Service (EKS) clusters has fallen to 8% in 2026 from 10% in 2025, with 69% of provisioned CPU now completely unused, up from 40% year-over-year, according to the Cast AI 2026 State of Kubernetes Optimization Report. The report also found GPU utilization at 5% and memory overprovisioning at 79%, while EC2 compute drives 61% of the average EKS bill. Cast AI's guidance recommends rightsizing pods first, then node provisioning, Spot instances, Graviton3 (roughly 19% cheaper per vCPU than x86), and Compute Savings Plans last, and warns that AWS extended support costs $0.60 per cluster per hour, about $438 per month per cluster.

EKS cost optimization is the process of reducing the cost of running Kubernetes workloads on Amazon Elastic Kubernetes Service EKS while meeting performance and availability requirements. It involves matching pod resources and node capacity to actual demand, choosing cost-effective EC2 instances and purchasing options, and eliminating unused capacity and avoidable cluster fees. EKS cost optimization is more urgent in 2026 than it has ever been, and the numbers prove it. According to the Cast AI 2026 State of Kubernetes Optimization Report https://cast.ai/reports/state-of-kubernetes-optimization/ , average CPU utilization across EKS clusters sits at just 8% down from 10% in 2025 , GPU utilization has fallen to 5%, and 69% of provisioned CPU is completely unused, up from 40% year-over-year. That last figure is the one to focus on: overprovisioning is accelerating, not reversing. EC2 compute drives 61% of the average EKS bill, so wasted capacity translates directly to wasted dollars. This guide covers the six levers that actually move the number: rightsizing pods, optimizing node provisioning, running Spot instances, adopting Graviton, layering in Savings Plans, and automating the sequence so it holds at scale. This guide walks through the engineering decisions behind a lower EKS bill, with configuration examples, implementation steps, and trade-offs for production workloads. It explains where to start, how the changes depend on each other, and what to check before rolling them out. Key takeaways - Rightsize first, without exception. With 69% of CPU and 79% of memory going unused, rightsizing pods is the highest-ROI action before anything else changes. - Karpenter replaces Cluster Autoscaler for most EKS workloads. Forty-five-second provisioning, native Spot support, and continuous bin-packing justify the migration cost. - Spot instances cut 60-90% off eligible compute. Spot-heavy clusters in Cast AI’s 2026 dataset average 77% savings; mixed fleets average 59%. - Graviton3 is ~19% cheaper per vCPU than x86 , with no reliability trade-off. Combined with Spot pricing, it’s the highest-savings compute configuration available on AWS. - Compute Savings Plans come last in the sequence. Committing before rightsizing locks in waste for 1-3 years. Order matters: rightsize, then provision, then Spot, then Graviton, then commit. Watch for the EKS extended support trap Before running the six-lever sequence, check your cluster versions. AWS automatically enables extended support for clusters running Kubernetes versions beyond the standard 14-month support window. The cost: $0.60 per cluster per hour approximately $438/month per cluster . For organizations running multiple dev/staging clusters on older versions, this fee is often the single largest surprise line item on the EKS bill. Check your cluster version with: aws eks describe-cluster --name <cluster --query 'cluster.kubernetesVersion' Upgrade before the support window closes, or budget explicitly for extended support. With multiple clusters, the monthly fee stacks quickly. Start with rightsizing Overprovisioning is not negligence. It is rational behavior under the wrong incentives. Engineers set CPU and memory requests based on peak estimates, add a safety margin, and move on. The team that provisions the pods rarely sees the infrastructure bill. Autoscalers then treat those inflated requests as real demand and provision nodes accordingly. The result: clusters running at 8% CPU utilization while the bill reflects 100% of provisioned capacity. Across thousands of production clusters in the Cast AI 2026 report, 69% of provisioned CPU is unused; memory overprovisioning is worse at 79%. Sizing methodology: use real data, not estimates The correct approach uses percentiles calculated from actual workload behavior over 2-4 weeks of production data. Use p95 for CPU requests and p99 for memory requests. P95 CPU gives headroom for typical spikes without padding for rare outliers. P99 memory is more conservative because OOM kills are harder to recover from than CPU throttling: a throttled pod slows down, while an OOM-killed pod restarts from scratch. Kubernetes ships the Vertical Pod Autoscaler VPA for this purpose. Three modes are available: - Off: Audit mode. VPA generates recommendations without applying them. Start here to understand your current state before touching anything. - Initial: Applies recommendations at pod creation only, with no in-place changes. Lower disruption than Auto, good for production services. - Auto: Continuously adjusts requests, which requires pod restarts. Use with caution in production. Here is a minimal VPA object to start auditing a deployment: apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: my-app-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: my-app updatePolicy: updateMode: "Off" Start with Off for auditing; change to Initial or Auto resourcePolicy: containerPolicies: - containerName: my-app minAllowed: cpu: 100m memory: 128Mi maxAllowed: cpu: 2 memory: 2Gi Start with updateMode: Off to audit recommendations without applying them. Move to Initial for safe one-time application, or Auto for continuous adjustment with pod restarts. One hard constraint: do not run VPA Auto alongside HPA when HPA scales on CPU or memory metrics. The two controllers will conflict. If your HPA uses custom metrics requests per second, queue depth , VPA Auto and HPA can coexist safely. Cast AI PrecisionPack: continuous rightsizing without the restart cycle Cast AI’s PrecisionPack goes beyond point-in-time recommendations. It continuously monitors workload behavior and adjusts requests without requiring pod restarts in most cases. It also raises limits for workloads under genuine pressure, not just cuts waste. Teams using PrecisionPack report meaningful reductions in OOM kills alongside cost reductions, because the system allocates memory where it is actually needed rather than applying a blanket multiplier. For more on Kubernetes-level cost reduction, see Cast AI’s Kubernetes cost optimization guide https://cast.ai/kubernetes-cost-optimization/ . Node provisioning: Karpenter, Auto Mode, or Cluster Autoscaler? Once pods are rightsized, the question shifts to whether nodes are provisioned efficiently. The answer depends on which autoscaler you’re running and what trade-offs you’re willing to accept. Cluster Autoscaler limitations Cluster Autoscaler has been the EKS default for years, but its architecture creates real constraints at scale. Node group lock-in means scaling decisions are limited to pre-defined instance types, preventing dynamic selection. Provisioning takes 3-4 minutes, creating meaningful latency for burst workloads. Most significantly, Cluster Autoscaler does not repack: it removes empty nodes, but it will not consolidate partially-utilized nodes. A cluster with 10 nodes at 30% utilization stays at 10 nodes until individual nodes drain entirely. Karpenter v1 API: the recommended EKS default Karpenter calls EC2 directly, bypassing the node group abstraction entirely. This delivers 45-60 second provisioning versus 3-4 minutes for Cluster Autoscaler. The v1 API introduces the WhenEmptyOrUnderutilized consolidation policy: Karpenter actively repacks workloads onto fewer nodes and terminates the underutilized ones. This is bin-packing, not just scale-down. For Spot workloads, Karpenter’s declarative NodePool model accepts multiple instance families and handles fallback automatically. The SpotToSpotConsolidation feature replaces running Spot instances with cheaper ones when availability improves, without waiting for interruption. This feature is disabled by default in Karpenter v1 and requires explicit opt-in: enable it via the SpotToSpotConsolidation=true feature gate by adding --feature-gates=SpotToSpotConsolidation=true to your Karpenter controller args. Disruption budgets via NodePool.spec.disruption.budgets provide per-NodePool control over consolidation aggressiveness. For a full comparison, see Karpenter vs Cluster Autoscaler https://cast.ai/blog/karpenter-vs-cluster-autoscaler/ . EKS Auto Mode: managed Karpenter with real trade-offs EKS Auto Mode GA December 2024 runs Karpenter as a managed, off-cluster component. AWS handles installation, upgrades, and operational overhead. The trade-offs are specific: - ~12% surcharge per node on EC2 On-Demand pricing an m5.large adds $0.0115/hr . This surcharge is not covered by Compute Savings Plans or Reserved Instances. - Bottlerocket only. No Amazon Linux 2, no custom AMIs. - No SSH or SSM node access. If your debugging workflow depends on getting into nodes, Auto Mode removes that option. - GPU surcharge reduced 60% in July 2026, improving Auto Mode’s economics for GPU-heavy workloads specifically. Choose Auto Mode when eliminating Karpenter operational overhead is worth the 12% surcharge, typically when platform engineering time is the constraint. Choose self-managed Karpenter when cost efficiency is the priority, when you need custom AMIs, or when node-level debugging is part of your runbooks. The full breakdown is in the EKS Auto Mode analysis https://cast.ai/blog/eks-auto-mode/ . Run Spot instances with fallback Spot instances represent the largest single-lever savings available on EKS for eligible workloads: 60-90% off On-Demand pricing. Across Cast AI’s 2026 production dataset, Spot-heavy clusters average 77% compute savings, and mixed fleets part Spot, part On-Demand average 59%. The prerequisite is correct interruption handling, not just adding Spot to your NodePool. AWS Spot termination: 2 minutes, not 30 seconds AWS provides a 2-minute termination notice before reclaiming a Spot instance. GCP and Azure provide only 30 seconds. This difference changes how you design the shutdown sequence. On AWS, 2 minutes is enough for a graceful drain, connection close, and checkpoint write if the application handles SIGTERM correctly. Set terminationGracePeriodSeconds: 90 in your pod spec. AWS Spot gives approximately 110 seconds of actual SIGTERM window inside that 2-minute notice, so 90 seconds leaves a buffer for the kubelet to drain the pod and for any preStop hooks to execute before the hard kill arrives. Spot-safe vs. Spot-unsafe workloads Stateless workloads with at least 2 replicas are the safest Spot candidates: web services, API servers, batch processors, and CI/CD runners. These workloads restart cleanly after interruption without losing meaningful state. For web services, the other replica absorbs traffic during the 2-minute drain. Avoid Spot for stateful databases, Kafka brokers, payment processors, and single-replica workloads. The Kubernetes control plane components etcd, API server, controller manager must run On-Demand. For those workloads, On-Demand with Compute Savings Plans is the right purchasing model. Interruption handling by autoscaler Karpenter handles Spot interruption natively, so you do not need the Node Termination Handler NTH . However, this capability requires two prerequisites: 1 an SQS queue provisioned in the same region as your cluster, and 2 Amazon EventBridge rules routing EC2 Spot interruption warnings to that queue, with the queue ARN configured in Karpenter settings. Without this infrastructure in place, Karpenter does not receive interruption notices and falls back to reactive eviction. Once configured, Karpenter begins cordoning and draining the affected node before the instance terminates, preserving the full 2-minute window. With Cluster Autoscaler, NTH in Queue Processor mode is required. NTH watches the SQS queue populated by EventBridge and initiates the drain. Without NTH, pods on a terminating Spot instance receive SIGKILL without utilizing the 2-minute warning at all. In both cases, PodDisruptionBudgets are non-negotiable. A PDB prevents Karpenter or NTH from draining a node if doing so would take the service below minimum availability. Configure PDBs for every production deployment before enabling Spot. On top of interruption handling, Cast AI analyzes EC2 Spot price history and regional capacity signals to predict interruptions approximately 1 hour before they occur, enabling proactive node replacement instead of reactive pod eviction. For implementation details, see Kubernetes Spot instances cost optimization https://cast.ai/blog/kubernetes-spot-instances-cost-optimization/ . Graviton and Savings Plans With pods rightsized and nodes provisioned efficiently, two more levers remain: instance architecture and purchasing model. These compound the savings already achieved rather than replacing them. Graviton3 and Graviton4: the cost case Graviton3 instances cost approximately 19% less per vCPU than equivalent x86 instances. Comparing directly: a c7g.xlarge Graviton3 costs $0.145/hr; a c7i.xlarge Intel x86 costs $0.179/hr. Same vCPU count, same memory tier, 19% price gap. Graviton4 c8g/m8g/r8g delivers up to 30% better performance than Graviton3 in memory-optimized and database workloads AWS benchmark, R8g vs R7g . For general compute workloads, expect 10-20% improvement. Where those gains apply, Graviton4 can reduce the instance size needed to serve the same load, stacking further savings on top of the per-unit price advantage. According to the Cast AI 2026 report, ARM processors now represent 9% of all Kubernetes CPUs, and ARM adoption is growing 3.5x faster than x86. Combine Graviton with Spot pricing and you have the highest-savings compute configuration available on AWS for stateless workloads. Migrating to Graviton: three steps Graviton migration follows a specific sequence. Step 2 is where most teams get blocked: Step 1: Multi-arch builds. Use docker buildx to produce linux/amd64 and linux/arm64 images in a single manifest. Most modern base images already support both architectures. Step 2: DaemonSet arm64 audit. Every DaemonSet in the cluster monitoring agents, log shippers, CNI plugins, security tools must have an arm64 binary available. Run this audit before adding arm64 nodes: kubectl get daemonsets -A -o json | \ jq -r '.items | select .spec.template.spec.nodeSelector "kubernetes.io/arch" = "arm64" | .metadata.name' This lists DaemonSets without an explicit arm64 node selector. Any DaemonSet that lacks a multi-arch image will prevent arm64 nodes from becoming Ready. Resolve each result before proceeding to arm64 nodes. Step 3: NodePool configuration. In Karpenter, add arm64 to the kubernetes.io/arch requirement in your NodePool alongside amd64 . In EKS Auto Mode, create a custom NodePool with aarch64 and set a weight greater than 0 to prefer Graviton when available. Savings Plans: the correct purchasing sequence Compute Savings Plans offer up to 66% discount versus On-Demand pricing with a 3-year all-upfront commitment; 1-year no-upfront Compute Savings Plans typically save 40-45%. Either way, there is no instance-type or region lock-in. This flexibility makes Savings Plans significantly better than Reserved Instances for most EKS workloads, where the specific instance mix shifts frequently as Karpenter repacks and Graviton adoption grows. The sequence is critical. Purchase Savings Plans only after completing rightsizing, adopting Karpenter, adding Spot where safe, and migrating eligible workloads to Graviton. Buying commitments before rightsizing locks in today’s waste for the full 1-3 year term. A cluster running at 69% CPU waste, committed on Reserved Instances, pays for that waste every month of the commitment period. - The EKS Auto Mode management fee ~12% per node is not covered by Savings Plans . The surcharge applies on top of any commitment discount. - As of June 2025, Savings Plans are no longer shareable across different end customers in the same AWS Organization . If you manage multi-tenant AWS Orgs, this affects how commitment purchases should be structured. Putting it together with automation The six-lever sequence for EKS cost optimization is: rightsize pods, optimize node provisioning with Karpenter or Auto Mode, run Spot where safe, migrate eligible workloads to Graviton, then buy Compute Savings Plans. Each step depends on the previous one. Running them out of order either leaves savings unrealized or, in the case of commitments, bakes in waste for years. The practical challenge is that every lever requires ongoing attention. Rightsizing degrades as workloads evolve. Karpenter configurations need tuning as new instance types launch. Spot availability shifts. Graviton migration is a project, not a one-time checkbox. Most platform engineering teams lack dedicated capacity to watch all six levers continuously. Cast AI automates all six levers as a continuous control loop rather than a one-time project. Across all customers using the full Cast AI stack, average compute cost reduction is 43% range 40-70% . As a concrete reference: Cast AI’s own EKS cluster went from $414/month to $207/month after enabling the Evictor for bin-packing, then to $138/month after adding Spot. That $414 to $207 to $138 trajectory is an above-average outcome from full-stack automation: aggressive rightsizing, Spot adoption across eligible workloads, and Graviton; your cluster profile will determine the actual reduction. For the full Kubernetes cost optimization picture beyond EKS, see Cast AI’s Kubernetes cost optimization guide https://cast.ai/kubernetes-cost-optimization/ . Frequently Asked Questions How do I reduce EKS costs? The correct sequence is: rightsize pods first 69% of provisioned CPU is unused on the average EKS cluster , then optimize node provisioning with Karpenter or Auto Mode, add Spot instances with proper fallback for stateless workloads, migrate eligible workloads to Graviton for an additional ~19% savings, and finally purchase Compute Savings Plans. Buying commitments before rightsizing locks in waste for 1-3 years. Also check your cluster Kubernetes versions: AWS charges $0.60/hr per cluster for extended support beyond the 14-month standard window. Which node autoscaler should I use on EKS? Karpenter is the recommended default for EKS. It provisions nodes in 45-60 seconds by calling EC2 directly, supports Spot natively, and continuously repacks workloads onto fewer nodes. EKS Auto Mode runs managed Karpenter but adds a ~12% surcharge per node that Savings Plans do not cover. Cluster Autoscaler remains viable for legacy clusters without the appetite to migrate. See Karpenter vs Cluster Autoscaler https://cast.ai/blog/karpenter-vs-cluster-autoscaler/ for a full comparison. Are Spot Instances safe for EKS? Spot instances are safe for stateless workloads web services with at least 2 replicas, batch jobs, CI/CD pipelines with proper interruption handling. AWS provides a 2-minute notice before termination. Set terminationGracePeriodSeconds to 90 seconds and configure PodDisruptionBudgets for every production deployment. Avoid Spot for stateful databases, Kafka brokers, and payment processors. Karpenter handles interruption natively no NTH needed once SQS and EventBridge are configured. Spot-heavy clusters in Cast AI’s 2026 dataset average 77% compute savings.