AWS Savings Plans vs Reserved Instances: Which to Buy

Originally published at rajesh.medampudi.com/blog/ri-vs-savings-plans.

For AWS Savings Plans vs Reserved Instances, the default answer is: buy a Savings Plan, not a Reserved Instance. The exception is OpenSearch, Redshift, and (until December 2025) databases, which still need the older Reserved model. That is the whole decision. For most teams a Compute Savings Plan is the right default: same discount as a Convertible Reserved Instance, far less to manage, and it follows your workload across instance families, regions, Fargate, and Lambda. The cases where a Reserved Instance still wins are narrow and specific, and the December 2025 launch of Database Savings Plans shrank them further.

This post is the decision — RI vs Savings Plan, when each wins. It is not a deep-dive on how Savings Plans work under the hood; I cover the mechanics — how the $/hour commitment gets applied, the billing-hour math, the queue order against On-Demand — in a separate post. Here I only want to answer the question you actually have when the Cost Explorer recommendation pops up: which one do I buy? (Commitments are step three of a full bill audit — where they sit in the order is in .)

The short version

Both Reserved Instances and Savings Plans are the same trade: you promise AWS a one- or three-year commitment, AWS gives you a discount over On-Demand. The difference is what you commit to.

A Reserved Instance commits you to a specific instance configuration — family, and depending on type, size, region, OS, tenancy.
A Savings Plan commits you to a dollar amount of usage per hour (e.g. "$10/hour of compute"), and AWS applies that discount to whatever matching usage you actually run.

The Savings Plan is the more flexible instrument at the same discount level, which is why AWS itself now recommends Savings Plans over Reserved Instances for compute. (AWS, Compute Savings Plans and Reserved Instances, accessed June 2026.) The Reserved Instance has not gone away — but for EC2 compute, it is mostly the legacy choice now.

The discount numbers, side by side

The headline rates line up almost exactly. From AWS's own comparison:

Instrument	Max discount vs On-Demand	Flexibility
Compute Savings Plan	up to 66%	EC2 + Fargate + Lambda, any family, any region
EC2 Instance Savings Plan	up to 72%	one instance family in one region, any size/OS/tenancy
Convertible Reserved Instance	up to 66%	exchangeable, but manual
Standard Reserved Instance	up to 72%	locked to configuration, best rate

(AWS, Compute Savings Plans and Reserved Instances, accessed June 2026.)

That table is the entire argument. The Compute Savings Plan matches the Convertible RI's discount (up to 66%) but applies across instance families, regions, and serverless compute, automatically, with no exchanges. The EC2 Instance Savings Plan matches the Standard RI's discount (up to 72%) while still giving you size, OS, and tenancy flexibility within the family you committed to.

So at every discount tier the Savings Plan gives you more flexibility for the same rate. That is why the default flipped.

Standard vs Convertible RI — the old trade-off, briefly

If you are still considering Reserved Instances, the choice between the two types is the same shape: more discount for less flexibility.

Standard RIs give the deepest discount (up to 72% off On-Demand) but you cannot change what you reserved — you can only modify size within a family (for Regional RIs) and sell unused ones on the Reserved Instance Marketplace. (AWS, Standard vs. Convertible offering classes, accessed June 2026.)
Convertible RIs give a smaller discount (up to 66%) but you can exchange them for RIs with different attributes — different family, OS, tenancy — by performing a manual exchange. (AWS, Standard vs. Convertible offering classes, accessed June 2026.)

Here is the catch that makes Savings Plans the better tool for most teams. The Convertible RI's whole reason to exist is flexibility, and the Compute Savings Plan does that better with no manual exchanges. The Standard RI's reason to exist is the deepest rate, and the EC2 Instance Savings Plan matches it while staying more flexible. So for EC2, the RI is rarely the right answer in 2026.

When a Reserved Instance still wins

The Savings Plan does not cover everything. These are the real cases where you still reach for an RI or a Reserved Node:

1. Databases, before December 2025. Until very recently, RDS, Aurora, ElastiCache, Redshift, and OpenSearch had no Savings Plan at all — Reserved Instances (or Reserved Nodes) were the only way to get a committed-use discount on them. This is the single biggest reason teams still had large RI portfolios. The December 2025 launch changed most of this — see the next section.

