The most common Azure billing surprise fits in one sentence: you shut a VM down and the compute charges kept coming. Nothing is broken. Azure has two different "off" states, they look nearly identical in the portal's list view, and only one of them stops the meter. Then, once you fix that, a second surprise arrives on the next invoice: the disks.
Here are the states, the exact costs at each, the commands to find every wrongly-stopped VM in the subscription, and the disk math nobody mentions when they tell you to deallocate.
Two kinds of off
Stopped. You shut the machine down from inside the OS (or the guest shut itself down). Azure sees a powered-off guest, but the VM still occupies its slot on the host: the CPU and memory are still reserved for you. You are billed for compute in full. Status shows "Stopped".
Stopped (deallocated). You stopped the VM through Azure (portal Stop button, az vm deallocate, an automation runbook). The hardware reservation is released. Compute billing stops. Status shows "Stopped (deallocated)".
The single most expensive word in that description is inside. Every team that runs "shutdown at 6pm" scripts inside the guest OS, the way on-prem habit suggests, produces a fleet of Stopped-but-fully-billing VMs. The dynamic IP may change on deallocation and the ephemeral disk is wiped, which is why Azure doesn't just deallocate on guest shutdown by default; the price of that safety is this trap.
Worked numbers: a D4s_v5 runs roughly $140 a month at list price. Stopped (not deallocated): still roughly $140. Deallocated: $0 compute. Same power button, $140 a month difference.
Finding the wrongly-stopped VMs
One command lists every VM's true power state:
az vm list -d --query "[?powerState=='VM stopped'].{name:name, rg:resourceGroup}" -o table
VM stopped is the bad state (billing); VM deallocated is the good one. Anything in the first list is paying full compute for nothing, and the fix is immediate:
az vm deallocate -g <resource-group> -n <vm-name>
For scheduled off-hours, use deallocation-aware machinery (automation runbooks, DevTest Labs schedules, or any scheduler that calls the Azure API) rather than OS-level shutdown, precisely because only API-level stops deallocate.
The disks nobody mentions
Deallocation stops compute billing. It does not touch storage, and managed disks bill at full price whether their VM runs, sleeps, or was deleted last spring:
- A P30 premium SSD (1 TB) is about $135 a month, running VM or not.
- A P10 (128 GB) is about $20 a month.
- Standard public IPs attached to the VM keep billing (about $3.65 a month), and so do orphaned IPs left behind after deletions.
So the deallocated D4s_v5 above didn't go to zero; it went from $278 a month (compute + P30 + IP) to about $139 (P30 + IP). That's the invoice line that makes people say "but it's off". For long-parked VMs the disk options, in increasing severity: downgrade premium disks to Standard SSD/HDD while parked (disk performance tiers are changeable), snapshot the disk and delete the original (snapshots bill on used-not-provisioned space at lower rates, and the VM can be recreated from the snapshot), or delete disks whose VM is never coming back, after checking the disk's diskState for Unattached and taking a final snapshot. And audit orphaned disks generally: deleting a VM in the portal historically kept its disks unless told otherwise, so most subscriptions carry a graveyard of Unattached managed disks billing full rate.
Detection for both patterns is one recommendation class in cost tooling now; ZopNight, for instance, flags Azure VMs that are switched off but still billing for their attached disks and public IP, itemized per meter with a cleanup savings estimate, precisely because "deallocated but still paying $139" is invisible on the compute bill people actually look at.
FAQ
Does Azure charge for a stopped VM?
If it's merely Stopped (shut down from inside the OS), yes, full compute price: the hardware stays reserved. Only Stopped (deallocated), triggered via the portal, CLI, or automation, releases the hardware and stops compute billing. Disks and Standard public IPs bill in both states.
What's the difference between stop and deallocate in Azure?
Stop powers off the guest but keeps the host reservation (and the billing). Deallocate releases the reservation: compute billing ends, the dynamic IP may change, and the ephemeral disk is wiped. The portal's Stop button deallocates; an OS-level shutdown does not, which is the root of most "why am I still charged" tickets.
How much do managed disks cost while a VM is deallocated?
Full price, always: roughly $135 a month for a P30 (1 TB premium), $20 for a P10 (128 GB), regardless of VM state. For long-parked VMs, downgrade the disk tier, or snapshot and delete the disk (snapshots bill on used space at lower rates) and recreate later.
How do I find all deallocated or stopped VMs in a subscription?
az vm list -d with a powerState filter: 'VM stopped' means billing-while-off (fix immediately with az vm deallocate), 'VM deallocated' means compute is free but disks and IPs still bill. Pair it with a managed-disk audit for diskState == 'Unattached' to catch the orphaned-disk graveyard.
Can I automatically deallocate VMs on a schedule?
Yes, as long as the scheduler calls the Azure API rather than shutting down the guest OS: auto-shutdown on the VM blade (dev/test), Azure Automation runbooks, DevTest Labs schedules, or third-party schedulers. OS-level cron shutdowns leave VMs in the Stopped-and-billing state, which defeats the purpose.
Top comments (0)