Savings plan renewal during a container migration
A container platform's annual cloud bill is $5.4M. Of that, $3.1M is EC2 compute covered by a compute savings plan purchased three years ago at a $1.6M/year commitment; the plan expires in 60 days and currently covers 78% of eligible compute with 99.2% utilization. The platform is migrating 25% of its EC2 node hours to a managed container service that the savings plan does not cover and expects 15% growth in container workloads next year. The remaining EC2 baseline is stable. Finance wants to renew at the same dollar level to avoid losing the discount; engineering wants to buy nothing until the migration completes. The CFO wants a recommendation with a downside case and a 12-month coverage forecast.
1. Calculate a defensible renewal level. What discount is implied, and why is renewing at $1.6M risky?
Read the worked answer
The current plan covers 78% of $3.1M, or $2.418M of on-demand-equivalent compute, for a $1.6M commitment. Implied discount = 1 − (1.6 / 2.418) = 33.8%, so use about 34%.
After 25% of EC2 node hours migrate, eligible EC2 is $3.1M × 0.75 = $2.325M on-demand-equivalent. To cover 75% of that at a 34% discount, the commitment should be 0.75 × $2.325M × 0.66 = $1.151M. Renewing at $1.6M would commit about 104% of the discounted eligible spend, leaving little room for further migration and risking unused commitment.
Recommend a commitment of roughly $1.1–1.2M, not $1.6M. This preserves most of the discount while matching the smaller EC2 footprint. Engineering's proposal to buy nothing is also wrong: the stable EC2 baseline still justifies coverage. The managed container service may have its own discount instruments, but do not assume the EC2 savings plan applies to it; verify before including it in coverage.
2. Build a 12-month coverage forecast for base, downside, and upside migration cases. Which metric do you manage to?
Read the worked answer
Assume a $1.15M commitment, 34% discount, stable remaining EC2, and no growth in EC2 itself.
| Case | EC2 eligible | Discounted eligible | Coverage | Utilization |
|---|---|---|---|---|
| Base, 25% migrated | $2.325M | $1.535M | 75% | 100% |
| Downside, 40% migrated | $1.860M | $1.228M | 94% | 100% |
| Upside, 15% migrated | $2.635M | $1.739M | 66% | 100% |
Coverage = commitment ÷ (eligible on-demand × (1 − discount)). Utilization = commitment consumed ÷ commitment; it stays at 100% until discounted eligible spend falls below the commitment, which happens at roughly 50% migration. At that point, unused commitment becomes pure loss.
Manage to both. Coverage below about 70% means you are leaving discount on the table; coverage above about 90% means the commitment is fragile if migration accelerates. Utilization below 98% is a hard alert. Do not chase 100% coverage in a changing architecture.
3. How should the purchase be structured and monitored over the next year?
Read the worked answer
Split the purchase. Put about 60% of the target ($0.7M) into a three-year tranche for the stable EC2 floor that will not migrate, and about 40% ($0.45M) into a one-year tranche for the uncertain portion. Choose the upfront payment level based on cash constraints, not on the largest possible discount. Leave the managed container service out until its own commitment options and usage baseline are measured for at least two months.
Monitor monthly: eligible spend, coverage, utilization, expiration calendar, and migration percentage. Set alerts at coverage below 65% or above 90%, and utilization below 97%. Assign a named owner for the commitment portfolio and review it quarterly with finance and engineering.
A commitment is not a substitute for rightsizing or spot. If the migration accelerates, do not offset stranded commitment by keeping idle EC2 running; absorb the small loss and resize the next tranche. The downside case should show the maximum unused commitment in dollars so the CFO can approve the risk explicitly.