Azure VM basics: stop vs deallocate, start, restart and resize without surprises

New Azure users often shut a VM down from inside Windows or Linux and assume it stops costing money. It does not. This post explains the power states and the safe way to stop, start and resize.

#The power states that matter

Disks, public IP addresses and other attached resources keep billing in every state. Deallocation only stops the compute charge.

#Check the state

az vm get-instance-view -g rg-app -n vm01 \
  --query "instanceView.statuses[?starts_with(code,'PowerState')].displayStatus" -o tsv

az vm list -d -g rg-app --query "[].{Name:name, State:powerState}" -o table

Get-AzVM -ResourceGroupName rg-app -Status | Select-Object Name, PowerState

#Stop, deallocate, start, restart

az vm deallocate -g rg-app -n vm01      # stops compute billing
az vm start      -g rg-app -n vm01
az vm restart    -g rg-app -n vm01      # reboot
az vm stop       -g rg-app -n vm01      # powers off but KEEPS the allocation (still billed)

Stop-AzVM  -ResourceGroupName rg-app -Name vm01 -Force                  # deallocates
Stop-AzVM  -ResourceGroupName rg-app -Name vm01 -StayProvisioned -Force # stop, keep allocation
Start-AzVM -ResourceGroupName rg-app -Name vm01

Tip

Keep the allocation (az vm stop) only when you must restart quickly on the same hardware, for example during a short maintenance window on a size that is hard to get. Otherwise deallocate.

#What changes after deallocate and start

• Dynamic public IP: released and likely different on start. Use a static public IP (Standard SKU public IPs are static) if anything depends on it.
• Private IP: dynamic private IPs are usually kept but are not guaranteed. Set it to static on the NIC for servers others connect to.
• Temporary disk (D: on Windows, often /mnt on Linux): wiped. Never keep data there.
• Host: the VM may land on different hardware, which can also clear some host-level issues.

az network nic ip-config update -g rg-app --nic-name vm01-nic -n ipconfig1 \
  --private-ip-address 10.10.1.20

#Resize a VM

First see which sizes the current hardware cluster can offer:

az vm list-vm-resize-options -g rg-app -n vm01 -o table
az vm resize -g rg-app -n vm01 --size Standard_D4s_v5

If the size you want is not in the list, deallocate first. A deallocated VM can move to any size available in its region and zone:

az vm deallocate -g rg-app -n vm01
az vm resize     -g rg-app -n vm01 --size Standard_E8s_v5
az vm start      -g rg-app -n vm01

Warning

Resizing reboots the VM. Some moves are not allowed directly, for example between sizes with and without a local temp disk, or between VM generations. The error message names the blocker; read the size documentation before planning the change.

Also confirm you have quota for the new size family:

az vm list-usage -l westeurope -o table

#Schedule it

For dev and test, let Azure deallocate VMs for you each evening:

az vm auto-shutdown -g rg-app -n vm01 --time 1900 --email "me@example.com"

Auto-shutdown deallocates the VM. Starting it again is manual or done by an automation runbook.

#Quick reference

#Prevent it next time

• Teach the team that shutting down inside the OS is not the same as Stop in the portal.
• Find VMs that are stopped but still allocated with Resource Graph:

az graph query -q "Resources | where type =~ 'microsoft.compute/virtualmachines' | extend s=tostring(properties.extended.instanceView.powerState.code) | where s =~ 'PowerState/stopped' | project name, resourceGroup, s"

• Use static IPs for anything referenced by firewall rules or DNS.
• Keep application data on data disks, never on the temporary disk.