Microsoft Azure — Azure Automation & Runbooks

Azure Automation provides a way to automate frequent, time-consuming, and error-prone cloud management tasks using runbooks and configuration management.

Azure Automation: The Automation Account as Your Control Plane

Azure Automation is not just a scheduler—it's a managed service for orchestrating repetitive tasks across your Azure estate. The core resource is the Automation Account, which hosts runbooks, modules, and shared assets like credentials and variables. When you create an Automation Account, you choose between Basic and Free pricing tiers; for production, always use Basic to avoid execution time limits. The account is tied to a region, but runbooks can manage resources in any region via service principals. A common mistake is treating the Automation Account as a single-purpose tool—instead, design it as a centralized control plane for operational tasks like VM start/stop, patching, and incident response. Always isolate Automation Accounts per environment (dev, staging, prod) to prevent cross-environment accidents. Use RBAC to grant the Automation Account's managed identity least-privilege access to target resources. Never store secrets in plain text; use Azure Key Vault integration or encrypted variables.

# Create Automation Account with system-assigned managed identity
$resourceGroup = "rg-automation-prod"
$location = "eastus"
$automationAccountName = "aa-prod-control"

New-AzResourceGroup -Name $resourceGroup -Location $location -Force

New-AzAutomationAccount `
    -ResourceGroupName $resourceGroup `
    -Name $automationAccountName `
    -Location $location `
    -AssignSystemIdentity

