Reserved Instances vs Savings Plans vs Spot: a one-page cheat sheet
Reserved Instances, Savings Plans, Spot, On-Demand — a decision matrix based on workload shape, risk tolerance, and the effective discount you actually realise.
AWS has four ways to buy EC2 capacity: On-Demand, Reserved Instances, Savings Plans, and Spot. Each one trades off some combination of price, flexibility, and risk. The marketing material on every one of them quotes a different "up to 72% savings". None of those numbers reflect what you actually pay.
This is the matrix I use when planning capacity for a new workload.
The four options, one paragraph each
On-Demand: Pay the list price per second. No commitment. Maximum flexibility, maximum cost. Use for workloads you can't predict — POCs, dev environments that scale to zero overnight, traffic spikes.
Reserved Instances (RIs): Commit to a specific instance type, in a specific region, for 1 or 3 years. Save 30-72% versus on-demand. Available as Standard (cheapest, can't change instance family) and Convertible (slightly more expensive, can exchange for a different family). Mostly being phased out in favour of Savings Plans.
Compute Savings Plans: Commit to a dollar amount per hour of compute spend, for 1 or 3 years. Applies to EC2, Fargate, and Lambda. Save 17-27% versus on-demand without locking yourself to a specific instance family or region. Lower headline savings than RIs, much more flexible.
Spot Instances: Bid on unused EC2 capacity. Save up to 90% versus on-demand. AWS can reclaim the instance with 2 minutes' warning. Designed for fault-tolerant, stateless, or batch workloads.
The decision matrix
| Workload | Pick | Why |
|---|---|---|
| Steady 24/7 production app, fixed instance family | 3-year No-Upfront Standard RI | Best discount (~58% on M-family), still flexible enough on payment |
| Steady 24/7 production, mixed families and regions | 3-year Compute Savings Plan | One commitment covers everything, no juggling RI inventory |
| Production with 30-40% weekend dips | 1-year Compute SP at the baseline + on-demand for peaks | SP covers what you definitely use; don't over-commit |
| CI/CD runners, batch jobs, build farms | 100% Spot with mixed instance types | Interruption tolerance is by design; savings of 70-90% |
| Stateless web servers behind an ASG | Mixed: 70% Spot + 30% On-Demand baseline | Spot for elasticity, On-Demand to absorb interruptions |
| Stateful workloads (databases, brokers) | RI or SP — never Spot | Reclaim during a primary failover is operationally painful |
| POC / new product | On-Demand for 60 days, then re-evaluate | Don't commit before you know the shape of the workload |
| Dev environments that scale to zero overnight | On-Demand with autoscaling, no commitment | You'd pay for unused commitment hours |
The "effective discount" trap
The big mistake teams make is committing to capacity based on peak. A workload that uses 100 instances during business hours and 20 overnight has a true 24/7 baseline of 20 instances, not 100. Commit to the 20. Use Spot or On-Demand for the rest.
The other trap: committing to the wrong instance family. A 3-year RI on m5.xlarge sounds smart in 2024. In 2026, AWS releases m7i at the same price with 30% more performance, and you're locked into the older family for two more years. Convertible RIs give you an out, but the discount is lower.
Compute Savings Plans dodge this entirely. You commit to $X/hour of compute spend, applied to any instance family in any region. This is the right default for most teams.
The Spot interruption rate is not "random"
The EC2 Spot Instance Advisor publishes interruption rates by instance type and region. For most production-grade modern families (m6i, c6i, m7g) in us-east-1 or us-west-2, interruption rates are typically <5% on a 24-hour window.
The strategy is to use a Spot capacity pool that mixes 5-10 instance types across 2-3 AZs. EC2 Auto Scaling's "capacity-optimized" allocation strategy picks the pool with the lowest interruption rate at any given moment. With that setup, real-world interruptions are far rarer than the marketing suggests.
What about GCP and Azure?
GCP Committed Use Discounts work like AWS Savings Plans — commit to dollar-hours, get a discount. Spot/Preemptible VMs are equivalent. Azure Reserved VM Instances and Spot work the same way, though Azure RIs are tied to a specific region.
For a cross-provider comparison of effective hourly rates including commitment discounts, see the cloudprice catalogue — every row shows On-Demand and 1-year reserved/committed prices side by side. Worth comparing against AWS vs GCP if you're picking between hyperscalers.
The honest summary: 1-year Compute Savings Plan for the steady baseline, Spot for everything else, On-Demand only for true unknowns. Anything else is over-engineering the commitment.