Reservations and savings plans still billing while the VM they were bought for is deallocated
What does ZopNight detect here?
An Azure reservation or savings plan keeps billing every hour of its term, even when the VM it was bought for is deallocated. ZopNight checks for deallocated VMs that sit under a commitment, but raises no finding, because no immediate action reduces the bill; the documented levers are exchange, a refund capped at USD 50,000 per 12 months, or non-renewal.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1380 |
| Category | discount |
| Severity | high |
| Metric | none — pure configuration read |
| Threshold | VM not running, covered by a reservation or savings plan |
| Source | ZopNight |
| Permissions used | Microsoft.Compute/virtualMachines/read · Microsoft.Capacity/reservationorders/read · Microsoft.Capacity/reservationorders/reservations/read |
Where it applies
Where the committed hours go when a VM is deallocated
Deallocating a VM stops its pay-as-you-go compute charge. It does not stop a commitment. Microsoft explains in how reservation discounts apply that when a resource shuts down, the discount moves to another matching resource in scope, and if none is found the reserved hours for that period are lost. They cannot be carried forward. Stopped (not deallocated) VMs are still billed and keep consuming the reservation.
So a deallocated VM under a reservation is only waste when nothing else in scope is soaking up the hours. A savings plan is a dollars-per-hour spend commitment rather than a size, but it is still a commitment you pay for whether or not this particular VM runs.
Checking whether the hours are being used
List deallocated VMs, then look at utilization of the reservation that was meant to cover them:
az vm list -d \ --query "[?powerState=='VM deallocated'].{name:name, rg:resourceGroup, size:hardwareProfile.vmSize, location:location}" \ -o table
az consumption reservation summary list --grain daily \ --reservation-order-id 00000000-0000-0000-0000-000000000000Utilization well below 100% on the days the VM was off is the real signal.
What ZopNight looks at
The check runs against VMs that are not running, that ZopNight’s billing data shows as covered by a reservation or savings plan, and that have a known, positive committed cost. Those are the same conditions you would use to shortlist the problem by hand.
Why no finding is ever raised
After those checks, ZopNight deliberately reports nothing. A commitment is already paid for, and turning the VM back on or off does not change what the reservation bills. The ways out are not a monthly saving ZopNight can price honestly: an exchange moves the commitment to other usage, a refund depends on your remaining cap, and non-renewal only helps at the end of the term. ZopNight also has no per-VM figure for wasted reservation hours to put a number on. Rather than show a made-up saving, it stays quiet, and this page exists so you know the pattern is worth checking.
No saving is claimed
There is no dollar figure. The cost is the unused commitment, visible as low utilization in the reservation summary.
Recovering unused commitment
- If the VM is still needed, start it; the reservation applies again automatically.
- If another workload of the same size group runs pay-as-you-go, widen the reservation’s scope to shared so it can pick up the hours.
- Otherwise, exchange or refund the reservation from Reservations in the portal. Refunds are limited to USD 50,000 of cancelled commitment in a rolling 12-month window, and the exchange policy makes reservations purchased after February 1, 2027 ineligible for exchange when savings plans cover the service.
- Savings plans cannot be cancelled or exchanged. Point new workloads at them instead.
- Turn off auto-renew on any reservation you do not intend to keep.