EKS Cost Optimization: Rightsizing, Spot, Karpenter, and Why Compute Savings Plans Are the Right Commitment Tool for Dynamic Clusters

Every EKS cost guide covers the same ground: right-size your pods, use Spot instances, autoscale aggressively. That advice is correct and well worth implementing. It is also incomplete.

The part that most guides skip or treat as an afterthought is the commitment layer — whether the underlying EC2 compute running your worker nodes is covered by Savings Plans, Reserved Instances, or Spot versus running at full on-demand rates.

The workload-layer optimizations reduce how many compute hours you consume. The commitment layer determines what you pay for each hour. Both matter, and the combination is where the largest total savings live.

This guide covers both layers in the order they make practical sense, and makes a specific point about the interaction between Karpenter and commitment instruments that most guides get wrong.

The EKS Cost Structure: What You Actually Pay For

Understanding the full EKS cost structure is the prerequisite for optimizing it. There are more line items than the cluster fee alone.

The cluster control plane fee

Every EKS cluster carries a per-cluster per-hour fee for the managed Kubernetes control plane. For Standard Kubernetes version support, this is $0.10 per cluster per hour — $73 per month per cluster. Source: aws.amazon.com/eks/pricing/ DIRECT. If your cluster is on an Extended Support Kubernetes version (which provides an additional 12 months of support beyond standard), the fee increases. The extended support fee is charged per cluster per hour at a higher rate than standard support.

For organizations running many small, purpose-built clusters (one per team, one per environment), the aggregate control plane fee is worth auditing. Ten clusters in standard support cost approximately $730 per month in control plane fees before a single pod runs. Consolidating where blast radius permits reduces this baseline cost.

EKS Auto Mode: the newer compute model

EKS Auto Mode, launched in late 2024, fully automates Kubernetes cluster management including compute provisioning, scaling, and core add-ons. When Auto Mode is enabled, you pay an additional EKS Auto Mode fee per EC2 instance launched and managed by Auto Mode, on top of the standard EC2 instance price. This fee is charged per-second with a one-minute minimum, similar to EC2 instance billing. Importantly: you can still use On-Demand, Reserved Instances, Compute Savings Plans, and Spot Instances with EKS Auto Mode — the Auto Mode management fee is independent of the EC2 purchase option.

For clusters considering Auto Mode, the relevant cost comparison is the Auto Mode management fee versus the operational overhead cost of self-managing node groups or Karpenter. For teams without dedicated platform engineering capacity, Auto Mode often delivers positive ROI through operational time savings even after accounting for the per-instance fee.

Worker node EC2 charges

Worker nodes are standard EC2 instances. You pay the same EC2 rates for EKS worker nodes as for any EC2 instance — on-demand, Spot, Reserved, or Savings Plans pricing depending on how you provision them. This is the largest component of most EKS bills and the primary target for both workload-layer and commitment-layer optimization.

Additional EC2-layer charges apply: EBS volumes attached to nodes for container storage, cross-AZ data transfer between nodes (relevant for multi-AZ deployments with significant east-west traffic), and public IPv4 addresses charged at $0.005 per IP per hour if you expose node or pod services externally.

Also read: AWS Savings Plans: the complete guide to Compute Savings Plans for EC2, Fargate, and Lambda

Layer One: Workload and Cluster Optimization

Pod resource request accuracy

Kubernetes schedules pods based on their declared CPU and memory requests. A pod that requests 4 vCPU and 8 GB memory forces the scheduler to find a node with at least that much available capacity, whether or not the pod actually uses those resources at runtime. If that pod typically runs at 0.4 vCPU and 1.2 GB, 90% of its allocated resources are wasted — consumed by the reservation but producing no workload value.

Accurate resource requests are the foundation of efficient EKS clusters. They allow the scheduler to pack pods densely, which means fewer nodes are needed to run the same workload. For Karpenter-managed clusters, accurate requests also allow Karpenter to select smaller, cheaper node types that still meet the actual workload requirements.

The practical approach: use Vertical Pod Autoscaler (VPA) in recommendation mode to collect actual CPU and memory usage metrics for each deployment over a representative period, then right-size requests based on actual P95 or P99 consumption plus an appropriate safety buffer. Avoid setting CPU requests too low — CPU throttling (not an out-of-memory kill but a performance degradation) is harder to detect and can degrade user-facing latency significantly without obvious error signals.

