Compute Savings Plans: a practical buying strategy
How much to commit, for how long, and how to avoid over-committing into a corner.
The finance team handed me a directive that sounded simple: "Buy Savings Plans, save 30%." What they didn't realize is that a Savings Plan is a one-to-three-year financial commitment, and over-committing is worse than not committing at all, you pay for compute you don't use. I've seen a team lock in a $40/hr commitment, then refactor onto Lambda a month later and eat the difference for two more years.
So I treat Savings Plans purchases the way I'd treat any leveraged bet: size the commitment to the floor I'm certain about, never the ceiling. Here's the practical strategy that's worked across a few hundred thousand dollars of annual compute.
Know which plan you're actually buying
There are three commitment products and they are not interchangeable:
| Type | Covers | Discount | Flexibility |
|---|---|---|---|
| Compute Savings Plan | EC2, Fargate, Lambda, any region, family, OS | Up to ~66% | Highest |
| EC2 Instance Savings Plan | One instance family in one region | Up to ~72% | Low |
| Reserved Instances | Specific instance type / scope | Up to ~72% | Lowest |
I almost always recommend the Compute Savings Plan despite the slightly lower ceiling. The extra ~6% you'd get from an EC2 Instance plan evaporates the moment you change instance families or move a workload to Fargate. Flexibility is worth more than the marginal discount for any team that's still evolving.
You're not buying a discount on instances. You're buying a discount on a dollar-per-hour of compute spend, applied automatically to whatever covers it best at that moment. Optimize for the commitment surviving your architecture changes.
Size to the floor, layer the rest
The core technique is laddering. Look at the last 90 days of compute spend, find the minimum hourly run rate, the baseline you never drop below, and commit to that. Everything above the floor stays on-demand or gets covered by a later, smaller plan once it proves durable.
Pull your historical hourly commitment usage from Cost Explorer to find that floor:
aws ce get-savings-plans-utilization \
--time-period Start=2026-03-01,End=2026-06-01 \
--granularity DAILY
# And to find the on-demand baseline you could cover:
aws ce get-cost-and-usage \
--time-period Start=2026-03-01,End=2026-06-01 \
--granularity HOURLY \
--metrics UnblendedCost \
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}'
If your minimum hourly compute spend over the window is $12/hr, that's your safe commitment. Buy a Compute Savings Plan at maybe $10-11/hr to leave margin, then revisit in a quarter and add another rung if the floor has risen.
The term and payment knobs
Two more decisions, each a real trade-off:
- 1-year vs 3-year: 3-year deepens the discount substantially but is a long bet on your architecture. I use 3-year only for rock-solid baselines (the database tier, core services) and 1-year for anything still in flux.
- Payment option: All Upfront > Partial Upfront > No Upfront in discount, but No Upfront preserves cash and still captures most of the savings. The delta between No Upfront and All Upfront is usually only a few percent, rarely worth tying up capital for.
The ladder in practice
Rather than one big purchase, I stagger commitments so they expire on a rolling schedule:
- Q1: commit to the proven baseline at ~85% of the floor.
- Q2: if utilization held above 95%, add a second rung for the next layer.
- Ongoing: as plans approach expiry, re-evaluate against current run rate before renewing.
This avoids the cliff where all your coverage expires at once and someone has to make a giant re-commitment decision under pressure. Staggered expirations keep every renewal small and low-risk.
Watch utilization, not just coverage
Two metrics, and people confuse them. Coverage is what fraction of eligible spend a plan is discounting, higher is more savings. Utilization is what fraction of your commitment you're actually using, and it must stay near 100%, because unused commitment is pure waste. I target ~80% coverage and demand >98% utilization. If utilization dips, you over-bought; if coverage is low, there's more safe savings to capture.
Takeaways
- Prefer Compute Savings Plans, the ~6% you give up versus EC2 Instance plans buys flexibility across families, regions, Fargate, and Lambda.
- Size to your 90-day minimum hourly spend (the floor), not your average or peak; over-commitment is unrecoverable waste.
- Ladder purchases with staggered expirations so no single renewal is high-stakes.
- Track utilization (keep it >98%) separately from coverage (target ~80%), they tell you over- vs under-commitment.