AWS Savings Plans vs Reserved Instances: The Break-Even Model Before Every Commitment
AWS offers two ways to commit compute spend in exchange for a discount: Savings Plans and Reserved Instances. Both offer up to 66-72% off on-demand rates. Both require a 1-year or 3-year commitment. The difference is what you are committing to.
A Reserved Instance commits to a specific instance type in a specific region. A Savings Plan commits to a dollar-per-hour spend rate that applies across any EC2 usage, Fargate, or Lambda. Reserved Instances have the higher ceiling discount. Savings Plans have the lower floor risk.
Most teams pick the wrong one because they optimize for the maximum discount percentage without modeling what happens when their workload changes. RI stranding, paying for committed capacity you cannot use, is the second-biggest source of cloud waste after idle resources. The break-even model prevents it.
The Discount Ceiling and Flexibility Trade-Off
The discount range varies by commitment type, payment option, and term. These are representative us-east-1 numbers for 1-year, no-upfront commitments.
| Commitment Type | Max Discount vs On-Demand | Applies To | Flexibility | Stranding Risk |
|---|---|---|---|---|
| Compute Savings Plan | 66% | Any EC2, Fargate, Lambda | Any instance family, size, region | Minimal: unused spend wastes the hourly rate but commitment auto-applies to whatever runs |
| EC2 Instance Savings Plan | 72% | One instance family in one region | Instance size flexible within family | Low: family-locked but size-flexible |
| Standard Reserved Instance | 72% | Specific instance type + region + OS | None without selling on Marketplace | High: wrong type or underutilization = full loss |
| Convertible Reserved Instance | 54% | Specific instance family, convertible | Convert to different family via AWS process | Moderate: conversion requires an AWS request |
The 6-8 percentage point difference between Compute Savings Plans and Standard RIs is the price of flexibility. For a workload spending $10,000 per month on EC2, that difference is $600-$800 per month in additional savings with Standard RIs. That is real money and the reason teams default to Standard RIs on paper.
The question is whether the workload will still be running the same instance type for the full commitment term. A Standard RI for m5.xlarge that converts to an m5.2xlarge 14 months into a 3-year term leaves 22 months of committed capacity with no matching workload.
The Three Variables in the Break-Even Model
Three variables determine whether Savings Plans or Reserved Instances produce lower total cost over the commitment term.
Utilization rate is the fraction of the commitment term during which the committed resource actually runs. A Reserved Instance at 100% utilization for 12 months returns its full discount. At 60% utilization, you pay for 12 months but only use 7.2 months. The unused 4.8 months of commitment is pure waste. Savings Plans do not strand this way: the hourly commitment rate auto-applies to whatever EC2 or Lambda usage is running, so a lower spend month wastes less.
Instance type change frequency is how often workloads resize, replatform, or move between instance families. If the m5.xlarge workload becomes an m5.2xlarge six months in, the Standard RI provides zero discount for the new size. A Compute Savings Plan covers the m5.2xlarge automatically because it commits to a spend rate, not a resource type.
Term length amplifies both of the above. A 1-year Standard RI that turns out to be the wrong type wastes at most 12 months of commitment. A 3-year Standard RI wastes at most 36 months. The discount premium for 3-year terms (roughly 10-15 percentage points over 1-year) is only worth the risk if the workload is genuinely stable.
| Utilization Rate | Change Frequency | Term | Recommended Commitment |
|---|---|---|---|
| Above 90% | Less than once per 18 months | 3 years | Standard Reserved Instance |
| Above 90% | Once per 6-12 months | 1 year | EC2 Instance Savings Plan |
| 70-90% | Once per 6-12 months | 1 year | Compute Savings Plan |
| Below 70% | Any | Any | Compute Savings Plan at reduced rate |
| Mixed families | Any | Any | Compute Savings Plan |
| Includes Fargate or Lambda | Any | Any | Compute Savings Plan |
RI Stranding: The Cost Most Teams Do Not Model
RI stranding is the gap between what you committed to pay and what your workload actually used. It is invisible on the monthly bill because AWS charges you either way.
Consider a 3-year Standard RI for m5.xlarge in us-east-1. No-upfront rate: $0.136 per hour, saving $0.068 per hour versus on-demand $0.192. Over 3 years that is $4,200 in savings per instance assuming 100% utilization.
Now model what happens when the workload resizes to m5.2xlarge at month 14:
| Scenario | RI Hourly Cost | Usage | Stranded Spend | SP Equivalent Total |
|---|---|---|---|---|
| 100% utilization, no resize | $0.136/hr | 26,280 hrs | $0 | Higher by ~$600/yr |
| Resize at month 14 (22 months stranded) | $0.136/hr (paid, unused) | 10,248 hrs used | $3,006 wasted | Compute SP saves $1,800 vs stranded RI |
| Resize at month 6 (30 months stranded) | $0.136/hr (paid, unused) | 4,380 hrs used | $4,089 wasted | Compute SP saves $2,700 vs stranded RI |
| Workload terminated at month 8 | $0.136/hr (paid, no usage) | 0 hrs remaining | $4,573 wasted | Compute SP: waste only unused hourly rate |
The stranded spend column shows why Standard RIs are dangerous for workloads that are not provably stable. A resize 6 months in turns $4,200 of savings into $4,089 of waste: a net swing of over $8,000 on a single instance commitment.
Selling unused RIs on the AWS Marketplace is theoretically possible but practically slow: marketplace listings take weeks to sell, and convertible RIs cannot be sold at all. Teams that have been stranded once almost universally switch to Compute Savings Plans for subsequent commitments.
The cost flow Sankey view makes stranded RI spend visible as a discrete cost band: committed spend with no matching workload shows up as a flow that enters the commitment layer and does not reach the workload layer. Without that visibility, stranded RIs hide inside the EC2 line item.
When Compute Savings Plans Win
Compute Savings Plans are the right default for any team where workload mix is not provably stable over the commitment term.
| Team Profile | Recommended | Reason |
|---|---|---|
| Mixed EC2 + Fargate workloads | Compute SP | Only SP covers Fargate usage |
| Teams using Lambda at scale | Compute SP | Only SP covers Lambda compute |
| Instance families changed more than once in the past 12 months | Compute SP | Past change frequency predicts future frequency |
| Multi-region workloads that shift between regions | Compute SP | SP applies across regions; RIs are region-locked |
| Teams that have been RI-stranded before | Compute SP | Risk tolerance has been calibrated by experience |
| Using AWS Bedrock or other ML inference workloads | Compute SP | Inference workload sizes shift with model versions |
The Compute SP flexibility is also valuable for teams planning major infrastructure changes: moving from m5 to m7g (Graviton) instances, for example. A Compute SP covers m7g.xlarge automatically because it commits to a spend rate. A Standard RI for m5.xlarge covers nothing after the migration.
When Standard Reserved Instances Win
Standard RIs outperform Compute Savings Plans in one specific scenario: a steady-state, high-utilization workload on a stable instance type with a 3-year horizon.
| Workload Characteristic | RI Advantage |
|---|---|
| Database servers (RDS is a separate RI program) | 3-year RDS RI for stable db.r6g.xlarge saves 60% vs on-demand |
| Single-family EC2 fleet (e.g., all m5 or all c5) | EC2 Instance SP or Standard RI covers the full discount ceiling |
| Predictable utilization above 90% | Full discount applies for full term |
| No planned instance type changes for 3 years | No stranding risk; maximum discount applies |
The one-sentence rule: if you can look at a workload and say with confidence that it will run the same instance type at above 90% utilization for the full commitment term, Standard RIs produce the best outcome. If you cannot say that with confidence, Compute Savings Plans produce the safer outcome.
The Safe First Commitment: Start at 80% of Baseline
For teams making their first commitment purchase, the safest approach is a Compute Savings Plan at 80% of current on-demand hourly spend.
The 80% figure accounts for natural spend variation: weekends, deployment gaps, workload seasonality. A commitment at 80% of average spend almost never goes unused, which means close to zero stranding risk on the first purchase.
After 30 days of data, the coverage report shows what fraction of EC2, Fargate, and Lambda spend the Savings Plan covered. If coverage is consistently above 95%, the remaining 20% of baseline spend is a candidate for additional commitment. If coverage fluctuates, the existing SP is the right size and the remaining spend should stay on-demand.
For teams planning a high-traffic event, the commitment model changes slightly: pre-event Savings Plan top-ups can cover expected burst spend, but event readiness planning with pre-scaled capacity changes the on-demand baseline for the duration of the event window. Model the commitment against steady-state spend, not event-period spend.
The maximum discount is available with Standard RIs on a 3-year term paid all upfront. The minimum risk is available with Compute Savings Plans on a 1-year term with no upfront. The break-even model sits between those two poles and tells you exactly where your workload lands.
