Azure Power Automation involves turning on and off virtual servers when they aren’t required. This saves costs by automatically shutting down testing environments over the weekend and bringing them back up for Monday morning.
In this post, we will look at why it’s important to make use of these tools and how to implement some basic solutions for Azure Power Automation.
Many businesses operate during a set number of hours. For example, a company might be open between 9am and 5pm. That’s 8 hours of the entire day that Virtual Machines are required. If we allow for an hour before and after the day as a contingency, then we only need virtual machines 10 hours per day, or under 50 percent of the time.
The pricing of Azure virtual machines is based on how many hours they are running for. Yes, there are also egress data and storage costs, but the virtual machine cost is normally the largest component. If a virtual machine is required for just 50 percent of the day, then why are we running it or, more importantly, paying for it 100 percent of the time?
The largest share of Azure subscription costs when using Virtual Machines (IaaS) is the compute time: how many hours the Virtual Machines are running per month. If you have Virtual Machines that can be stopped during certain time periods, you can reduce the bill by turning them off (and “deallocating” them).
Azure Power Automation uses a feature of PowerShell called workflows to create runbooks. A runbook is an atomic unit, allowing you to automate a piece of work, such as powering up or shutting down a bunch of virtual machines in Azure.
Automation uses something called assets, where an asset is defined as a reusable resource. Examples of assets are credentials (enabling a runbook to sign into Azure to manipulate resources) and schedules (allowing you to automatically execute a runbook at days/times of your choosing).
By now you should start to understand how Azure Power Automation works:
The aim of this step by step guide is to use the graphical runbooks feature to schedule starting and stopping of a virtual machine. This will be achieved using pre-existing graphical runbooks available in the gallery, built by the Automation product team.
The virtual machine is of the “resource manager” variety, rather than “classic”, but there are specific runbooks that are tailored to each type so use whichever is appropriate to your situation.
If you don’t already have an Automation account, create a new Automation account in the Azure Portal, by navigating to New > Management > Automation and completing the required details.
Once you’ve created an account you’ll see it listed in the Automation Accounts blade.
Clicking on the Automation Account shows all of its details, allowing you to view and create the various resources, and see monitoring information for jobs.
In order to execute PowerShell scripts, whether they are regular scripts, Workflows, DSC or graphical runbooks, you need some form of credential. There is now a specific Automation resource for defining Credential assets.
In this guide, we will use an Azure RM AD service principal. With this, you can assign fine grained role based access to the resources in your Azure directory. For example, the service principal could be assigned the “VM Contributor” role for a specific resource group only. Or it could be assigned full access to an entire subscription. There are many built-in roles and you can define custom roles as well.
To learn how to create the service principal, follow the steps from a previous post.
Once you have a service principal, you can assign it to a particular resource with a particular role. For example, navigate to the Subscriptions blade, and click on the Subscription you want it to have access to. Near the top right of this blade, there is a set of icons.
Click on the “Access” icon (looks like two people and is highlighted red in the image). This allows you to assign user access.
From there select a role, and add the service principal user. You can use the search box on the Add Users blade to find your service principal.
Now that the service principal has been given access to the subscription, an Automation Credential can be created.
From the Automation account blade, navigate to Assets then Credentials and click the “Add a credential” button. Enter your service principal details.
Time to create the Runbooks! From the Automation blade in the portal navigate to Runbooks then click the “Browse Gallery” button.
We’ll be using pre-existing graphical runbooks available in the gallery, built by the Automation product team. If you search for the text “azure arm vms” you’ll see the two Runbooks we’ll be using for this guide.
Clicking on the “Stop Azure ARM VMs” brings up a view that shows the graphical runbook in all its glory.
Clicking the “Import” button will bring this graphical runbook into your Automation account and allow you to alter, test and publish it.
Clicking the “Test pane” button will allow you to fill in the parameters the runbook requires and start the runbook and see the output.
The parameters this runbook needs are:
The Credential Asset was made in a previous step. You’ll need to create a new Variable Asset for the Subscription ID.
If you successfully enter the parameters and test the runbook, you should see output that says it is Completed and that the VM has been stopped.
Once you’ve successfully tested the runbook, you can hit the “Publish” button.
Now that we have a published runbook to stop a virtual machine, we need to link it to a schedule, so the runbook starts automatically when we want it to.
From the Runbook blade, click the “Schedule” button, then “Add a Schedule”. First you need to set up a schedule to link to this runbook. You can use an existing schedule or create a new one. When creating a new schedule you need to enter a name and when it should run e.g. daily at 20:00.
The parameters that will be given to the runbook on this scheduled run then need to be populated as well.
Once the schedule has been created, you’ll see that schedule on the runbook blade.
We could now repeat all the steps to create a new runbook, but use the “Start Azure ARM VMs” graphical runbook from the gallery. In this way, we can schedule the VM to start and stop according to our needs.
By following this guide, we can use Azure Automation to cleanly shutdown virtual machines that aren’t required after the end of the day, and then start them up before employees start the day.
This should also be a nice solution for those of you who are trying to squeeze as much as possible out of your monthly partner internal usage rights, free MSDN benefits, or an Azure subscription.
If you would like further information on Azure Power Automation, or if Digital Craftsmen can help you with automating your systems on any other platform, please get in touch.