Understanding Azure VM States: Stopped (Deallocated) vs. Stopped (Incurring Charges)

Rajesh Kumar Yadav - Sep 12 - - Dev Community

Managing Azure Virtual Machines (VMs) effectively can be crucial for optimizing costs. One common area of confusion is the difference between a VM in the "Stopped (Deallocated)" state and one that is simply "Stopped (Incurring Charges)". In this post, I'll break down the distinction between these two states and help you make sure you're only paying for what you need.

What Happens When You Stop an Azure VM?

When you stop an Azure VM, it can end up in one of two different states:
Stopped (Deallocated)
Stopped (Incurring Charges)

While both states indicate that the VM isn't running, the underlying Azure resource management and billing implications are different. Let’s dive into the details.

1. Stopped (Deallocated)

What It Means:
When a VM is in the "Stopped (Deallocated)" state, Azure has released the physical resources (CPU, RAM, and network resources) that were being used to run the machine. Essentially, Azure has unhooked the machine from its physical infrastructure.

Billing Impact:
In this state, you are no longer being charged for the VM's compute resources (i.e., the CPU and memory). The only cost you incur is for the storage of the VM's disks (both the OS disk and any additional data disks).

How to Trigger This State:
To ensure that your VM reaches this state, you need to stop it from the Azure Portal, Azure CLI, or PowerShell. By stopping the VM through these Azure management tools, the system knows to release the underlying hardware.

Resource Allocation:
Once the VM is deallocated, Azure will assign new physical resources the next time you start the VM. This means you may not be using the same hardware you were before the stop.

2. Stopped (Incurring Charges)

What It Means:
When a VM is in the "Stopped (Incurring Charges)" state, it has been powered off, but Azure has not released the physical compute resources. This means Azure is still reserving the CPU, RAM, and any associated network resources for the VM, so it's ready to start again immediately on the same hardware.

Billing Impact:
Because the compute resources are still allocated to your VM, you will continue to incur charges for those resources, even though the VM is not actively running.

How to Trigger This State:
This state typically happens if you stop or shut down the VM from within the operating system. For example, using a shutdown command from the VM's OS (like shutdown on a Linux server or shutdown /s on Windows) won’t deallocate the VM in Azure. Instead, it simply powers off the VM while keeping the allocated resources.

Image description

How to Stop a VM Without Incurring Compute Costs
To avoid unnecessary charges, always stop your VM through the Azure Portal or other Azure management tools like the Azure CLI. This ensures the VM enters the Stopped (Deallocated) state, where compute resources are released and billing for those resources stops.

Here’s an example using Azure CLI to stop a VM and deallocate resources:

az vm deallocate --resource-group <ResourceGroupName> --name <VMName>
Enter fullscreen mode Exit fullscreen mode

This command ensures that your VM is stopped and deallocated, saving you money on compute resources.

Conclusion
Understanding the difference between Stopped (Deallocated) and Stopped (Incurring Charges) is essential to managing your Azure costs effectively. If you're not actively using a VM and want to save money, always make sure it’s in the Stopped (Deallocated) state to avoid paying for idle compute resources.

Got any other Azure tips for cost management? Drop them in the comments!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .