How commitments work
The principle is simple: you commit to a level of consumption for 1 or 3 years, and the cloud provider gives you a large discount. There are two main families:
- Reserved Instance: a commitment on a specific resource (SKU, region). The biggest discount, the least flexibility.
- Savings plan: a commitment on an hourly spend, flexible across SKUs, regions and sometimes services. A bit less discount, much more flexibility.
| Reserved Instance | Savings plan | |
|---|---|---|
| Discount | The biggest | Slightly lower |
| Flexibility | Low (SKU, region) | High (families, regions) |
| Services covered | VMs, databases, storage, data capacities depending on the provider | Mainly compute |
| Best for | Stable, known workloads | Changing estates, ongoing migrations |
Our 4-step method
- Clean up before you commit. Rightsizing, cleaning and Stop/Start first. Reserving an oversized VM means paying three years for waste.
- Measure the baseline. Usage history by VM family (SKU), region and service, to reserve only what runs all the time.
- Choose the right commitment. Reserved Instance or savings plan, 1 or 3 years, shared or single scope. Beyond VMs: storage, databases, Synapse, Fabric, and an overall commitment with the cloud provider (MACC on Azure, a discount agreement on AWS).
- Manage it over time. Coverage and utilization tracked daily, exchanges and refunds when the architecture changes, renewals prepared ahead of time.
Coverage and utilization: the two KPIs to watch
- Coverage: the share of eligible consumption covered by a commitment. 80% or more of the baseline is a good target.
- Utilization: the share of the commitment actually used. A reservation used at 60% loses part of its discount.
Both KPIs are tracked in our dashboard, with alerts when utilization drops or an expiry date approaches.
The most common mistakes
- Reserving before rightsizing the estate.
- Reserving non-prod that should rather be shut down at night: a reserved VM that is stopped keeps paying for its reservation.
- Over-reserving right before a migration or a decommissioning.
- Letting reservations expire without renewal, and going back to pay-as-you-go without noticing.
- Forgetting commitments beyond VMs: storage, databases, data capacities.
Reservations and Stop/Start don't stack
On a non-prod VM, a fixed-schedule Stop/Start saves 50 to 60%, almost as much as a reservation. But the two don't stack. In prod, the VM runs continuously: reservations apply. In non-prod, the best lever is an automatic Stop every evening with Start on demand, at about 90% savings.
What a reservation doesn't do
A reservation lowers the bill, but changes nothing in physical consumption, so nothing in the real carbon footprint. We always separate financial savings from footprint reductions. See our GreenOps page.