Savings Plans vs Reserved Instances in 2026: The Complete Decision Tree

Four commitment mechanisms coexist today on AWS to cut the compute bill: Compute Savings Plans, EC2 Instance Savings Plans, Standard Reserved Instances, and Convertible Reserved Instances. On paper, they all do the same thing — trade a time commitment for a lower rate. In practice, they behave very differently when an instance generation changes, an architecture pivots, or you need guaranteed capacity.

What we see in FinOps engagements: most audited organizations either have a legacy mix of one-off purchases with no overall logic, or — worse — no commitment at all on a baseline that has been stable for years, out of fear of picking the wrong mechanism. Both situations are expensive. This article lays out the method: a decision tree, not a glossary.

The 4 mechanisms, what they actually cover

Before the decision tree, the facts need to be pinned down. These are AWS’s own published figures, not third-party estimates.

Two points routinely get missed in the generic comparisons you find online:

A Savings Plan does not reserve capacity. It cuts the bill, full stop. If you need a guarantee that instances will be available in a given AZ — a common case for GPU (p4d, p5) during supply-constrained periods — only a zonal Reserved Instance provides that. This is the most expensive confusion we run into during audits: a team believes it secured capacity with a Compute SP, then discovers on launch day that it didn’t.

Only the Standard RI is resellable. RI Marketplace lets you offload the remaining months of a commitment if the project changes direction. No other mechanism — not EC2 Instance SP, not Convertible RI, not Compute SP — offers that exit door. That’s a real safety net for a 3-year commitment at an organization whose 3-year roadmap is never guaranteed.

The decision tree

The method we apply on engagements comes down to four questions, in this order:

1. Has the workload been stable for more than 6 months?

No — no commitment. An unconfirmed baseline committed for 1 or 3 years is the scenario that generates the most waste we see in audits: reserved instances running half-empty because the product pivoted in the meantime. Stay On-Demand (or Spot for interruption-tolerant workloads) until you have 3-6 months of stable metrics via Cost Explorer.

2. Can the instance/service mix change before the term ends?

Yes — instance family, region, or a possible move to Fargate/Lambda → Compute Savings Plan. It’s the only mechanism that follows the workload automatically, with no loss of discount, as it changes shape. It’s also the default recommendation for an organization that doesn’t yet have fine-grained 3-year visibility into its architecture — flexibility is worth more than the few extra points of discount from a rigid commitment.

3. Do you need a capacity guarantee?

Yes (GPU, specialized instance in a supply-constrained zone) → zonal Standard RI, the only mechanism that combines a price cut with a capacity reservation. No → move to question 4.

4. Can the project’s configuration change before the term ends?

Yes, but you want to keep the commitment (just swap the config) → Convertible RI, exchangeable for another family or region of equal or greater value. No, the configuration is locked in for the term → final arbitration between EC2 Instance SP and Standard RI, which offer the same discount ceiling (72%). At this point the deciding factor is no longer price but optionality: the Standard RI can be resold if the project changes direction anyway, the EC2 Instance SP cannot.

The generation-refresh trap

One factor generic comparisons routinely miss: the pace at which new instance generations ship. AWS launched the C8i/C8a families in 2025 and kept up the pace into 2026 (C8in/C8ib announced in spring), with a price/performance gain that makes commitments on older generations (C6i, C7i) increasingly questionable as the cycle progresses.

Only two mechanisms absorb that risk with no downside: the Compute Savings Plan, which follows any family, including a new generation launched mid-commitment, and the Convertible RI, manually exchangeable for the new generation. A Standard RI or EC2 Instance SP bought on a C6i family in 2024 stays billed on that family until the term ends, even if C8i becomes economically superior in the meantime — a rarely quantified but real opportunity cost on a 3-year commitment.

Practical rule: on a 3-year commitment, favor the Compute SP or Convertible RI as soon as the instance family is more than 18 months old at purchase time — the obsolescence risk over the commitment period outweighs the discount gain of the rigid mechanism.

Worked example: a 20-instance m6i.xlarge baseline

Take a representative case: a backend stable for over a year, 20 m6i.xlarge instances (4 vCPU, 16 GiB) running 24/7. At the public On-Demand rate ($0.192/hr), the reference monthly bill is roughly $2,803 (20 × $0.192 × 730 hrs).

On this specific profile — a confirmed baseline, a single instance family, no architecture change planned within 3 years — the 3-year Standard RI remains the most cost-effective option in absolute terms, with the added bonus of the RI Marketplace exit door if the roadmap changes. This is exactly the case where question 4 of the decision tree tips toward RI over EC2 Instance SP: at comparable discount, optionality wins.

What we recommend in practice

1. Never commit 100% of the baseline. Cover 70-80% of the floor observed over 90 days, leave the rest On-Demand to absorb seasonal variance — re-tune the split every quarter via Cost Explorer.
2. Start with 1-year terms, not 3-year, as long as the stability track record is under 12 months — the discount delta between 1 and 3 years (roughly 20 points on a Standard RI) doesn’t offset the risk of obsolescence or a product pivot on a young stack.
3. Default to Compute SP on any workload without a documented need for capacity reservation — it’s the choice that minimizes operational risk, even if it isn’t always the cheapest option down to the last percentage point.
4. Audit the existing commitment portfolio every quarter via the AWS Cost Explorer Savings Plans / RI utilization report — an under-utilized commitment (coverage < 90%) signals a workload change that hasn’t been followed by an adjustment.

aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-09-01 \
  --granularity MONTHLY \
  --query 'SavingsPlansUtilizationsByTime[].Total.{Coverage:UtilizationPercentage,Savings:NetSavings}' \
  --output table

Conclusion

The choice between Savings Plans and Reserved Instances isn’t about “which is cheapest” — on a comparable 3-year commitment, both ceilings converge at 72%. The real question is risk: architecture-change risk (Compute SP), generation-obsolescence risk (Convertible RI or Compute SP), guaranteed-capacity need (zonal RI), exit-door need (resellable Standard RI). This article’s decision tree covers those four axes in the order they should actually be asked.

If your AWS commitment portfolio hasn’t been reviewed in over a quarter, or you’re still torn between the two mechanisms on a new project, let’s talk — a typical FinOps audit identifies optimal coverage and the right commitment mix for your trajectory in 3 to 5 days.