AWS Savings Plans vs Reserved Instances: Which Should You Choose?

Every AWS cost review reaches the same moment. Someone points at the On-Demand line, someone else says "we should buy commitments," and the conversation stalls because nobody is confident about which instrument to buy or how much.

The choice between AWS Savings Plans and Reserved Instances is really a choice between discount depth and flexibility, and the right answer depends less on the percentages than on how confident you are about what you will be running in twelve months.

This guide covers how each mechanism works, where the discounts actually land, which workload patterns suit which instrument, and — the part most guides skip — what to do when you are already holding a commitment you cannot use.

How Reserved Instances Work

A Reserved Instance is not a reserved server. It is a billing discount applied to matching usage, which is the single most useful thing to understand about them.

You commit to a specific configuration — instance family, size, region, platform, tenancy — for one or three years. When usage matches that configuration, AWS bills it at the reserved rate instead of On-Demand. When it doesn't match, you pay the commitment anyway and get nothing back.

The two RI types

Convertible RIs trade roughly six percentage points of discount for the ability to exchange. In practice, most teams who need that flexibility are better served by a Compute Savings Plan, which gives similar flexibility without the exchange mechanics.

Where RIs still matter

Savings Plans have absorbed most of the RI use cases, but not all:

• Amazon Redshift — no Savings Plan exists. Reserved Nodes are the only committed discount.
• Older database generations — Database Savings Plans cover Generation 7 and newer only. Gen 5 and Gen 6 RDS instances need RIs.
• ElastiCache on Redis — Database Savings Plans cover Valkey only.
• Zonal capacity reservations — if you need AWS to hold capacity in a specific AZ, that is a Capacity Reservation, and RIs can be attached to it. Savings Plans never reserve capacity.
• Exit liquidity — Standard RIs can be sold on the RI Marketplace. Savings Plans cannot be sold at all.

That last point matters more than it looks. A Standard RI you no longer need has a resale route; a Savings Plan you no longer need is a sunk cost for the rest of its term.

How Savings Plans Work

A Savings Plan is a commitment to spend a fixed dollar amount per hour on eligible usage for one or three years. You do not commit to instances, counts or configurations — just to the hourly spend figure.

AWS applies the discounted rate to eligible usage up to your commitment. Usage above it bills at On-Demand. Usage below it still costs you the full commitment.

There are four types.

Compute Savings Plans — up to 66%

The most flexible instrument AWS sells. Covers EC2, Fargate and Lambda across any instance family, size, region, operating system and tenancy.

The practical consequence: the discount follows your architecture. Migrate from m5 to m7g, move a service from EC2 to Fargate, shift a batch job to Lambda, open a new region — the commitment keeps applying. For most organisations this is worth considerably more than the six-point discount gap to EC2 Instance Plans.

EC2 Instance Savings Plans — up to 72%

Covers EC2 only, locked to one instance family in one region. Within that boundary you can move freely between sizes, AZs, operating systems and tenancy.

Six points deeper than a Compute Plan, and the trade is real: if you move off that family, the commitment strands. Note that m5 and m7g are different families — a Graviton migration breaks an EC2 Instance Plan bought for an Intel family.

Database Savings Plans — up to 35%

Introduced at re:Invent 2025, and the most significant recent change to this decision. A single hourly commitment applies across ten database services: Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS and OpenSearch Service.

The discount tiers matter:

Important constraints: Generation 7 and newer instances only, ElastiCache limited to Valkey, Timestream limited to InfluxDB. It is a one-year commitment, and Amazon Redshift is not included.

What makes it genuinely useful is portability — you can migrate from RDS for Oracle to Aurora PostgreSQL, or from RDS to DynamoDB, and the commitment follows. A database RI never could.

SageMaker Savings Plans — up to 64%

Covers Amazon SageMaker instance usage across regions and instance families. Relevant if you run meaningful ML training or inference.

The discount application order

This trips people up when estimating a new purchase. AWS applies benefits in a fixed sequence:

1. Reserved Instances first
2. EC2 Instance Savings Plans next (narrower scope, so AWS spends it first)
3. Compute Savings Plans last (broadest scope, retained for whatever else appears)

Savings Plans do not stack on RI-covered hours. If an RI already covers an instance-hour, a Savings Plan sees nothing left to discount there. When you size a new Savings Plan, subtract RI-covered usage from the baseline first or you will over-commit.

Side-by-Side: Flexibility, Discount Depth and Commitment

The number that actually decides it

Headline discounts are ceilings at three-year All Upfront. What you realise is:

realised saving = headline discount × utilisation rate

A 72% EC2 Instance Plan running at 80% utilisation realises about 58%. A 66% Compute Plan running at 98% realises about 65%. The flexible instrument wins whenever utilisation differs by more than a few points, and in practice it usually does.

