There are 2 options to “shutdown” a Virtual Machine (VM) running in Microsoft Azure. Each of the two methods have different affects on the cost of your Azure subscription. One way you will still get charged for the compute resources, and the other will free you from paying for the compute resources and help you reduce your overall cost. This article takes a look at these, and explains the difference between them.





Stopped vs Stopped (Deallocated)

The first method to shutdown an Azure VM, that sounds logical in the context of connecting with Remote Desktop, is to Shutdown the Operating System. In this scenario you would be connected with Remote Desktop, and when done with your work you go to the Power options within the Windows operating system and then select the Shutdown option. This will essentially “turn off” or power down the Virtual Machine (VM), and stop it from running. However, with this method, even though the VM is not running you will still be paying for the Azure VM compute resources (aka hardware allocation) in the datacenter. This will cause the Azure Portal to report the status of the VM as “Stopped”.

The second method, and the important one to remember, is to go into the Azure Portal (or use the Azure CLI or Azure PowerShell) and use Azure to Stop the VM. Instead of just shutting down the Operating System, Azure will also deallocate the compute resources allocated for the VM. This releases the compute resources to be used for another customer within Microsoft Azure. This will cause Azure to no longer charge you for the compute resources, and Azure will report the status of the VM as being in a “Stopped (Deallocated)” state.

Screenshot: VM blade in Azure Portal showing VM is Stopped (deallocated)

While an Azure VM is in the “Stopped (Deallocated)” state, you will not be charged for the VM compute resources. However, you will still need to pay for any OS and data storage disks attached to the VM.

It’s a good idea that when ever you don’t actually need the VM to be running that you Stop it using Azure so that the resources are released. While in the “Stopped (Deallocated” status, you will not be paying for the VM resources. This will really help you save money!

Use Azure CLI to Stop (Deallocate) Azure VM

Using the Azure Portal is nice, but there are time when you want to automate stopping and deallocating an Azure VM. This can be done using the Azure CLI using the following commands:

# Stop Azure VM az vm stop --name {vm name} --g {resource group name} # Deallocate Azure VM az vm deallocate --name {vm name} -g {resource group name}

I encourage you to check out the Quickly Start / Stop ALL VMs article I’ve previously written, as it includes more description and additional script samples for stopping Azure VMs.

Manually Shutdown VM within Azure Portal

To “properly” Stop a VM in the Azure Portal to release the resources and save money, you can follow these steps:

Within the Azure Portal, navigate to the Virtual Machine blade for the desired VM. On the Overview pane, click the Stop button.



Screenshot: “Stop” button highlighted for VM blade in Azure Portal

There is one caveat to be aware of when shutting down an Azure VM so it gets placed into the Stopped (Deallocated) status. Since this causes Azure to release the server resources associated with the Virtual Machine, it not only releases the CPU and Memory resources but also the Dynamic IP Address allocation. Due to this, when you Start the VM back up again, the IP Address will likely change. If you require the IP Address to never change for your VM, then you’ll need to configure a Static IP Address for the VM.

To start up a Stopped VM, you can follow these steps:

Within the Azure Portal, navigate to the Virtual Machine blade for the desired VM. On the Overview pane, click the Start button.

Screenshot: “Start” button highlighted for VM blade in Azure Portal

Another point that’s important to remember when stopping Azure VM’s and placing them into the “Stopped (Deallocated)” state is that you do still pay for the Azure Storage account usage. Remember, the Storage account is where the VM’s .vhd disk image file is stored. Stopping the VM retains all the VM’s settings / configurations, as well as the .vhd image stored in Azure Storage. As a result, you will still incur some cost for the storage, but at least you will save on the VM resources. After all, the Storage will only cost a small amount of money compared to the much higher cost of the Virtual Machine resource allocation if it were left running constantly.

Schedule VM Auto Shutdown

Manually shutting down a VM to put it in the Stopped (Deallocated) status is a great way to save cost on Azure VM’s. Although, you do need to remember to Stop the VM. This introduces a certain level of human error in the process of saving you hosting costs on your Azure VMs. As a result, Microsoft has added a scheduled auto-shutdown feature into the platform to assist you in this effort.

With the Auto-shutdown feature, you are able to configure a specific Time (with Time Zone) when Azure is to automatically shutdown the VM. When configured, the VM will automatically be stopped if it is still running at that time of day.

To configure Auto-shutdown of an Azure VM, you can follow these steps:

Within the Azure Portal, navigate to the Virtual Machine blade for the desired Virtual Machine. In the list of links on the Virtual Machine blade, click on Auto-shutdown. On the Auto-shutdown pane, configure the specific Time, Time Zone, and desired notification Webhook URL settings, then click Save.

Screenshot: “Auto-shutdown” pane of VM blade with options highlighted

If you forget to Stop your VM at the end of the day, or whenever the Auto-shutdown time is configured it will get Shutdown automatically. When using a Visual Studio development VM, this can become a good thing on Friday afternoons (or any other day when you might be in a hurry) when you’re most likely to forget to shutdown the VM.

Article Author

Chris Pietschmann Chris is the Founder of Build5Nines.com and a Microsoft MVP in Azure & IoT with 20 years of experience designing and building Cloud & Enterprise systems. He is also a Microsoft Certified: Azure Solutions Architect, developer, Microsoft Certified Trainer (MCT), and Cloud Advocate. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.