# Grant the managed identity Contributor role on a subscription (example)
$identity = (Get-AzAutomationAccount -ResourceGroupName $resourceGroup -Name $automationAccountName).Identity.PrincipalId
New-AzRoleAssignment `
    -ObjectId $identity `
    -RoleDefinitionName "Contributor" `
    -Scope "/subscriptions/$(Get-AzContext).Subscription.Id"

Runbook Types: PowerShell, Python, and Graphical—Pick the Right Tool

Azure Automation supports three runbook types: PowerShell, Python, and Graphical. PowerShell runbooks are the most common for Azure resource management, leveraging the Az module. Python runbooks are ideal for cross-platform tasks or when you need libraries not available in PowerShell. Graphical runbooks are a drag-and-drop interface best avoided in production—they're hard to version control, review, and debug. For production, always use PowerShell Workflow runbooks only if you need parallel execution or checkpointing; otherwise, stick with PowerShell 5.1 or 7.2 (preview). Python runbooks run Python 3.8 and support pip packages, but module imports can be tricky—use the Automation Account's Python packages feature. A key decision: choose PowerShell 7.2 for modern cmdlets and cross-platform compatibility, but be aware that some Azure modules may not be fully supported yet. Always test runbooks locally using the same module versions as in Azure.

param(
    [Parameter(Mandatory=$true)]
    [string]$ResourceGroupName
)

Write-Output "Starting runbook for resource group: $ResourceGroupName"

# Authenticate using managed identity
Connect-AzAccount -Identity

# List VMs in the resource group
$vms = Get-AzVM -ResourceGroupName $ResourceGroupName
foreach ($vm in $vms) {
    Write-Output "VM: $($vm.Name) - Status: $((Get-AzVM -ResourceGroupName $ResourceGroupName -Name $vm.Name -Status).Statuses[1].DisplayStatus)"
}

Authentication: Managed Identity Over Service Principal Every Time

Authentication is the most common source of runbook failures. Azure Automation supports three methods: Run As Account (deprecated), service principal, and managed identity. Managed identity is the modern, secure, and hassle-free approach. When you enable system-assigned managed identity on the Automation Account, Azure automatically manages the identity lifecycle. Your runbook calls Connect-AzAccount -Identity to authenticate. No secrets, no certificate rotations. If you need cross-tenant access, use a user-assigned managed identity. Avoid Run As Accounts—they rely on certificates that expire and require manual renewal. Service principals are acceptable for legacy scenarios but introduce secret management overhead. In production, always use managed identity and grant it least-privilege RBAC roles on the target resources. For hybrid scenarios (on-premises resources), use Hybrid Runbook Workers with managed identity via Azure Arc.

# Connect using system-assigned managed identity
Connect-AzAccount -Identity

# Verify context
$context = Get-AzContext
Write-Output "Connected as: $($context.Account.Id)"
Write-Output "Subscription: $($context.Subscription.Name)"

# Example: list resource groups
Get-AzResourceGroup | Select-Object ResourceGroupName, Location

Runbook Execution: Schedules, Webhooks, and Event-Driven Triggers

Runbooks can be triggered in three ways: schedules, webhooks, and event-driven (via Azure Monitor alerts or Event Grid). Schedules are the simplest—cron-like expressions for recurring tasks. Use UTC time and be mindful of daylight saving. Webhooks allow external systems to start a runbook via HTTP POST; secure them with a token and validate the payload. Event-driven triggers are the most powerful: connect a runbook to an Azure Monitor alert or an Event Grid subscription to react to resource changes. For example, automatically stop a VM when its CPU exceeds 90% for 5 minutes. In production, prefer event-driven triggers over polling schedules to reduce cost and latency. However, beware of retry storms—if a runbook fails, the event may trigger again. Implement idempotency and idempotency checks at the start of your runbook. Use the $Trigger parameter to differentiate between trigger types.

param(
    [object]$WebhookData
)

# If triggered by webhook, parse the body
if ($WebhookData) {
    $body = $WebhookData.RequestBody | ConvertFrom-Json
    $vmName = $body.VMName
    $action = $body.Action
} else {
    # Default parameters for scheduled run
    $vmName = "web-server-01"
    $action = "Start"
}

Connect-AzAccount -Identity

$vm = Get-AzVM -Name $vmName -ResourceGroupName "rg-app-prod"
if (-not $vm) {
    throw "VM $vmName not found"
}

switch ($action) {
    "Start" { Start-AzVM -VM $vm -NoWait }
    "Stop" { Stop-AzVM -VM $vm -Force -NoWait }
    default { throw "Unknown action: $action" }
}

Write-Output "$action initiated on $vmName"

Hybrid Runbook Workers: Automating On-Premises and Multi-Cloud

Hybrid Runbook Workers (HRW) extend Azure Automation to runbooks on machines outside Azure—on-premises, other clouds, or edge devices. You install the Azure Automation Agent on a Windows or Linux machine and register it with your Automation Account. The agent polls for jobs and executes them locally. This is essential for scenarios like patching on-premises servers, managing Active Directory, or orchestrating multi-cloud workflows. For production, deploy HRW in a highly available configuration (at least two workers per Automation Account) and use Azure Arc for governance. Be aware of network requirements: the worker needs outbound HTTPS to Azure (ports 443 and 9354). Security is critical—the worker runs with the privileges of the local system account; restrict what the account can do. Use the worker's managed identity (via Azure Arc) for authentication to Azure resources.

# Run on the target machine as Administrator
$automationAccountName = "aa-prod-control"
$resourceGroup = "rg-automation-prod"
$hybridGroupName = "hg-onprem-servers"

# Download and install the agent
$agentUrl = "https://aka.ms/azureautomationagent"
$installerPath = "$env:TEMP\AMAInstaller.msi"
Invoke-WebRequest -Uri $agentUrl -OutFile $installerPath

# Install silently
Start-Process msiexec.exe -ArgumentList "/i $installerPath /quiet" -Wait

# Register the worker
$registrationKey = Get-AzAutomationRegistrationKey `
    -ResourceGroupName $resourceGroup `
    -AutomationAccountName $automationAccountName

Register-AzAutomationHybridRunbookWorker `
    -ResourceGroupName $resourceGroup `
    -AutomationAccountName $automationAccountName `
    -HybridRunbookWorkerGroupName $hybridGroupName `
    -RegistrationUrl $registrationKey.Endpoint `
    -RegistrationKey $registrationKey.PrimaryKey

