Powershell in the Cloud – Part 1 – Azure Automation – Managing your Infrastructure from the Cloud

I recently held a talk about Powershell in the Cloud in Powershell User Group Sweden, this 3 part series is an attempt to refine and expand on that talk. The series will focus on the functionality rather than the code behind it as I want the content to be accessible for not anyone, whether you the reader is of a technical background or not.
When you have read the entire post and have any questions or feedback feel free to contact me: vikingur.saemundsson@xenit.se

The 3 part series is going to cover some basic ideas about managing infrastructure through Automation, Just Enough Administration (JEA), building HTTP APIs using Powershell and finally automating the infrastructure using Azure DevOps & Infrastructure As Code (IAC).

Even though we will talk about many different methods of running Powershell in the Cloud we are going to focus on one single use case:

Leveraging Automation to Reduce your Costs in Microsoft Azure

So the scenario we are presenting is that you have adopted Azure to some extent and have Virtual Machines in Microsoft Azure that are somewhat redundant, and to save cost you want to turn them off and deallocate them when they are not in use. The problem is that most of the redundant machines are not used by you or the IT department and you don’t want to give the end-users the option to access Azure in order to manage the machine powerstate.

To solve this problem we are going to use Azure Automation and build a super simple Runbook (Powershell script in the cloud) to control and delegate access to all our machines.

Azure Automation Accounts

Azure Automation delivers a cloud-based automation and configuration service that provides consistent management across your Azure and non-Azure environments.” – https://docs.microsoft.com/en-us/azure/automation/automation-intro

In the content I’m displaying we will use as few features as we can to manage our infrastructure as well as keeping our code as simple as possible. If you’re interested in the full suite capabilities i highly suggest you read the Microsoft docs & create your own test environment.
The features we will use is the built in Run as Account and a single Powershell Runbook. In the Powershell Runbook we will create a simple weekly schedule as well as add webhooks to create JEA endpoints to end-users.

When creating a Azure Automation Account we will choose the option to create a Run as Account, this will create a service principle that has Contributor rights on the entire subscription. The Service Principal can later be delegated more granular access for security hardening and even be applied on other resources across the entire Azure Tenant. When we are done we will navigate to Process Automation\RunbooksCreate a Runbook and name it VirtualMachinePower, the runbook type is Powershell

We then add three parameters to the script. This is done exactly the same as in any powershell script and will allow us to control specific machines.

  • Action – We want this to be a start/stop action.
  • VMName – the displayname of the VM (in azure)
  • ResourceGroupName – Where the VM resides in your Azure subscription
When the code is added press Save and then Publish the runbook. Try it out by pressing Start and enter the desired Action, VMName and ResourceGroupName and press OK to send the job to the queue.


In the example above there is a Failed in Recent Jobs. This is the job queue history for this specific runbook. These are expandable so you can investigate the status, output and eventual error. In this specific case i entered a faulty Action and the ValidateSet threw an error.
Cannot validate argument on parameter ‘Action’. The argument “asda” does not belong to the set “start,stop” specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again. (The argument “asda” does not belong to the set “start,stop” specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.)”

When the job is submitted to the queue we will se it cycle through Queued, Running and hopefully Completed

When Completed we will be able to see that the Virtual Machine went from Status Running to Stopped (deallocated) and thus the compute cost is reduced to zero as opposed to when the Virtual Machine is shut down from within the operating system.

How does this help me reduce costs? We have not accomplished anything new!

Well, yes we have. We have just pressed the “Start/Stop” buttons using code. Now let’s connect all the dots and save some money.

The easy way to do this is Start/Stop the machines on a schedule. Azure Virtual Machines already has the option to automatically shut down, and if you know when to stop the machines by all means use the built-in functionality. Unfortunately we can’t use the same mechanism to start the Virtual Machines.
In this case we can easily from the runbook view press the Schedules and configure a daily start-up schedule, just specify the schedule and choose which Virtual Machine to start using the Parameters. This is nothing fancy so I will not go into any depth about this. What we will focus on is the Add Webhook functionality.

With this functionality we can create individual webhooks and distribute them to end-users and give them the option to either start and/or stop Virtual Machines from anywhere without access to Azure.

AzureAutomation-Webhook0AzureAutomation-Webhook1 AzureAutomation-Webhook2

With the webhook created we can distribute the URL or a simple script to the end-user to allow the user to start/stop the Virtual Machine from without accessing Azure

AND VOILÀ! We have just Leveraged Automation to Reduce Costs in Microsoft Azure

In the next part of this series we will go through how to create and deliver HTTP endpoints with Powershell that are accessible from your browser using Azure Function Apps.

Powershell in the Cloud – Part 2 – Azure Function App – Creating HTTP APIs with Powershell

Disclaimer: All information on this blog is offered "as is" with no warranty. It is strongly recommended that you verify all information and validate all scripts in isolated test environments before using them in production environments.