---
title: Reserved Instances vs Savings Plans on AWS (2026): The Three-Way Choice, the 22-Month Break-Even, and When to Skip Commitment Entirely
description: Most "RI vs Savings Plan" content treats them as peers. In mid-2026 they are not. A 3-year All-Upfront Compute Savings Plan saves a composite ~$60k/mo SaaS roughly $864k over 3 years vs a 1-year No-Upfront plan—but breaks even at ~22 months and locks instance-family flexibility. Buy the wrong commitment and a Graviton migration strands the discount. Here is the decision tree we use.
url: https://www.factualminds.com/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/
datePublished: 2026-06-02T00:00:00.000Z
dateModified: 2026-06-02T00:00:00.000Z
author: Palaniappan P
category: Cost Optimization & FinOps
tags: savings-plans, reserved-instances, cost-optimization, finops, ec2, aws
---

# Reserved Instances vs Savings Plans on AWS (2026): The Three-Way Choice, the 22-Month Break-Even, and When to Skip Commitment Entirely

> Most "RI vs Savings Plan" content treats them as peers. In mid-2026 they are not. A 3-year All-Upfront Compute Savings Plan saves a composite ~$60k/mo SaaS roughly $864k over 3 years vs a 1-year No-Upfront plan—but breaks even at ~22 months and locks instance-family flexibility. Buy the wrong commitment and a Graviton migration strands the discount. Here is the decision tree we use.

**As of June 2026, AWS still publishes Reserved Instance discounts for EC2**—but the practical landscape has narrowed. Savings Plans, introduced in 2019 and now covering EC2, Fargate, Lambda, and SageMaker training and inference, dominate the compute decision. Reserved Instances remain mandatory only for stateful database services: RDS, ElastiCache, Redshift, and OpenSearch. The cost playbook from 2021 — "compare RI and Savings Plan discounts, pick the higher one" — produces measurably worse outcomes than the three-way framing this post recommends.

This is for FinOps leads, platform engineers, and CTOs who are mid-year-budget-review and need to commit $200k+ to AWS without buying the wrong instrument. We model the math against a real on-site calculator ([Savings Plans calculator](/tools/aws-savings-plans-calculator/) and [Reserved Instance calculator](/tools/aws-reserved-instance-calculator/)) and ship a downloadable [commitment comparison CSV](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/ri-vs-savings-plans/commitment-comparison.csv) you can adapt to your own rates.

> **Benchmark pattern (not a cited client)** — A composite 30-engineer B2B SaaS, ~$60k/mo steady-state EC2 (m5/m6i mix) + ~$12k/mo RDS Multi-AZ + ~$8k/mo S3/data egress, growing ~25% YoY with an m5 → m7g Graviton migration planned in the next 18 months. Modeled in the [commitment comparison CSV](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/ri-vs-savings-plans/commitment-comparison.csv): a 1-year No-Upfront Compute Savings Plan saves ~$432k over 3 years vs on-demand; a 3-year All-Upfront Compute SP saves ~$864k; an EC2 Instance SP at +10 percentage points headline saves ~$1.08M *only if the workload stays on the same family for 36 months*. A Standard RI on m5 bought four months before the Graviton migration becomes a stranded commitment at month 14.

## The decision is not "RI vs Savings Plan" — it's a three-way choice

The 2021 framing — "Reserved Instances vs Savings Plans, pick the higher discount" — quietly stopped being correct in 2024 when Savings Plans expanded to SageMaker and AWS deprecated the EC2-Convertible RI as the default flexibility tool. By mid-2026 the real choice on compute spend is:

| Instrument | Flexibility | 2026 typical list discount | Use when |
| --- | --- | --- | --- |
| **Compute Savings Plan** | Cross-family, cross-region, cross-OS, cross-product (EC2 + Fargate + Lambda + SageMaker) | 20–40% | Default for any compute spend. Survives Graviton migrations. |
| **EC2 Instance Savings Plan** | Pinned to a single instance family + region | 30–50% | Stable workload, region-pinned, no migration plan for the full term |
| **Reserved Instance (Standard)** | Pinned to family + AZ (or regional) for EC2; only option for RDS/ElastiCache/Redshift/OpenSearch | 30–55% (EC2); 30–55% (RDS) | RDS/ElastiCache/Redshift/OpenSearch (no SP option); EC2 only with written "no migration" sign-off |

