Savings Plans are bonds, not coupons
Engineers tend to think of Savings Plans as a coupon: commit, get a discount, done. The discount is real, up to 66% for Compute Savings Plans and 72% for EC2 Instance Savings Plans compared with On-Demand. But a Savings Plan is better understood as a bond: you promise to pay a fixed amount per hour for one or three years, whatever happens to your usage.
The question isn’t “how much can we save?” It’s “how much future spend are we confident enough to lock in?”
The two numbers
Cost Explorer reports two, and they pull in opposite directions:
- Coverage: how much of your eligible spend is covered by commitments. Low coverage means you’re paying On-Demand rates for steady usage.
- Utilization: how much of what you committed to is actually used. Below 100% means you’re paying for capacity you don’t use.
Push coverage to 100% and any drop in usage, like a migration, a rightsizing project or a lost customer, shows up as unused commitment. Keep coverage low and you overpay every hour. The goal is high utilization at a coverage level you can defend.
Why 2026 makes this harder
Usage has become harder to predict. GPU and AI workloads arrive in large, uneven chunks. Graviton migrations and rightsizing reduce the baseline. Containers move between instance families. A single large purchase made from last quarter’s average is a bet that none of this changes for three years.
Ladder your commitments
Bond investors don’t buy one bond with all their money. They ladder: buy smaller bonds at regular intervals, so a slice matures every period. Each maturity is a chance to reinvest at current conditions.
Do the same with commitments:
- Measure the floor: the lowest hourly eligible spend over the last 30 to 60 days, not the average.
- Commit only to a share of that floor, for example 70 to 80%.
- Make that commitment in several smaller purchases spread over months, rather than all at once.
- Each month or quarter, look at the new floor and buy a small additional slice if it has grown.
Because purchases are spread out, so are expirations. No single month has a cliff where half your coverage disappears and the bill jumps. And a drop in usage only affects the newest, smallest slice of your decision.
Choose the instrument per workload
| Workload | Instrument |
|---|---|
| Steady, but moving between families/regions/Fargate/Lambda | Compute Savings Plan |
| Steady, pinned to one instance family in one region | EC2 Instance Savings Plan |
| Spiky, interruptible, batch | Spot, no commitment |
| Planned GPU burst | Capacity reservation for that window |
| New or unproven | On-Demand until it has a floor |
Report it like finance would
Put three lines in the monthly report: utilization (target close to 100%), coverage (target set on purpose), and the expiry schedule for the next 12 months. The last one is the line most teams don’t have, and it’s the one that prevents the surprise.