# Savings Plans vs. Reserved Instances vs. On-Demand: The Commitment Decision

Canonical: https://kaansystems.com/library/savings-plans-vs-reserved-instances
Topic: FinOps · Published: 2026-09-16 · Updated: 2026-09-16
Summary: The commitment decision is a FinOps trap: sign for three years and you lock in whatever you're running, waste included. Savings Plans now beat Reserved Instances for compute for most regulated SMBs, but only after you rightsize and only across the stable part of the baseline. Here is the comparison, the coverage math, and the honest verdict.

## Key takeaways

- For compute (EC2, Fargate, Lambda), Savings Plans beat Reserved Instances for most regulated SMBs: you commit to a dollars-per-hour spend and keep flexibility across instance family, size, region, and OS. AWS steers most teams here.
- Rightsize before you commit. A commitment locks in whatever you are running, so a three-year term on an oversized fleet just buys three years of discounted waste.
- Cover roughly 70-80% of your stable baseline, not 100%. Leave spiky and uncertain usage on On-Demand (or Spot for interruptible batch) so you never owe an hourly commitment you outgrew — Savings Plans are not refundable or resellable.
- Compute SP (floats across family/size/region/OS, slightly lower discount) vs EC2 Instance SP (locked to a family+region, higher discount); Standard RI (locked, highest RI discount, sellable in the Marketplace) vs Convertible RI (exchangeable, lower discount, largely superseded by Savings Plans).
- The good-enough bar: 1-year terms when uncertain, 3-year only for genuinely durable workloads, partial-upfront as the default balance — and still buy Reserved Instances or reserved nodes for the non-compute services (RDS, ElastiCache, Redshift, OpenSearch) that Savings Plans do not cover.

**Savings Plans vs. Reserved Instances: which should you buy?** For compute — EC2, Fargate, and Lambda — Savings Plans win for most regulated SMBs, because you commit to a dollars-per-hour spend rather than to specific instances and keep flexibility across instance family, size, region, and operating system. Reserved Instances are the older mechanism, and AWS now steers most teams to Savings Plans; the place RIs still clearly belong is the services Savings Plans do not cover. On-Demand stays the right home for anything spiky or uncertain — it is the most expensive per hour and the most flexible, and you pay that premium on purpose.

This is the decision-stage companion to [the 30-day cloud cost cleanup](/library/30-day-cloud-cost-cleanup), whose fourth week is "commit." That plan tells you *when* to commit; this article settles *what to commit to*, and the trap it exists to prevent: signing a three-year deal before you have any business signing anything. The single most expensive mistake in this whole area is committing to waste, which is why the first move is not a purchase at all.

## What are On-Demand, Savings Plans, and Reserved Instances?

They are three ways to pay for the same compute, trading flexibility for discount. On-Demand is pay-as-you-go: the list rate, no commitment, turn it on and off whenever. Savings Plans and Reserved Instances are both commitments — you promise AWS a certain amount of usage for one or three years, and in exchange the per-hour rate drops. The difference between them, and the difference between the flavors within each, is *what exactly you are committing to*.

- **On-Demand** — the baseline. Highest price per hour, total flexibility, zero commitment. This is what everything costs before you optimize.
- **Compute Savings Plan** — you commit to a dollars-per-hour spend (for example, $10/hr) for 1 or 3 years. It floats: the discount applies to EC2 across any family, size, region, and OS, and to Fargate and Lambda too. Slightly lower discount than the locked options, in exchange for that flexibility.
- **EC2 Instance Savings Plan** — same dollars-per-hour commitment model, but locked to one instance family in one region (size and OS still float). Higher discount than the Compute plan, because you have given up most of the flexibility.
- **Standard Reserved Instance** — the older mechanism. You reserve a specific instance type for the term. Highest discount of the RI options, but locked; its one escape hatch is that you can sell it in the AWS Reserved Instance Marketplace if you no longer need it.
- **Convertible Reserved Instance** — an RI you can exchange for a different configuration during the term, at a lower discount, and which you cannot resell.

The mental model that matters: **Savings Plans commit to spend; Reserved Instances commit to instances.** Committing to spend is almost always the more forgiving promise for a team that is still rightsizing and still changing shape — which describes every SMB at 10 to 80 engineers.

## Savings Plans vs. Reserved Instances vs. On-Demand: how do they compare?

