An Azure VM has two off states that cost very different amounts. Stopped (allocated) means the guest is shut down but the machine still holds its place on a physical host, so you keep paying the full compute rate. Stopped (deallocated) means Azure has released the host, and the compute meter stops; you pay only for the resources that survive a deallocation. Shutting down from inside the operating system usually leaves the VM allocated and billing. Deallocating from the Azure portal, CLI, or an automation schedule is what actually stops compute charges. The practical win is scheduling non production VMs to deallocate outside working hours.
This single distinction is one of the most common quiet leaks on an Azure bill. Here is exactly what each state costs and how to capture the saving safely.
What is the difference between stopped and deallocated?
When you shut a VM down from within the guest, for example a Linux shutdown or a Windows power off, the VM enters the stopped state but remains allocated. Its CPU and memory reservation on the host is still held for you, and Azure still charges the compute rate as if it were running. The machine is idle, but the meter is not.
When you stop a VM through the Azure portal, the CLI, PowerShell, or an automation runbook, Azure moves it to stopped (deallocated). The host resources are returned to the pool, and the compute charge stops. The trade is that the machine no longer holds a guaranteed slot, so a later start places it on whatever host has capacity.
The headline for any cost owner: the word stopped is ambiguous, and the ambiguity is expensive. Always confirm the power state reads deallocated, not just stopped, before you assume a machine has stopped billing.
What still costs money after you deallocate?
Deallocation stops the compute meter, but several attached resources keep billing because they persist independently of the host.
Managed disks keep billing. Your operating system disk and any data disks are storage, not compute, so they are charged whether the VM is running, stopped, or deallocated. A large deallocated fleet can still carry a meaningful disk bill.
Static public IP addresses and reserved addresses keep billing. A standard static IP is charged regardless of VM state. Dynamic IPs are released on deallocation, which is also why a deallocated VM often comes back on a different address unless you reserved it.
Reservations and Savings Plans bill regardless. If the VM sits under a commitment, that commitment bills on its schedule whether the machine runs or not. Deallocating a reserved VM saves nothing on the commitment itself, which is why the risk adjusted approach to Azure commitments keeps non production off commitments.
The temporary disk is wiped. The local temp disk does not survive deallocation, so anything written there is lost. Never store state you need on the temp disk for a machine you intend to deallocate.
How much can scheduled deallocation save?
The arithmetic is straightforward. A week has 168 hours. A development or test machine that only needs to be available during business hours, say 10 hours a day across 5 days, needs about 50 hours a week. Deallocating the other 118 hours removes roughly 70 percent of the compute charge for that machine, while disks and reserved IPs continue at their small fixed rate.
| Schedule | Billed compute hours per week | Compute time removed |
|---|---|---|
| Always on (no schedule) | 168 | 0 percent |
| On 12 hours, 7 days | 84 | 50 percent |
| Business hours, 10 by 5 | 50 | about 70 percent |
| On demand, started only when needed | 20 to 30 | about 85 percent |
Across a fleet of dozens of dev and test machines, that 70 percent compounds into one of the easiest wins on the bill, with no production risk because the machines are not serving customers.
A worked example: a development fleet on a schedule
A Fortune 500 retailer ran about 40 development and test VMs that engineers shut down by hand at the end of the day, believing this stopped the charges. A power state audit showed most were stopped but still allocated, billing full compute around the clock. We moved them to an automation schedule that deallocated every machine at 8pm and on weekends, with a self service start button for anyone working late. Compute time on the fleet fell by roughly two thirds, disks and reserved addresses continued at their small fixed cost, and no engineer lost working capability. Figures are verified against billing data and anonymised.
How should you schedule deallocation safely?
Automate it rather than relying on people. Azure offers built in auto shutdown on individual VMs, the Start and Stop VMs automation solution for fleets, and resource policies you can drive from a runbook or Logic App. Tag machines that are safe to deallocate, give engineers a self service way to start a machine outside the schedule, and exclude anything stateful that cannot tolerate a host change. Pair this with rightsizing and commitment discipline from the Azure cost optimization guide so you are not just turning off oversized machines but running the right ones.
Frequently asked questions
Get the buyer side Azure waste playbook
We audit power states across your Azure estate, find the machines billing for nothing, and put non production on a schedule your engineers will accept, with zero provider commissions. It is the same discipline behind the 31 percent median reduction we see in the first 90 days. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.