Spot instances for fault-tolerant workloads

Spot instances provide access to spare EC2 capacity at up to 90% discount compared to on-demand prices. Source: aws.amazon.com/ec2/spot/. The trade-off is that Spot instances can be interrupted with a two-minute notice when EC2 needs the capacity back. Workloads that can handle interruption — batch jobs, data processing pipelines, CI/CD workers, stateless microservices with multiple replicas and proper pod disruption budgets — are strong Spot candidates.

Karpenter improves Spot reliability materially versus the Cluster Autoscaler because it uses the Price Capacity Optimized allocation strategy when provisioning Spot, which selects from the deepest capacity pools with the lowest interruption risk rather than just the cheapest available pool. Additionally, the more instance types Karpenter can select from, the better it can optimize Spot availability — configuring Karpenter NodePools to allow diverse instance families rather than a fixed type significantly improves Spot stability.

A production team running 80% of their EKS nodes on Spot is achievable with Karpenter and properly configured pod disruption budgets. Grover achieved this, increasing Spot usage by 25% after migrating to Karpenter, with no material disruption to production workloads.

Karpenter for dynamic node provisioning

Karpenter is an open-source Kubernetes node autoscaler that provisions EC2 instances directly via the AWS API without the intermediate layer of Auto Scaling Groups. When a pod goes pending due to insufficient node capacity, Karpenter reads the pod’s requirements and provisions the optimal instance type, with nodes typically ready in 45-60 seconds on standard configurations.

Karpenter’s consolidation feature continuously evaluates whether running pods can be repacked onto fewer nodes. When a node becomes underutilized and its pods can be moved to other nodes, Karpenter evicts the pods and terminates the empty node. This ongoing bin packing prevents the gradual cluster sprawl that causes EKS bills to drift upward as nodes accumulate idle capacity over time.

Karpenter also supports interruption handling for Spot instances natively. When EC2 issues a Spot interruption notice, Karpenter receives it via the EC2 Instance Metadata Service and proactively drains the affected node before the interruption, gracefully rescheduling pods to avoid service disruption. This interruption handling is built into Karpenter rather than requiring separate tooling.

Dev, test, and staging: turn off what is not running

Not every EKS cluster needs to run 24 hours a day. Development clusters, staging environments, and QA clusters that are used only during business hours can be stopped or scaled down outside those hours. EKS allows you to stop a cluster to prevent compute charges from accumulating. When a cluster is stopped, the control plane stops billing but the cluster state is preserved.

For clusters that do need to exist 24/7 but have low usage overnight, scaling node groups to zero during off-peak hours with an automated scaling schedule achieves similar savings without the operational complexity of full cluster stop and restart.

Layer Two: Compute Commitments — and Why Savings Plans Beat Reserved Instances for Karpenter Clusters

This is the layer most EKS cost guides reduce to a single sentence. It deserves more than that because getting the commitment instrument wrong is a meaningful, concrete mistake for Karpenter-managed clusters specifically.

The problem with EC2 Reserved Instances on Karpenter clusters

An EC2 Reserved Instance provides a discount on a specific instance family, size, operating system, and region in exchange for a 1-year or 3-year commitment. A reservation for m5.xlarge covers m5.xlarge usage and nothing else (or other sizes within the m5 family with instance size flexibility, which applies within the same family).

Karpenter does not commit to a specific instance type. It selects the optimal instance type from the allowed NodePool configuration at provisioning time, based on current spot pricing, capacity availability, and pod requirements. On a given day, Karpenter might provision m5.xlarge nodes. The next week, m6i.xlarge might be cheaper or more available, and Karpenter will shift there. The week after that, c5.2xlarge might better fit the pod mix.

If you have purchased EC2 Reserved Instances for m5.xlarge to cover your Karpenter-managed nodes, and Karpenter migrates to a different instance type because it’s cheaper or more available, your m5.xlarge reservations are stranded. You are paying for reserved capacity that is not being used, while the nodes actually running are billed at on-demand rates. The optimization tool and the commitment instrument are working against each other.

