Azure Automation – Reducing Cost

The idea behind this is extremely simple: to run a deployment machine in Azure that will be used to deploy updates to production. In my environment we get everything packaged on build server, but deployment has to happen in a controlled environment and from a manual kick-off. Deployments are not performed at night, hence compute time is wasted. To save 50% (at least) of compute time, VM has to be down.

Plan for solution: get a single instance VM down during night and up at work hours. My initial thought was to use Azure Cloud Services auto-scale feature.

Pros:

- Defined under Cloud Service VM instance belongs to

- Scaling is a property of Cloud Service

Cons:

- Requires Availability Set to be created and associated with VM instance

- Requires at least 2 VM instances to run Auto-Scaling (deal breaker!)

Fortunately, with the new release of Azure Automation, this can be done with Runbooks (a Runbook is a workflow that contains a PowerShell script, that can also call child Runbooks).

Pros:

- Doesn’t require multiple instances of VM (hence saving money)

- Runs under the context of subscription, therefore has access to all resources

Cons:

- Scheduling is not as flexible as with Auto-Scaling and needs to be associated with a Runbook

What I ended up doing was quick and dirty, but it does the job for now.

1. Create an automation object (Virtual-Machines)

2. Imported two Runbooks into automation (Start-AzureVMsOnSchedule and Stop-AzureMVsOnSchedule)

Note that “import” is as simple as importing PS script wrapped in workflow name_of_workflow { #powershell script }

3. Published imported runbooks

4. Associated a schedule with each runbook

5. Specified for each schedule to execute on a certain time daily (for Start runbook to run at 7AM, for Stop runbook to run at 7PM). BTW, parameters can be passed to individual runbooks, so that job (executed runbook) becomes a parameterized job. Also, resources can be used from all

6. Once a job (schedule runbook) was executed, it’s logged (you can drill into details of each command – can see Bruce`s eyes light up)

7. Job executed (spike at 7AM) and VM is up and running. Big Success *Borat accent* :)

Note that when you edit Draft of your runbook, you can run (test) it before publishing. Also, you can import existing modules (Azure module is imported by default) using command toolbar at the bottom, add settings that can be shared by multiple runbooks, and insert Activity (powershell command) / Runbook / setting.

Azure Automation is a great feature to leverage. Excited to see all of these things shaping up and making work easier, allowing to cut down costs at the same time.

Update 1: I’ve noticed that while VM was started and stopped, scripts didn’t execute cleanly. To solve that, I had to wrap commands in InlineScript { #start/stop-AzureVM … } construct