Savings Plans vs Reserved Instances: The Decision Framework

Reserved Instances were the original AWS commitment vehicle. Savings Plans launched in late 2019 as a more flexible alternative, and for most workloads they are now the right default. But Reserved Instances remain commercially active, remain right for specific workload patterns, and remain present in essentially every legacy AWS portfolio we review.

This guide walks through the decision framework we use across 500+ buyer-side engagements and $2.4B+ in reviewed AWS spend. The mechanics, the math, the conversion strategy, and the residual situations where RIs remain the better instrument.

The fundamental difference

Both Savings Plans and Reserved Instances are commitments to AWS in exchange for discount. The difference is the unit of commitment.

Reserved Instances commit to a specific instance configuration — instance family, size (with size flexibility within a family), region or availability zone, OS, tenancy, and term. The discount applies when you use a matching instance. AWS bills the RI hourly regardless of whether matching usage exists.

Savings Plans commit to a dollar-per-hour spend rate, not to a specific instance. AWS automatically applies the discount to whichever eligible compute usage maximizes savings in each hour, up to the committed level. The buyer doesn't specify instance characteristics; the commitment is purely commercial.

The implication: Savings Plans absorb architectural change; Reserved Instances do not. An m5 RI does not cover m6i usage; an m5 EC2 Instance Savings Plan can be combined with the broader m6i coverage; a Compute Savings Plan covers both without intervention.

The discount comparison

Reserved Instances and Savings Plans publish similar discount tiers, but the comparison requires care because the units differ. Here's the practical mapping:

Read at the peak discount tier, Standard RIs and EC2 Instance Savings Plans are roughly comparable on a stable, predictable workload. Convertible RIs sit between Compute Savings Plans and EC2 Instance Savings Plans on the flexibility axis but offer worse discount than either. This is part of why Convertible RIs have largely been displaced by Savings Plans.

What Reserved Instances still do better

Despite Savings Plans being the default, four situations keep Reserved Instances commercially active:

1. RDS, ElastiCache, Redshift, and OpenSearch

Savings Plans do not cover database services. Reserved Instances remain the only commitment instrument for RDS (Aurora, MySQL, PostgreSQL, SQL Server, Oracle on RDS), ElastiCache (Redis, Memcached), Redshift, OpenSearch, MemoryDB, DocumentDB, and Neptune. Buyers with material database spend essentially require RI portfolios for those workloads.

2. Zonal capacity reservations

Zonal RIs include a capacity reservation in the specified availability zone — AWS guarantees the capacity will be available. Savings Plans do not include capacity reservations. For workloads with hard capacity requirements in specific availability zones (often for resilience or proximity reasons), zonal RIs are the only commitment vehicle that provides the guarantee.

3. RI Marketplace liquidity

Standard RIs can be sold on the RI Marketplace. Savings Plans cannot be transferred or sold. For buyers exiting an instance family, region, or AWS entirely, the RI Marketplace provides a recovery path that Savings Plans don't. (The marketplace is imperfect — pricing is buyer-dependent and not all RIs sell — but it exists.)

4. Legacy RIs that are still in their term

Active RIs from 2022–2024 commitments still cover usage today. Buyers can't elect to "convert" Standard RIs to Savings Plans; they can only let them expire (or sell them on the marketplace and use the proceeds to fund Savings Plans).

What Savings Plans do better

For everything else — EC2 compute, Fargate, Lambda — Savings Plans are now the default, and the advantages compound:

1. Architecture-change absorption

Compute Savings Plans cover instance family migrations, region changes, OS changes, EKS/Fargate adoption, and Lambda growth. RIs cover none of those without explicit exchange (Convertible) or marketplace transactions (Standard).

2. Automatic application across the portfolio

Savings Plans apply automatically to whichever eligible usage maximizes discount in each hour. RIs require manual portfolio matching, modification, and exchange to stay aligned with usage. Operationally, Savings Plans are dramatically simpler.

3. Consolidated billing flow

Both Savings Plans and RIs flow benefits across an AWS Organization by default, but Savings Plans aggregation is cleaner — the commitment is a dollar figure, not a count of instance-hours, so allocation across accounts is purely consumption-based.

4. Lambda and Fargate coverage

Compute Savings Plans cover Lambda invocations and Fargate task duration. RIs do not. For buyers with material serverless usage, Savings Plans capture discount that is otherwise unreachable.

5. No exchange friction

Convertible RI exchanges require explicit action and have known restrictions (residual term retention, exchange ratio mechanics). Savings Plans absorb the equivalent change automatically.

The conversion question

Buyers with active RI portfolios face a recurring question: should we convert RIs to Savings Plans? The answer depends on the RI type, the remaining term, and the workload trajectory.

Convertible RIs

Convertible RIs cannot be directly converted to Savings Plans, but they can be exchanged for other RIs. The practical path is to let Convertible RIs expire and replace them with Savings Plans at expiration. Pre-expiration conversion attempts (exchange to a different config, then to another, attempting to align with a Savings Plans-like exposure) usually fail mechanically and waste residual term value.

For Convertible RIs with more than 9 months remaining: hold to expiration. For those with less than 9 months remaining: also hold to expiration — the value loss from exchange is rarely worth the marginal flexibility gain.