Compute Savings Plans: the correct commitment for Karpenter clusters

Compute Savings Plans apply to eligible EC2 usage regardless of instance family, size, operating system, or region within the commitment scope. A Compute Savings Plan commits to a minimum hourly EC2 spend across all eligible compute usage — it does not specify which instances will consume it. Source: aws.amazon.com/savingsplans/.

For Karpenter-managed clusters where instance types change dynamically, this is exactly the right instrument. The Savings Plan discount applies to whatever EC2 instances Karpenter provisions, whether those are m5.xlarge, m6i.xlarge, c5.2xlarge, or any other eligible instance type. The commitment follows the compute spend rather than a fixed instance specification.

Compute Savings Plans deliver 66% savings on eligible compute versus on-demand rates at maximum commitment. Even a partial commitment — covering 50-70% of the stable compute floor — delivers substantial savings. The stable floor concept matters: you do not need to commit to average or peak compute usage, only to the minimum compute that runs continuously. For a 10-node Karpenter cluster that never drops below 6 nodes even during the lightest periods, sizing a Compute Savings Plan to cover 6 nodes worth of compute at the on-demand rate provides savings on the baseline while leaving the variable portion to benefit from Spot pricing.

The sequencing that works: first, run Karpenter and optimize Spot adoption for fault-tolerant workloads. Let those optimizations run for 60-90 days and observe your stable compute floor — the on-demand EC2 spend that remains after Spot has taken over the interruptible workloads. That stable floor is your Savings Plan target. Buying a Compute Savings Plan sized to the stable floor captures 30-66% off that on-demand component without interfering with Karpenter’s ability to optimize Spot usage on the rest of the fleet.

EC2 Instance Savings Plans still apply to fixed-type node groups

If you run EKS with managed node groups that use a fixed, stable instance family and size (a common pattern for dedicated workloads with specific hardware requirements — GPU nodes, high-memory nodes, storage-optimized nodes), EC2 Instance Savings Plans deliver slightly deeper discounts than Compute Savings Plans on that specific family. For those fixed-type node groups, EC2 Instance Savings Plans are appropriate because the instance type is not subject to dynamic Karpenter selection.

The practical split: Compute Savings Plans for Karpenter-managed general-purpose node pools where instance types vary, EC2 Instance Savings Plans (or Reserved Instances) for fixed-type node pools with stable, known instance families.

Also read: AWS Savings Plans vs Reserved Instances: which actually saves more in 2026

Fargate: When It Helps and When It Doesn’t

AWS Fargate for EKS lets you run Kubernetes pods on serverless compute without managing EC2 nodes at all. You pay per-second for vCPU and memory resources requested by the pod, with a one-minute minimum. Fargate is well-suited for spiky, bursty workloads where the overhead of managing node capacity exceeds the cost premium of Fargate’s per-pod billing.

Fargate is also supported by Compute Savings Plans, which apply to Fargate compute spend alongside EC2 compute. A Compute Savings Plan that covers EKS worker node EC2 spend also covers Fargate pod spend within the same commitment scope.

Fargate is not the right choice for continuously running, resource-intensive workloads. The per-vCPU Fargate rate is higher than on-demand EC2 for equivalent compute, and there is no equivalent of Spot pricing for Fargate on EKS (unlike ECS, which has Fargate Spot). For always-on workloads with stable resource requirements, EC2 node groups with Savings Plan coverage are consistently cheaper than Fargate.

EKS Cost Governance: Tagging and Visibility

Optimization without visibility produces results you cannot measure and savings you cannot attribute. The AWS Well-Architected Framework for EKS cost optimization explicitly calls out defining and enforcing cost allocation tagging as the first pillar. Source: AWS cost optimization for Kubernetes on AWS.

At minimum, tag every EC2 node with the cluster name, the node group or NodePool name, and the environment (production vs staging vs dev). With these tags, AWS Cost Explorer can show you EC2 spend by cluster and environment, making it possible to see which clusters are driving cost and which optimization actions are moving the number.

For workload-level cost visibility within a cluster, the same namespace and label-based approach described in Kubernetes cost allocation applies: labels on pods aggregate through cost allocation tools (Kubecost, OpenCost, AWS Container Insights) to show spend by team, service, and environment at the pod level.

