By Cloudledger · Updated
Expiry is a scheduled cost change
When a reservation ends, the covered usage returns to normal pay-as-you-go rates unless it is renewed or replaced. If nobody is tracking end dates, that appears later as an unexplained cost increase. Treat expiry as a planned event with an owner and a decision date.
Build the expiry calendar
List every reservation and savings plan with its scope, term, end date and current utilization. Add the workloads each one covers and the team responsible. Review the list monthly so decisions are made before the last week of a term.
- Export or record all commitments with end dates and scopes.
- Note utilization and coverage for the recent period.
- Map each commitment to the workloads it covers.
- Set a decision date at least a month before expiry.
- Record the decision and who approved it.
Decide from the workload, not the habit
Renewal makes sense when the workload will persist and utilization has been high. It makes less sense when the workload is being migrated, rearchitected or rightsized. Where the shape has changed, a different size, scope or commitment type may fit better than repeating the previous purchase.
Check auto-renewal settings deliberately
Automatic renewal avoids an accidental lapse but can also renew a commitment you intended to end, at whatever the terms are on the renewal date. Confirm the setting for each commitment and make sure the outcome matches the decision recorded by the owner. Where a workload is being migrated or retired during the term, put the renewal decision date in the same calendar as the migration plan so the two are not decided by different people in different weeks.
Verify the following period
After a renewal or lapse, compare the next complete billing period against the previous one and confirm the change is what you expected. Use the amortized view for like-for-like comparison, and record the explanation for the next cost review.