← Back to blog

AWS Savings Plans vs Reserved Instances: Which to Buy

awscost-optimizationsavings-plansreserved-instances
AWS Savings Plans vs Reserved Instances: Which to Buy

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 what I’d audit first on a $50K AWS bill.)

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:

InstrumentMax discount vs On-DemandFlexibility
Compute Savings Planup to 66%EC2 + Fargate + Lambda, any family, any region
EC2 Instance Savings Planup to 72%one instance family in one region, any size/OS/tenancy
Convertible Reserved Instanceup to 66%exchangeable, but manual
Standard Reserved Instanceup 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:

  1. Is it Redshift or OpenSearch? → Reserved Node (Redshift) or Reserved Instance (OpenSearch). No Savings Plan exists. Done.
  2. 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.
  3. 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).
  4. 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.”

Sources