Error Handling and Logging: Fail Gracefully, Debug Quickly

Production runbooks must handle errors gracefully. Use try/catch blocks, trap statements, and the -ErrorAction parameter. Never use -ErrorAction SilentlyContinue without logging. Stream logs to Azure Monitor Logs (Log Analytics) for centralized analysis. Use Write-Output for standard output, Write-Warning for non-critical issues, Write-Error for failures, and Write-Verbose for debug details. Enable verbose and progress streams in the runbook settings. For long-running runbooks, implement checkpointing (PowerShell Workflow only) or periodic status updates to avoid timeouts. Use the $Error variable to inspect errors. A common pattern: wrap the entire runbook in a try/catch, log the exception, and send an alert via Send-AzAlert or a webhook to your incident management system. Always set a default value for parameters to avoid null reference errors.

param(
    [string]$VMName = "web-server-01"
)

Connect-AzAccount -Identity

try {
    $vm = Get-AzVM -Name $VMName -ResourceGroupName "rg-app-prod" -ErrorAction Stop
    
    if ($vm.PowerState -eq "VM running") {
        Write-Output "VM $VMName is already running. No action taken."
    } else {
        Start-AzVM -VM $vm -NoWait
        Write-Output "Starting VM $VMName..."
    }
}
catch {
    Write-Error "Failed to process VM $VMName : $_"
    
    # Send alert to Teams via webhook
    $body = @{ text = "Runbook failed: $_" } | ConvertTo-Json
    Invoke-RestMethod -Uri $env:TEAMS_WEBHOOK_URL -Method Post -Body $body -ContentType "application/json"
    
    throw $_  # Re-throw to mark runbook as failed
}

Testing and Version Control: Treat Runbooks Like Application Code

Runbooks are code—treat them as such. Store runbooks in a Git repository (Azure Repos, GitHub) and use CI/CD pipelines to deploy them to Automation Accounts. Use the Azure Automation source control integration to sync directly from a repo, but be aware of limitations (no branching strategy). Better approach: export runbooks as .ps1 files, version control them, and use a release pipeline with Az.Automation module to import/update runbooks. Write Pester tests for PowerShell runbooks to validate logic locally. Test in a non-production Automation Account before deploying to production. Use deployment slots or separate Automation Accounts for testing. Parameterize everything—avoid hardcoded values. Use Azure DevOps variable groups or Key Vault for secrets. Runbooks should be idempotent and stateless; if state is needed, use external storage like Azure Table Storage or a database.

param(
    [string]$ResourceGroupName = "rg-automation-prod",
    [string]$AutomationAccountName = "aa-prod-control",
    [string]$RunbookPath = "./runbooks/Start-Stop-VM.ps1",
    [string]$RunbookName = "Start-Stop-VM"
)