Discount rises as flexibility falls; the term length multiplies both the discount and the risk. The table is the whole decision in one view. Treat every discount figure as AWS's headline "up to" number — it assumes the most aggressive term and payment on specific families, and your blended, real-world discount will be lower. Verify current pricing before you model anything.

| Option | Discount vs On-Demand | Flexibility | Term | Best for |
|---|---|---|---|---|
| **On-Demand** | 0% (baseline, highest price) | Total — any instance, any time, no commitment | None | Spiky, short-lived, or uncertain workloads; anything you might turn off next month |
| **Compute Savings Plan** | up to ~66% (approximate, verify current) | High — floats across family, size, region, OS; covers EC2, Fargate, Lambda | 1 or 3 years | Your stable compute baseline while the fleet still changes shape |
| **EC2 Instance Savings Plan** | up to ~72% (approximate, verify current) | Low — locked to one family in one region (size/OS still float) | 1 or 3 years | A baseline you are confident stays on the same family in the same region |
| **Standard Reserved Instance** | up to ~72% (approximate, verify current) | Low — locked to instance type; **sellable** in the RI Marketplace | 1 or 3 years | Non-compute services (RDS, ElastiCache, Redshift, OpenSearch) and estates already standardized on RIs |
| **Convertible Reserved Instance** | up to ~66% (approximate, verify current) | Medium — exchangeable for other types, but **not** sellable | 1 or 3 years | Largely superseded by Compute Savings Plans; only if you already live in the RI model |

Two properties that the discount column hides but that decide real cases. First, **Savings Plans are not refundable or resellable.** Once you commit $10/hr for three years, you owe it whether or not you use it — there is no marketplace to unload it, unlike a Standard RI. That asymmetry is the single strongest argument for under-committing. Second, **Savings Plans provide no capacity reservation.** They lower your rate; they do not guarantee the instance is available in your AZ when you need it. If guaranteed capacity is the actual requirement, that is a zonal Reserved Instance or an On-Demand Capacity Reservation, not a Savings Plan.

## Compute vs. EC2 Instance Savings Plans — which flexibility do you buy?

Take the Compute Savings Plan unless a baseline is genuinely locked to one instance family in one region. The Compute plan floats across family, size, region, and OS, and stretches across EC2, Fargate, and Lambda, for a few points less discount. The EC2 Instance plan buys those few points back by nailing you to, say, the `m` family in `us-east-1` for the whole term.

For a team that is still rightsizing — and every SMB reading this is still rightsizing — the flexibility is worth more than the points. You will move a service from `m6i` to `m7g` (Graviton) for a 20% saving, you will shift a workload from `us-east-1` to a cheaper region, you will re-platform something onto Fargate. Under a Compute Savings Plan, every one of those changes stays covered automatically. Under an EC2 Instance plan or a Standard RI, each one either strands the commitment or forces an exchange. Reserve the EC2 Instance plan for the settled, boring core of the estate whose shape you can defend a year out.

## Standard vs. Convertible Reserved Instances — what's the difference?

A Standard RI is locked to an instance type for the term at the highest RI discount, and can be sold in the RI Marketplace; a Convertible RI can be exchanged for a different type during the term at a lower discount, and cannot be sold. Convertible RIs existed to solve the "I want a commitment but my instance types keep changing" problem — which is exactly the problem Compute Savings Plans now solve, more cleanly and with broader reach. There is very little reason to write a new Convertible RI in 2026. If you want flexible commitment, buy a Compute Savings Plan. If you want maximum discount on something that will never change and might need selling later, buy a Standard RI. The middle option has been eaten.

## Should you still buy Reserved Instances in 2026?

Mostly not for EC2, but yes for two specific cases. For general EC2 compute, a Compute Savings Plan gives you the same discount ballpark with dramatically more flexibility, so new EC2 commitments should default to Savings Plans. Reserved Instances still earn their place in two situations:

1. **Services without a Savings Plan.** RDS, ElastiCache, Redshift, and OpenSearch are covered by Reserved Instances or reserved nodes, not by compute Savings Plans. The steady-state of your managed databases and caches is prime RI territory, and the sister guide on [the 30-day cost cleanup](/library/30-day-cloud-cost-cleanup) commits RDS via one-year, no-upfront RIs for exactly this reason. (SageMaker has its own Savings Plans; the point stands that coverage is per-service, so verify current before you assume.)
2. **Guaranteed capacity.** When you need a specific instance *available* in a specific AZ — not just discounted — a zonal Standard RI carries a capacity reservation. A Savings Plan does not.

