Reserved Instances vs Savings Plans: Avoiding Wasted Commitment
· Cloud Credits Research, FinOps research
Reserved Instances and Savings Plans both offer the same bargain: promise the provider a one- or three-year commitment, get a meaningful discount off on-demand rates. The trap is identical for both. A commitment is a bet on your own future usage, and architectures change while the bet does not.
What each one actually locks
- Reserved Instances (RIs) commit you to attributes: instance family, region, and often the operating system or tenancy. Standard RIs are the cheapest per hour but the least flexible. Convertible RIs cost a little more and let you exchange configurations later.
- Savings Plans commit you to a dollar-per-hour of compute spend rather than a specific box. The discount applies automatically to whatever matches. The Compute Savings Plan is the most flexible, spanning instance families, regions, Fargate, and Lambda; the EC2 Instance Savings Plan is cheaper but narrower.
The other two clouds have direct analogs. Azure sells Reserved VM Instances and Savings Plans for compute; Google sells Committed Use Discounts (resource-based or spend-based). The wasted-commitment failure mode is the same everywhere.
Which to choose
| Situation | Better fit | Why |
|---|---|---|
| Truly fixed, long-lived workload | Standard RI | Lowest rate, and the attributes will not move |
| Mixed or evolving fleet | Compute Savings Plan | Auto-applies across families and regions |
| Want some flexibility, some savings | Convertible RI | Exchangeable within program rules |
| Serverless-heavy (Fargate, Lambda) | Compute Savings Plan | Only Compute plans cover these |
For most modern fleets the Compute Savings Plan is the safe default: you give up a sliver of discount versus a standard RI and buy back the freedom to change instance families without stranding the commitment.
Term length and payment options
Both instruments come in one-year and three-year terms, and both offer no-upfront, partial-upfront, and all-upfront payment. The pattern to internalize: longer terms and more upfront payment earn deeper discounts, but each also raises the cost of being wrong. A three-year all-upfront commitment on an instance family you abandon in month eight is capital you cannot get back. Unless the workload is genuinely fixed and long-lived, a one-year no-upfront or partial-upfront commitment captures most of the savings while keeping your exit cheap. Save the three-year terms for the truly boring baseline that has not changed in a year and will not change next year.
How commitment gets wasted
Waste is rarely a bad purchase on day one. It accumulates:
- Overcommitment. Buying to cover peak instead of the stable baseline. The peak-only portion sits underused, and unlike RIs, a Savings Plan usually cannot be cancelled.
- Drift. Coverage scoped to a project that got deprecated, a region you migrated out of, or an instance family you left behind. The discount keeps applying to nothing.
- Overlap. Layering new commitments without accounting for the ones already running, so total committed spend exceeds actual eligible usage.
The single most useful metric is utilization: the percentage of what you committed to that you actually consumed. Anything drifting below ~85 percent deserves an explanation. Coverage (how much of your eligible usage a commitment discounts) is the companion metric; low coverage means you are paying on-demand rates you could have discounted.
A buying discipline that ages well
- Commit to the baseline, not the peak. Look at the floor of your usage over the last few months and commit to that. Let on-demand and Savings Plans absorb the spiky top.
- Buy in layers. Several smaller one-year commitments over time beat one large three-year bet when your usage is still moving.
- Prefer flexibility when unsure. Compute Savings Plans and convertible RIs cost slightly more and forgive far more.
- Review every quarter. Fold commitment utilization into the same pass you use to hunt other billing drift in finding billing errors in cloud invoices.
Where commitments meet the rest of recovery
Commitment math sits inside a larger picture. Startup Activate credits cover early spend before commitments make sense. Once you are at scale, negotiated discounts (covered in negotiating enterprise cloud discounts) can stack with or replace some commitments. And when an outage breaches an SLA, the provider owes credits regardless of any commitment: track incidents at awsdown.com, azuredown.com, and gcpdown.com, then size the credit with the SLA calculators at cloudslacredit.com.
The per-cloud AWS, Azure, and GCP playbooks walk the specifics, and the resources library has the checklists. Automating detection and recovery end to end is what our sponsor Next Signal builds. Start with the blog or run a quick recovery estimate.
