Azure Automation: Letting the Cloud Do the Repetitive Work for You
A complete, plain-English guide to Azure Automation: accounts, runbooks, schedules, webhooks, hybrid workers, managed identities, shared resources, source control, monitoring, security, cost, and the retired and replaced features you must know about before you design anything new.
Picture a hotel at the end of every day. Someone must lock the side doors, switch off lights in empty conference rooms, turn down the heating in unused wings, restock the minibars, and write a report for the manager. If a human does this by hand, it takes hours, it is boring, and sooner or later a door is forgotten. Now imagine a trusted night manager who follows a written checklist, runs it at exactly the same time each night, never forgets a step, and leaves a signed record of everything done. Azure Automation is that night manager for your cloud.
This guide assumes you know nothing about cloud automation. Every new term is explained the first time it appears, together with an everyday comparison. We then go deep: what an automation account is, how runbooks run, how they prove who they are, how they reach private networks, how they are scheduled and triggered, how they are monitored and secured, and how to keep cost under control. Azure Automation has changed a lot in recent years, with several features retired or replaced, so wherever details may have moved we say so and ask you to confirm with the official documentation before designing anything new.
1Why Automation Matters and What Azure Automation Is
Anything a person does the same way more than a few times is a candidate for automation.
The cost of doing it by hand
Cloud environments contain hundreds or thousands of resources: virtual machines, databases, storage accounts, networks. Operating them involves endless routine jobs. Start the test servers each morning and stop them each night. Remove unused disks. Apply tags to new resources. Rotate keys. Create reports. Restart a stuck service. Done manually, these jobs consume skilled people’s time, produce inconsistent results, and fail silently when someone is on holiday. Worse, manual work is hard to audit, because nobody remembers exactly what was typed.
Automation means writing the steps down once, in a form that a computer can follow, and letting the computer do it on a schedule or whenever something happens. Azure Automation is Microsoft’s cloud service for exactly this. It gives you a managed place to store scripts, run them reliably, schedule them, trigger them from other systems, keep their history, and control who can do what.
A recipe card pinned in a restaurant kitchen makes every cook produce the same dish. Azure Automation is the kitchen where the recipe cards live, along with the clock that tells the cook when to start, the logbook of every dish prepared, and the lock on the recipe cabinet.
The three main areas, in simple terms
Process automation
Runbooks: scripts that carry out tasks, such as starting machines, tagging resources or calling other systems. This is the heart of the service and the main subject of this guide.
Configuration management
Keeping machines in a desired state and tracking what is installed and what changes. Several features in this area have moved to newer Azure services, covered later.
Update management
Patching operating systems on many machines. The original feature here has been replaced by a newer service, explained in a later chapter.
Azure Automation has been through several retirements and replacements, including older credential accounts, older patching and inventory features, older agents, and certain language versions. This guide was written from memory without a live search. Before building, confirm the current status of any feature named here on the official Azure documentation and the Azure updates page.
2The Automation Account: Your Control Room
Everything in Azure Automation lives inside one container called an automation account.
An automation account is the top-level resource you create in a subscription and region. It holds your runbooks, schedules, variables, credentials, certificates, connections, modules, webhooks, hybrid worker groups, and the history of every job. It is also the security boundary: access is granted to the account, and the account has an identity that its runbooks use when they touch other Azure resources.
flowchart TD
AA["Automation account"] --> RB["Runbooks"]
AA --> SC["Schedules"]
AA --> WH["Webhooks"]
AA --> SR["Shared resources: variables, credentials, certificates, connections, modules"]
AA --> HW["Hybrid worker groups"]
AA --> ID["Managed identity"]
AA --> JB["Job history and logs"]
AA --> SCM["Source control links"]
Choices you make when creating one
| Choice | What it means | Advice |
|---|---|---|
| Subscription and resource group | Where the account is billed and managed | Place it in a resource group dedicated to operations tooling, with clear naming |
| Region | Where the account’s data and the cloud execution environment are tied | Choose a region near the resources it manages and that satisfies data rules |
| Managed identity | The identity runbooks use to sign in to Azure | Enable a system-assigned identity, or attach a user-assigned identity if several accounts share one |
| Networking | Whether access is public or through private endpoints | Use private access where company rules demand it, and plan DNS carefully |
| Tags | Labels for ownership and cost | Always tag with owner, environment and cost center |
The automation account is the night manager’s office: it holds the checklists, the keys cabinet, the schedule on the wall, the logbook and the manager’s own staff badge. Everything the night manager does happens from within that office.
Do not put every automation of every team into one account. Separate accounts by environment and by team. This limits the blast radius of a mistake, keeps permissions simple and makes cost easy to attribute.
3Runbooks: The Heart of the Service
A runbook is a saved set of instructions that Azure Automation can run for you.
The word comes from operations teams, who keep “run books”: documents describing how to carry out routine tasks. In Azure Automation a runbook is the same idea but executable. It might stop a group of virtual machines, check for untagged resources, call a company web service, or collect a report and send it by email.
Types of runbook
PowerShell runbook
The most common type. Written in PowerShell, the scripting language long used for managing Microsoft systems. Newer runtime versions are available, so check which versions are currently supported.
Python runbook
Written in Python, popular for data and integration tasks. Older Python versions have been retired, so confirm the supported versions.
Graphical runbook
Built by dragging and connecting blocks in the portal, without writing code. Friendly for beginners, harder to review and version.
PowerShell Workflow runbook
An older style supporting checkpoints and parallel steps. Generally kept for existing needs; newer designs favor other approaches.
| Need | Good choice | Why |
|---|---|---|
| Manage Azure resources in a team that knows PowerShell | PowerShell runbook | Rich Azure command set and large community |
| Process data or call many web services | Python runbook | Strong libraries for data and web calls |
| Quick simple task by a non-programmer | Graphical runbook | Visual building blocks |
| Long, complex orchestration across many steps | Consider other services, such as workflow or function services | Better tools for long-running or event-heavy logic |
Runbook lifecycle: draft, test, publish
Every runbook has two versions at the same time. The draft is your working copy that you can edit and test. The published version is the one that schedules, webhooks and other runbooks actually use. You edit the draft, test it in the test pane, then publish it. This protects live automation from half-finished changes. Publishing replaces the live version with the draft.
Create
Choose the type, name and description. Name by purpose and scope, for example by the resource it acts on and the verb.
Edit the draft
Write or paste the steps. Define input parameters so the runbook can be reused with different values.
Test
Run the draft in the test pane against a non-production target. Read the output and errors carefully.
Publish
Make the draft the live version. Existing links such as schedules start using it.
Run, monitor and improve
Start jobs, read their history, and refine the runbook as needs change.
A draft and a published runbook are like a rehearsal script and the final script handed to the actors. You can scribble and experiment on the rehearsal copy, and only when you are happy do you replace the one the live show depends on.
Testing a destructive runbook against production because “it is just a test run”. The test pane performs real actions. Always point test runs at a safe target, or build in a “what-if” or dry-run input that reports what would change without changing it.
4Jobs and Execution: What Happens When a Runbook Runs
A runbook is the recipe; a job is one cooking session.
Each time a runbook starts, Azure Automation creates a job. The job records who or what started it, the input values, the status, the output streams and the start and end times. You can have many jobs of the same runbook at the same time, each with its own inputs and history.
stateDiagram-v2
[*] --> New
New --> Queued
Queued --> Starting
Starting --> Running
Running --> Completed
Running --> Failed
Running --> Suspended
Running --> Stopped
Suspended --> Running
Completed --> [*]
Failed --> [*]
Stopped --> [*]
Where does the job actually run?
A job runs in one of two places. In the cloud, it runs in a sandbox: a temporary, isolated environment managed by Microsoft, created for the job and thrown away afterwards. You do not manage servers. Alternatively, it runs on a hybrid worker, which is a machine of your own, in your datacenter or in another cloud, that has been registered to take jobs. Hybrid workers are covered in a later chapter.
Output stream
The results the runbook returns. Useful when another runbook or a person consumes the result.
Error and warning streams
Messages about problems. Errors can fail the job depending on how the runbook is written.
Verbose and progress streams
Detailed diagnostic messages that you can switch on to learn more when troubleshooting. They increase log volume and cost, so use them sparingly.
A job is a single delivery trip by a courier following the route card, which is the runbook. The cloud sandbox is a rented van that exists only for that trip. A hybrid worker is your own van, parked in your own yard, driving into places the rented van cannot enter.
Limits you should respect
Cloud sandboxes are shared and designed for short jobs. They apply a fair share limit: a job that runs for too long is unloaded and restarted from the beginning, which can repeat actions and cause trouble if the runbook is not designed for it. There are also limits on memory, the number of concurrent jobs, the size of output and the total job minutes. Exact numbers change, so check current documentation. For very long tasks, either break the work into smaller pieces that are chained together, use checkpoints where the runbook type supports them, or move the work to a hybrid worker or to a different service built for long-running processes.
Problem
A single huge runbook loops over thousands of resources for hours in a cloud sandbox, with no checkpoints and no record of progress.
Why It’s Harmful
When the sandbox is recycled, the job restarts from the start and repeats work, possibly sending duplicate notifications or modifying resources twice.
Correct Approach
Split the work into small, repeatable jobs, record progress outside the job, and make each step safe to run again with the same result.
5Identity: How a Runbook Proves Who It Is
A runbook that changes resources must sign in, just like a person, and what it can do depends on the identity it uses.
Managed identity: the recommended way
A managed identity is an identity that Azure creates and looks after for a resource. Nobody ever sees or types a password. An automation account can have a system-assigned managed identity, tied to the account and removed when it is deleted, or one or more user-assigned managed identities, which are separate resources that you can share across several accounts and keep when an account is deleted.
sequenceDiagram
participant RB as Runbook job
participant MI as Managed identity
participant ENTRA as Microsoft Entra ID
participant RES as Azure resource
RB->>MI: Request to sign in
MI->>ENTRA: Ask for an access token
ENTRA-->>MI: Token for the identity
MI-->>RB: Token
RB->>RES: Call with token
RES-->>RB: Allowed only if the identity has a role
A managed identity is a staff badge issued by the building itself. The guard at each door checks the badge and the door list. The employee never carries a password that could be copied or lost, and when the employee leaves, the badge is simply cancelled.
Granting only what is needed
An identity can do nothing until it is given roles. A role assignment says who can do what on which scope, where the scope might be a subscription, a resource group or a single resource. Give each automation account’s identity the narrowest role on the narrowest scope that lets its runbooks do their job. A runbook that only starts and stops virtual machines needs a role that allows that, on the resource group holding those machines, not full ownership of the subscription.
| Identity method | Status | Comment |
|---|---|---|
| System-assigned managed identity | Recommended | Simple, one per account, lifecycle follows the account |
| User-assigned managed identity | Recommended | Shareable, survives account deletion, fits shared role design |
| Run As account | Retired | The older approach using a certificate and app registration. It reached end of support and must be replaced by managed identities |
| Stored credentials | Allowed but discouraged | A stored username and password; needed only for systems that cannot use modern identity |
Older automation accounts may still have Run As accounts, and older scripts may sign in using them. Microsoft retired Run As accounts, so such scripts need to be moved to managed identities. Confirm the current guidance and your account’s state in the portal, and test every runbook after migration.
Problem
The automation account’s identity is given the Owner or Contributor role on the entire subscription “to make sure scripts always work”.
Why It’s Harmful
Any person who can edit a runbook can effectively do anything in the subscription. A mistaken script or a compromised account can delete everything.
Correct Approach
Create focused roles on small scopes and use separate accounts or identities for separate duties.
6Shared Resources: Variables, Credentials, Certificates, Connections and Modules
Reusable building blocks, kept outside the runbooks so scripts stay clean.
Variables
Named values such as a subscription name, a threshold or an email address. Change the value once and all runbooks use it. Variables can be encrypted for sensitive values.
Credentials
A stored username and password for systems that need them. Encrypted, and readable only by runbooks inside the account.
Certificates
Stored certificates for signing in to services that require them.
Connections
A bundle of values needed to connect to an external system, such as an identifier and a certificate reference.
Modules
Packages of commands that runbooks can use, such as the commands for managing Azure resources. You can import your own modules and keep versions up to date.
Runtime environments
A newer way to bundle a language version with a chosen set of module versions, so that different runbooks can use different versions safely side by side.
Shared resources are the pantry and the tool drawer of the kitchen. The recipe says “add the house sauce” and “use the whisk” without copying the sauce recipe or forging a new whisk every time. If the house sauce changes, every dish that uses it changes automatically.
Secrets belong in a secret store
Automation can hold encrypted variables and credentials, but for important secrets such as database passwords and API keys, a dedicated secret store such as Azure Key Vault is usually a better home. Key Vault adds fine-grained access, versioning, rotation and auditing. A runbook can use its managed identity to read the secret at run time, so that no secret is stored in the automation account or in the script.
Module versions: a quiet source of breakage
Automation accounts include some default modules, and you can import newer versions. Updating a module changes the behavior of every runbook that uses it. Because commands can change between versions, an update may silently break a runbook that worked for years. Use runtime environments or controlled imports, test runbooks after updates, and record which versions each runbook was tested with.
Updating all modules to the latest versions on a Friday afternoon without testing. Updates can rename or remove commands. Test in a non-production account first and update in a planned window.
7Starting Runbooks: Manual, Schedules, Webhooks and Triggers
A runbook that nobody starts does nothing. There are several ways to wake it up.
flowchart LR
A["Person in portal or command line"] --> R["Runbook"]
B["Schedule"] --> R
C["Webhook from another system"] --> R
D["Azure alert through an action group"] --> R
E["Another runbook"] --> R
F["Workflow or pipeline"] --> R
G["Watcher task detecting an event"] --> R
R --> J["Job"]
Schedules
A schedule tells Automation to start a runbook at set times: once, hourly, daily, weekly or monthly, in a chosen time zone. A single schedule can be linked to many runbooks, and a runbook can have many schedules, each with its own input values. Schedules are the right tool for predictable work, such as nightly shutdown of test machines or a weekly report. Keep in mind that the minimum frequency is limited, so for something that must happen every few minutes you may need a different design. Also remember daylight saving changes when choosing a time zone, and avoid scheduling many jobs at exactly the same minute, since this creates a burst of load and a delayed start.
Webhooks
A webhook is a special web address that starts a runbook when something calls it. The calling system can pass data to the runbook. Webhooks let outside tools trigger automation: a chat message, a ticket in a help desk tool, a build pipeline, a monitoring product. The address contains a secret token that is shown only once when you create it, so the address itself acts like a password. Store it in a secret store, give each webhook an expiry date, and rotate it regularly.
Alerts and event-based triggers
An Azure Monitor alert can use an action group to start a runbook automatically, enabling self-healing: a disk fills up, the alert fires, the runbook cleans temporary files and posts the result. Events from other Azure services can also start runbooks, often through an event routing service or a lightweight workflow service that calls the webhook.
Watcher tasks
A watcher task is a pair of runbooks: one that checks for a condition repeatedly, and another that acts when it is found. It is meant for simple event detection at short intervals, such as noticing a new file. Confirm its current status and consider whether a dedicated event service would serve you better.
| Trigger | Best for | Watch out for |
|---|---|---|
| Manual | On-demand tasks, emergency actions | Needs access control, otherwise anyone can start sensitive jobs |
| Schedule | Predictable recurring jobs | Time zones, daylight saving, bursts at common times such as midnight |
| Webhook | Integration with external tools | The address is a secret; expiry and rotation are essential |
| Alert and action group | Self-healing and incident response | Runaway loops if the action does not actually fix the cause |
| Another runbook | Building large processes from small parts | Failure handling across parent and child jobs |
A schedule is an alarm clock. A webhook is a doorbell that anyone with the right address can ring. An alert is a smoke detector that calls the fire team. All three wake the same night manager, but for different reasons.
Pasting a webhook address into a chat channel or a public repository. Anyone who finds it can start your runbook. Treat it exactly like a password, and rotate it immediately if it leaks.
8Input Parameters, Child Runbooks and Composition
Small, reusable, well-named runbooks beat giant scripts.
Parameters
Parameters are the inputs of a runbook, such as the name of a resource group, the action to take, or whether to run in dry-run mode. They make one runbook usable in many situations: the same “stop machines” runbook can be linked to different schedules for different groups. Give parameters clear names, set safe defaults, and validate them at the start of the runbook so that a typo is caught before anything is changed.
Child runbooks
A runbook can start another runbook, called a child. This allows you to build complex processes from small, tested building blocks, such as a “write a log entry” runbook or a “send a notification” runbook that many parents share. A child can be run inline, where the parent waits for it, or as a separate job started independently. Choose carefully: inline children are simpler to reason about, while separate jobs allow parallel work but make error handling more complex.
flowchart TD
P["Parent runbook: nightly cleanup"] --> C1["Child: find untagged resources"]
P --> C2["Child: stop idle machines"]
P --> C3["Child: delete old snapshots"]
C1 --> N["Child: send summary notification"]
C2 --> N
C3 --> N
A large recipe such as a wedding feast is not one giant card. It references smaller cards: how to make the sauce, how to cook the rice, how to plate the dessert. Each small card can be tested, improved and reused for other meals.
Make every runbook idempotent whenever possible. Idempotent means that running it twice has the same effect as running it once. “Ensure the machine is stopped” is idempotent; “toggle the machine” is not. Idempotent runbooks are safe to retry after a failure.
9Hybrid Runbook Workers: Reaching Beyond the Cloud Sandbox
Some work must happen on your own machines, inside your own network.
Cloud sandboxes are in Azure’s shared environment and cannot reach private systems that are not exposed to the internet, such as an on-premises database, a server behind a firewall, or an application inside a private virtual network. A hybrid runbook worker is a machine you control that is registered to an automation account and picks up jobs from it. The machine can be in your datacenter, in another cloud provider, or in Azure. It makes an outbound connection to Azure Automation, so no inbound firewall hole is needed.
flowchart LR
AA["Azure Automation service"] -->|Job assignment, outbound connection from worker| HW["Hybrid worker machine"]
HW --> DB["On-premises database"]
HW --> APP["Private application server"]
HW --> FS["Internal file share"]
HW -->|Job status and output| AA
Worker groups
Workers are placed in hybrid worker groups. When you start a runbook you choose the group to run it on, and Automation hands the job to one of the workers in that group. A group with several machines gives you resilience: if one worker is down, another takes the job. Use separate groups for different networks and security zones.
| Model | How it works | Status and advice |
|---|---|---|
| Extension-based worker | Installed as a virtual machine extension, or through the Azure Arc extension for machines outside Azure; uses managed identity and modern authentication | The current model; use it for all new workers |
| Agent-based worker | Older model relying on the Log Analytics agent | Retired; existing workers should be migrated to the extension-based model |
A hybrid worker is a trusted local agent stationed inside a secure compound. The head office never needs to open the gate to outsiders; the local agent phones the head office to ask whether there is any task, then performs it from the inside.
Securing and operating workers
Treat it as a powerful server
A worker runs scripts with the permissions of its account. Harden it, patch it, restrict who can sign in, and monitor it as you would any sensitive server.
Use dedicated machines
Avoid running workers on busy shared application servers. Jobs consume memory and processor and may interfere with other workloads.
Plan for high availability
Put at least two workers in each important group, in different failure zones where possible.
Control scripts that run locally
Where supported, require signed scripts or limit which runbooks may run on a worker, so that someone with portal access cannot run arbitrary commands on a sensitive server.
The agent-based worker model was retired and replaced by the extension-based model. Confirm supported operating systems, language runtimes, Azure Arc requirements and network endpoints on the current documentation before deployment, since these change.
10Typical Use Cases for Runbooks
What organizations most often automate.
Start and stop virtual machines on a schedule
Development and test machines run only during working hours. A schedule starts them in the morning and stops them in the evening and on weekends, which saves a large share of compute cost.
Enforce tagging and governance
A runbook scans for resources without an owner tag, tags them from a lookup, or notifies a team. Governance becomes continuous rather than a yearly audit.
Clean up unused resources
Detached disks, old snapshots, unused public addresses and empty resource groups are found and removed, or flagged for review after a grace period.
Self-healing from alerts
When monitoring detects a stopped service or a full disk, an alert starts a runbook that applies the standard fix and posts the result to the incident record.
Scale resources up and down
Database tiers or application plans are scaled up before a busy period and down afterwards, according to a schedule or demand signals.
Onboarding and offboarding
A request in a ticketing tool triggers a webhook that creates accounts, assigns access groups and prepares a workspace, with every step logged for audit.
Reporting and housekeeping
Weekly inventories, cost summaries, certificate expiry reports and backup checks are collected and sent to the right people automatically.
Secret and key rotation helpers
A runbook renews credentials near expiry, updates the secret store and restarts the dependent applications in order.
All of these are the building’s routine chores: lights, locks, cleaning, restocking and reports. Each is simple, repetitive, and costly if forgotten, which makes them ideal for a tireless night manager.
Start with the chore that wastes the most money or causes the most late-night pages. A quick win, such as shutting down idle test machines, funds and justifies the automation effort for everything else.
11Source Control, Versioning and Deployment Pipelines
Scripts that run production are code. Treat them like code.
Editing runbooks directly in the portal is quick but risky: there is no review, no easy history and no way to rebuild the setup elsewhere. Azure Automation can link an account to a source control repository, so that runbooks stored in a folder of the repository are synchronized into the account. Supported systems include popular hosted code repositories and Azure’s own repository service. A sync can be manual or automatic when changes are pushed.
flowchart LR
DEV["Developer"] --> PR["Pull request and review"]
PR --> MAIN["Main branch"]
MAIN --> PIPE["Pipeline: validate and test"]
PIPE --> DEVAA["Dev automation account"]
PIPE --> PRODAA["Production automation account after approval"]
Keep runbooks in a repository
One folder per area, with clear names and a short readme describing purpose, inputs and required permissions.
Require review of changes
Another person reads every change to a production runbook, as with application code.
Test automatically
Use static checks and run tests against a non-production account in the pipeline.
Deploy the infrastructure and runbooks together
Define the automation account, schedules, identities and role assignments as infrastructure templates so environments are identical.
Disable portal editing in production
Restrict who can edit directly, so that the repository stays the single source of truth.
Source control is the master binder of recipe cards kept in the head office, with a record of who changed which card and why. The kitchen copies are printed from the binder, so no cook can quietly scribble a new ingredient on the wall card.
Having both automatic sync from a repository and people editing in the portal. The next sync silently overwrites the portal edits. Choose one source of truth and enforce it.
12Monitoring, Logging and Alerting on Automation Itself
Automation that fails silently is worse than no automation, because everybody assumes it works.
Job history and streams
The portal shows every job with its status, duration, inputs and output streams. Job data is kept for a limited period, so for long-term analysis, send it elsewhere.
Sending logs to Azure Monitor
You can connect the automation account to a Log Analytics workspace through diagnostic settings. Job status, job streams and, where enabled, audit information flow into the workspace. There you can query them, build workbooks, and create alerts when jobs fail, are suspended, or stop running when they should.
flowchart LR
AA["Automation account"] --> DS["Diagnostic settings"]
DS --> LA["Log Analytics workspace"]
LA --> AL["Alert rules"]
AL --> AG["Action group"]
AG --> T["Team channel or incident tool"]
LA --> WB["Workbook for job health"]
Job failed
Alert when a specific important runbook ends with a failed or suspended status.
Job did not run
Alert on the absence of a successful completion in the expected window. This catches broken schedules, expired links and disabled accounts.
Job took unusually long
Compare duration with normal. A sudden increase may indicate throttling, a slow dependency or a hung task.
Worker offline
Alert when a hybrid worker has stopped checking in, before jobs begin to queue.
If the night manager must sign a log after each task, the day manager reads the log in the morning. The most important entry is not “all done” but a missing signature, which shows that something never happened.
Make runbooks write clear, short, human-readable messages about what they did, with counts and names of affected resources. Good messages turn a mysterious failure at three in the morning into a five-minute fix.
Turning on verbose and progress streams for every runbook forever. This inflates log volume and cost. Switch them on only while troubleshooting.
13Error Handling, Retries and Safe Design
Real systems fail in small, boring ways. Good runbooks expect it.
Validate inputs first
Check that names exist and values are in range before changing anything.
Treat errors as stopping conditions
Configure the runbook so that a serious error stops the job and marks it failed, instead of continuing and hiding the problem.
Retry with patience
Transient problems such as brief network failures often clear in seconds. Retry a few times with increasing waits, then give up and report.
Make actions repeatable
Design so that running again after a half-finished attempt is safe.
Report clearly
On completion, say what was done, what was skipped and what failed, with names and counts.
Add safety brakes
For destructive jobs, add a dry-run mode, a maximum number of items allowed per run, and an exclusion tag that protects critical resources.
A careful electrician switches off the power, checks that it is off, labels the switch and then works, leaving a note when finished. Good runbooks follow the same careful order, because they act on many things at once and mistakes scale quickly.
Problem
A cleanup runbook deletes anything older than a number of days across a whole subscription, with no dry run, no exclusions and no limit.
Why It’s Harmful
A wrong filter, a changed naming convention or an unexpected empty list can remove important resources in seconds, and the deletion is repeated every night.
Correct Approach
Start with report-only mode, add exclusion tags, cap the number of deletions per run, require a grace period and send a summary before and after.
14Security: Who May Edit, Run and See Secrets
An automation account is a powerful robot. Whoever can instruct it holds some of its power.
Role-based access control
Azure provides roles for the account itself. Some people may only view, some may start jobs, some may author runbooks, and a few may manage the entire account. Remember that someone who can edit and run a runbook effectively inherits the permissions of the account’s identity, so granting authoring rights is as serious as granting those permissions directly.
| Role purpose | Who needs it | Risk if too broad |
|---|---|---|
| Reader | Support and audit teams | Low, but check that logs do not reveal secrets |
| Job operator | Operations staff who start and stop jobs | Can trigger actions with the account’s power |
| Runbook operator | People who read and start runbooks without editing | Limited, but still triggers actions |
| Contributor or author | Automation engineers | Can change what runs with the account’s identity |
| Owner | A very small number of administrators | Can reassign access and change identity settings |
Network isolation
By default, an automation account is reachable through public endpoints, protected by authentication. For tighter control, private endpoints let you reach the account from a private network and turn off public access. Plan for hybrid workers, deployment pipelines and administrators, who must also be able to reach the account privately. Because the details and supported scenarios have been changing, check the current network isolation documentation.
Protecting data and secrets
Encryption
Account data is encrypted at rest by default, and an option for customer-managed keys is available for stricter policy requirements.
Secret store
Keep sensitive values in Key Vault and read them at run time through managed identity.
Output hygiene
Never write passwords, tokens or personal data into output streams; they are stored in job history and logs.
Activity logging
Send the account’s activity log and audit logs to a workspace to record who changed a runbook, schedule or permission.
Policy and locks
Use governance policy to enforce settings, and resource locks to prevent accidental deletion of the account.
Whoever can write on the night manager’s checklist can make the night manager do almost anything. So the right to edit the checklist, not just the right to hold the master key, must be tightly guarded and recorded.
Problem
A large group of developers has author rights on a production automation account whose identity can modify production networks and databases.
Why It’s Harmful
Any member can use the runbook editor to run commands with powers they were never given directly, bypassing approvals and review.
Correct Approach
Limit authoring in production to a small group, deploy through a reviewed pipeline, and log every change.
15Update Management and Its Replacement
Keeping operating systems patched is one of the most important chores of all.
Patching means installing security and quality updates on operating systems. Doing it on many machines by hand is slow and error-prone. Azure Automation originally offered an Update Management feature that assessed missing updates and installed them on schedules, relying on an agent and Log Analytics. That feature has been retired and replaced by Azure Update Manager, a separate Azure service that works natively with Azure virtual machines and, through Azure Arc, with machines elsewhere, without needing an automation account for the core function.
| Capability | Old approach | Newer approach |
|---|---|---|
| Assessment of missing updates | Automation Update Management with an agent | Azure Update Manager, with periodic assessment |
| Scheduled installation | Update deployments tied to an automation account | Maintenance configurations and schedules |
| Non-Azure machines | Agent connected to a workspace | Azure Arc enabled servers |
| Reporting | Workspace queries | Built-in views and workspace data |
The old patching feature was a dedicated repair crew attached to the night manager’s office. The new service is a full maintenance department of its own, which can still be called by the night manager when a job needs a runbook in front or behind it.
If you still run the older Update Management feature, plan the migration now and confirm retirement status and migration guidance. For new designs, use the newer patching service, and use runbooks only for pre- and post-patching tasks such as notifying teams or draining traffic.
16Change Tracking, Inventory and State Configuration
Knowing what is installed, what changed, and what should be true on a machine.
Change Tracking and Inventory
This feature records what software, services, files and registry settings exist on machines and reports changes over time. It answers questions such as “what changed on this server before the outage”. It has been moved off the older agent to the newer Azure Monitor Agent, and its management has been shifting toward newer experiences. Check the current setup instructions before enabling it.
State Configuration
State Configuration, built on Desired State Configuration, lets you describe how a machine should look, for example which features are installed and which services run, and have machines compare themselves with that description and correct drift. Microsoft has been steering customers toward Azure Machine Configuration, part of Azure Policy, as the successor and has announced retirement of the automation-based version. Treat any new design with caution here and confirm dates.
Change Tracking and Inventory
Visibility: what is there and what changed. Check agent requirements and the current setup path.
State Configuration
Enforcement: keep machines matching a description. Being replaced by a policy-based service; avoid starting new designs on it.
Azure Machine Configuration
Audits and optionally enforces settings inside machines through Azure Policy, at scale, for Azure and Arc enabled machines.
Inventory is a photograph of every room. Change tracking is the album of before and after photos. State configuration is the housekeeper with a checklist who puts anything moved back where it belongs.
This is one of the most fast-moving corners of Azure Automation. Verify retirement dates, agent requirements and migration paths on the official site before choosing any configuration management approach.
17Start/Stop VMs During Off-Hours and Other Packaged Solutions
Some chores are so common that Microsoft ships ready-made solutions for them.
The best-known packaged solution turns virtual machines off outside working hours and back on in the morning. An earlier version was built on Automation runbooks and the Log Analytics agent. It has been retired and replaced by a newer version built on other Azure services, such as functions and workflow tools, which you deploy separately and configure with schedules and lists of machines. The newer version offers sequencing, tags, and notifications.
flowchart TD
S["Schedule at end of day"] --> F["Start/Stop solution"]
F --> Q["Find machines by resource group or tag"]
Q --> X{"Excluded by tag?"}
X -->|Yes| K["Skip"]
X -->|No| ST["Stop the machine"]
ST --> N["Send summary notification"]
K --> N
Savings estimate
A machine used only during weekday working hours runs roughly a quarter of the week. Turning it off for the rest can reduce its compute charges considerably. Remember that disks and some other components continue to cost money even while a machine is stopped, so make sure the machine is deallocated rather than only shut down inside the operating system.
Leaving all the lights on in an empty office all night costs money for nothing. A timer on the switches is cheap, but you must remember to exclude the server room and the security desk.
Use tags to mark which machines are included or excluded, and review the exclusion list periodically. A forgotten exclusion silently wastes money, and a wrongly included production machine causes an outage.
18Automation Compared with Other Azure Services
Azure offers several ways to automate. Choosing the right one saves pain.
| Service | Strength | Weakness | Choose when |
|---|---|---|---|
| Azure Automation runbooks | Scripts for operations, strong identity integration, hybrid workers, schedules, history | Limits on job length and rates, script-centered, less suited to complex event flows | Operational tasks on Azure and hybrid resources written in PowerShell or Python |
| Azure Functions | Event-driven code, many languages, fast scale, fine-grained triggers | More developer effort, no built-in operations catalog | Application-style code reacting to events at scale |
| Logic Apps | Low-code workflows with many connectors to business tools | Heavy scripting is awkward, pricing by actions | Business process integration and approvals across many services |
| Pipelines in a DevOps tool | Build and deployment orchestration, approvals, history | Not designed for scheduled operations in production | Deploying infrastructure and applications |
| Infrastructure templates | Declarative, repeatable resource creation | Describes state, not procedures | Creating and updating resources predictably |
| Azure Policy | Continuous compliance with automatic remediation | Limited to supported policy effects | Enforcing rules such as required tags or allowed locations |
| Azure Update Manager | Purpose-built patching | Only patching | Operating system updates at scale |
Choosing among these is like choosing among a caretaker, a courier, a business secretary, a construction crew, a building inspector and a maintenance contractor. They all “do things”, but each is best at a particular kind of job, and good organizations use several together.
Combining services is normal. A common pattern: an alert starts a workflow, the workflow asks a manager for approval, and then calls an Automation webhook to carry out the operation on a private network through a hybrid worker.
19Cost and Limits
Automation is inexpensive compared with the work it replaces, but not free.
Process automation is generally billed by job run time, measured in minutes, with a small monthly free allowance. Additional charges apply for watcher tasks, for features such as configuration management on non-Azure machines, and for the data you send to monitoring. Hybrid worker jobs have been priced differently from cloud jobs, so check current pricing. Prices and free amounts change, so confirm the numbers on the current pricing page before budgeting.
Job minutes
Long-running jobs and frequent schedules add up. Waiting for something to finish counts as run time.
Logging volume
Verbose output sent to Log Analytics is billed by the amount of data stored.
Hybrid worker machines
The servers you run for workers have their own compute, licensing and maintenance cost.
Related services
Key Vault operations, private endpoints, and workflow or function services used alongside Automation.
Avoid waiting inside jobs
Instead of sleeping while a long operation finishes, start the operation and schedule a follow-up check.
Right-size the schedule
Run jobs only as often as the business needs. Hourly is not better than daily if daily is enough.
Control log verbosity
Keep default streams lean and enable detailed ones only briefly.
Measure the savings
Track what automation saves, such as machine hours switched off and manual hours avoided, to show its value.
The night manager is paid by the hour. An efficient manager finishes the checklist quickly and goes home; one who stands waiting for the kettle to boil on every task runs up the wage bill for nothing.
Writing a runbook that polls in a tight loop for hours, waiting for something to happen. It burns job minutes and risks being unloaded. Use events, alerts or a periodic short check instead.
20Reliability, Regions and Disaster Recovery
The robot that fixes your outages must survive them.
An automation account lives in one region. Its content, such as runbooks and schedules, is stored with that region’s resilience features, but if the entire region has a serious problem, the account may be unavailable. Planning for this means keeping everything needed to recreate the account elsewhere, and deciding which automations are critical in a disaster.
flowchart LR
REPO["Repository with runbooks and templates"] --> A1["Primary region automation account"]
REPO --> A2["Secondary region automation account"]
A1 --> RES1["Resources in primary region"]
A2 --> RES2["Resources in secondary region"]
A2 -.->|Used during failover or regional outage| RES1
Everything as code
Keep runbooks, schedules, variables structure and role assignments in templates and repositories so a new account can be built in minutes.
Secondary account
For critical operations, keep a prepared account in another region with schedules disabled, ready to enable when needed.
Do not depend on one worker
Have several hybrid workers in more than one location in each group.
Practice the failover
Test building and activating the secondary account, and record how long it takes.
A fire brigade whose station burns down in the same fire is useless. Keep a second station with copies of the maps and procedures, in another part of town, and rehearse driving the trucks there.
Avoid making your recovery process depend on the very thing that failed. If the disaster-recovery runbooks need the primary region’s automation account to start, they will not be there when you need them most.
21Troubleshooting Common Problems
A checklist for the most common reasons things do not work.
| Symptom | Likely cause | What to check |
|---|---|---|
| Runbook fails with an authorization error | Identity lacks a role on the target scope, or a role assignment has not taken effect yet | Review role assignments of the account’s identity; allow a few minutes after changes |
| Sign-in command fails | Script still uses retired Run As method, or managed identity not enabled | Confirm identity is enabled and the script uses the managed identity sign-in |
| Command not found | Module missing or wrong version in the runtime | Check imported modules and the runtime environment selected for the runbook |
| Schedule did not start the runbook | Schedule disabled or expired, runbook not published, time zone mix-up | Check schedule status, next run time, and that the published version exists |
| Job suspended | An unhandled error stopped the job, or a checkpoint-based run was interrupted | Read the error stream and job exceptions |
| Job restarts or stops after long run | Fair share limit reached | Split into smaller jobs or move to a hybrid worker |
| Job stays queued on hybrid worker | Worker offline, group empty, network access blocked | Verify worker status, connectivity and group membership |
| Webhook returns an error | Expired or regenerated token, wrong address, runbook unpublished | Check expiry, recreate the webhook, verify the target runbook |
| Cannot reach a private resource from the cloud | Cloud sandbox cannot reach private network | Use a hybrid worker, or configure supported private access |
| Output truncated or missing | Output size limits or streams not enabled | Write summaries, send large results to storage rather than output |
When the night manager did not finish the checklist, ask in order: did they have the key to that room, did they have the right tools, did the alarm clock ring, and was the van able to reach the building. Most failures fall into these four questions.
Always read the job’s exception and error stream before changing anything. The first error message is usually the real one; later messages are just consequences of it.
22Patterns and Anti-Patterns
Habits that make automation trustworthy, and habits that turn it into a liability.
Patterns worth adopting
One account per environment and team
Separate development, test and production, and separate teams with different responsibilities. Smaller accounts mean smaller risk and clearer ownership.
Managed identity with least privilege
Every runbook uses an identity that can do only what it needs, on the smallest scope that works.
Small, idempotent, reusable runbooks
Compose big processes from tested small parts. Design every step to be safe to repeat.
Everything in source control, deployed by pipeline
Review, test and promote automation like application code, with the repository as the source of truth.
Dry run first, then act
Every destructive runbook supports report-only mode, limits and exclusions, with a summary of what was or would be changed.
Monitor the automation, not just the systems
Alert on failed jobs and on jobs that did not run. Review the health of automation regularly.
Document ownership and purpose
Each runbook has a description, an owner, a list of required permissions and a contact for questions.
More anti-patterns to avoid
Problem
Secrets such as passwords and keys are written directly inside runbooks or stored as plain variables.
Why It’s Harmful
Anyone who can read a runbook can read the secret; copies spread through exports, repositories and screenshots; rotation requires editing many scripts.
Correct Approach
Prefer managed identity so that no secret is needed. Where a secret is unavoidable, keep it in a secret store and read it at run time.
Problem
One person wrote the automation, nobody else understands it, and it has no description, no repository copy and no alerts.
Why It’s Harmful
When it fails, or when that person leaves, the organization is left with a critical black box that nobody dares touch.
Correct Approach
Require descriptions, reviews, shared ownership and runbook documentation as part of the definition of done.
Problem
The team keeps using retired or soon-to-be-retired features, such as the old Run As accounts, agent-based workers or older packaged solutions, because “they still work”.
Why It’s Harmful
When support ends, automation stops suddenly, often at a bad time, and a rushed migration is far more dangerous than a planned one.
Correct Approach
Track retirement announcements, keep an inventory of features in use, and schedule migrations well ahead of end dates.
23Best Practices Checklist
A review list to use before going live and at regular intervals afterward.
Do
- Use managed identities and least-privilege role assignments on small scopes
- Separate accounts by environment and team
- Store runbooks in source control and deploy through a reviewed pipeline
- Keep secrets in a secret store and read them at run time
- Write idempotent runbooks with validation, retries and clear messages
- Add dry-run mode, limits and exclusion tags to destructive jobs
- Send job logs to a workspace and alert on failures and missing runs
- Use extension-based hybrid workers, in groups of at least two
- Rotate webhook addresses and set expiry dates
- Tag the account for owner and cost, and lock it against deletion
- Track retirement notices and plan migrations early
Avoid
- Broad roles such as subscription owner for the automation identity
- Editing production runbooks directly in the portal
- Relying on retired features such as Run As accounts and agent-based workers
- Writing secrets or personal data into output streams
- Very long single jobs in cloud sandboxes
- Tight polling loops that burn job minutes
- Updating modules without testing
- Unmonitored automation that fails silently
- Sharing webhook addresses in chats or repositories
Hold a short automation review every quarter: which jobs failed, which schedules are still needed, which permissions can be reduced, which features are nearing retirement, and what the automation saved. Small regular reviews keep the robot trustworthy.
24Real-World Scenarios
How organizations put Azure Automation to work.
Software company cutting test environment cost
A company runs hundreds of development and test machines that were left on around the clock. A tag-driven shutdown solution stops them each evening and on weekends, with an exclusion tag for machines running long tests. Compute spend on those environments falls by a large share, and a summary message goes to team channels every morning.
Bank enforcing governance continuously
A bank uses runbooks to scan for resources without required tags, public storage settings and expired certificates. Findings are posted to a ticketing system through a webhook, and critical findings start remediation through an approval workflow. Audit teams review the job history and change logs rather than relying on spreadsheets.
Manufacturer with on-premises systems
A manufacturer runs plant systems that cannot be exposed to the internet. Hybrid workers inside the plant network pick up jobs that restart services, collect logs and update records, while all scheduling, history and permissions are managed centrally in Azure.
Operations team building self-healing
An operations team connects alerts for full disks and stopped services to runbooks that perform the standard fix. Incidents that used to wake an engineer at night now resolve themselves, and a record is attached to the ticket. Only repeated failures page a person.
Platform team onboarding projects
A platform team uses a request form that triggers a runbook through a webhook. The runbook creates a resource group with standard tags, assigns access groups, applies policy and posts the details back to the requester. Onboarding time drops from days to minutes with a consistent result every time.
Migrating away from retired features
A company discovers it still depends on old Run As accounts, agent-based workers and the original patching feature. It inventories every runbook, moves sign-in to managed identities, moves workers to the extension model, adopts the newer patching service and tests each change in a non-production account before cutting over.
25Frequently Asked Questions
Short answers to common beginner questions.
It is an Azure service that stores and runs your scripts, called runbooks, on schedules or in response to events, with identity, history, monitoring and access control built in.
A saved set of instructions, written in PowerShell, Python or built graphically, that carries out a task such as stopping machines or generating a report.
The container that holds your runbooks, schedules, shared resources, identity and job history. It is also the main security and billing boundary.
Through the automation account’s managed identity, which needs no stored password. The older Run As account method has been retired.
A machine you control that is registered to the account and runs jobs, letting automation reach private networks and on-premises systems that cloud sandboxes cannot reach.
Manually, on a schedule, from a webhook, from an alert through an action group, from another runbook, or from workflows and pipelines.
Cloud sandboxes apply a fair share limit on run time, after which the job is unloaded and may restart. Split the work into smaller jobs or use a hybrid worker.
It has been retired and replaced by Azure Update Manager. Confirm dates and migration guidance on the official site.
Use Automation for operational scripts on Azure and hybrid resources, Functions for event-driven application code, and Logic Apps for low-code business workflows. They often work well together.
Use least-privilege identities, limit who can author, keep secrets in a secret store, deploy through reviewed pipelines, and send audit logs to a workspace.
Send job logs to a Log Analytics workspace and create alerts for failed jobs and for jobs that did not run when expected.
Mainly job run time in minutes, with a small free allowance, plus logging, hybrid worker machines and related services. Check the current pricing page.
The concepts are stable, but features, runtime versions, retirements and prices change. Confirm details in the current official documentation before finalizing a design.
26Summary and Key Takeaways
Azure Automation is your tireless night manager: a managed place to keep the checklists of your cloud, run them on time, prove who is running them, and record what happened. The automation account is the control room, runbooks are the instructions, and jobs are individual runs, in a cloud sandbox or on hybrid workers inside your own network. Managed identities and narrow role assignments keep power under control, while source control, review and pipelines keep changes safe. Monitoring, alerts and clear messages ensure that failures are noticed, and thoughtful design with idempotent steps, dry runs and limits keeps mistakes small. Because Microsoft has retired or replaced several older features, including Run As accounts, agent-based workers and the original patching and shutdown solutions, it is vital to check current guidance before building. With these habits, automation stops being a pile of fragile scripts and becomes a dependable part of how your cloud is run.
Key Takeaways
- Automate the repetitive, not the unknown — begin with chores that waste money or cause late-night pages, such as idle machine shutdown and tagging.
- Use managed identities with least privilege — no stored passwords, narrow roles on small scopes, and no reliance on the retired Run As method.
- Design runbooks to be safe — small, idempotent, validated, with retries, dry-run modes, limits and exclusions.
- Treat runbooks as code — keep them in source control, review them, test them and deploy them through pipelines to separate environments.
- Choose the right place to run — cloud sandboxes for short Azure tasks, extension-based hybrid workers for private networks and long or special work.
- Watch the automation itself — send logs to a workspace and alert on failed jobs and on jobs that never ran.
- Plan for change — patching, configuration and shutdown features have moved to newer services, so track retirements and verify current documentation before you build.