Comparison
Two commitments, both sold as reservations. They aren't the same bet.
A Reserved Instance commits to a specific instance class, in a region, for a service. A Savings Plan commits to an hourly dollar amount. AWS sells them for compute and, since December 2025, for databases. The discount follows whatever usage qualifies. A head-to-head comparison shows when each one fits. Both share one failure mode.
First, the two commitments
Same idea, pay now and save later. Two different things to commit to.
A Reserved Instance is a commitment to a specific instance class in a specific region, for a service (RDS, ElastiCache, or EC2), in exchange for a lower rate on any usage that matches it exactly. A Savings Plan is a commitment to spend a fixed dollar amount per hour. AWS sells Savings Plans for compute (EC2, Fargate, or Lambda) and, since December 2025, for databases (RDS, Aurora, ElastiCache, and others). AWS applies the discount automatically to whatever qualifying usage shows up, regardless of instance family, size, region, or OS. One reserves a thing; the other reserves a number.
In practice that means an RI on a db.r6g.xlarge only discounts a db.r6g.xlarge. Resize it and the reservation has nothing left to cover. A Savings Plan sized to the same hourly spend keeps discounting even if that workload moves to a different instance family or off EC2 entirely, as long as the dollar commitment is still being spent somewhere eligible.
Head-to-head
Neither one wins outright. They cover different ground.
All figures below are AWS's own published ceilings, not a quote. Your actual rate depends on instance class, region, term, and payment option.
| Dimension | Reserved Instance | Savings Plan |
|---|---|---|
| What it locks in | ✓a specific instance family, region, and service | ✓a $/hour of compute or database spend, not a specific instance |
| Flexes across instance family, size, region, or OS | ~EC2 Convertible only; Standard EC2 and all RDS/ElastiCache RIs are fixed to what you bought | ✓discount follows usage wherever it lands, automatically |
| Covers Amazon RDS and ElastiCache | ✓ | ~Database Savings Plans only, since December 2025. RDS and Aurora on Generation 7 and newer, or serverless. ElastiCache for Valkey only. A Compute Savings Plan never covers them |
| Covers Generation 6 and older database classes | ✓ | ✗not eligible for a Database Savings Plan |
| Covers EC2, Fargate, and Lambda compute | ~EC2 only | ✓Compute Savings Plans span all three |
| Published max discount vs on-demand | ✓up to 72% EC2 · 69% RDS · 56% ElastiCache | ✓up to 72% (EC2 Instance SP) · 66% (Compute SP) · 35% (Database SP) |
| Resellable on the AWS Marketplace | ✓EC2 Standard RIs only, unused term | ✗ |
| 1-year and 3-year terms, No/Partial/All Upfront payment | ✓ | ~a Database Savings Plan has a 1-year term and No Upfront payment only |
| Auto-renews at term end | ✗reverts silently to on-demand | ✗reverts silently to on-demand |
Reserved Instance
- ✓What it locks ina specific instance family, region, and service
- ~Flexes across instance family, size, region, or OSEC2 Convertible only; Standard EC2 and all RDS/ElastiCache RIs are fixed to what you bought
- ✓Covers Amazon RDS and ElastiCache
- ✓Covers Generation 6 and older database classes
- ~Covers EC2, Fargate, and Lambda computeEC2 only
- ✓Published max discount vs on-demandup to 72% EC2 · 69% RDS · 56% ElastiCache
- ✓Resellable on the AWS MarketplaceEC2 Standard RIs only, unused term
- ✓1-year and 3-year terms, No/Partial/All Upfront payment
- ✗Auto-renews at term endreverts silently to on-demand
Savings Plan
- ✓What it locks ina $/hour of compute or database spend, not a specific instance
- ✓Flexes across instance family, size, region, or OSdiscount follows usage wherever it lands, automatically
- ~Covers Amazon RDS and ElastiCacheDatabase Savings Plans only, since December 2025. RDS and Aurora on Generation 7 and newer, or serverless. ElastiCache for Valkey only. A Compute Savings Plan never covers them
- ✗Covers Generation 6 and older database classesnot eligible for a Database Savings Plan
- ✓Covers EC2, Fargate, and Lambda computeCompute Savings Plans span all three
- ✓Published max discount vs on-demandup to 72% (EC2 Instance SP) · 66% (Compute SP) · 35% (Database SP)
- ✗Resellable on the AWS Marketplace
- ~1-year and 3-year terms, No/Partial/All Upfront paymenta Database Savings Plan has a 1-year term and No Upfront payment only
- ✗Auto-renews at term endreverts silently to on-demand
When to choose which
The choice follows the shape of the usage, not the size of the bill.
Most fleets with any real history don't pick just one. They use RIs where usage is nailed down and a Savings Plan where it isn't, and revisit the split as the fleet's shape changes.
How this scales with you
The RI-vs-Savings-Plan call matters at 1 reservation and at 1,000.
Usually just RIs. A small fleet of Generation 6 databases cannot use a Database Savings Plan, so an RI is the only commitment. Simplicity matters more than flexibility at this size.
The mix starts to matter: RIs for the steady RDS/ElastiCache floor, a Savings Plan layered on top of EC2 usage that's beginning to shift between instance families or into containers. A Database Savings Plan can cover Generation 7 database usage that starts to move.
Most real fleets at this scale run both, deliberately. RIs cover anything with a stable footprint and resale value. Savings Plans cover compute that moves. Database Savings Plans cover Generation 7 and newer database usage that moves. The choice is made once, per workload, not re-litigated purchase by purchase.
The tooling should scale the same way the decision does: one flat price whether it's covering a handful of reservations or thousands, never a cut of what you save. See pricing.
The shared failure mode
Neither one renews itself.
Whichever you buy, the term still ends on a fixed date, and AWS doesn't prompt anyone when it does. A lapsed Reserved Instance and a lapsed Savings Plan fail identically: the running usage doesn't change at all, only the price does. It reverts to the standard on-demand rate immediately and silently, and stays there until somebody notices and buys again. See the renewal playbook for the full mechanics of the cliff, or run your own numbers on the savings calculator: a small, fixed cost to watch for the lapse against a large, avoidable loss if nobody does, whether it's one commitment or a thousand.
Where Reserver fits
RIs today. Savings Plans on the roadmap.
Reserver recommends Reserved Instances today. It does not yet track Savings Plans, including Database Savings Plans. Reserver connects to your AWS accounts read-only and matches Reserved Instances to what's actually running across RDS, ElastiCache, and EC2: coverage maps, purchase recommendations with the math shown, and an expiry radar. You buy in the AWS console. One-click buying and renewal autopilot are on the roadmap, not built yet. Savings Plans are on our roadmap, not shipping yet. If your fleet already holds a Savings Plan, Reserver's coverage view shows only the RI half for now. See features, how it works, and the security model behind the read-only connection, or read the savings playbook and the coverage playbook for the RI side of the math. See also: how Azure and Google Cloud handle renewal differently from either AWS commitment above.
Can I use Reserved Instances and Savings Plans together?
Yes. They're not mutually exclusive, and most fleets of any real size use both. For EC2, AWS applies Reserved Instance discounts first, then applies any Savings Plan to what is left. A common split is RIs on steady usage and a Savings Plan over compute that shifts. For databases, AWS does not combine the two on the same workload. You can use RIs on one database workload and a Database Savings Plan on another.
Which one saves more money?
Neither wins outright. It depends on how stable the usage is. A Reserved Instance on usage that never changes can match a Savings Plan's discount depth while adding marketplace resale as a safety net. A Savings Plan on usage that resizes or moves keeps discounting through changes an RI would just stop covering. The right answer is usage-shape-dependent, not a fixed ranking.
Do Savings Plans cover RDS or ElastiCache?
Yes, since 2 December 2025, through Database Savings Plans. They have limits. The discount is up to 35%. The term is 1 year, with No Upfront payment only. Provisioned RDS and Aurora instances must be Generation 7 or newer. Serverless usage is also covered. For ElastiCache, only Valkey is covered. A Compute Savings Plan still does not cover RDS or ElastiCache.
Should I buy an RDS Reserved Instance or a Database Savings Plan?
It depends on the usage. For steady Generation 7 or newer usage, the RI gives the deeper discount (up to 69% on RDS) and a 3-year option. For usage that moves between engines, families, or regions, the plan fits better. For Generation 6 and older classes, and for ElastiCache for Redis OSS or Memcached, only an RI is available. Every commitment still ends at term end. A 1-year plan puts a renewal date on the calendar every year.
Does a Savings Plan auto-renew like a subscription?
No. AWS does not renew a Savings Plan. You can queue a replacement with Renew Savings Plan, but you must do it. This is the trap both share. A Savings Plan is a fixed-term commitment exactly like a Reserved Instance: when the term ends, the hourly spend commitment stops, and every dollar of usage it was discounting reverts to the standard on-demand rate immediately and silently.
Sources, fetched and confirmed on 2026-10-12: AWS announcement of Database Savings Plans, 2 December 2025; Savings Plans plan types; Database Savings Plans pricing; Savings Plans FAQ; and queue a Savings Plan replacement.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list, and we will onboard you when we have capacity. Your first recommendation lands within minutes of connecting.