Key takeaways
- Both reach up to 72 percent off on-demand; the ceiling is the same, the flexibility is not
- Savings Plans cover EC2, Fargate, and Lambda; RIs are the only discount for RDS and the other database engines
- Standard RIs can be resold on the AWS Marketplace; a Savings Plan cannot be exited early
- AWS applies RI discounts before Savings Plans, which matters when you hold both
What each one actually locks
A Reserved Instance is an attribute lock. You commit to an instance family in a region (for example, m7i in us-east-1), and usage matching those attributes bills at the discounted rate. Regional Linux RIs flex across sizes within the family, so one m7i.2xlarge reservation can cover two m7i.xlarge instances. Standard RIs hold their attributes for the whole term; convertible RIs can be exchanged for different attributes, at the cost of a few points of discount and a manual exchange process.
A Savings Plan is a dollar lock. You commit to an hourly spend, say $15 per hour, and AWS applies it to your most-discounted eligible usage first, every hour, automatically. A Compute Savings Plan follows your usage across EC2 instance families, regions, operating systems, Fargate, and Lambda with no action from you. An EC2 Instance Savings Plan narrows to one family in one region, like an RI, in exchange for the top discount tier.
In travel terms: a Reserved Instance books a specific hotel room for the year, while a Savings Plan prepays a nightly budget that discounts whichever hotel you end up in.
The comparison, line by line
| Reserved Instances | Savings Plans | |
|---|---|---|
| Maximum discount | Up to 72% (standard, 3-year, all upfront) | Up to 72% (EC2 Instance SP, 3-year, all upfront) |
| Flexible-option discount | Up to 66% (convertible) | Up to 66% (Compute SP) |
| Covers | EC2, RDS, ElastiCache, OpenSearch, Redshift, DynamoDB reserved capacity | EC2, Fargate, Lambda, SageMaker (separate plan) |
| What you commit to | Instance attributes (family, region, term) | Dollars per hour of compute spend |
| Adapts to family or region moves | Standard: no. Convertible: manual exchange | Compute SP: automatically |
| Capacity reservation | Zonal RIs reserve capacity | Never |
| Early exit | Standard EC2 RIs can be sold on the AWS Marketplace | No resale, no cancellation |
| Applies to the bill | First, before Savings Plans | After RIs, largest discount first |
Two rows in that table decide most real purchases: coverage and early exit.
Where Savings Plans win
For compute, the case is hard to argue against. A Compute Savings Plan survives the events that strand Reserved Instances: an instance-family refresh to the next generation, a Graviton migration, a region move, a workload shifting from EC2 to Fargate. Each of those turns a standard RI into dead weight or an exchange ticket, and turns a Compute Savings Plan into nothing at all, because the plan never knew which instances it was covering in the first place.
That resilience is worth real money in practice. Teams that were burned by stranded RIs respond by under-committing, and paying on-demand rates for steady usage costs more than a slightly imperfect commitment ever would. A discount instrument you trust enough to actually buy beats a marginally deeper one you keep postponing.
If the workload's home is genuinely stable, the EC2 Instance Savings Plan takes the top discount tier while keeping size, OS, and tenancy flexibility within the family. It is the direct replacement for the standard EC2 RI in almost every case.
Where Reserved Instances still win
Databases, first and always. Savings Plans do not touch RDS, ElastiCache, OpenSearch, or Redshift. If a third of your bill is RDS, the only commitment discount available for that third is a reservation, and database RIs are often the calmest purchase on the menu: a production Postgres instance rarely changes family mid-term, and RDS reserved pricing reaches roughly 60 percent off on 3-year terms.
Capacity guarantees, second. A zonal RI reserves actual capacity in an availability zone. If you run workloads that must scale into scarce instance types during a regional event, that guarantee has a value no Savings Plan offers. Most teams do not need this; the ones that do already know.
The marketplace exit, third. A standard EC2 RI can be listed on the AWS Marketplace and sold if plans change. Recovery is rarely full price, but it is an exit. A Savings Plan has none: whatever you commit, you pay, every hour, until the term ends. Teams that value the escape hatch sometimes prefer RIs for that reason alone, though the same logic argues for committing a smaller, safer number instead.
The trap when you hold both
AWS applies Reserved Instances to matching usage first, then applies Savings Plans to whatever remains, largest discount first. That ordering has a sharp edge: if you buy RIs to cover a workload that a Savings Plan was already covering, the plan's committed dollars do not go away. They shift onto other usage, and if there is not enough eligible usage left, the commitment goes unused while you pay for it. Any purchase decision should start from your current hourly coverage picture, not from a service-by-service look at on-demand spend.
The same ordering makes staged purchases safer: cover the stable floor with the deep-discount instrument for that workload class, then layer a Compute Savings Plan over the variable remainder, sized to the hourly level your total eligible spend never drops below.
How to decide in practice
Split the bill in two. Everything that is a database engine gets evaluated as a reservation, term by term, against how confident you are the engine and family survive the term. Everything that is compute gets a Savings Plan: EC2 Instance SP where the family is settled, Compute SP everywhere else, sized to the measured hourly floor rather than the monthly average.
