Azure for SRE

Azure Automation Accounts – Complete Guide

This guide provides a comprehensive explanation of Azure Automation Accounts, covering all essential concepts, services, and features. It is designed for learners who want to master automation in Azure, especially in DevOps and SRE roles.

1. Basics and Core Concepts

What is Azure Automation?

Azure Automation is a cloud-based service that helps you automate repetitive tasks, manage configurations, and ensure consistency across Azure and hybrid environments. It’s ideal for reducing manual effort, improving reliability, and enforcing governance.

Key Features:

What is an Automation Account?

An Automation Account is a container for all your automation-related resources, such as:

Example: You can create one Automation Account per environment (Dev, QA, Prod) to organize scripts and schedules separately.

Pricing Tiers

Use the Azure Pricing Calculator to estimate costs.

Supported Regions

Azure Automation is available in most Azure regions, including:

You can find the full list of supported regions here.

2. Runbooks – Heart of Automation

What is a Runbook?

A Runbook is a script or a workflow that performs a specific task, such as:

Runbooks can be scheduled, triggered via webhook, or integrated with alerts.

Type Language Description
PowerShell PowerShell Most widely used, flexible
Python Python 2.x Useful for Python automation
Graphical Drag-and-drop No-code visual builder
PowerShell Workflow Workflow-based PowerShell Supports checkpoints
Hybrid Worker Any (on-prem) Runs outside Azure

Note: Azure Automation currently supports Python 2.7 only.

How to Author Runbooks

  1. Azure Portal: Use the built-in editor.
  2. VS Code: With PowerShell extension and Azure Tools.
  3. GitHub: Sync runbooks from a repo.
  4. Upload: Import .ps1 or .py files.

Example PowerShell Runbook:

Types of Runbooks

Azure Automation supports several types of runbooks based on the execution method and scripting language:

I. PowerShell Runbook

Example:

param (
    [string]$VMName,
    [string]$ResourceGroupName
)

Stop-AzVM -Name $VMName -ResourceGroupName $ResourceGroupName -Force

II. Python Runbook

Example:

import datetime
print("Automation Runbook started at:", datetime.datetime.utcnow())

Python 3 is not currently supported in Azure Automation.

III. Graphical Runbook

IV. PowerShell Workflow Runbook

Example:

workflow Restart-MultipleVMs {
    param ([string[]]$VMNames)

    foreach -parallel ($vm in $VMNames) {
        Stop-AzVM -Name $vm -Force
        Start-AzVM -Name $vm
    }
}

V. Hybrid Worker Runbook

VI. Runbook Variables and Automation Assets

Runbooks often require shared data, credentials, or modules to run securely and consistently. Azure Automation provides a set of Assets to simplify this.

| Asset Type | Description | | —————- | ————————————————————————– | | Variables | Store reusable values (e.g., region = “eastus”) | | Credentials | Secure storage for username/password combinations | | Certificates | Used for secure communications and authentication | | Connections | Store authentication contexts for services like Azure, OMS, or custom APIs | | Modules | PowerShell/Python libraries (Az, MSGraph, etc.) available to runbooks | —

Examples: Using Assets in Runbooks

Get a Variable:

$location = Get-AutomationVariable -Name "DefaultRegion"

Use a Credential:

$creds = Get-AutomationCredential -Name "ServiceAccount"
Connect-AzAccount -Credential $creds

Use a Connection:

$connection = Get-AutomationConnection -Name "AzureRunAsConnection"
Connect-AzAccount `
  -ServicePrincipal `
  -Tenant $connection.TenantId `
  -ApplicationId $connection.ApplicationId `
  -CertificateThumbprint $connection.CertificateThumbprint

Lifecycle of a Runbook

Summary

| Component | Description | | —————— | ——————————————– | | Runbook | Script or workflow to automate tasks | | PowerShell Runbook | Most commonly used, full Azure support | | Python Runbook | Supports Python 2.7 only | | Graphical Runbook | Drag-and-drop interface for simple logic | | Hybrid Worker | Run scripts on on-prem or custom VMs | | Authoring Options | Portal, VS Code, GitHub, or uploaded script | | Automation Assets | Variables, credentials, connections, modules | —

