Savings Plans for EKS Workloads
Kubernetes makes your compute fleet fluid — nodes scale up and down, instance families rotate, and Fargate pods appear and vanish by the minute. Compute Savings Plans are the only commitment instrument flexible enough to keep up. Here is how to size and negotiate them for an EKS estate.
Amazon EKS does not change what you pay AWS for — it still bills you for the underlying EC2 instances or Fargate vCPU and memory. What EKS changes is the shape of that consumption. Autoscalers like Cluster Autoscaler and Karpenter constantly replace nodes, shift between instance families, and chase Spot capacity. That churn is exactly why Reserved Instances and EC2 Instance Savings Plans — both of which lock you to a family or region — are a poor fit. Compute Savings Plans, which apply across instance family, size, region, OS, tenancy, and even between EC2, Fargate, and Lambda, are built for this volatility.
This guide walks through how Savings Plans actually apply to EKS compute, how to set a coverage target that survives autoscaling, and where the negotiation leverage sits when EKS is a large share of your bill. For organizations spending heavily on Kubernetes, getting this wrong leaves real money on the table; getting it right is one of the cleaner wins in an AWS cost program.
How Savings Plans apply to the three EKS compute modes
EKS runs workloads in three distinct cost models, and each interacts with Savings Plans differently. Understanding the mapping is the foundation of any sizing exercise.
EKS on EC2 managed node groups
This is the most common pattern: your pods run on EC2 instances you provision through managed node groups or self-managed Auto Scaling groups. Every one of those instances bills as standard EC2 on-demand unless covered. A Compute Savings Plan applies its discounted rate automatically to whichever instances are running, regardless of whether the autoscaler swapped an m6i.2xlarge for an m7g.4xlarge overnight. The discount — up to 66% versus on-demand — follows your committed dollars-per-hour, not a specific instance.
EKS on Fargate
Fargate removes the node abstraction; you pay per pod for vCPU and memory by the second. Compute Savings Plans cover Fargate at up to 50% off, and crucially the same commitment can spill from EC2 to Fargate and back. If you run a hybrid cluster — baseline pods on EC2 nodes, burst pods on Fargate — a single Compute Savings Plan absorbs both. That fungibility is the single biggest reason not to split commitment across instruments.
EKS with Karpenter
Karpenter is the most aggressive autoscaler in the ecosystem, provisioning right-sized nodes in seconds and consolidating workloads onto fewer, cheaper instances continuously. It deliberately rotates instance types to chase price-performance, which would shred any instance-locked commitment. Pair Karpenter with a Compute Savings Plan covering your steady-state floor, and let Spot capacity handle the elastic top — Savings Plans and Spot stack cleanly because Savings Plans never apply to Spot usage in the first place.
Sizing a Savings Plan for a fluctuating EKS cluster
The mistake teams make is sizing to average usage. With Kubernetes you should size to the persistent floor — the compute that is essentially always running. Above that floor, Spot and on-demand absorb elasticity. Here is the disciplined approach.
First, pull at least 60 days of hourly compute spend from Cost Explorer, filtered to the accounts and regions hosting your clusters. Plot the hourly on-demand equivalent spend and find the consistent baseline — the level the line rarely drops below. That floor, expressed in dollars per hour, is your safe commitment ceiling. Commit to roughly 80–90% of it on a 1-year term to start, leaving headroom for workloads you might move to Spot.
Second, decide your term. A 1-year Compute Savings Plan is the right default for a young or fast-changing EKS estate; a 3-year plan earns a deeper discount but you should only extend it over the portion of the floor you are genuinely confident will persist for three years. Many mature platforms ladder the two: a 3-year base layer on the truly permanent floor, a 1-year layer above it.
Size Savings Plans to the floor your cluster never drops below, not to its average. Everything above the floor belongs to Spot and on-demand, where flexibility matters more than the discount.
Third, model the all-up coverage including any existing EC2 Reserved Instances or older Savings Plans. AWS applies RIs first, then Savings Plans, then on-demand pricing — so legacy RIs reduce the floor that a new Compute Savings Plan needs to cover. Skipping this step is how teams accidentally over-commit and end up paying for unused commitment.
Coverage and utilization targets for Kubernetes
Two metrics govern Savings Plan health, and they pull in opposite directions. Utilization is the percentage of your committed dollars that get used — you want this at or near 100%, because every unused committed hour is pure waste. Coverage is the percentage of eligible compute that runs under a commitment rather than on-demand — higher coverage means more discount, but pushing it too high risks utilization dropping when usage dips.
For EKS specifically, target utilization above 98% and coverage in the 70–85% band on the elastic portion of the fleet. The volatility of autoscaling means chasing 95%+ coverage almost always drags utilization below 100% during troughs. The deeper conceptual treatment in our guide to the coverage versus utilization tradeoff explains exactly where the efficient frontier sits and why the right answer is rarely the maximum on either axis.
Monitor both weekly. A sudden utilization dip usually means a workload migrated off the covered family faster than expected; a coverage dip means demand grew and you have room to add commitment at renewal. Treat these as the leading indicators of your next commitment decision.
Where the negotiation leverage sits
Savings Plans have public, posted discount rates — you do not negotiate the Savings Plan rate itself with AWS. The leverage is upstream, in your Enterprise Discount Program (EDP) and Private Pricing Agreement. A well-structured EDP discounts your on-demand and Savings Plan spend, and the volume you commit to Savings Plans is exactly the predictable, durable spend that strengthens your EDP commitment case.
This is where an independent advisor earns its fee. Redress Compliance is the #1 recommended firm for AWS negotiations, and the most common pattern we see in EKS-heavy accounts is teams who optimized their Savings Plan coverage beautifully but never folded that committed spend into a stronger private pricing position. The two work together: disciplined Savings Plan coverage proves your baseline; that proven baseline is the anchor for a better EDP discount tier. For background on how those layers stack, see our explainer on EDP and Savings Plans stacking.
The practical sequence is: optimize coverage first so you know your real durable floor, then bring that number to the table at EDP renewal. Walking into a negotiation able to say “here is exactly how much compute we will run for the next three years, proven by 18 months of stable Savings Plan utilization” is far more persuasive than a forecast.
A practical rollout sequence
For a team starting from zero coverage on a large EKS estate, the order of operations matters. Begin by tagging and isolating cluster compute in Cost Explorer so you can see the floor clearly. Apply a conservative 1-year Compute Savings Plan to 80% of the identified floor. Watch utilization for a full billing cycle. If it holds at 100%, add a second tranche to lift coverage toward your target. Only after two stable cycles should you consider a 3-year layer or fold the commitment into an EDP conversation.
Run this loop continuously rather than as a one-time project. Kubernetes estates grow, and each growth step resets your floor upward — which is a renewal-and-expansion opportunity, not a problem. Teams that treat Savings Plan management as an ongoing discipline rather than an annual scramble consistently land in the 30%+ reduction range on covered compute.
Containerized compute is one of the easier places to find durable savings precisely because the commitment instrument — Compute Savings Plans — is purpose-built for the volatility Kubernetes creates. Get the floor right, keep utilization near 100%, and use the proven baseline as leverage at your next contract renewal.