Savings Plans vs Reserved Instances: which to buy

Every year someone on the team asks me to "just buy reserved instances and save 40%," and every year I have to walk through why that's the wrong default in 2026. Savings Plans and Reserved Instances both trade a one- or three-year commitment for a discount, but they flex very differently, and buying the wrong one locks you into instances you'll regret in six months.

Here's the framework I use to decide, with the numbers that drive it.

What each commitment actually locks you into

• Compute Savings Plans, commit to a dollars-per-hour spend. Applies automatically across EC2, Fargate, and Lambda, any region, any instance family, any OS. Maximum flexibility, slightly lower discount.
• EC2 Instance Savings Plans, commit to spend within a specific instance family in a region (e.g. m5 in us-east-1). You can change size, OS, and tenancy within that family. Higher discount, less flexible.
• Standard RIs, commit to a specific instance type/region. Best discount, but you're pinned. Can be sold on the Marketplace (only the Standard kind).
• Convertible RIs, exchangeable for other types, lower discount than Standard.

The discount-vs-flexibility trade

The discount delta between a Compute Savings Plan and a Standard RI is only a few percentage points. The flexibility delta is enormous. For most teams, paying a small premium to never be stuck with the wrong instance is the better trade.

My default recommendation

For nearly everyone running modern compute, I recommend Compute Savings Plans as the baseline. They cover Fargate and Lambda, survive a migration to a newer instance generation, and apply automatically without you managing a portfolio of reservations. RIs still make sense in two cases: you need the absolute lowest rate on a stable, long-lived fleet, or you need a capacity reservation (only RIs and On-Demand Capacity Reservations guarantee capacity, Savings Plans do not).

Don't commit to 100%, buy to your floor

The classic mistake is committing to your average spend. You should commit to your baseline, the floor of usage that's on 24/7, and leave the variable top to On-Demand or spot. I pull the data from Cost Explorer's coverage and utilization reports before buying anything.

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS

The recommendation API returns an hourly commitment, estimated savings, and, crucially, the estimated utilization at that commitment. I aim for 95%+ utilization. If the recommended commitment would push utilization below that, I buy less. Unused Savings Plan commitment is money set on fire; you pay the committed rate whether or not you use it.

Term and payment choices

Three-year terms deepen the discount meaningfully but bet on three years of stable usage, aggressive for a fast-moving startup, fine for a steady enterprise baseline. On payment, the difference between No Upfront and All Upfront is usually only a couple of points; I take No Upfront and keep the cash unless that small delta matters more than liquidity.

A laddering strategy beats one big purchase: buy in tranches over time so commitments expire on a rolling basis and you re-baseline against current usage rather than year-old numbers.

Takeaways

• Default to Compute Savings Plans, the small discount give-up buys huge flexibility across EC2, Fargate, and Lambda.
• Use RIs only for the lowest rate on a stable fleet, or when you need a guaranteed capacity reservation.
• Commit to your usage floor, not your average; target 95%+ utilization or unused commitment becomes waste.
• Prefer 1-year No Upfront and ladder purchases over time unless your baseline is rock-steady for three years.