RI vs Savings Plans: Choosing an AWS Commitment Discount
Every time this series covered choosing EC2, RDS, containers, or storage, the same sentence appeared at the end: “if long-running usage is certain, look into commitment discounts.” This post provides a framework for choosing that commitment. The conclusion up front: for new EC2-centric commitments, Savings Plans are the default; the places where RIs (Reserved Instances) are still needed are services outside EC2 — RDS and its peers — and capacity reservation. When discounts are equal, pick the more flexible instrument. Prices and discount rates use us-east-1 as the reference region and on-demand rates as the baseline.
Side-by-side comparison #
| Standard RI | Convertible RI | EC2 Instance SP | Compute SP | |
|---|---|---|---|---|
| Max discount (3yr, all upfront) | ~72% | ~66% | ~72% | ~66% |
| Scope | Instance family + region | Changeable via exchange | Family + region fixed | All EC2 + Fargate + Lambda |
| Family change | No | Via exchange process | No | Applies automatically |
| Size/OS change | Conditional (regional, Linux, etc.) | Via exchange process | Automatic | Automatic |
| Resale | Marketplace | No | No | No |
The structural difference: buying attributes vs buying spend #
An RI is a commitment that buys instance attributes. You specify a combination — “m5.xlarge, us-east-1, Linux, for 1 year” — and running instances that match those attributes get the discount. If the attributes drift, the discount sits idle and you pay on-demand. Regional Linux RIs apply flexibly across sizes within a family, but crossing families is impossible with a Standard RI and requires the exchange process of a Convertible RI.
A Savings Plan is a commitment that buys an hourly spend. Commit to, say, $10 per hour for a year, and usage up to that amount gets the discounted rate, with only the overflow billed on-demand. AWS automatically allocates the discount to whatever saves the most. Swap m5 for c7g, shrink EC2 and grow Fargate (under a Compute SP) — the commitment keeps being consumed. For teams that keep optimizing across EC2 instance families, this difference is decisive.
The management burden also follows the structure. RIs require tracking “which attributes did we buy, how many, and how many currently match”; with SPs you only watch the hourly commitment and its coverage against actual usage.
Discount rates: compare like against like, not the maximums #
On paper, Standard RIs and EC2 Instance SPs top out the same (~72%), as do Convertible RIs and Compute SPs (~66%). The practical conclusions are simple.
- EC2 Instance SP vs Standard RI: effectively identical discounts, but the SP is more flexible with automatic size and OS application. Unless you need capacity reservation or resale (covered below), the SP wins.
- Compute SP vs Convertible RI: again similar rates, but a Convertible RI’s exchange is a manual process while a Compute SP applies automatically. For new commitments, Compute SP.
- The maximums assume 3-year all-upfront. A 1-year no-upfront commitment discounts less (roughly the 20〜30% range for a Compute SP) but carries less weight. Upfront payment is a cash-flow question more than a discount question — settle it with finance.
Where RIs remain: what Savings Plans cannot cover #
Savings Plans cover EC2, Fargate, and Lambda (SageMaker has its own separate SageMaker Savings Plans). Flip that around and it means everything else still runs on the RI-style reservation system.
- RDS Reserved Instances: the databases discussed in RDS instance classes and Aurora are not SP-eligible. For a steadily running production database, an RDS RI is the only commitment instrument, and the savings are substantial.
- ElastiCache, OpenSearch, Redshift, DynamoDB: each has its own reserved-node or reserved-capacity scheme. Different names, same RI structure.
- Capacity reservation: SPs and regional RIs are billing discounts only — they guarantee no capacity. If you must be able to launch instances in a specific AZ, solve it with zonal RIs or On-Demand Capacity Reservations (ODCR); ODCRs combine with Compute SPs.
- Resale: the only commitment you can dispose of mid-term is a Standard RI (via the Marketplace). SPs cannot be cancelled or transferred.
Sizing: commit only up to the stable floor of your bill #
The one real risk of commitments is overcommitting. An SP bills the full hourly commitment even when usage falls short, so unused commitment is pure loss. A safe sizing sequence:
- Measure the baseline: in Cost Explorer’s recent months, find the always-on usage that persists through nights and weekends. That is your committable floor.
- Commit to only part of the floor first: start from the recommendation Cost Explorer computes, but keep the first purchase conservative — 1 year, no upfront.
- Build up in layers: commitments stack. Reviewing coverage and utilization each quarter and buying only the shortfall carries less risk than one large commitment.
- Exclude usage that is scheduled to shrink: workloads slated for migration, or services with a movement plan like the ones in Lambda vs Fargate, come out of the calculation. For the same reason, purge waste with the standing checklist before committing — committing to waste just means wasting at a discount.
Selection order #
- Check the service scope first: EC2, Fargate, or Lambda means SP; databases and analytics — RDS and its peers — mean that service’s own RI or reservation.
- Pick the SP flavor by family confidence: if the family and region are locked in for years, EC2 Instance SP (up to 72%); if they might change, Compute SP (up to 66%). Grabbing a fixed commitment to save 6 points without that confidence is the classic regret pattern.
- Check capacity guarantee requirements: if capacity in a specific AZ is mandatory, plan zonal RIs or ODCRs separately.
- Size below the stable floor: commit the always-on portion only and leave the variable portion on-demand.
- Revisit quarterly: watch coverage and utilization metrics and add layers. A commitment is not a one-time decision but a recurring operation.
Summary #
- For new EC2-centric commitments, Savings Plans are the default. At equal discounts, the instrument that applies automatically wins.
- Confident in the family? EC2 Instance SP (up to 72%). Not confident? Compute SP (up to 66%). The 6-point gap is the price of flexibility.
- RDS, ElastiCache, OpenSearch, and Redshift are not SP-eligible — they use their own reservation schemes. Production database commitments remain RI territory.
- SPs and regional RIs are billing discounts only. Capacity guarantees are solved separately with zonal RIs or ODCRs.
- Size commitments up to the stable floor of the bill, layered across multiple purchases. Unused commitment is loss, and committing to waste is just discounted waste.