2. Redshift and OpenSearch — still Reserved-only. Even after December 2025, Amazon Redshift uses Reserved Nodes and Amazon OpenSearch Service uses Reserved Instances as their committed-discount model. Neither is covered by any Savings Plan today. (AWS, Amazon Redshift reserved nodes; AWS, Reserved Instances in Amazon OpenSearch Service, accessed June 2026.) If your bill is heavy on either, the Reserved model is not legacy — it is the only lever you have.

3. Capacity guarantees. A zonal Reserved Instance reserves capacity in a specific Availability Zone. A Savings Plan does not reserve capacity at all — AWS is explicit that "Savings Plans doesn't provide capacity reservations." (AWS, Compute Savings Plans and Reserved Instances, accessed June 2026.) If you need a guarantee that the instance will be available in a constrained AZ — not just discounted — you want a zonal RI or an On-Demand Capacity Reservation, not a Savings Plan.

4. The Reserved Instance Marketplace. Standard RIs can be sold to other AWS customers if your needs change. Savings Plans cannot be cancelled or sold — "[they] can't be cancelled during the term." (AWS, Compute Savings Plans and Reserved Instances, accessed June 2026.) If you genuinely expect to need an exit and are willing to take a haircut, a Standard RI has a resale path a Savings Plan does not.

Outside of these, the Savings Plan is the better instrument.

What the December 2025 Database Savings Plans changed

On 2 December 2025, AWS launched Database Savings Plans, finally bringing the Savings Plan model to managed databases — the gap that kept most database spend stuck on Reserved Instances. (AWS, Introducing Database Savings Plans for AWS Databases, accessed June 2026.)

What it covers. The supported services are: Amazon Aurora, Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB, Amazon Neptune, Amazon Keyspaces, Amazon Timestream, and AWS Database Migration Service (DMS). (AWS, Introducing Database Savings Plans, accessed June 2026.)

What it does NOT cover. Note two absences that matter: Amazon Redshift and Amazon OpenSearch Service are not on the list. They remain Reserved-Node / Reserved-Instance only. So if you read a summary that says Database Savings Plans cover OpenSearch, it is wrong — check the official service list. Redshift and OpenSearch are exactly the two database-family services where the RI/Reserved-Node model is still the only committed-discount option.

The discount. Database Savings Plans save up to 35% on serverless deployments and up to 20% on provisioned instances, with smaller tiers for DynamoDB and Keyspaces throughput. (AWS, Introducing Database Savings Plans, accessed June 2026.) These are lower than EC2's headline numbers — databases were always a shallower discount — but the flexibility is the same draw: the plan applies regardless of engine, instance family, size, deployment option, or region, so you can move an Aurora workload from db.r7g to db.r8g, shift regions, or modernise from RDS for Oracle to Aurora PostgreSQL and keep the discount. (AWS, Introducing Database Savings Plans, accessed June 2026.)

The terms — read this before you commit. As launched, Database Savings Plans are one-year term, No Upfront payment only. (AWS, Announcing Database Savings Plans, accessed June 2026.) There is no three-year option and no upfront-payment option at launch — which is a meaningfully different shape from EC2 Savings Plans and from database Reserved Instances, both of which offer 1- or 3-year terms and All/Partial/No Upfront. If you have been buying 3-year database RIs for the deepest rate, the Savings Plan does not yet replace that specific play. Available in all AWS Regions except China. (AWS, Announcing Database Savings Plans, accessed June 2026.)

The practical effect: for RDS, Aurora, ElastiCache, DocumentDB, Neptune, DynamoDB, Keyspaces, Timestream, and DMS, you now have a flexible Savings Plan option that did not exist before December 2025, and for steady-state database spend on a 1-year horizon it is usually the easier instrument to manage than database RIs. For Redshift and OpenSearch, nothing changed — keep buying Reserved Nodes / Reserved Instances.

The decision, step by step

Here is how I would route the decision today:

Is it Redshift or OpenSearch? → Reserved Node (Redshift) or Reserved Instance (OpenSearch). No Savings Plan exists. Done.
Is it another managed database (RDS, Aurora, ElastiCache, DynamoDB, DocumentDB, Neptune, Keyspaces, Timestream, DMS)? → Database Savings Plan (1-year, No Upfront) for steady-state spend. Database RIs only if you specifically need a 3-year term or upfront payment for a deeper rate.
Is it EC2 / Fargate / Lambda compute?
- Do you need flexibility across instance families and regions, or you run Fargate/Lambda? → Compute Savings Plan (up to 66%).
- Is your usage concentrated and stable in one instance family in one region, and you want the deepest rate? → EC2 Instance Savings Plan (up to 72%).
- Do you need a capacity guarantee in a specific AZ, or a resale exit? → Reserved Instance (zonal for capacity; Standard for the Marketplace).
Everything else (steady compute, no special constraint)? → Compute Savings Plan. It is the safe default.

The honest summary: Savings Plans are the default for almost everything now, Database Savings Plans closed the biggest remaining gap in December 2025, and Reserved Instances survive in three specific corners — Redshift/OpenSearch, capacity guarantees, and the resale exit.

One caveat I will state plainly: I have not personally run a Database Savings Plan commitment for a full year yet — it launched in December 2025 and I am writing this in 2026. The EC2 Savings Plan guidance is from production use; the database guidance is from the AWS documentation and the launch terms, which I have verified and cited above. Treat the database section as "what the docs say and what I would do," not "what I have run for twelve months."

Social Doors (publish after blog is live)

LinkedIn (200–400 words)

For most AWS teams in 2026, the Reserved Instance is the legacy choice — and most people haven't updated the rule in their head.

Here is the trade, stripped down. Reserved Instances and Savings Plans are the same deal: commit for 1 or 3 years, get a discount. The difference is what you lock in. An RI commits you to an instance configuration. A Savings Plan commits you to a dollar-per-hour of usage, and AWS applies the discount to whatever you actually run.

Look at AWS's own numbers and the decision makes itself:

Compute Savings Plan: up to 66% off, works across instance families, regions, Fargate, and Lambda.
EC2 Instance Savings Plan: up to 72% off, one family in one region.
Convertible RI: up to 66%, but you exchange manually.
Standard RI: up to 72%, locked to the configuration.

The Savings Plan matches the RI's discount at every tier and beats it on flexibility. That is why AWS itself now recommends Savings Plans over RIs for compute.

So when does an RI still win? Three cases. Redshift and OpenSearch — still Reserved-only, no Savings Plan exists for them. Capacity guarantees — a Savings Plan does not reserve capacity in an AZ; a zonal RI does. And the resale exit — Standard RIs can be sold on the Marketplace; Savings Plans cannot be cancelled.

The big news: on 2 December 2025 AWS launched Database Savings Plans, covering RDS, Aurora, ElastiCache, DynamoDB, DocumentDB, Neptune, Keyspaces, Timestream, and DMS — up to 35% on serverless, 20% on provisioned. That closed the biggest reason teams still ran huge RI portfolios. Two catches: it's 1-year, No Upfront only at launch, and it does NOT cover Redshift or OpenSearch (despite what some summaries claim).

I wrote the full decision guide — including a flowchart for routing any commitment — on my blog.

Full piece in the first comment.

#awscostoptimization #aws #savingsplans #finops #cloudcomputing

X / Twitter (thread)

1/ For most AWS teams in 2026, the Reserved Instance is the legacy choice.

The rule most people still carry in their head is out of date. Here's the actual RI vs Savings Plans decision. 🧵

2/ Same deal, both: commit 1–3 years, get a discount.

The difference is WHAT you lock in.

RI → a specific instance configuration
Savings Plan → a $/hour of usage, applied to whatever you run

3/ AWS's own numbers:

Compute SP: up to 66%, any family + region + Fargate + Lambda
EC2 Instance SP: up to 72%, one family/region
Convertible RI: up to 66%, manual exchange
Standard RI: up to 72%, locked

SP matches the rate, beats the flexibility.

4/ That's why AWS itself now recommends Savings Plans over RIs for compute.

The Convertible RI's whole point — flexibility — is done better by the Compute SP, with no manual exchanges.

5/ So when does an RI still win? Three cases:

