Reservation and savings plan optimization is the discipline of placing the right commitment instruments under your broader deal so they capture discount without creating overlap. Reservations and savings plans stack underneath an AWS EDP, and they complement an Azure MACC, but layered carelessly they can leave you paying twice for the same coverage. Getting the mix right is part of our FinOps optimization for cloud commitments practice and feeds commitment structuring and sizing advisory.
How reservation and savings plan optimization fits the bigger commitment
It helps to see the discounts as layers. At the top is the enterprise commitment, an AWS EDP spend floor or an Azure MACC consumption commitment. Underneath sit the resource level instruments, reserved instances and savings plans, that discount specific compute usage.
As of June 2026, AWS reserved instances and savings plans stack on top of an EDP, meaning the spend they generate counts toward the EDP commitment while also earning their own discount. Azure reservations and savings plans are complementary to a MACC. The optimization question is how much resource level coverage to buy, of which type, without overcommitting the layer beneath the layer.
Match the instrument to the stability of the workload
Reservations and savings plans trade flexibility for discount. The more you lock in, the deeper the discount, but the less room you have to change. So match the instrument to the workload. Steady, predictable compute that will run for the full term is a candidate for deeper, less flexible coverage. Variable workloads call for more flexible instruments or no resource level commitment at all.
The same downside logic that governs the enterprise commitment applies here. Buy resource level coverage for demand you are confident in, and leave volatile demand uncovered so you are not stranded with reservations you cannot use.
Avoid stacking discounts you cannot use
The trap in reservation and savings plan optimization is overcoverage. Buy too many reservations and savings plans and you can cover the same baseline twice, paying for committed capacity that your on demand usage was never going to reach. The discount looks good on paper and wastes money in practice.
Model the resource level coverage against the same utilisation targets you set for the enterprise commitment. The combined coverage, enterprise floor plus reservations plus savings plans, should track your confident demand, not exceed it. This is closely tied to avoiding double spend across commitments.
Keep the portfolio tuned through the term
Reservation and savings plan portfolios are not static. Expirations, new instance families, changing workloads, and pricing updates all shift the optimal mix. Review the portfolio on a regular cadence so expiring coverage is renewed only where demand still justifies it, and new coverage is added only for demand that has proven stable.
This continuous tuning is part of post signature optimization. A portfolio set once and forgotten drifts out of alignment with demand, leaving both stranded coverage and uncovered usage at full price.
Flexibility versus discount, quantified
Every reservation and savings plan choice is a trade between flexibility and discount. Longer terms and full upfront payment buy deeper discounts but lock you in harder. Shorter terms and no upfront keep flexibility but discount less. Put numbers on the trade rather than defaulting to the deepest discount.
The right point on the curve depends on workload stability. For a workload certain to run three years, the deep discount is worth the lock in. For a workload that might change in a year, the flexibility is worth more than the extra discount points.
Set coverage targets for the resource layer
The resource layer needs its own coverage target, distinct from the enterprise commitment. Cover the steady baseline of compute that runs continuously, and leave the variable top on demand. A common buyer side posture is to cover the predictable trough and let usage above it run flexibly.
Model that target against real utilisation. Overbuying reservations to chase a coverage percentage is how the resource layer becomes its own source of waste, paying for committed capacity that usage never reaches.
Provider differences in the instruments
The instruments are not identical across clouds. As of June 2026, AWS offers reserved instances and several savings plan types with differing flexibility, and their spend counts toward an EDP floor. Azure offers reservations and savings plans that complement a MACC. GCP offers resource based and spend based committed use discounts, plus automatic sustained use discounts that need no commitment.
Because the rules differ, the optimal mix differs. Map your instruments to each provider's specific stacking and flexibility rules rather than assuming one playbook fits all three.
Manage expirations and renewals deliberately
Reservations and savings plans expire, and an expiration is a decision point, not an automatic renewal. Before a tranche lapses, recheck whether the demand it covered still exists and at what level. Renew only what demand still justifies, and resize the rest.
Letting coverage auto renew without review is how portfolios drift out of alignment with demand, stranding coverage on workloads that have shrunk while newer workloads run at full price.