**Opinionated take:** Default to a 1-year No-Upfront Compute Savings Plan at 60–80% of steady-state compute spend. Step up to 3-year only when (a) workload survival horizon ≥ 22 months, (b) finance can absorb the prepayment, (c) instance-family roadmap is settled, and (d) the workload is not in scope for an M&A or org redesign. Use EC2 Instance SP only when you can name the region and family in writing. Use Reserved Instances only when Savings Plans do not apply (RDS, ElastiCache, Redshift, OpenSearch), or for a single niche EC2 case described below.

## Step 1: Match the product to the workload (compute vs stateful data)

Savings Plans only apply to four products in 2026: EC2, Fargate, Lambda, and SageMaker. If your spend is on RDS, ElastiCache, Redshift, or OpenSearch, the Savings Plans path does not exist — you are choosing between on-demand and Reserved Instances. Most over-commitment failures we see start here: a FinOps lead signs a "Compute Savings Plan to cover our database spend" — which silently does not cover RDS, leaves the database on-demand, and produces a smaller discount than expected.

Stateful data commitments use traditional RI mechanics (engine + instance class + term + payment option), with the same Standard / Convertible split EC2 had. Discounts in 2026 sit in the 30–55% list band depending on engine and term.

## Step 2: Pick your flexibility ceiling (Compute SP > Instance SP > RI)

For compute spend that *does* have a Savings Plans option, the flexibility-vs-discount trade is the real decision:

- **Compute Savings Plan** is the most flexible. It applies the committed dollar/hour rate across EC2 instance families, regions, operating systems, tenancies, *and* across Fargate, Lambda, and SageMaker. It is the only commitment that survives an x86 → Graviton migration cleanly.
- **EC2 Instance Savings Plan** pins to a single instance family and region (e.g. `m6i` in `us-east-1`). Headline discount is 5–10 percentage points better than Compute SP. Anything that moves the workload off that family + region — capacity issue, regional outage, instance type change, or a Graviton migration — strands the commitment.
- **Reserved Instance (Standard)** has the highest headline discount for EC2 but is the least flexible. Standard RIs can be sold on the RI Marketplace, which is the one operational advantage they retain over Savings Plans.

The trap: the +5–10 percentage points from Instance SP looks like free money until the first time you need to change family or region. We have seen a stranded Instance SP commitment cost more in 18 months than the entire incremental discount earned in months 1–12.

> **What broke** — A team bought 3-year All-Upfront Standard RIs on `m5.large` in `us-east-1` for a ~$45k/mo workload, four months before the platform team started a Graviton migration to `m7g.medium` for further savings. The RIs did not apply to the new family, so on-demand spend on Graviton stacked on top of the RI prepayment. Detected via Cost Explorer's "Reservation utilisation" report dropping to 38% in month 5. Mitigation that worked: listed the unused RIs on the RI Marketplace for 60% of remaining value, accepted the ~$28k write-off, and reissued the new commitment as a 1-year No-Upfront Compute Savings Plan. Total drag: ~$28k. Same workload on a 3-year Compute SP from day one would have absorbed the family migration for zero loss.

## Step 3: Set coverage from your baseline-to-peak ratio

Coverage % — how much of your on-demand spend you commit to — is where most committed-spend money goes wrong. The rule of thumb is **not** "70% of bill" (which we hear from sales teams). It is **70% of the steady-state baseline**, where baseline is the trough hour of your weekly trough day.

Pull from Cost Explorer:
- `B` = average compute usage at your weekly low (typically Sun 03:00 UTC for B2B SaaS)
- `P` = peak hour usage
- `baseline_ratio = B / P`

A typical B2B SaaS sits around 0.65–0.85. The full math is in the [coverage target worksheet](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/ri-vs-savings-plans/coverage-target-worksheet.md). The short version:

| Baseline-to-peak | Coverage target | Why |
| --- | --- | --- |
| ≥ 0.85 | 75–85% | Flat shape; over-commit risk is low |
| 0.65–0.85 | 65–75% | Standard SaaS; covers baseline + shoulder hours |
| 0.40–0.65 | 50–65% | Spiky/9-to-5; commit baseline only |
| < 0.40 | ≤ 40% or skip | Event-driven; look at Spot, scheduled scaling, or Compute Optimizer first |

Adjust for projected growth (+/-% over the next 12 months), bound by `[0, total compute spend]`. Cap at 85% so you keep on-demand headroom for incident response and product launches.

## Step 4: Choose the term — the 22-month break-even rule

The most common mistake we see on 3-year All-Upfront commitments is underestimating workload survival horizon. The break-even for a 3-year All-Upfront Compute SP vs pay-as-you-go on a typical workload sits at month 18–22 of the term. If the workload sunsets, materially shrinks, or moves accounts before month 22, the discount has not paid back the prepayment.

The bar for 3-year All-Upfront is all four of:

1. Workload survival horizon ≥ 22 months — supported by the product roadmap, not by hope.
2. Finance can prepay the full commitment without breaching banking covenants or runway.
3. Instance-family roadmap is settled for the full 36 months — Graviton plan is either done or off the table.
4. No M&A or org redesign is in flight that would move the workload across AWS Organizations.

If you cannot tick all four, drop to 1-year No-Upfront. The break-even on 1-year No-Upfront Compute SP is near zero — you pay the rate only as you use it, and the worst case if you over-commit is the unused commit fee at the end of the year.

