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.
- Azure subscription
- Azure VM
- Azure Automation account
- Azure Log Analytics Workspace
Step 1. First, make sure you got your Azure Automation account created. From the portal, type
Automation in the search console, and click on
Step 2. Choose the automation account, and click
Start/Stop VM under
Step 3. Click
Learn more about and enable the solution.
Step 4. Click
Step 5. Now, under
Automation account choose a Log Analytics Workspace and Automation Account respectively, or if you don’t have any, create them.
Step 6. Under
Parameters, update the configuration, and click
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.
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.