Choosing a Purchasing Commitment: Savings Plans vs. Reserved Instances

The two commitment options for EC2 are Reserved Instances and Savings Plans, and they commit to different things.

A Reserved Instance commits to a specific configuration: instance family, size, region, OS, and tenancy. In exchange you get up to ~72% off On-Demand for that exact shape.

A Savings Plan commits to a dollar-per-hour spend instead. Any eligible usage counts toward the commitment, whatever shape it runs in, so the coverage follows your usage and nothing in the commitment is tied to a resource shape. The discount is a bit shallower: Compute Savings Plans top out lower, though EC2 Instance Savings Plans match RI's ~72% within one family/region.

The commitment binds whether or not you use it. Say your hourly Savings Plan commitment sits above your actual eligible usage in a given hour. You are still charged the committed amount for that hour, and the difference buys nothing.

Unused Reserved Instance capacity is dead spend too, with one exit: a Standard RI can be resold on the Reserved Instance Marketplace. Convertible RIs can't be resold, but they can be exchanged internally. Savings Plans have no exit at all once purchased — no exchange, no resale.

Then there's the order in which discounts apply, which catches teams holding several commitments at once. RIs apply first, then EC2 Instance Savings Plans, then Compute Savings Plans. Whatever usage is still uncovered after all three is billed at On-Demand.

The trap is buying overlapping commitments in the belief that they stack. A higher-priority commitment absorbs the usage first, so the overlap never discounts anything. Teams that don't understand the application order are the ones who end up here.