> **Reproduce this** — Clone the [commitment comparison CSV](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/ri-vs-savings-plans/commitment-comparison.csv) and the [coverage target worksheet](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/ri-vs-savings-plans/coverage-target-worksheet.md). Replace the illustrative discount bands with your actual rates from the on-site [Savings Plans calculator](/tools/aws-savings-plans-calculator/) or [AWS Pricing Calculator](https://calculator.aws/). Pull `B` and `P` from a 90-day Cost Explorer window. The "failed at month 14" row is the m5 → m7g Graviton failure mode — leave it in the file as a counter-example.

## What to do this week

1. Pull a 90-day Cost Explorer window. Compute `baseline_ratio = weekly_low / peak_hour` for compute spend only (EC2 + Fargate + Lambda + SageMaker), separately from stateful data spend (RDS/ElastiCache/Redshift/OpenSearch).
2. Score the four "3-year-ready" criteria for each workload in scope. If any fails, drop that workload's plan to 1-year No-Upfront.
3. Plug your numbers into the [coverage target worksheet](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/ri-vs-savings-plans/coverage-target-worksheet.md). Bound the coverage target by `baseline_ratio × (1 + growth)`, capped at 85%.
4. Write the over-commit recovery plan **before** signing. It belongs in the same doc as the commitment proposal — what happens if utilisation falls below 90% for 30 days, below 75% for 30 days, or a major migration is announced.
5. If the workload mix spans EC2 + Lambda + Fargate + SageMaker, the answer is almost always Compute SP. Resist the +5–10 points from Instance SP unless region + family is contractually locked.

## What this post doesn't cover

- **EC2 Spot** and Spot best-effort strategies — separate decision layer from commitment-based discounts. See [EC2 Spot intelligent selection](/blog/ec2-spot-instance-intelligent-selection-cost-optimization/).
- **Capacity Reservations** (on-demand capacity guarantees, not discount instruments).
- **SageMaker training-specific Savings Plans math** — different discount structure from compute SP on inference.
- **2026 Bedrock Provisioned Throughput** commitments — separate AI-spend instrument.
- **Aurora Serverless v2** capacity commitments (Aurora I/O-Optimized vs Standard is a separate decision).
- **DynamoDB Reserved Capacity** — niche, declining usage pattern; not covered here.

---

**Related:** [Cost control architecture](/blog/aws-cost-control-architecture-optimization-playbook/) · [FinOps on AWS](/blog/finops-on-aws-complete-guide-cloud-cost-governance/) · [FinOps gap and cost ownership](/blog/aws-finops-gap-engineering-cost-ownership/) · [AWS cost optimization services](/services/aws-cloud-cost-optimization-services/)

**If you only do one thing:** Pull the 90-day baseline-to-peak ratio for your compute spend today. Coverage target = `baseline_ratio × (1 + growth)`, capped at 85%. That single number decides whether you should be looking at a 1-year or 3-year commitment at all.

## FAQ

### Are Reserved Instances being deprecated in 2026?
No. AWS still publishes EC2 RI discounts and continues to sell them, and RIs remain the only commitment instrument for RDS, ElastiCache, Redshift, and OpenSearch (Savings Plans do not apply to those services in 2026). What has changed is the practical EC2 decision: for compute spend that touches Lambda, Fargate, EC2, and SageMaker, Compute Savings Plans dominate because they follow instance-family changes (including x86 → Graviton) and span products. EC2 RIs are now niche even for EC2 — useful for a stable, region-pinned family with no migration plan, or for selling on the RI Marketplace.

### When should we NOT buy a 3-year Savings Plan?
Skip 3-year commitments if any of: workload survival horizon is below 22 months (the typical 3-year All-Upfront break-even); finance cannot prepay 100% without straining runway; an instance-family migration (x86 → Graviton, or a sizing redesign) is planned during the term; the workload is pre-product-market-fit; an M&A or org redesign is in flight that would move accounts across AWS Organizations. A 1-year No-Upfront Compute SP has a near-zero break-even and survives most of these scenarios; default there and only step up to 3 years when all four conditions are met.

### Compute Savings Plan vs EC2 Instance Savings Plan — which one for a stable workload?
Default Compute SP. The headline rate on an EC2 Instance SP is 5–10 percentage points better, but Instance SP locks you to a single instance family and region for the term. One regional capacity issue or one mid-term family migration (e.g. m6i → m7g for Graviton economics) and the locked discount strands. The extra 5–10% from an Instance SP rarely beats the cost of one mid-term disruption. Only choose EC2 Instance SP if you can name the region + family today, the workload is provably staying there for the entire term, and you have written sign-off on no migration plans.

### What happens to our commitment if we migrate from x86 to Graviton mid-term?
It depends on the instrument. A Standard Reserved Instance is pinned to the original instance family (e.g. m5) — Graviton (m7g) is a different family, so the RI no longer applies and you pay on-demand on the new family while still holding the old RI. A Convertible RI can be exchanged for the new family at AWS list rates, with a lower headline discount than Standard. A Compute Savings Plan follows you across the move — same dollar/hour rate applies to both x86 and Graviton compute. An EC2 Instance SP behaves like a Standard RI and strands. This is the single biggest reason to default to Compute SP in 2026.

### When does it still make sense to buy Reserved Instances in 2026?
For RDS (including Aurora MySQL/Postgres in the older RI model, not the Aurora Serverless v2 capacity model), ElastiCache, Redshift, and OpenSearch — these services have no Savings Plans equivalent in 2026, so RIs are the only commitment tool. For EC2 specifically: a Standard RI still makes sense for a workload pinned to a single family and region for the full term, where you have a written "no migration" plan, and where the extra ~5–10 percentage points vs Compute SP is meaningful at your scale. Convertible RIs are rare in 2026 — Compute SPs deliver the same flexibility with cleaner mechanics.

### How do we recover if we over-commit and our usage drops?
The recovery options depend on the instrument and they are not symmetric. Reserved Instances: Standard RIs can be listed on the AWS Reserved Instance Marketplace (no Convertible sale; partial sale only for whole-RI multiples). Convertible RIs can be exchanged for a different family or term. Savings Plans: there is no marketplace and no cancellation — once signed, you pay the committed dollar/hour for the full term whether you use it or not. The mitigation is preventive: cap coverage at the baseline-to-peak ratio, write a recovery plan (shift dev workloads onto the same family/region to absorb commit), and lower the next commitment cycle. Plan over-commit recovery before signing, not after.

---

*Source: https://www.factualminds.com/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/*