The rough break-even: the six-point gap between Compute and EC2 Instance Plans only pays off above roughly 90–92% utilisation on the narrower plan. Below that, flexibility is worth more than depth.

Term and payment option

Two levers, both meaningful:

• Term length. Three-year terms typically save 12–20 percentage points more than one-year at the same payment option. That is a large gap — and a three-year bet on an architecture you are actively changing.
• Payment option. All Upfront beats No Upfront by roughly 2–5 points. Partial Upfront sits between. The trade is working capital against discount.

A defensible default for a team without three years of stable history: one-year, No Upfront, on Compute Savings Plans. Validate the pattern, then layer three-year terms onto the portion of the baseline that has proven stable.

Which One Fits Which Workload Pattern

Three situations where the answer is "buy nothing"

• Mid-migration. Committing while workloads are moving between regions, families or services is how stranded commitments happen. Stabilise, then commit.
• Under 90 days of usage history. You cannot see your floor yet, and the floor is what you commit against.
• Actively right-sizing. If a rightsizing programme is about to cut 30% of your compute, buying against today's usage locks in the waste you are removing. Rightsize first — it is the cheaper win, and part of any serious cloud cost optimization effort.

There is a sequencing principle underneath all three: eliminate waste, then rightsize, then commit. Commitments bought on top of unoptimised infrastructure lock in the inefficiency for one to three years.

Choosing a Coverage Target and Fixing Underused Commitments

Find your floor, not your average

Pull 60 to 90 days of hourly On-Demand usage from Cost Explorer or your CUR. You want the minimum hourly spend — the level your usage never drops below — not the mean.

Averages include peaks. Committing to an average means the commitment goes unused during every trough, and unused commitment is money spent for nothing.

Set coverage at 70–80% of that floor

Full coverage of the floor sounds efficient and is not. It leaves no room for the things that reduce usage: a rightsizing pass, a service decommission, a seasonal dip, an unexpectedly effective caching change.

The two numbers to monitor monthly

• Utilisation — what share of your commitment is being consumed. Target 95%+. Below 90% means you have over-committed and are paying for capacity you cannot use.
• Coverage — what share of eligible usage is covered by commitments. Target 70–80%. Rising toward 100% means you are about to over-commit; falling sharply means new uncommitted workloads have appeared.

Utilisation below 100% is an immediate loss. Coverage below target is only an opportunity cost. Given a choice, protect utilisation.

Fixing commitments you cannot use

You are already holding something stranded. The options, in order of usefulness:

1. Return it — within 7 days. AWS allows Savings Plans to be returned within 7 days of purchase, subject to conditions: the commitment must be $100/hour or less, the plan must be in an active state, the purchase must be in the same calendar month, and annual return quotas apply. Useful only for correcting a recent mistake.

2. Generate usage to fill it. If you hold an EC2 Instance Plan for a family you have moved off, running eligible workloads on that family again may cost less than eating the commitment. Check the arithmetic — sometimes running otherwise-unnecessary instances is genuinely cheaper than wasting the commit.

3. Sell it (Standard RIs only). The RI Marketplace accepts Standard RIs. Expect to sell below face value, and note that Convertible RIs and Savings Plans cannot be sold at all.

4. Exchange it (Convertible RIs only). Exchange for a different configuration of equal or greater value. Not available for Standard RIs beyond size changes within a family, and not available for Savings Plans.

5. Shift workloads back into scope. For a Compute Savings Plan this is usually easy, because the scope is so broad. It is the main argument for accepting the lower ceiling in the first place.

6. Wait it out and plan the replacement. For an unusable one-year commitment with months left, the practical answer is often to absorb it and buy the replacement correctly. Queue the next purchase to start when this one expires, so coverage does not gap.

Operational habits that prevent the problem

• Queue renewals. AWS supports queuing future-dated purchases. Set them to start when the current commitment expires — no coverage gap, no scramble.
• Turn on expiration alerts. Cost Explorer sends alerts 1, 7, 30 or 60 days ahead. Deliberately let a commitment lapse; do not discover it lapsed.
• Ladder purchases. Buying everything at once creates a single large renewal event. Buying in tranches through the year smooths both renewal risk and the chance of committing at one bad moment.
• Review quarterly, not annually. Utilisation drift is easier to correct at month two than month ten.

For teams running this continuously, our cloud cost management practice covers commitment portfolio management alongside rightsizing, and Karpenter and EKS cost work deals with the compute-side reductions that should happen before you commit.

And the sequencing holds regardless: remove waste, rightsize, then commit. Buying commitments on top of unoptimised infrastructure locks in the inefficiency for the length of the term.

If you want a view of where your current commitments sit, where coverage is leaking, or what to buy before your next renewal, our cloud cost management team does this work continuously alongside 24×7 SRE support.

Talk to our team → We will start with 90 days of your hourly usage, because that is where the real floor is.