# Import the runbook
Import-AzAutomationRunbook `
    -ResourceGroupName $ResourceGroupName `
    -AutomationAccountName $AutomationAccountName `
    -Path $RunbookPath `
    -Type PowerShell `
    -Name $RunbookName `
    -Published `
    -Force

Write-Output "Runbook $RunbookName imported and published."

Performance Optimization: Avoid Timeouts and Throttling

Azure Automation runbooks have a 30-minute timeout for jobs in the sandbox (3 hours for Hybrid Workers). Long-running tasks must be chunked or offloaded. Use parallel execution with ForEach -Parallel in PowerShell Workflow, or split work across multiple runbooks. Be aware of API throttling: Azure Resource Manager has limits (e.g., 1200 writes per hour per subscription). Implement retry logic with exponential backoff. Use the -NoWait parameter for long-running operations (e.g., Start-AzVM -NoWait) and then poll for completion. For data-intensive tasks, use Azure Storage or a database instead of in-memory collections. Monitor job metrics (execution time, status) in the Automation Account. If a runbook consistently approaches the timeout, refactor it into smaller runbooks or move to a Hybrid Worker with longer timeout.

function Invoke-AzOperationWithRetry {
    param(
        [scriptblock]$ScriptBlock,
        [int]$MaxRetries = 5,
        [int]$BaseDelaySeconds = 2
    )
    
    $retryCount = 0
    $delay = $BaseDelaySeconds
    
    while ($retryCount -lt $MaxRetries) {
        try {
            return & $ScriptBlock -ErrorAction Stop
        }
        catch {
            if ($_.Exception -match "429|TooManyRequests") {
                Write-Warning "Throttled. Retrying in $delay seconds..."
                Start-Sleep -Seconds $delay
                $delay *= 2
                $retryCount++
            } else {
                throw $_
            }
        }
    }
    throw "Max retries exceeded."
}

# Usage
Invoke-AzOperationWithRetry -ScriptBlock { Get-AzVM -ResourceGroupName "rg-app-prod" }

Monitoring and Alerting: Know When Your Automation Fails

Automation is only useful if you know it's working. Azure Automation emits metrics and logs to Azure Monitor. Key metrics: Total Jobs, Failed Jobs, and Job Execution Time. Set up alerts for failed jobs and job duration anomalies. Use Log Analytics to query runbook job streams (verbose, error, etc.). Create a dashboard showing runbook health. For critical runbooks, implement a heartbeat pattern: a runbook that runs every 5 minutes and writes a timestamp to a storage table; if the timestamp is older than 10 minutes, trigger an alert. Also monitor the Automation Account's health (e.g., module import failures). Use Azure Workbooks for custom reporting. Integrate with your incident management system (PagerDuty, Opsgenie) via webhooks. Regularly review runbook logs to identify silent failures or performance degradation.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.AUTOMATION"
| where Category == "JobLogs"
| where ResultType == "Failed"
| project TimeGenerated, RunbookName_s, ResultDescription, JobId_g
| order by TimeGenerated desc
| take 10

Security Best Practices: Least Privilege, Secret Management, and Auditing

Security in Azure Automation starts with identity. Use managed identities and scope RBAC to the minimum required resources. Never assign Contributor at subscription level. Use custom roles if needed. Store secrets (API keys, passwords) in Azure Key Vault and reference them in runbooks using Get-AzKeyVaultSecret. Avoid storing secrets in encrypted variables—they are less auditable. Enable diagnostic logs for the Automation Account and send them to Log Analytics for auditing. Regularly review who has access to the Automation Account and runbooks. Use Azure Policy to enforce that Automation Accounts have managed identity enabled and that runbooks use Key Vault for secrets. For Hybrid Workers, ensure the machine is hardened and the worker account has least privilege. Rotate keys and certificates regularly. Finally, implement a change management process for runbook updates—peer review and automated testing before deployment.

param(
    [string]$KeyVaultName = "kv-automation-prod",
    [string]$SecretName = "ServicePrincipalPassword"
)

Connect-AzAccount -Identity

$secret = Get-AzKeyVaultSecret -VaultName $KeyVaultName -Name $SecretName
$secretValue = $secret.SecretValue | ConvertFrom-SecureString -AsPlainText

Write-Output "Retrieved secret: $SecretName (length: $($secretValue.Length))"

# Use the secret (e.g., for service principal authentication)
# $cred = New-Object System.Management.Automation.PSCredential("username", $secret.SecretValue)

Cost Management: Optimize Automation Spend

Azure Automation costs come from job execution time (per minute), storage (runbook content, logs), and data transfer. For production, choose the Basic tier (no free monthly minutes) to avoid limits. Optimize costs by reducing job duration: use parallel execution, avoid unnecessary API calls, and use -NoWait where possible. Delete old job logs and runbook versions. Use Hybrid Workers for long-running jobs to avoid sandbox costs (though you pay for the VM). Monitor cost with Azure Cost Management and set budgets. Consider using Azure Functions for simple, event-driven automation—they can be cheaper for low-volume tasks. However, for complex orchestration with schedules and hybrid execution, Automation Accounts are still the right choice. Regularly review runbook usage: if a runbook hasn't run in 90 days, archive or delete it.

param(
    [string]$ResourceGroupName = "rg-automation-prod",
    [string]$AutomationAccountName = "aa-prod-control",
    [int]$RetentionDays = 90
)

Connect-AzAccount -Identity

$cutoffDate = (Get-Date).AddDays(-$RetentionDays)

$jobs = Get-AzAutomationJob `
    -ResourceGroupName $ResourceGroupName `
    -AutomationAccountName $AutomationAccountName `
    -Status Completed

