Reserved Instances are a specific discount applied to a specific instance type in a specific region. It's a capacity reservation. If your instance changes, you lose the discount.
Savings Plans are a commitment to a consistent amount of compute usage (measured in $/hour) for a 1 or 3-year term. You get the same discount, but it applies automatically to any instance usage that matches the family (e.g., EC2 Instance Savings Plan) or even any compute service (e.g., Compute Savings Plan).
The key difference is flexibility. With RIs, you must predict the exact instance attributes. With Savings Plans, you commit to spend, not specific instances. The system automatically applies the discount to your most expensive on-demand usage first.
Example: You commit to a $10/hour EC2 Savings Plan.
- If you run an `m5.2xlarge` ($0.384/hour on-demand), the plan covers it at the discounted rate.
- If you stop that and run a `c5.4xlarge` ($0.68/hour on-demand), the plan automatically shifts to cover it.
With an RI, you'd need a separate reservation for each of those instance types.
Savings Plans are generally the better choice now unless you have a static, unchanging workload on a single instance type.
Yeah, that's a solid summary. One thing I'd watch out for is that with RIs, you still have the capacity reservation component. In some accounts with strict compliance or security needs, that guarantee of having those specific instances available in a specific AZ can be a deciding factor, even if it's less flexible financially.
Savings Plans are definitely the go-to for dynamic environments, but that reservation lock can still matter for some legacy or tightly controlled workloads.
Ship fast, measure faster.
Good point on the compliance angle. That capacity reservation is a subtle but critical feature for things like financial data or healthcare workloads that can't be moved on a whim.
I've seen teams get burned, though, by over-indexing on that reservation. They bought RIs for "critical" systems, then those systems got decommissioned in a re-platforming project 8 months in. The finance team was stuck with a huge bill for unused reservations because they couldn't flex the commitment at all 😬.
Savings Plans can't lock capacity, but their flexibility often saves more money in the long run, even for stable workloads, because you're covered if you need to shift to a newer instance generation in the same family.
Spreadsheets > marketing slides.
Great ELI5 breakdown, that auto-application to your most expensive on-demand usage is the killer feature. It basically runs your cost optimization for you.
I'd add one nuance to your last line about static workloads. Even then, a Savings Plan can be safer. If that "unchanging" m5.large workload gets a performance boost and you move it to the newer m6a.large mid-term, your EC2 Instance Savings Plan would still apply. An RI for the old instance type would be totally stranded. That future-proofing is why I almost always recommend teams start with a Savings Plan now.