You shut the VM down to save money, and next month it is still on the bill. This is one of the most common Azure billing surprises, and it comes down to a distinction Azure does not make obvious: there is a difference between a VM that is Stopped and one that is Stopped (deallocated), and only one of them stops the compute charges.
Here is exactly what is happening, and the cost that survives even when you do it right.
Stopped vs Stopped (deallocated)
Azure has two "off" states, and they bill completely differently.
-
Stopped (from inside the OS). If you run
shutdowninside the guest OS, the VM powers off but Azure keeps the compute resources allocated to it. The status shows Stopped. You are still paying full compute price for a VM doing nothing. This is the trap. - Stopped (deallocated). If you stop the VM from the Azure Portal, CLI, or PowerShell, Azure deallocates it, releasing the underlying compute. The status shows Stopped (deallocated), and compute billing stops.
So the rule: shutting down from inside the guest does not save you money. You must deallocate, and deallocation only happens when you stop it through Azure, not through the OS.
# This deallocates and stops compute billing:
az vm deallocate --resource-group my-rg --name my-vm
# Inside-the-OS "shutdown" does NOT deallocate. Status stays "Stopped", billing continues.
Check which state you are actually in:
az vm get-instance-view --resource-group my-rg --name my-vm \
--query "instanceView.statuses[?starts_with(code, 'PowerState')].displayStatus" -o tsv
If that returns VM stopped you are still paying. If it returns VM deallocated you are not paying for compute.
The disks nobody mentions
Here is the part that catches people even after they deallocate correctly: deallocation stops compute billing, not storage billing. The managed disks attached to the VM (the OS disk and any data disks) keep costing money whether the VM is running, stopped, or deallocated. A deallocated VM with a 512 GB Premium SSD is still billing you for that 512 GB every hour.
Other charges that also survive deallocation:
- Static public IP addresses. A reserved (static) public IP keeps billing when the VM is off. Dynamic IPs are released on deallocation.
- Reserved capacity or licenses tied to the VM, depending on how they were purchased.
So "I turned it off and I am still charged" almost always means one of two things: you stopped from inside the OS (compute still billing), or you deallocated correctly but are seeing the disk and IP charges that never stop.
What to actually do
- To pause a VM you will use again soon: deallocate it (through Azure, not the OS). You stop compute, keep the disks, and it starts back up with its data intact. This is the right move for dev and test boxes overnight.
- To stop paying entirely for something you are done with: deallocating is not enough. You must delete the VM and its disks (and release the static IP). A deleted VM whose disks you forgot to remove is a classic zombie cost.
- For non-production VMs you deallocate nightly: automate it on a schedule rather than trusting people to remember. A start/stop schedule on dev and test VMs is one of the highest-return Azure cost moves there is, and it only works if it is automatic. (We schedule non-prod VMs the same way across clouds, that scheduling is part of what ZopNight does, but an Automation runbook or a Logic App on a timer does the crude version.)
The one-line summary
Stopping a VM from inside Windows or Linux saves you nothing. Deallocating it through Azure stops the compute charge but keeps billing you for the disks and any static IP. To fully stop paying, delete the VM and its disks. Most "why am I still being charged" cases are one of those three facts.
Have you been bitten by the inside-the-OS shutdown, or by the disks that keep billing after deallocation? For me it was the disks, I deallocated a fleet of test VMs, felt clever, and still saw a chunk of the bill I could not explain until I looked at the storage line.
