Reserved Instances (RIs) reserve a specific instance. Same family, size, OS, region, tenancy. If your running instance does not match, the discount does not apply.
Savings Plans (SPs) commit a dollar amount per hour. You commit $X/hour for 1 or 3 years and get a discount across a broad range of compute usage.
The more specific the commitment, the bigger the discount. Standard RI > Convertible RI > Savings Plan.
Use both. RIs for stable, predictable workloads. SPs for flexible or evolving ones. Convertible RIs when you want a middle ground.
AWS and Azure only. GCP uses a different model called CUDs — covered in a separate article.

Knowing the definition is not enough

You can ask ChatGPT what an RI is. That is the easy part. The hard part is knowing how the discount is actually applied — because that is what decides whether you save money or waste it.

I’ve seen teams buy 3-year RIs for instances that got retired six months later. I’ve seen teams stick with On-Demand because “commitments felt risky” while burning six figures a year in avoidable cost. Both mistakes come from the same place: not understanding the mechanics of how the discount attaches to usage.

This article walks through that mechanic. Once you understand it, the buying decision becomes obvious.

Three things to take away

RIs reserve a specific instance shape. The discount only applies when a running resource matches the reservation.
Savings Plans commit a dollar rate. The discount applies across eligible usage automatically, prioritising the highest savings first.
The discount tier follows the rigidity. The more you lock in, the more you save. The more flexibility you want, the more you pay for it.

Everything below is the mechanics behind those three points.

The travel analogy

The names tell you most of the story.

A Reserved Instance is booking seat 7B on flight NY213 from London to New York. A Savings Plan is committing to spend $500 on travel between London and New York — you can fly, sail, take any route, any airline.

That is the difference in one line. Everything else is a consequence of it.

A side-by-side comparison

	Standard RI	Convertible RI	Savings Plan
Discount rate	Highest (~72%)	High (~66%)	Lower (~66% EC2, ~54% Compute)
Locks in	Family, size, OS, region, tenancy	Family (can swap size, OS, region)	A $/hour commitment — nothing else
Service coverage	Per-service (EC2, RDS, ElastiCache, Redshift, OpenSearch…)	Per-service (EC2 mostly)	Broad (EC2, Fargate, Lambda, SageMaker…)
Term	1 or 3 years	1 or 3 years	1 or 3 years
Flexibility	Low	Medium	High

Three notes on this table:

RIs cover some services that SPs don’t. AWS ElastiCache, Redshift, and OpenSearch Service are only covered by RIs. If you run those, you need RIs — there is no SP equivalent.

SPs cover services that RIs don’t. Most notably, AWS Compute Savings Plans cover Fargate and Lambda. No RI option exists for those.

Azure Savings Plans are broader than AWS. They cover more service categories than AWS Compute SPs. Worth a look if you’re on Azure and assumed parity.

So far, this is the surface-level view. The interesting question is what actually happens at billing time — how the discount gets applied. That is where the choice starts to matter.

How Standard RIs apply

An RI is a reservation. Every hour, the billing engine asks: is there a running instance that matches this reservation’s specs exactly?

 RI spec: m5.large, Linux, us-east-1, shared tenancy, 1yr term

 ┌──────────────────────────── Hour-by-hour ──────────────────────────┐
 │                                                                    │
 │  Hour 1   Running m5.large ✓ match   →  discount applied           │
 │  Hour 2   Running m5.large ✓ match   →  discount applied           │
 │  Hour 3   Running m5.xlarge ✗ no match → discount wasted           │
 │  Hour 4   Instance stopped  ✗ nothing → discount wasted            │
 │  Hour 5   Running m5.large ✓ match   →  discount applied           │
 │                                                                    │
 └────────────────────────────────────────────────────────────────────┘

If nothing matches in a given hour, the RI benefit for that hour is gone. You paid for it. You didn’t use it. There is no rollover.

The coupon book analogy (from the Cloud FinOps 2nd Edition book, and still the best I’ve read):

Imagine a coupon book costing $750 with 30 meal coupons. Each coupon gets you a meal that would normally cost $50. That’s $25 per coupon for a $50 meal, saving you $25 a meal. If you use all 30 coupons, you saved 50%. If you use only 15, you broke even. If you use fewer than 15, you lost money.

That is an RI. The break-even point is roughly half the commitment. Below that, you would have paid less On-Demand.

So RIs work when the workload is stable and the instance spec is not going to change for a year or more. A production database. A core always-on web tier. Steady things.

How Convertible RIs apply (and Instance Size Flexibility)

Convertible RIs relax the “exact match” rule in two ways:

1. You can exchange the RI for a different instance type later in the term. You lose nothing except the difference in discount rate — the exchanged RI discount rate matches what’s on offer at exchange time.

2. Instance Size Flexibility (ISF) lets one RI cover multiple instances in the same family, proportionally. The unit is the “normalized unit.” A large is 4 units, an xlarge is 8, a 2xlarge is 16, and so on.

 1 × m5.2xlarge RI (16 normalised units)

 Scenario A: 1 running m5.2xlarge
 ┌──────────────────────────────────┐
 │  [████████████████] 16 units     │  ← fully covered
 └──────────────────────────────────┘

 Scenario B: 2 running m5.xlarge
 ┌──────────────────────────────────┐
 │  [████████][████████] 8 + 8 = 16 │  ← fully covered
 └──────────────────────────────────┘

 Scenario C: 1 running m5.4xlarge (32 units)
 ┌──────────────────────────────────┐
 │  [████████████████] 16 of 32     │  ← half covered, rest On-Demand
 └──────────────────────────────────┘

