Reserved Instances vs Savings Plans: Break-Even Math and What a Commitment Costs You If You're Wrong

Every Savings Plan pitch, from AWS or anyone else, shows you the same number: the discount. Commit for a year, save 28%. Commit for three, save half. What the pitch never shows is the other curve: what the commitment costs you if your usage drops, your architecture changes, or the product line whose baseline you committed to gets cancelled in month seven.

Finance always asks the second question ("what happens if we're wrong?"), engineering usually can't answer it with a number, and the commitment decision stalls or, worse, gets made on vibes. So here's the downside math, worked all the way through.

The instruments, in one paragraph each

Standard Reserved Instances commit you to an instance family in a region (with size flexibility within the family for Linux). Deepest discounts, least flexibility. The one escape hatch: Standard RIs can be listed on the RI Marketplace, usually at a haircut.

Convertible RIs trade a few points of discount for the right to exchange into other instance families. No marketplace resale, but the exchange right is a real hedge against architecture change.

Compute Savings Plans commit you to a dollar-per-hour spend across almost all compute: any instance family, any region, Fargate, Lambda. Most flexible, slightly shallower discount, and the important fine print: no resale, no exchange, no early exit. A Savings Plan is a promise to spend $X per hour, every hour, for the whole term, whether or not anything runs.

EC2 Instance Savings Plans sit between: deeper discount, locked to a family in a region, same no-exit rule.

Typical discount magnitudes (us-east-1 Linux, on-demand baseline, as of early 2026): a 1-year no-upfront Compute Savings Plan lands around the high-20s percent; 3-year around 50%; EC2 Instance Plans and Standard RIs a few points deeper at each term. Exact numbers vary by family; the shapes below don't.

The break-even formula

A commitment with discount d breaks even when your utilization of it stays above (1 - d). That's the whole formula.

Worked: your workload costs $1.00/hour on demand. A 1-year plan covers it at $0.72/hour (28% off). Break-even utilization is 72%: as long as the covered capacity is actually needed at least 72% of the term's hours, you win.

Now run the downside:

• Usage drops to 60% of what you committed. You pay $0.72/hour for every hour anyway. Effective rate on the hours you used: $0.72 divided by 0.60, which is $1.20/hour, 20% above on-demand. On one instance-equivalent that's about $1,050 lost over the year, and it scales linearly with the size of the miss.
• The workload dies at month 6 of a 3-year term. Remaining liability: your committed rate times every remaining clock-hour of thirty months. On a $5/hour Compute Savings Plan, that's around $109,000 of spend with nothing behind it, non-cancellable, non-resellable. A Standard RI in the same situation could be listed on the marketplace at a loss; a Convertible could be exchanged toward whatever replaced the workload; the Savings Plan has no lever at all.
• The subtle one: you committed to the average, not the trough. Usage that oscillates between 40 and 140 instances with a mean of 90 does not support a 90-instance commitment; every hour below 90 is paying the committed rate for idle coverage. Commitments should be sized on the floor of the usage curve, not its middle.

That last point is why the standard eligibility test is uptime-based: a workload is commitment-grade when it has run at high utilization (70% and up) for a sustained window (30 days and more), because the break-even math for a high-20s discount sits right at that threshold.

Decision rules that survive the downside

1. Sequence matters: optimize first, commit last. Rightsize, kill idle, schedule non-production, then commit to what remains. Committing before shrinking locks in the waste at a discount.
2. Commit to the trough. Size against a low percentile (p10) of the last 90 days of usage, not the average.
3. Ladder the terms. Several smaller commitments purchased quarterly instead of one big annual buy: your coverage tracks reality, and no single bet is fatal.
4. 1-year until proven, 3-year for bedrock. Three-year terms only for load that has already survived a year of architecture churn.
5. Target 60-80% coverage, not 100%. The last slice of usage is the volatile slice; leave it on demand deliberately.
6. Prefer flexibility at equal math. Compute Savings Plans over instance-scoped commitments unless the family is genuinely settled; Convertible over Standard when in doubt. The few points of discount you give up are the insurance premium.
7. Review utilization monthly. A commitment at 93% utilization is a decision working; the same commitment at 70% is a leak with a contract.

One more honesty check worth demanding from any tool (or spreadsheet) that recommends commitments: it should refuse to print a savings number it can't defend. ZopNight's commitment recommendations are a working example of that bar: they fire only on sustained measured uptime, price each 1-year and 3-year option from live rate feeds rather than a flat assumed discount, suppress any recommendation whose projected saving clears break-even by less than 10%, and when uptime can't be measured they say "savings unknown" instead of assuming 100%, with the term, rates, and break-even evidence attached to every figure (rule docs). Whatever you use, reject any recommendation that credits discount on hours you never ran.

FAQ

What's the difference between Reserved Instances and Savings Plans?

RIs reserve a specific instance family in a region (Standard: resellable on the RI Marketplace; Convertible: exchangeable). Savings Plans commit a dollar-per-hour spend (Compute: any family, region, Fargate, Lambda; EC2 Instance: one family, deeper discount) with no resale or exchange. Roughly: RIs are an asset you can partially unwind; Savings Plans are a pure spend promise.

What utilization makes a commitment break even?

One minus the discount. A 28% discount breaks even at 72% utilization of the committed amount; a 50% discount at 50%. Below break-even you're paying more than on-demand for the hours you actually used, which is why sustained high uptime over a meaningful window is the eligibility test, and why sizing on average rather than trough usage quietly guarantees waste.

Can I exit a Savings Plan or RI early?

Savings Plans: no. No cancellation, no resale, no exchange; the hourly commitment bills to the end of the term. Standard RIs can be sold on the RI Marketplace (usually below face value). Convertible RIs can be exchanged for different configurations of equal or greater value. This asymmetry is the strongest argument for flexible instruments when your architecture is still moving.

How much of my usage should be covered by commitments?

Most teams land at 60-80% of steady-state compute. Cover the floor of the usage curve with commitments, leave the volatile top slice on demand, and grow coverage in quarterly tranches as baselines prove themselves. 100% coverage means you've committed to your peaks, and peaks are exactly what usage stops doing.

Should I fix utilization or buy more coverage first?

Fix utilization first, always. Low utilization on an existing commitment means you're already paying for idle coverage; adding more commitment on top compounds it. And before any new commitment: rightsize, delete idle, schedule non-production. Commit to the fleet you should have, not the one you currently do.