Scheduling automated start and stop for Azure VMs is almost as good as provisioning and deprovisioning infrastructure on-demand, by using Infrastructure as Code (IaC) tools, like Terraform, ARM templates, or even Bicep. So, what’s the use-case scenario you may ask. Well, using immutable infrastructure is commonly used and best fit in scenarios where we don’t deal with a state, take stateless apps for example. But, sometimes there are these so-called snowflake servers, that needs to be taken care of, for example: a VPN server, a bastion host, you get my point. In most of the cases, these snowflake servers have their configuration drifted far more than required.
So, unless we find another solution, which I’ve mentioned it in the Conclusion part below, we would be babysitting these instances for a long time. Let’s go through the steps described below.
Prerequisites
- Azure subscription
- Azure VM
- Azure Automation account
- Azure Log Analytics Workspace
Azure Automation
Step 1. First, make sure you got your Azure Automation account created. From the portal, type Automation in the search console, and click on Automation Accounts.
Step 2. Choose the automation account, and click Start/Stop VM under Related Resources.
Step 3. Click Learn more about and enable the solution.
Step 4. Click Create.
Step 5. Now, under Workspace and Automation account choose a Log Analytics Workspace and Automation Account respectively, or if you don’t have any, create them.
Step 6. Under Configuration, click Parameters, update the configuration, and click OK.
Step 7. Click Create. Once the deployment succeeded, a new resource under Solution is created. 
Step 8. As a next logical step, you should configure an Automation job alerts, so you’ll get notified if a start or stop operation failed.
Conclusion
So, instead of worrying about configuration drifts, using a managed service like Azure Bastion, or Azure VPN Gateway, should be a lot easier and simpler solution, maybe not the cheapest one in most of the cases, but could save you from operation costs on a long run, if you follow best practices, of course. And, the last but not least, if you don’t want to deal with managed services, storing the configuration on remote location, and pulling it once the VM provisioning is done, should be the way to go.
In case you missed it, check out the rest of the Azure series. Feel free to leave a comment below and if you find this tutorial useful, follow our official channel on Telegram.