Standard RIs

Standard RIs can be sold on the RI Marketplace, and the proceeds can fund Savings Plans purchases. The arbitrage is real but rarely large enough to be worth the operational overhead unless:

• The RI is materially mismatched to current usage (e.g., m5 RI on a portfolio that has migrated to m6i, with no remaining m5 footprint).
• The RI has substantial remaining term (more than 12 months).
• The instance family is still active on the RI Marketplace (some legacy families have weak liquidity).

For RIs that fail any of those tests, hold to expiration and replace with Savings Plans at that point.

Database RIs (RDS, ElastiCache, Redshift, OpenSearch)

No conversion path exists. RIs are the commitment instrument for these services. The decision is purely whether to renew at expiration or shift toward On-Demand for the affected workloads — almost always renew, given the discount tiers.

The layered portfolio we recommend

For a typical mature AWS buyer at $10M+ annual spend, the optimal commitment portfolio looks like:

• Compute Savings Plans as the primary EC2/Fargate/Lambda commitment layer, sized to 60–75% of expected baseline.
• EC2 Instance Savings Plans layered onto the two or three most stable workload families, sized to capture additional discount on demonstrably non-migrating workloads.
• RDS Reserved Instances covering 70–85% of database baseline, sized against current production capacity with modest growth assumption.
• ElastiCache / Redshift / OpenSearch RIs sized against current capacity, with shorter terms (1-year) where workloads are evolving.
• No new Convertible RIs. The flexibility benefit is captured better by Compute Savings Plans; the discount tier of Convertible RIs is no longer competitive.
• Active Standard RIs and Convertible RIs held to expiration unless materially misaligned with current usage.

The application order when both exist

If a portfolio has both RIs and Savings Plans, AWS applies discounts in a fixed order:

1. Reserved Instances apply first, against any eligible usage matching the RI configuration.
2. EC2 Instance Savings Plans apply next, against eligible usage matching the plan's family/region.
3. Compute Savings Plans apply against remaining eligible compute usage.
4. Any remaining usage falls to On-Demand.

This order means RIs and Savings Plans cannot "double-cover" the same hour. The narrowest instrument consumes its eligible usage first; broader instruments absorb the residual. This is why portfolio layering works without operational risk of paying twice for the same hour.

The EDP interaction

Both Savings Plans and RIs count toward EDP commit. The mechanics are similar: dollars committed via either instrument register as EDP-eligible AWS spend.

For buyers using commitment instruments to manage EDP under-burn, the relative flexibility favors Savings Plans for everything except database commitments. RIs absorb under-burn for the database categories where Savings Plans don't exist; Savings Plans absorb under-burn for everything else with more flexibility than RIs would provide.

The renewal cadence

One operational difference matters: RIs and Savings Plans expire on specific dates, and discount cliffs at expiration can be material if renewals are not pre-staged.

Mature buyers operate to a 6-month-forward renewal calendar — every commitment that expires in the next six months has a documented renewal posture, sized against current consumption, ready to execute on the expiration date so there is no uncovered window.

For RIs, renewal is essentially a re-purchase (RIs cannot be renewed in-place; a new RI must be purchased to replace an expiring one). For Savings Plans, the same — new commitment, sized to current consumption.

The RI Marketplace strategy

The RI Marketplace deserves a separate mention. For buyers with mismatched RI portfolios — common after migrations, M&A activity, or major architecture changes — the marketplace can recover meaningful value.

The economics are imperfect: marketplace pricing typically returns 60–85% of remaining commitment value to the seller. Below 60%, hold; above 85%, sell. The marketplace also has thin liquidity in some instance families — t-family RIs typically sell faster than r-family, and unusual configurations (specific OS / tenancy combinations) often sit unsold for months.

For systematic portfolio cleanup: identify RIs with remaining term > 12 months and zero matching current usage; list them on the marketplace; use proceeds to fund Compute Savings Plans purchases. The capital efficiency improvement is typically 10–20% versus letting the RIs expire unused.

When to still buy RIs in 2026

Three situations remain where new RI purchases are correct:

• Database commitments. RDS, ElastiCache, Redshift, OpenSearch. No Savings Plans alternative exists.
• Zonal capacity needs. Workloads with hard availability zone capacity requirements where the AWS capacity guarantee is operationally important.
• Specific compliance or accounting structures. A small number of enterprise buyers prefer the predictability of fixed instance-hour commitments for internal allocation reasons. Rare, but exists.

For everything else — compute, container, serverless — Savings Plans are the default.

What to do this quarter

Inventory all active RIs and Savings Plans across your AWS Organization. For each RI: identify the expiration date, the remaining term value, and the current usage match. Build a renewal calendar covering the next 18 months.

For Convertible RIs and Standard RIs that no longer match usage, evaluate marketplace liquidity. For database RIs, build renewal-cadence discipline. For Compute Savings Plans, ensure layering against EC2 Instance Savings Plans where workloads support it.

If you would like an independent review of your RI-vs-Savings-Plans portfolio mix, including the marketplace strategy and renewal cadence, Contact Us for a no-obligation assessment. For deeper reading, see our pillar guides on AWS Savings Plans strategy and AWS Reserved Instance optimization, plus the RI-to-Savings-Plans conversion guide.