Reserved instances vs on-demand vs savings plans

Most cloud bills contain the same quiet mistake: steady, predictable servers billed at the on-demand rack rate for months on end. Commitment discounts are the single largest lever on a compute bill, and the math for using them safely fits on one page.

The three ways to pay

Every major provider offers the same three tiers under different names:

Model	Typical discount	What you commit to	The catch
On-demand	0% (the baseline)	Nothing	You pay the rack rate for flexibility you may not be using
Commitments (reserved instances, savings plans, CUDs)	30 to 45% at 1 yr, 50 to 70% at 3 yr	An instance type or an hourly spend, for the full term	You pay whether you use it or not
Spot / preemptible	60 to 90%	Nothing, but capacity can be reclaimed with minutes of notice	Only fits interruption-tolerant workloads

Within commitments there are two species, and the difference matters more than the brand names:

Resource-based (AWS Standard Reserved Instances, Azure Reservations, GCP resource CUDs): you commit to a specific instance family in a specific region. Deepest discounts, least flexibility. If you migrate off that instance family mid-term, the discount strands.
Spend-based (AWS Compute Savings Plans, Azure savings plans, GCP flexible CUDs): you commit to spending, say, $5/hour on compute, and the discount follows your usage across instance families and usually regions. You give up a few points of discount for commitments that survive replatforming.

The break-even math

A commitment is a bet that the workload keeps running. The break-even point is just the discount inverted:

Break-even utilization = 1 minus the discount.

At a 40% discount, the commitment costs 60% of on-demand, so it pays off as long as you’d have run the workload more than 60% of the term. Concretely:

A server at $100/month on-demand costs $1,200/year. A 1-year commitment at 40% off costs $720/year, guaranteed.
If you’d have run it all 12 months on-demand: you save $480.
If the project gets cancelled at month 7: on-demand would have cost $700; the commitment costs $720. You’re $20 underwater, roughly the break-even.
Cancelled at month 4: you’ve paid $720 for $400 of value. The “discount” cost you $320.

Same logic at 3-year terms, with bigger stakes: a 60% discount breaks even at about 14.4 months of a 36-month term. That sounds forgiving until you remember how different your architecture was 3 years ago.

A worked fleet example. Say your compute bill is $10,000/month on-demand, and metrics show $7,000 of it is steady baseline (always-on production servers and databases) while $3,000 is spiky (autoscaled workers, dev environments that shut down at night).

Commit to the $7,000 baseline with a 1-year spend-based plan at 35%: pay $4,550 for it, saving $2,450/month, $29,400/year.
Leave the $3,000 spiky layer on-demand (or push the tolerant parts to spot).
New bill: about $7,550/month, a 24.5% cut, with zero architectural change and modest risk.

Now the failure mode: commit to the full $10,000 instead, then usage drops to $8,000. You still pay commitment rates on $10,000 of coverage. The extra $2,000 of commitment at 35% off costs $1,300/month for nothing, and your effective discount on real usage shrinks to around 19%. Overcommitment is how a savings instrument becomes a line item you resent.

What each provider calls it

	AWS	Azure	Google Cloud
Resource-based	Standard / Convertible Reserved Instances	Reservations (exchangeable within limits)	Resource-based committed-use discounts
Spend-based	Compute Savings Plans	Azure savings plan for compute	Flexible CUDs
Automatic	None	None	Sustained-use discounts, up to ~30% off with no commitment
Interruptible	Spot, 60 to 90% off	Spot VMs	Spot VMs, 60 to 91% off

Provider-specific notes worth knowing:

AWS: Compute Savings Plans are the default recommendation; they apply across EC2 families, Fargate, and Lambda. Standard RIs still win a few extra points for workloads you’d bet the term on (a database that isn’t going anywhere).
Azure: Reservations can be exchanged or refunded within limits (a genuine safety valve), and they stack with Hybrid Benefit licensing, which is often the bigger discount for Windows shops.
GCP: Sustained-use discounts apply automatically the longer an instance runs each month, which forgives procrastination. CUDs stack on top for the committed layer.
DigitalOcean and OCI: DigitalOcean’s list prices are flat and already near hyperscaler committed rates, so there’s nothing to manage. OCI discounts through negotiated universal credit commitments rather than self-service instruments.

When each model fits

On-demand: anything you can’t predict a year out. New products, experiments, workloads being rightsized, autoscaled peaks, and dev/test that shuts down nights and weekends (turning things off beats any discount: a stopped instance is 100% off).
1-year spend-based commitments: your steady production baseline. The default instrument for most teams.
3-year commitments: the subset you’d bet the business’s architecture on: the core database, the always-on fleet of a mature product. Take the deeper discount only where the 3-year assumption is honestly defensible.
Spot: CI runners, batch processing, rendering, stateless queue workers. Free money for tolerant workloads, an outage generator for everything else.

A sane commitment strategy

Rightsize first. Committing to oversized instances locks in the waste at a discount. Run the rightsizing process before signing anything.
Measure your baseline. Pull 3 months of usage and find the floor your compute never drops below. That floor, minus a safety margin, is your committable base.
Cover 60 to 80% of the baseline with spend-based 1-year commitments. Undercommitting slightly costs a few percent; overcommitting costs real dollars.
Ladder your terms. Buy commitments quarterly rather than one annual block, so expirations stagger and each renewal is a fresh look at actual usage.
Review utilization monthly. Every provider reports commitment utilization and coverage. Utilization below ~95% means you overcommitted; coverage below ~60% of steady usage means money is still on the table. Fold it into the same review that catches bill shock.

FAQ

What’s the difference between a reserved instance and a savings plan?

A reserved instance commits you to a specific instance family in a specific region; a savings plan commits you to an hourly spend amount that applies across instance types and often regions. Discounts are similar (savings plans give up a few points for the flexibility). For most teams, spend-based commitments like AWS Compute Savings Plans are the safer instrument because they survive architecture changes.

How much do commitments actually save?

Roughly 30 to 45% off on-demand for 1-year terms and 50 to 70% for 3-year terms, across AWS, Azure, and GCP, with the deepest discounts on locked-down, upfront-paid, 3-year instruments. On a $10,000/month compute bill with a $7,000 steady baseline, a 1-year commitment at 35% saves about $29,000 a year.

What happens if I commit and my usage drops?

You keep paying. Commitments bill for the committed amount whether you consume it or not, so a $5,000/month commitment against $3,500 of actual usage wastes $1,500 monthly, which can erase the discount entirely. Azure allows limited exchanges and refunds, AWS allows queued modifications on some instruments, but the honest planning assumption is that a commitment is a bill you’ve agreed to pay.

Should I use spot instances instead?

For the right workloads, alongside commitments rather than instead of them. Spot (or preemptible) capacity is 60 to 90% off but can be reclaimed by the provider with minutes or seconds of notice, so it fits fault-tolerant batch jobs, CI runners, and stateless workers behind a queue. Databases and anything a customer is waiting on stay on committed or on-demand capacity.

Not sure how much of your bill is safely committable, or sitting on commitments you suspect are underwater? Talk to a Webisoft cloud engineer. We’ll read your usage data and give you a commitment plan with the break-even math shown, not just a discount percentage.