Savings Plans or Reserved Instances: which one for your EKS cluster

Both give a discount in exchange for a 1 or 3 year commitment, so they look interchangeable. For an EKS cluster, the difference is how locked in you are to an instance family and whether you need guaranteed capacity.

What each one is

• Compute Savings Plans are an hourly spend commitment. They apply to EC2 of any family, size, region, operating system and tenancy, plus Fargate and Lambda. This is the most flexible option.
• EC2 Instance Savings Plans are also an hourly spend commitment, but tied to one instance family in one region. In exchange, the discount AWS advertises is higher.
• Reserved Instances (RI) are a commitment on instance attributes. Standard RIs have the highest discount and fixed attributes. Convertible RIs let you exchange attributes, with a smaller discount.

Percentages vary by instance, region, term and payment option (all upfront, partial or no upfront). Check the AWS pricing table before deciding.

The differences that matter day to day

One point changes the decision: Savings Plans do not reserve capacity. If you need a guarantee that the instance exists in a given zone, that is solved with an On-Demand Capacity Reservation, which can be combined with a plan. Confirm the current rules in the AWS documentation.

Which one fits with Karpenter

Karpenter picks the instance type on the spot, and the mix changes with price, availability and your NodePool rules. A commitment tied to one family works poorly here: if the cluster starts using another family, the discount stops covering the usage.

That is why, for the stable base of an EKS cluster, the Compute Savings Plan is usually the starting point. It follows family changes, and a move to Graviton as well, without you having to buy again. The EC2 Instance Savings Plan only pays off if the family stays stable for the whole term.

Where Reserved Instances still show up

Some managed services, such as databases and caches, traditionally use Reserved Instances instead of Savings Plans. AWS has been widening plan coverage, so check the pricing page to see whether the service you use is already covered. If it is not, RI is still the way to discount that spend.

An order that works

1. Rightsize first. Commitment on inflated requests locks in waste for 1 to 3 years. Use rightsizing-check.
2. Decide what goes to Spot. Spot does not consume Savings Plans, so whatever moves leaves the committed base. See how to combine Spot and Savings Plans.
3. Commit only the stable base, what runs 24/7 and does not go to Spot. Committing the peak is the classic mistake.
4. Prefer Compute Savings Plans for EKS and keep RIs for what the plans do not cover.
5. Buy in layers. Instead of one big commitment, buy in steps over time, so you are not locked to an old snapshot of the cluster.
6. Review coverage and utilization every quarter, and before any architecture migration.

Common mistakes

• Buying before rightsizing.
• Buying an EC2 Instance Savings Plan and then migrating to Graviton, which leaves the commitment pointing at a family you no longer use.
• Moving workloads to Spot without revisiting the commitment, and paying for an underused plan.
• Committing an amount based on the peak month.
• Forgetting the term: 3 years only makes sense for a very stable base.

To estimate

The Savings Plans estimator shows how different coverage levels affect your bill, and the savings calculator adds up rightsizing, Spot and Graviton. The numbers are estimates: real measurement depends on your workloads. If you want me to build the commitment strategy for your environment, the efficiency assessment is the starting point.