Both Savings Plans and Reserved Instances trade a commitment for a discount off on-demand pricing. Past that, they work differently enough that picking the wrong one — or committing before you know what you're committing to — is one of the more expensive mistakes an account can make, because unlike most cost mistakes, this one locks in for one to three years.
What each one actually is
A Reserved Instance is a commitment to a specific instance family, size, and region (or a specific Availability Zone, if you want capacity reservation on top of the discount). It's the most rigid option and, in exchange, can offer the deepest discount for workloads that genuinely aren't going to change shape.
A Savings Plan is a commitment to a dollar amount of compute spend per hour, not to a specific instance type. A Compute Savings Plan applies across instance family, size, region, and even compute type (EC2, Fargate, Lambda). An EC2 Instance Savings Plan is narrower — locked to a family in a region — but still flexible on size and AZ, and usually prices a bit better than the fully flexible option in exchange for that narrower scope.
Illustrative, not to exact scale — the trade-off is the point: RIs commit to specifics for a deeper discount, Savings Plans trade some discount for flexibility.
Where accounts get this wrong
- Committing before right-sizing. A Reserved Instance or Savings Plan locks in against current usage. If that usage includes oversized instances that haven't been right-sized yet, the commitment locks in the waste right along with the workload.
- All RIs, no flexibility. Accounts whose instance mix changes — new services, migrations to newer instance generations, autoscaling that shifts family over time — end up with Reserved Instances that no longer match what's actually running, sitting unused while on-demand rates get paid on top.
- One giant commitment, no laddering. Committing 100% of baseline spend in a single one- or three-year term removes any room to adjust as the account's shape changes. Laddering shorter and longer commitments, or covering only the genuinely stable baseline and leaving the variable portion on-demand, keeps that flexibility.
A simpler way to decide
Right-size first. Committing to a discount on top of an oversized instance just makes the waste cheaper per hour, not gone. Once usage reflects what the workload actually needs:
- If the instance family and region are genuinely stable and unlikely to change for the term, a Reserved Instance (or EC2 Instance Savings Plan) usually prices better.
- If there's any real chance the mix shifts — different instance families, more Fargate or Lambda, multi-region growth — a Compute Savings Plan's flexibility is worth the smaller discount, because an unused RI earns nothing while an unused Savings Plan commitment still applies to whatever compute is actually running.
- Cover the baseline you're confident about; leave headroom for spiky or seasonal usage on-demand rather than committing against it.