Redshift & OpenSearch → still Reserved-only, no SP exists
Capacity guarantee in a specific AZ → SP doesn't reserve capacity, a zonal RI does
Resale exit → Standard RIs sell on the Marketplace; SPs can't be cancelled

6/ The big shift: on 2 Dec 2025 AWS launched Database Savings Plans.

Covers RDS, Aurora, ElastiCache, DynamoDB, DocumentDB, Neptune, Keyspaces, Timestream, DMS. Up to 35% serverless / 20% provisioned.

7/ Two catches on Database SP:

1-year, No Upfront ONLY at launch (no 3-year, no upfront)
does NOT cover Redshift or OpenSearch — despite what some write-ups claim. Check the official service list.

8/ Decision, short version: Redshift/OpenSearch → Reserved. Other DBs → Database SP. EC2/Fargate/Lambda → Compute SP (or EC2 Instance SP for the deepest rate). Need capacity or resale → RI. Everything else → Compute SP.

9/ Full decision guide + a routing flowchart, with every number cited to AWS docs: {{BLOG_URL}}

Facebook

Skip. This is a technical AWS billing post — the audience is cloud engineers and finance-for-cloud folks, not a general Facebook audience. No personal/career angle to make it fit. Per the voice spec, pure technical posts skip Facebook.

Reddit (r/aws)

Title: RI vs Savings Plans decision in 2026 — and what Database Savings Plans (Dec 2025) actually changed

Body:

Wrote this up after one too many "should I buy RIs or Savings Plans?" conversations, figured the decision is worth laying out plainly with the current numbers.

The short version: for EC2 compute, Savings Plans now dominate RIs at every tier. From AWS's own comparison table — Compute SP up to 66% (matches Convertible RI) but works across instance families, regions, Fargate, and Lambda with no manual exchanges; EC2 Instance SP up to 72% (matches Standard RI) with size/OS/tenancy flexibility in the family. The SP matches the discount and beats the flexibility, which is why AWS itself recommends SPs over RIs for compute.

Where RIs still win, specifically:

Redshift (Reserved Nodes) and OpenSearch (Reserved Instances) — still no Savings Plan covers them.
Capacity guarantees — a Savings Plan doesn't reserve capacity in an AZ; a zonal RI / ODCR does.
Resale — Standard RIs can be sold on the Marketplace; SPs can't be cancelled mid-term.

On the Dec 2, 2025 Database Savings Plans launch: covers RDS, Aurora, ElastiCache, DynamoDB, DocumentDB, Neptune, Keyspaces, Timestream, DMS. Up to 35% serverless / 20% provisioned. Two things worth flagging because I've seen them stated wrong already — it's 1-year, No Upfront only at launch (no 3-year, no upfront tier yet), and it does not cover Redshift or OpenSearch. If you've been running 3-year database RIs for the deepest rate, the SP doesn't replace that play yet.

Curious whether anyone here has already moved a steady-state RDS/Aurora workload onto the new Database SP and how the realised discount compared to the RIs they retired.

I put the full decision guide with a routing flowchart and every figure cited to the AWS docs on my blog if useful: {{BLOG_URL}}

Nostr (kind:1)

for most aws teams in 2026, the reserved instance is the legacy choice. savings plans match the discount at every tier and beat it on flexibility — which is why aws itself recommends them over RIs for compute now.

RIs still win in exactly three corners: redshift & opensearch (still reserved-only), capacity guarantees in a specific AZ, and the resale exit.

the dec 2025 database savings plans launch closed the biggest remaining gap — RDS, aurora, elasticache & more, up to 35% serverless. but it's 1-year no-upfront only, and it does NOT cover redshift or opensearch.

full decision guide + flowchart, every number cited to aws docs: {{BLOG_URL}}

#aws #cloudcomputing #finops #devops

Image concepts

All six follow images/IMAGE-GENERATION-GUIDE.md: 1200×675, #dbeafe background, Virgil font (fontFamily 1), roughness 1 on content / 0 on background, hatched fills, semantic colour (red = locked/expensive, green = flexible/saved, gold = highlight), footer rajesh.medampudi.com · ri-vs-savings-plans bottom-right mono gray. Personal brand only — no brand-family tokens anywhere (run check-image-brand.mjs before attaching).

