Automatic Shutdown Settings in Azure VMs

This post will discuss the Auto-Shutdown settings in the properties of an Azure virtual machine, how to configure them, and whether you should use this feature or not.
 

 

Overview

We normally pay for Azure virtual machines on a pay-as-you-go (PAYG) basis; for each minute that a virtual machine is running, you pay for that virtual machine’s consumption of compute and operating system (in the case of Windows Server). There are some variations to this rule, but this is the norm.
A virtual machine might not be required to run all of the time. For example:

• A business application might be used only for end-of-month processing/reporting.
• A company might only operate during certain hours.
• A lab machine might only be required during the work day.

By powering off the virtual machine, we can save money. Note that additional costs, such as the OS disks and data disks, will continue to accrue. Because of this, many customers want to be able to automatically power down virtual machines.

Auto-Shutdown

The auto-shutdown feature that Microsoft added to Azure virtual machines comes to us from Azure DevTest Labs; the sandbox service for developers and testers allows a subscription administrator to minimize compute costs by automatically powering down virtual machines at the end of the workday and optionally power them up again in the morning.
However, things are slightly different for normal virtual machines that are not controlled by DevTest Labs. We only get the auto-shutdown feature and there is no option to automatically start up machines again – more on this later.

Configuring Auto-Shutdown

You can configure auto-shutdown when creating a new virtual machine or in the settings of an existing machine. In the case of an existing machine, open the virtual machine’s settings and open Auto-Shutdown under Operations.
Here you will find a button to either enable or disable auto-shutdown for this particular virtual machine. If you click On under the Enable button, the other configuration controls will be enabled:

• Scheduled Shutdown: Here you will specify what time the shutdown will happen in the HH:MM:SS format.
• Time Zone: Specify the time zone you are referring to in Scheduled Shutdown. It’s easy to not notice that this is set to UTC by default.
• Send Notification Before Auto-Shutdown: Would you like to send a message or trigger an action before the machine shuts down?
• Webhook URL: If you want something to happen in sync with the machine being shut down, then you can provide the URL of an Azure Automation (or some other system) webhook.
• Email Address: Provide an email address (maybe a distribution list or monitoring system) that will be notified ahead of the shutdown.

 
If you do configure the email option, you will receive an email 30 minutes before the shutdown is due to commence. The email will inform you of the name of the machine and it will offer you some options:

• Postpone the shutdown by 1 hour or 2 hours.
• Skip the shutdown.

Confusingly, the email is sent to you by DevTest Labs, even if your machine is not managed by DevTest Labs.

When To Use Auto-Shutdown

I regularly use the auto-shutdown feature but never with production virtual machines. In the case of production workloads, you are probably better served by using Azure Automation, which can group the processing of many machines by powering them off and on again in an orchestrated manner.
I normally use Auto-Shutdown with lab machines that I use to write articles, such as this one, to do demonstrations with customers or at events, or when I’m learning about Azure services. I typically set up the feature while creating the machine. The machine will shut down at 7pm automatically, so I don’t have to remember to shut it down at the end of the day to avoid wasting credit.
Another scenario I found was when I went through my own rather small cloud transformation. I migrated my websites from an Azure virtual machine to Azure App Services. Several days after redirecting the DNS records, I configured auto-shutdown to power down the old web server. And then several days after that, I felt comfortable with deleting the resources for the redundant machine.