Everything else that used to be an RI decision is now a Savings Plan decision.

## What coverage ratio should you target, and for how long?

Rightsize first, then cover about 70-80% of the stable baseline on a 1-year term unless the workload is genuinely durable. The order is not negotiable, because a commitment is a discount on *whatever you are running* — and if you are running an oversized fleet, you have just locked in the oversizing at a discount for the length of the term.

**Rightsize before you commit.** Run the [rightsizing pass that shrinks instances without breaking production](/library/rightsizing-aws-without-breaking-production) first, and clear out idle and orphaned resources, so the number you commit against reflects the workload you actually need — not the one that accreted over two years. Committing before rightsizing is the most common and most expensive sequencing error in FinOps: it converts a fixable overspend into a contractual one.

**Cover the stable baseline, not the peak.** Split your usage into the flat floor that is always on and the spiky part that comes and goes. Commit to roughly 70-80% of the floor. The uncovered slice absorbs growth, migration, and the services you might retire, and interruptible batch belongs on Spot rather than under any commitment at all. Aiming for 100% coverage feels thrifty and is a trap: the first rightsizing or decommission strands an unsellable, unrefundable hourly commitment.

**Know what "stable" means before you sign.** You can only commit confidently to a baseline you can actually see, which means committed spend has to be attributable to a team and a service. If your allocation runs on [cost-aware tags that survive reorgs](/library/cost-aware-tagging), someone owns each commitment and its renewal; if it does not, you are committing against a number nobody trusts. Pull the AWS Cost Explorer Savings Plans recommendations, but sanity-check them against your own baseline rather than accepting the number the engine that profits from commitment hands you.

**Term and payment.** Default to 1-year when there is any uncertainty; take 3-year only for workloads whose shape you can defend a year from now. Partial-upfront is the usual balance — most of the all-upfront discount without draining the cash — though a regulated shop watching runway should check the delta before parking capital with a vendor for three years.

## Which should you pick?

Pick On-Demand for anything spiky or uncertain, a Compute Savings Plan for the stable compute baseline, and a locked option (EC2 Instance SP or Standard RI) only for the durable core you would bet on a year out. The verdict table:

| Your situation | The call |
|---|---|
| Spiky, seasonal, or uncertain usage; a workload you might kill next quarter | On-Demand (Spot for interruptible batch) |
| A stable compute baseline, but the fleet still shifts families/sizes | Compute Savings Plan, 1-year |
| A large, genuinely durable baseline on a settled family + region | EC2 Instance SP or Standard RI, 3-year |
| RDS, ElastiCache, Redshift, or OpenSearch steady-state | Reserved Instances / reserved nodes for that service |
| You need guaranteed capacity in a specific AZ | Zonal Standard RI or On-Demand Capacity Reservation |
| Mid-migration, instance types still moving | Compute Savings Plan, 1-year (or stay On-Demand until it settles) |

The good-enough bar: a regulated SMB has made the right commitment call when its stable baseline is discounted, its spiky usage is not committed, and no single commitment covers usage that no longer exists. You do not need a FinOps platform or a 95% coverage trophy to clear that bar — you need to rightsize first, cover 70-80% of the floor with Compute Savings Plans, keep Reserved Instances for the non-compute steady-state, and prefer 1-year terms until a workload has earned three years of trust. The only genuinely wrong move is the one that feels most decisive: signing a big three-year deal to look aggressive about cost, before anyone has rightsized the thing you are about to reserve.

## The Template

Work top to bottom. The first section gates the rest — if you have not rightsized, do not buy anything yet.

**Before you commit (rightsize first)**
- [ ] Rightsizing pass complete; over-provisioned instances downsized and idle/orphaned resources deleted
- [ ] Stable baseline separated from spiky/seasonal usage in Cost Explorer
- [ ] Committed spend is attributable to a team/service via tags, so someone owns each renewal
- [ ] You are committing against the workload you need, not the one that accreted

**Sizing the commitment**
- [ ] Coverage target set at ~70-80% of the stable baseline, not 100%
- [ ] Spiky/uncertain usage left on On-Demand; interruptible batch moved to Spot
- [ ] Cost Explorer Savings Plans recommendations pulled and sanity-checked against your own baseline number
- [ ] You have accepted that Savings Plans are non-refundable and non-resellable before sizing them

**Choosing the instrument**
- [ ] Compute Savings Plan chosen for compute unless a baseline is truly locked to one family+region
- [ ] EC2 Instance SP / Standard RI reserved only for the settled, durable portion
- [ ] Reserved Instances (or reserved nodes) bought for non-compute steady-state (RDS, ElastiCache, Redshift, OpenSearch)
- [ ] Convertible RIs avoided for new commitments (Compute SP replaces them)
- [ ] Capacity actually guaranteed (zonal RI / Capacity Reservation) where availability, not just price, is the requirement

**Term and payment**
- [ ] 1-year term when there is any uncertainty; 3-year only for genuinely durable workloads
- [ ] Partial-upfront chosen as the default; all-upfront only when the discount delta justifies the cash
- [ ] Discounts verified against current AWS pricing, not this article's approximate figures

**After you commit**
- [ ] Savings Plans / RI utilization + coverage dashboards reviewed monthly
- [ ] Renewal dates calendared so nothing lapses silently back to On-Demand
- [ ] Commitment review folded into the quarterly cost-cleanup cadence

Most teams find they have been either over-committed on the wrong instrument or entirely uncommitted and paying full On-Demand. Both are normal starting points. The path out is the same: rightsize, then commit to the durable 70-80% with the most flexible instrument that fits, and revisit it every quarter.

## Frequently asked questions

**Q: Savings Plans vs Reserved Instances — which is better?**

For compute — EC2, Fargate, and Lambda — Savings Plans are better for most regulated SMBs, because you commit to a dollars-per-hour spend rather than to specific instances and keep flexibility across instance family, size, region, and operating system. AWS itself now steers most teams to Savings Plans. Reserved Instances still belong in two places: the non-compute services Savings Plans do not cover (RDS, ElastiCache, Redshift, OpenSearch), and zonal capacity reservations, since a Savings Plan is a discount, not a guarantee of capacity in an Availability Zone.

**Q: Should I buy Reserved Instances in 2026?**

For EC2 compute, usually no: a Compute Savings Plan gives a comparable discount with far more flexibility, and Convertible RIs are effectively superseded by it. Still buy Reserved Instances (or reserved nodes) for the steady-state of services that have no Savings Plan — RDS, ElastiCache, Redshift, OpenSearch — and use a zonal Standard RI or an On-Demand Capacity Reservation when you actually need guaranteed capacity in an Availability Zone. Verify current service coverage before you assume, since AWS changes what Savings Plans apply to over time.

**Q: What coverage ratio should I target?**

Target roughly 70-80% coverage of your stable baseline, not 100%. The uncovered 20-30% stays on On-Demand as a buffer for growth, migration, and the workloads you might turn off, and interruptible batch belongs on Spot rather than under a commitment. Commit to 100% and the first time you rightsize or retire a service you are paying an hourly commitment against usage that no longer exists — and unlike a Standard RI, you cannot sell a Savings Plan to recover it.

**Q: 1-year vs 3-year commitment?**

Default to 1-year when there is any uncertainty about the workload, the instance family, or the roadmap; the discount is smaller but you are not married to a decision for three years. Reserve 3-year terms for genuinely durable workloads whose shape you can defend a year from now. Partial-upfront is the common balance: most of the discount of all-upfront without draining the cash, though a real regulated shop should still check the delta before parking capital with a cloud provider for three years.

**Q: Compute vs EC2 Instance Savings Plans?**

A Compute Savings Plan floats across instance family, size, region, and operating system, and applies to EC2, Fargate, and Lambda, at a slightly lower discount. An EC2 Instance Savings Plan locks you to a single instance family in a single region (size and OS still float) in exchange for a higher discount. Most SMBs should take the Compute Savings Plan: the flexibility is worth the few points, because you will rightsize and shift families before the term ends. Only reach for the EC2 Instance plan on a baseline you are confident stays on the same family in the same region.

**Q: What's the difference between Standard and Convertible RIs?**

A Standard Reserved Instance is locked to an instance type/family for the term but carries the highest RI discount and can be sold in the AWS Reserved Instance Marketplace if you no longer need it. A Convertible Reserved Instance can be exchanged for a different configuration during the term but earns a lower discount and cannot be sold. In practice, Compute Savings Plans now do what Convertible RIs were for — flexible commitment — only better, so new commitments rarely have a reason to be Convertible RIs.

Template: "Commitment decision checklist" — branded PDF at https://kaansystems.com/templates/savings-plans-vs-reserved-instances.pdf

Source: https://kaansystems.com/library/savings-plans-vs-reserved-instances · Work with Kaan Systems: https://kaansystems.com/contact