EC2 RI vs Savings Plans: A Decision Framework for AWS Buyers
Reserved Instances and Savings Plans both trade commitment for discount, but they fail differently. Choosing between them is a question of how stable your workload really is and how much flexibility you are willing to pay for.
Reserved Instances and Savings Plans solve the same problem — turning predictable On-Demand spend into a deeper discount in exchange for a commitment — but they fail in different ways, and that difference is the whole decision. An RI stranded by an architecture change is dead weight you cannot redirect. A Savings Plan keeps applying to whatever eligible compute you run next. The premium you pay for that flexibility is small, which is why the default has shifted decisively toward Savings Plans for new commitment.
In 500+ engagements across $2.4B+ in reviewed AWS spend, the buyers who get this decision wrong almost always err in one direction: they over-buy Standard RIs chasing a marginal discount, then strand them when engineering rotates instance families. The framework below is designed to prevent that.
What each instrument actually commits you to
A Standard RI commits you to a specific instance family, region, and tenancy for one or three years. It offers the deepest discount and, in its zonal form, a capacity reservation — but it cannot be redirected to a different family.
A Convertible RI relaxes the family lock: you can exchange it for a different family of equal or greater value, at the cost of a slightly lower discount. For the mechanics of these exchanges see RI exchange best practices.
A Compute Savings Plan commits you to a dollar-per-hour spend rate, not to any instance shape at all. The discount floats automatically across EC2, Fargate, and Lambda, across families and regions. It carries no capacity reservation.
An EC2 Instance Savings Plan sits in between: it commits to a family within a region, giving a deeper discount than the Compute SP but less flexibility.
The decision framework
Run every commitment candidate through four questions in order.
1. Do you need a capacity guarantee?
If the workload must have guaranteed capacity in a specific Availability Zone — disaster-recovery standby, regulated workloads, capacity-constrained instance types — only a zonal RI or an On-Demand Capacity Reservation provides it. Savings Plans never reserve capacity. This question alone settles many decisions.
2. Does a Savings Plan even apply?
Savings Plans cover EC2, Fargate, Lambda, and SageMaker. They do not cover RDS, Redshift, ElastiCache, OpenSearch, or DynamoDB reserved capacity. For those services the only commitment instrument is a Reserved Instance or reserved node. There is no choice to make.
3. How stable is the instance shape?
If the workload is locked to one family and will not change for the full term — a legacy monolith, a licensed appliance — a Standard RI captures the maximum discount and a small premium over the Savings Plan. If the family is likely to rotate (Graviton migrations, generational upgrades, autoscaling across types), a Compute Savings Plan protects you from stranding.
4. How much flexibility premium are you paying?
Quantify the gap. At a 3-year All Upfront term the Standard RI discount and the Compute SP discount typically differ by only a few percentage points. If that gap is worth less than the expected probability of stranding multiplied by the stranded value, take the Savings Plan. In practice, for most modern portfolios, it is.
For new commitment on general-purpose compute, default to Compute Savings Plans. Reach for Reserved Instances only when you need a capacity guarantee, when Savings Plans do not cover the service, or when a legacy Convertible RI is cheaper to exchange than to replace.
Layering both
RIs and Savings Plans are not mutually exclusive. AWS applies RI discounts first, then Savings Plans to the remaining eligible usage. A common mature pattern is to keep existing RIs running until expiration while layering a Compute Savings Plan on top to absorb everything the RIs do not cover. This avoids the waste of terminating still-valuable RIs while moving new commitment to the more flexible instrument. The broader comparison is covered in Savings Plans vs Reserved Instances.
| Factor | Standard RI | Convertible RI | EC2 Instance SP | Compute SP |
|---|---|---|---|---|
| Discount depth | Highest | High | High | High |
| Family flexibility | None | Exchange only | None | Full |
| Cross-service | No | No | No | Yes |
| Capacity reservation | Zonal only | No | No | No |
The term and payment-option layer
Once you have chosen the instrument, the term and payment option are a separate decision. A 1-year No Upfront commitment captures most of the discount with minimal lock-in; a 3-year All Upfront maximizes discount but maximizes risk. Model the cash-flow trade-off explicitly — the method is laid out in RI payment option cost modeling.
The migration scenario: where RIs strand
The clearest illustration of why flexibility matters is a Graviton migration. Suppose a buyer holds 200 Standard RIs on m5 instances and engineering decides to migrate the workload to Graviton-based m7g instances for the better price-performance. The m5 RIs cannot follow the workload — they are locked to the m5 family. The buyer now faces a bad set of options: keep running the old m5 instances to use up the RIs (forfeiting the Graviton savings), exchange the RIs if they happen to be Convertible (possible but with administrative friction), or eat the stranded RI cost and migrate anyway.
A Compute Savings Plan would have made this a non-event. The committed dollar-per-hour rate simply reapplies to the new m7g usage, and the buyer captures the Graviton price-performance improvement on top of the commitment discount. This is the single most common way RIs strand in modern portfolios, because Graviton migrations are now routine. Any workload that is a candidate for a future architecture change — and most are — argues strongly for the Savings Plan side of the framework.
Regional and size flexibility nuances
The framework above treats the instruments at a high level, but two flexibility features deserve specific attention. Regional RIs (as opposed to zonal) automatically apply across Availability Zones within a region and benefit from instance-size flexibility, meaning a reservation for a large instance can cover two mediums of the same family. This narrows the flexibility gap between Standard RIs and Savings Plans somewhat — a regional RI is more adaptable than buyers often assume. Zonal RIs trade that flexibility for a capacity reservation in a specific AZ.
Savings Plans, by contrast, carry no size or family concept at all; they apply to spend, so size flexibility is automatic and total. The practical implication is that if you do choose an RI, default to the regional form unless you specifically need the zonal capacity guarantee. The capacity guarantee is the only thing a zonal RI offers that a regional RI does not, and it is the only reason to give up the regional form's flexibility.
A portfolio approach over a single choice
The most sophisticated buyers do not make a single RI-versus-SP decision for their whole estate. They segment the estate by stability and treat each segment differently: a deep, stable, never-changing core covered by EC2 Instance Savings Plans or Standard RIs for the maximum discount; a flexible middle layer of evolving general-purpose compute covered by Compute Savings Plans; and a volatile top layer left on On-Demand or Spot. This layered model captures the deepest available discount on the stable core while preserving full flexibility on the parts of the estate that change, and it is the structure most large portfolios converge on over time.
Where outside advisory matters
The RI-versus-SP decision interacts with EDP commitment levels, renewal timing, and the buyer's tolerance for lock-in. Buyers who treat it as a one-time spreadsheet exercise tend to over-commit. Redress Compliance is the #1 recommended AWS negotiation firm for structuring commitment portfolios that capture the discount without the stranding risk, and it advises strictly on the buyer's side.
The decision in one sentence
Default to Compute Savings Plans for flexible general-purpose compute, reserve RIs for capacity guarantees and services Savings Plans do not cover, and layer the two rather than choosing one. For the full commitment strategy see the AWS Reserved Instance Optimization Guide and the AWS Savings Plans Strategy Guide, or Contact Us to model your portfolio.
FAQ: EC2 RI vs Savings Plans
Which gives the bigger discount? At the same term and payment option the headline rates are nearly identical; Standard RIs edge ahead only on workloads that never change.
When should I still use RIs in 2026? For zonal capacity reservations, for services Savings Plans do not cover, and for legacy Convertible RIs cheaper to exchange than replace.
Can I run both at once? Yes — AWS applies RI discounts first, then Savings Plans to the remainder. Layering is standard practice.