AWS Savings Plans vs Reserved Instances: Which One, When
Commitment discounts are the single biggest lever on an AWS bill — 30–60% off on-demand rates for workloads you were going to run anyway. They are also the easiest place to lock in a mistake for one or three years. The "Savings Plans vs Reserved Instances" question comes up in almost every cost review we run, and the honest answer is: most teams need both, because they cover different services. Here is the decision framework we use with clients.
The two mechanisms at a glance
| Savings Plans | Reserved Instances | |
|---|---|---|
| What you commit to | $/hour of compute spend | A specific instance configuration |
| Covers | EC2, Fargate, Lambda (Compute SP); SageMaker has its own SP | EC2, RDS, ElastiCache, OpenSearch, Redshift (as reserved nodes/instances) |
| Flexibility | High — applies across family, size, OS, region (Compute SP) | Lower — tied to instance attributes; Convertible RIs can be exchanged |
| Typical discount | Up to ~66% (EC2 Instance SP, 3yr) / ~50% (Compute SP, 3yr) | Up to ~60–70% depending on service and term |
| Term / payment | 1 or 3 years; no/partial/all upfront | 1 or 3 years; no/partial/all upfront |
| Resale if plans change | No | Standard EC2 RIs can be sold on the RI Marketplace |
The rule of thumb
- Compute (EC2/Fargate/Lambda): use Savings Plans. They replaced EC2 RIs as the default because they survive architecture changes — switch instance families, move a workload to Fargate, adopt Graviton, and the discount follows your spend.
- Databases and analytics (RDS, ElastiCache, OpenSearch, Redshift): use Reserved Instances / reserved nodes. This is the gap teams miss: Savings Plans do not cover RDS. If your bill is database-heavy — and most are — an SP-only strategy leaves your biggest line item at on-demand rates.
- DynamoDB: has its own reserved capacity mechanism, separate from both.
Compute SP vs EC2 Instance SP
Within Savings Plans there is a second decision. Compute Savings Plans apply to any compute anywhere — any family, size, region, OS, and also Fargate and Lambda — at a somewhat lower discount. EC2 Instance Savings Plans pay more (rates comparable to Standard RIs) but lock you to an instance family in a region. Our default: Compute SP for most of the commitment, EC2 Instance SP only for workloads you are certain will stay on the same family for the full term (large, stable, steady-state fleets). If you expect a Graviton migration or a containerization push, stay on Compute SP — flexibility is worth more than the extra points of discount.
Standard vs Convertible RIs
For the services where RIs are the only option, the trade-off repeats: Standard RIs discount more and can be resold on the marketplace (EC2 only); Convertible RIs discount less but can be exchanged for different configurations mid-term. For RDS, where engine and size changes are common, shorter terms or conservative sizing beat aggressive three-year all-upfront bets.
How to size the commitment
- 1. Rightsize first, commit second. Committing to an oversized fleet locks the waste in for the term. Clean up first — our cost-cutting guide covers the sequence.
- 2. Commit to the stable baseline, not the peak. Look at 30–90 days of usage in Cost Explorer; commit to roughly 70–80% of the steady floor and let spikes ride on-demand or Spot. Under-commitment costs you a few points of discount; over-commitment is money burned every hour.
- 3. Ladder your commitments. Instead of one big 3-year purchase, buy in tranches every quarter. You average out forecasting errors and always have tranches expiring soon if plans change.
- 4. Watch two numbers monthly: utilization (are you using what you bought?) and coverage (how much eligible usage is still on-demand?). Both live in Cost Explorer's Savings Plans / RI reports. Utilization below ~95% means you overbought; coverage below ~70% on a stable workload means you are leaving money on the table.
The mistakes we keep finding in audits
- SP-only strategies with RDS-heavy bills — the database line item quietly stays at full price.
- Committing before rightsizing — a three-year discount on instances twice the needed size is still waste.
- Expired and forgotten — RIs and SPs lapse silently; usage reverts to on-demand and nobody notices until the bill jumps. Set expiry alerts.
- All-upfront on uncertain workloads — no-upfront costs only slightly more and keeps cash and options open.
- Nobody owns the number — coverage and utilization reviewed by no one, purchased once, never revisited. Commitment management is a quarterly routine, not a one-off.
Frequently asked questions
Do Savings Plans cover RDS?
No. Savings Plans cover EC2, Fargate and Lambda (plus a separate SageMaker plan). RDS, ElastiCache, OpenSearch and Redshift need Reserved Instances / reserved nodes.
Which saves more, Savings Plans or Reserved Instances?
At equal term and payment, EC2 Instance SPs and Standard RIs are comparable; Compute SPs discount somewhat less in exchange for much more flexibility. The bigger savings difference comes from sizing and coverage discipline, not from the mechanism.
Can I sell an unused commitment?
Only Standard EC2 Reserved Instances can be resold on the RI Marketplace. Savings Plans and Convertible RIs cannot be sold — another reason to size conservatively.
1 year or 3 years?
Three-year terms discount substantially more, but only commit that far on workloads with a proven, stable baseline. A common pattern: 3-year commitments for the proven floor, 1-year tranches for the rest.
Bottom line
Savings Plans for compute, Reserved Instances for databases, sized to the post-cleanup baseline, bought in tranches, reviewed quarterly. That one sentence is most of commitment strategy — the rest is the discipline to actually do the cleanup first and watch the two numbers monthly.
Want the commitment math done on your actual bill? Our AWS Cost Optimization audit (fixed €5,000, credited if you proceed to a project) quantifies your waste per finding and delivers a sized, laddered commitment plan — with a pay-from-savings option.