How Usage.ai Fits Into EKS Cost Optimization

Usage.ai handles the Compute Savings Plan and Reserved Instance layer for EKS — the commitment purchasing that sits beneath Karpenter’s dynamic node selection. The platform analyzes actual EC2 spend across EKS worker node groups, identifies the stable compute floor (the on-demand EC2 spend that persists after Spot optimization is in place), and sizes Compute Savings Plan recommendations to that floor.

Because Usage.ai recommends Compute Savings Plans rather than EC2 Reserved Instances for Karpenter-managed clusters, the commitment follows the compute spend rather than a fixed instance type. When Karpenter shifts between instance types, the Savings Plan discount continues applying. The commitment and the autoscaler stay aligned rather than working against each other.

The buyback guarantee matters specifically for EKS environments where cluster scale can change significantly. If a commitment covers EC2 spend that subsequently drops because a cluster is decommissioned, consolidated, or migrated to Fargate, the unused portion comes back as cashback in real money rather than sunk cost. That changes the sizing decision from conservative to accurate.

$91M+ in savings delivered to 300+ customers across AWS, Azure, and GCP. Fee is a percentage of realized savings only. No savings, no fee. 30-minute setup, billing-layer access only.

Frequently Asked Questions

1. How much does an EKS cluster cost?

An EKS cluster has two cost components: the control plane fee and the worker node EC2 costs. The control plane fee for Standard Kubernetes version support is $0.10 per cluster per hour, approximately $73 per month. Extended Kubernetes version support (providing an additional 12 months beyond standard support) carries a higher per-hour fee. Worker nodes are standard EC2 instances billed at on-demand, Spot, Reserved, or Savings Plans rates depending on how you provision them. EKS Auto Mode adds an additional per-instance management fee on top of EC2 costs. Source: aws.amazon.com/eks/pricing/.

 

2. Why are Compute Savings Plans better than Reserved Instances for Karpenter?

EC2 Reserved Instances apply to a specific instance family, size, and operating system. Karpenter selects instance types dynamically based on workload requirements and pricing, meaning it may provision m5.xlarge one day and m6i.xlarge the next. A Reserved Instance for m5.xlarge strands when Karpenter migrates to m6i.xlarge — you pay for the reservation while on-demand rates apply to the actual running nodes. Compute Savings Plans apply regardless of instance family, size, or operating system, so the discount follows Karpenter’s dynamic instance selection. For fixed-type node groups with stable instance families, EC2 Reserved Instances or EC2 Instance Savings Plans remain appropriate.

 

3. How much can Spot instances save on EKS?

Spot instances provide up to 90% savings compared to on-demand EC2 prices. Source: aws.amazon.com/ec2/spot/. Real-world savings depend on the instance types used, the stability of Spot capacity in your region, and how much of your workload tolerates interruption. Teams using Karpenter with diverse NodePool instance configurations have achieved 80% Spot adoption in production with acceptable interruption rates. Karpenter uses the Price Capacity Optimized strategy for Spot provisioning, which selects from capacity pools with the lowest interruption risk.

 

4. What is EKS Auto Mode?

EKS Auto Mode is a fully managed compute model launched in late 2024 that automates node provisioning, scaling, and core cluster add-ons. It charges an additional per-instance management fee on top of standard EC2 instance prices, billed per-second with a one-minute minimum. You can use On-Demand, Reserved Instances, Compute Savings Plans, and Spot Instances with EKS Auto Mode — the management fee applies regardless of the EC2 purchase option. Source: aws.amazon.com/eks/pricing/.

 

5. Should I use Fargate or EC2 nodes for EKS?

Fargate works well for bursty, intermittent workloads where pod-level billing avoids paying for idle node capacity. EC2 nodes with Savings Plan coverage are consistently cheaper for always-on, resource-intensive workloads because the per-vCPU Fargate rate exceeds on-demand EC2 for equivalent compute, and there is no Spot equivalent for EKS Fargate. Compute Savings Plans cover both EC2 and Fargate spend, so a single commitment can cover a mixed fleet. The right choice depends on the specific workload pattern.