You give up around 5–8 percentage points of discount vs a Standard RI for this flexibility. Usually worth it if your fleet changes size often.

How Savings Plans apply

An SP is not a reservation. It is a dollar commitment per hour.

You commit, say, $0.50/hour for 1 year. Every hour, AWS looks at your eligible On-Demand usage, applies the SP discount rate to fill up that $0.50 of spend, and bills the rest at On-Demand.

 Commitment: $0.50/hour Compute Savings Plan, 1 year

 ┌──────────────── What runs in hour X ─────────────────┐
 │                                                      │
 │  Fargate task (US-East)        $0.18/hr On-Demand    │
 │     → SP applies, discounted to $0.12/hr             │
 │                                                      │
 │  Lambda invocations             $0.30/hr On-Demand   │
 │     → SP applies, discounted to $0.20/hr             │
 │                                                      │
 │  EC2 m5.large (eu-west-1)       $0.25/hr On-Demand   │
 │     → SP partially applies                           │
 │                                                      │
 │  ────────────────────────────────────────            │
 │  SP commitment used this hour:  $0.50                │
 │  Anything beyond $0.50: billed On-Demand             │
 │                                                      │
 └──────────────────────────────────────────────────────┘

Two properties worth remembering:

SPs prioritise the deepest discount first. The billing engine ranks your eligible usage by savings percentage and applies the SP to whichever usage saves you the most, until the hourly commitment is exhausted.

SPs are easy to ease into. You can start with $0.10/hour and increase later. RIs are all-or-nothing per reservation.

This is why SPs are the default recommendation for teams that are still figuring out their baseline or actively modernising. You don’t need to know the exact instance shape you’ll be running in 14 months — you just need a floor of compute spend you’re confident in.

Choosing one — or, more realistically, combining them

This is where most articles stop. I want to go one level deeper, because in practice you combine them.

Use Standard RIs when:

Workload is stable, running 24/7, not going anywhere for 1–3 years.
Instance family, size, OS, region are locked in by a real constraint (compliance, licensing, dependency on a specific instance generation).
Example: a production RDS primary. Core always-on EC2 web tier. ElastiCache or Redshift (no SP option anyway).

Use Convertible RIs when:

Same as above, but there is a reasonable chance the instance shape changes within the term.
You want better discount than SPs but more flexibility than a Standard RI.
Example: a production EC2 fleet that might shift from m5 to m7i during a tech refresh.

Use Savings Plans when:

Workload mix is changing — migrations, modernisation, container adoption.
You have baseline compute spend but can’t pinpoint the instance types 12 months out.
You use Fargate, Lambda, or other services RIs don’t cover.
Example: a platform mid-migration from EC2 lift-and-shift to ECS/Fargate.

Use them together — almost always.

A realistic production portfolio looks like this:

 Total compute spend: $100K/month

 ┌────────────────────────────────────────────────────┐
 │  Standard RIs  ████████████     40%  stable core   │
 │  Conv. RIs     █████            15%  flexible core │
 │  Savings Plans █████████        30%  everything    │
 │                                       else covered │
 │  On-Demand     ████             15%  bursts, dev,  │
 │                                       new services │
 └────────────────────────────────────────────────────┘

The split above is illustrative, not prescriptive. The real ratio depends on your workload stability, which is exactly what coverage and utilisation metrics measure — covered in the next article.

The trap worth naming

Here is a mistake I see often, and it is worth its own callout:

Do not run instances 24/7 just because they are covered by a commitment.

I have seen organisations run Virtual Desktops around the clock because “they are already paid for.” In reality those desktops are used 8 hours a day, 5 days a week — about 24% of the hours in a week. Shutting them down outside working hours and paying On-Demand for the hours they run would be cheaper than keeping them up permanently under an RI.

The point of FinOps is business value per dollar, not commitment utilisation per dollar. Utilisation is a means, not an end.

Summary

RIs reserve an instance shape. SPs commit a dollar rate. That single difference drives everything else.
More rigidity = more discount. Standard RI > Convertible RI > SP. Pick the tightest commitment you can genuinely honour.
Mix them. Stable core on RIs. Everything else on SPs. Keep On-Demand for bursts and truly new workloads.
The real failure mode is not buying the wrong one — it is keeping dead instances alive to “use up” the commitment. Don’t do that.

In my opinion, Savings Plans are the right default for most teams today. Architectures are moving faster than 1-year horizons — container adoption, serverless, cross-region growth, Graviton migrations. The flexibility SPs offer usually beats the few extra percentage points you’d win with Standard RIs, once you price in the risk of being wrong.

That is a preference, not a rule. If your workload is genuinely stable and genuinely not going anywhere, Standard RIs still win on pure discount rate. Match the tool to the scenario.

Thanks for reading. If this helped, share it. Questions or topic suggestions — send them through.

How Do Reserved Instances and Savings Plans Actually Work?