3: Execution and Scheduling in Azure Automation

Runbooks are only useful if they can be executed reliably and flexibly. This section explains the different ways to start runbooks, how to schedule them, and how to manage parameters, errors, and logs.

Runbook Execution Methods

Azure Automation allows you to trigger runbooks using multiple methods:

Method Description
Manual Run directly from the Azure Portal
Scheduled Execute at defined intervals or times
Webhook Triggered via HTTP request from external services
Alert Trigger Triggered by Azure Monitor or Log Analytics alerts
Hybrid Worker Execute on on-premise or custom VM

I. Manual Execution

You can run any published runbook manually via the Azure Portal:

Ideal for testing or ad-hoc tasks.

II. Scheduled Execution

Runbooks can be triggered automatically using schedules:

How to Create a Schedule:

  1. Go to Runbooks → Select a runbook
  2. Click on Schedules
  3. Create a new schedule or link an existing one

You can link the same schedule to multiple runbooks.

III. Webhook Trigger

A Webhook is a unique URL that can trigger a runbook from outside Azure.

Use Cases:

Treat webhooks like secrets. Regenerate or disable if leaked.

IV. Alert-Based Triggers (Azure Monitor)

Runbooks can respond automatically to system events, such as:

Example:

Set this up in:

V. Runbook on Hybrid Worker

If a runbook needs to interact with on-prem resources or systems not reachable by Azure:

Error Handling and Logging

| Concept | Description | | ———————– | ————————————— | | Manual Execution | Run via Portal | | Schedule | One-time or recurring jobs | | Webhook | Trigger from external systems | | Alert Trigger | React to Azure Monitor or metrics | | Hybrid Worker | Execute locally on-prem | | Input Parameters | Accept values from user/scheduler | | Output / Logging | Capture runbook results and errors | | Error Handling | Use Try/Catch and write logs | | Job Monitoring | View status, input, output in portal | | Alerting & Notification | Get alerts via Action Groups or Monitor | — —

4. Automation Assets

Automation Assets are reusable resources in Azure Automation that help you simplify scripts, store shared data securely, and manage dependencies across multiple runbooks.

They act like global variables or configuration items for your automation environment.

What Are Automation Assets?

Assets are stored in the Automation Account and can be used across all runbooks. They help:

I. Variables

Variables are name/value pairs stored at the account level.

Create Variable (Portal) Automation Account > Shared Resources > Variables > Add a Variable

II. Credentials

Create Credential (Portal) Automation Account > Shared Resources > Credentials > Add a Credential

III. Certificates

IV. Connections

Azure provides built-in connection types like:

V. Modules

Modules are PowerShell or Python packages used in your runbooks. Azure Automation includes common modules like:

Manage Modules: Automation Account > Shared Resources > Modules

| Asset Type | Usage | | —————- | ————————————————- | | Variables | Store values for re-use across runbooks | | Credentials | Securely store and retrieve secrets | | Certificates | Authenticate using certs for APIs or services | | Connections | Structured authentication info (e.g., AzureRunAs) | | Modules | Libraries used in PowerShell/Python runbooks | — —

5. Hybrid Runbook Worker

Not all automation tasks can be done in the cloud. Sometimes, you need to run scripts on on-premises servers, other clouds, or restricted environments. That’s where Hybrid Runbook Workers come in.

What is a Hybrid Runbook Worker?

A Hybrid Runbook Worker (HRW) is a VM or server that runs runbooks outside Azure, while still being managed from your Azure Automation Account.

It allows you to:

Think of it as a bridge between Azure and your private environment.

Key Concepts

Term Description
Hybrid Worker Group A logical group of one or more machines registered to execute runbooks
Runbook Job A task executed by Azure Automation, offloaded to a Hybrid Worker
HRW Agent Software that connects your machine to Azure Automation
Job Runtime Billed just like cloud jobs — by execution time

Installing Hybrid Runbook Worker

Requirements:

Installation Steps:

  1. Go to Azure Portal > Automation Account > Hybrid Worker Groups
  2. Click Add a hybrid worker group
  3. Choose “Add a machine”
  4. Download and run the HRW agent installer on your server
  5. Authenticate using:
    • Azure Run As Account
    • OR Managed Identity

The agent runs as a Windows service and polls Azure Automation for jobs to execute.

Runbook Execution on HRW

You can choose to run a runbook on a Hybrid Worker Group instead of in Azure:

The runbook will then execute locally on the VM instead of in the Azure sandbox.

Benefits:

Use Cases for Hybrid Workers

Scenario Why HRW is Ideal
Access on-prem SQL Server Azure sandbox can’t reach private networks
Run long or complex scripts HRW has no strict execution time/memory limits
Use custom binaries or EXEs Sandbox doesn’t allow executable binaries
Automate 3rd-party systems E.g., VMware, file shares, Active Directory
Enforce DSC on local machines Apply configurations via Azure Automation DSC

Monitoring and Logging

Hybrid Workers send job logs back to Azure, just like cloud jobs.

You can view:

In:

Tip: Use Log Analytics queries to track all Hybrid Worker activity.

Security and Best Practices

Summary

Feature Description
HRW Machine that runs Azure Automation runbooks locally
Install Agent Connects your server to Azure Automation
No Sandbox Limits Full PowerShell/OS access
Secure Supports credential encryption, firewalls, private links
Ideal for On-prem automation, hybrid scenarios, complex jobs

6. Desired State Configuration (DSC) with Azure Automation

Desired State Configuration (DSC) is a declarative configuration management platform built into PowerShell. When used with Azure Automation, it allows you to define, deploy, and maintain consistent configurations on virtual machines (VMs) or servers — whether they are in Azure, on-prem, or other cloud providers.

What is PowerShell DSC?

DSC is a feature of PowerShell that enables you to:

Think of DSC as “Infrastructure as Code” for machine configuration.

DSC vs. Runbooks

Feature Runbook DSC
Type Procedural (step-by-step scripting) Declarative (define desired state)
Execution On-demand, scheduled, or triggered Continuous monitoring and enforcement
Use Case Automate tasks and operations Maintain system configuration
Idempotent Not always Yes — DSC ensures consistent end-state
Target Single task or workflow Configuration of services, roles, registry, etc.

Use Runbooks for automation tasks, and DSC to enforce system state.

Key Components of DSC

Component Description
Configuration PowerShell script defining the desired system state
Resource The building blocks (e.g., File, WindowsFeature, Service) used in a configuration
LCM Local Configuration Manager – runs on the target VM to apply and monitor config
MOF File Compiled version of a configuration sent to the node (in .mof format)

Authoring a DSC Configuration

Basic Example: Install IIS

Configuration InstallIIS {
    Node "localhost" {
        WindowsFeature WebServer {
            Name = "Web-Server"
            Ensure = "Present"
        }
    }
}
InstallIIS

Pull Server vs. Push Model

| Model | Description | | ——– | ———————————————————————————————– | | Pull | Nodes check in with Azure periodically to pull and apply the latest configuration (Recommended) | | Push | Admin pushes the config manually to the node (for testing or one-time use) | —

Use Cases for DSC

| Use Case | Why DSC? | | —————————————- | ——————————————— | | Install/ensure specific Windows features | e.g., IIS, .NET Framework | | Enforce local user/group membership | Ensure specific users or policies are present | | Manage services | Ensure services are running or stopped | | Configure registry keys | Enforce registry settings for compliance | | Install applications via packages | Use Package resource to install software | | Maintain file/folder structures | Ensure certain files exist or do not exist | —

Summary

| Concept | Description | | ——————- | ——————————————————– | | DSC | Declarative tool for managing and enforcing system state | | Configuration | PowerShell code defining the desired state | | LCM | Agent running on the target system | | Pull Model | Nodes retrieve config from Azure and report back | | Compliance | Track if a node matches its assigned configuration | | Use With Hybrid | Can apply DSC to on-prem VMs or non-Azure environments | — —

💬
AI Learning Assistant