Decision flowchart (template 3) — HERO. Title "RI vs Savings Plans: which to buy". Diamonds (#2980B9 fill / #1a5276 stroke): "Redshift or OpenSearch?" → Yes (red label) → outcome box "Reserved Node / RI" (green fill). "Other managed DB?" → Yes → "Database Savings Plan (1yr, No Upfront)". "EC2/Fargate/Lambda?" → flows to "Compute SP" default, branch to "EC2 Instance SP (deepest rate)" and "Reserved Instance (capacity / resale)". This is the post's spine — make it the hero PNG.
Comparison table as stat grid (template 5 variant). Four rows: Compute SP (66%, blue bar), EC2 Instance SP (72%, green bar), Convertible RI (66%, amber bar), Standard RI (72%, red bar). Right column flexibility icons. Gold callout: "Savings Plans match the rate, beat the flexibility."
"When an RI still wins" — summary-of-points (template 1). Three white label boxes: "Redshift & OpenSearch — still Reserved-only", "Capacity guarantee in an AZ", "Resale on the Marketplace". Footer callout (#fef3c7): "Everything else → Savings Plan."
Before/after architecture (template 2). LEFT "RI" (red): locked box "family + size + region + OS". RIGHT "Savings Plan" (green): "$/hour commitment → applies to any matching usage". Blue arrow between. CTA box: "Same discount. Less to manage."
Stat card (template 4) — Database Savings Plans. Quote: "Database Savings Plans — launched 2 Dec 2025". Supporting: "RDS · Aurora · ElastiCache · DynamoDB · DocumentDB · Neptune · Keyspaces · Timestream · DMS". Gold divider. Red stat box: "NOT Redshift · NOT OpenSearch · 1yr · No Upfront only".
Cost comparison bars (template 5). On-Demand (100%, red) → Compute SP (−66%, amber) → EC2 Instance SP / Standard RI (−72%, green) → Database SP serverless (−35%, blue). Green savings callout arrow. Labels and percentages inside the diagram.

Sources

AWS — Compute Savings Plans and Reserved Instances (comparison table, discounts, flexibility, "no capacity reservations", "can't be cancelled"): docs.aws.amazon.com/savingsplans/latest/userguide/sp-ris.html — accessed June 2026.
AWS — Standard vs. Convertible offering classes (Standard up to 72% / Convertible up to 66%, exchange vs no-exchange): docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/standard-vs.-convertible-offering-classes.html — accessed June 2026.
AWS — Introducing Database Savings Plans for AWS Databases (launch 2 Dec 2025, supported services list, up to 35% serverless / 20% provisioned, engine/family/region flexibility): aws.amazon.com/blogs/aws/introducing-database-savings-plans-for-aws-databases — accessed June 2026.
AWS — Announcing Database Savings Plans with up to 35% savings (1-year term, No Upfront only, all Regions except China): aws.amazon.com/about-aws/whats-new/2025/12/database-savings-plans-savings — accessed June 2026.
AWS — Amazon Redshift reserved nodes (Redshift remains Reserved-Node only): docs.aws.amazon.com/redshift/latest/mgmt/purchase-reserved-node-instance.html — accessed June 2026.
AWS — Reserved Instances in Amazon OpenSearch Service (OpenSearch remains Reserved-Instance only; 1/3-year, No/Partial/All Upfront): docs.aws.amazon.com/opensearch-service/latest/developerguide/ri.html — accessed June 2026.
AWS — Compute and EC2 Instance Savings Plans pricing (1 or 3 year terms, up to 66% / 72%): aws.amazon.com/savingsplans/compute-pricing — accessed June 2026.

Publish-time checklist (not body content)

The two inline personal-number placeholders have been cut from the body — no verification brackets remain in the prose. The items below are operational, to handle when scheduling:

Replace the {{BLOG_URL}} placeholder in the social doors with the live rajesh.medampudi.com/blog/ri-vs-savings-plans URL before scheduling.
Set the {{PUBDATE}} frontmatter to the actual publish date.
Re-confirm Database Savings Plans terms (still 1-year / No Upfront only) at publish time — AWS may add 3-year or upfront options after the Dec 2025 launch.