foreach ($job in $jobs) {
    if ($job.CreationTime -lt $cutoffDate) {
        Remove-AzAutomationJob `
            -ResourceGroupName $ResourceGroupName `
            -AutomationAccountName $AutomationAccountName `
            -Id $job.JobId
        Write-Output "Deleted job: $($job.JobId) from $($job.CreationTime)"
    }
}

Advanced Scenarios: Orchestrating Multi-Step Workflows

For complex workflows (e.g., patching followed by testing, then promotion), use Azure Automation to orchestrate multiple runbooks. Use the Start-AzAutomationRunbook cmdlet to call child runbooks and wait for completion with -Wait. Pass parameters and handle output. For parallel execution, use PowerShell Workflow's ForEach -Parallel or start multiple runbooks asynchronously and poll. Another pattern: use Azure Logic Apps or Azure Data Factory to orchestrate runbooks as part of a larger pipeline. For stateful workflows, use external storage (Azure Table Storage) to persist state between runbooks. Avoid tight coupling—each runbook should do one thing well. Use tags and naming conventions to organize runbooks. For long-running workflows, consider using durable functions instead, but if you're already invested in Azure Automation, the hybrid worker with longer timeout can handle it.

param(
    [string]$VMName = "web-server-01"
)

Connect-AzAccount -Identity

# Step 1: Stop VM
Write-Output "Step 1: Stopping VM $VMName"
$job1 = Start-AzAutomationRunbook `
    -ResourceGroupName "rg-automation-prod" `
    -AutomationAccountName "aa-prod-control" `
    -Name "Stop-VM" `
    -Parameters @{ VMName = $VMName } `
    -Wait

if ($job1.Status -ne "Completed") {
    throw "Step 1 failed"
}

# Step 2: Apply patch (simulated)
Write-Output "Step 2: Applying patches"
Start-Sleep -Seconds 10

# Step 3: Start VM
Write-Output "Step 3: Starting VM $VMName"
$job2 = Start-AzAutomationRunbook `
    -ResourceGroupName "rg-automation-prod" `
    -AutomationAccountName "aa-prod-control" `
    -Name "Start-VM" `
    -Parameters @{ VMName = $VMName } `
    -Wait

if ($job2.Status -ne "Completed") {
    throw "Step 3 failed"
}

Write-Output "Workflow completed successfully."

Update Management: Patch Orchestration with Azure Update Manager

Azure Update Manager (the replacement for the retired Automation Update Management) provides patch orchestration across Azure VMs, Arc-enabled servers, and on-premises machines. It uses the Azure Monitor Agent to assess patch compliance and apply updates. Configure maintenance configurations to schedule recurring update deployments — use UTC time and multiple schedules for different severity levels. For production, use pre/post-events to control the update window: stop the application before patching, apply updates, run health checks, then restart the service. Use dynamic scoping to target VMs by tags (e.g., 'Environment:Production', 'PatchWindow:Window1') rather than maintaining static lists. Monitor patch compliance via Azure Workbooks and set up alerts for machines that miss update windows. For critical security patches, use 'classifications' to filter by 'Critical' and 'Security' only. Enable reboot handling based on your application's tolerance: 'IfRequired', 'Never', or 'Always'. For SQL Server or Active Directory VMs, coordinate patching across availability sets to avoid simultaneous reboots. Use Azure Policy to enforce that all VMs have Update Manager enabled and are assigned to a maintenance configuration.

Connect-AzAccount -Identity

# Get update compliance for all VMs in a subscription
$vms = Get-AzVM -Status
foreach ($vm in $vms) {
    $compliance = Get-AzUpdateManagementCompliance `
        -ResourceGroupName $vm.ResourceGroupName `
        -Name $vm.Name
    
    Write-Output "$($vm.Name): $($compliance.ComplianceStatus)"
    Write-Output "  Pending critical: $($compliance.PendingCriticalUpdatesCount)"
    Write-Output "  Pending security: $($compliance.PendingSecurityUpdatesCount)"
}

Change Tracking and Inventory: Detecting Configuration Drift

Azure Change Tracking and Inventory (CTI) tracks changes to files, registry keys, software, Windows services, and Linux daemons across your VMs and Arc-enabled servers. It uses the Azure Monitor Agent with Data Collection Rules (DCRs) to collect change data. Enable CTI from your Automation account under 'Change tracking' or 'Inventory'. Configure tracking for critical files (e.g., web.config, /etc/ssh/sshd_config), registry keys (e.g., HKLM\Software\Microsoft\Windows\CurrentVersion\Run), and services. Enable file content tracking to store before/after snapshots of changed files. Review change results in the Azure portal or query them via Log Analytics (using the ConfigurationChange table). Set up alerts for configuration changes — for example, alert when a security-critical file changes or when unauthorized software is installed. Use Inventory to maintain a real-time catalog of installed software, hotfixes, and services across your fleet. For compliance, export inventory reports regularly. CTI helps detect configuration drift, unauthorized changes, and potential security incidents. For scale, enable CTI across all VMs using Azure Policy.

ConfigurationChange
| where TimeGenerated > ago(24h)
| where ChangeType == "Add" or ChangeType == "Update"
| where ConfigChangeType == "Files"
| where FileSystemPath contains "/etc/" or FileSystemPath contains "C:\\inetpub\\wwwroot"
| project TimeGenerated, Computer, FileSystemPath, ChangeType, SvcName, SvcState
| order by TimeGenerated desc
| take 20

Azure Automation State Configuration: Desired State with PowerShell DSC

Azure Automation State Configuration (DSC) enables you to define and enforce the desired state of your Windows and Linux machines using PowerShell Desired State Configuration. Write a DSC configuration, import it to your Automation account, compile it into MOF node configurations, and assign them to machines. The DSC agent on each machine periodically checks and enforces the configuration, auto-correcting drift. For production, use DSC to enforce security baselines (e.g., enable Windows Firewall, set password policies, configure audit policies), application settings (e.g., IIS configuration, registry settings), and compliance requirements. Use ConfigurationData to separate structural configuration from environment-specific settings. Store credentials securely using Get-AutomationPSCredential. Import modules from the PowerShell Gallery to extend DSC resources. Important: Azure Automation State Configuration will be retired on September 30, 2027 — plan migration to Azure Machine Configuration (Azure Policy guest configuration). Machine Configuration uses DSC v3 with PowerShell 7, supports Arc-enabled servers, and integrates with Azure Policy for at-scale compliance. Start your migration by exporting existing configurations, re-authoring for DSC v3, and testing in a non-production environment.

Configuration WebServerConfig {
    param([string[]]$NodeName = 'localhost')
    
    Import-DscResource -ModuleName PsDesiredStateConfiguration
    Import-DscResource -ModuleName xWebAdministration
    
    Node $NodeName {
        WindowsFeature IIS {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }
        
        File WebContent {
            Ensure          = 'Present'
            Type            = 'Directory'
            DestinationPath = 'C:\inetpub\wwwroot\MyApp'
        }
        
        xWebSite DefaultSite {
            Ensure          = 'Present'
            Name            = 'Default Web Site'
            State           = 'Started'
            PhysicalPath    = 'C:\inetpub\wwwroot\MyApp'
            DependsOn       = '[File]WebContent'
        }
    }
}

# Compile and assign via Azure Automation