Design and Build an Azure Automation in a hybrid environment
Updated: Nov 22
Azure Automation delivers cloud-based automation, operating system updates, and configuration service that supports consistent management across your Azure and non-Azure environments. It includes process automation, configuration management, update management, shared capabilities, and heterogeneous features.
Automation is needed in three broad areas of cloud operations :
Deploy and manage - Deliver repeatable and consistent infrastructure as code.
Response - Create event-based automation to diagnose and resolve issues.
Orchestrate - Orchestrate and integrate your automation with other Azure or third party services and products.
The Benefits Of Azure Automation
Azure Automation Service simplifies cloud management and automation by optimizing your existing investment and skills of integration. Some of the benefits of Azure Automation are:
Lowers costs: Your routine and time-consuming cloud management tasks are often error-prone. Azure Automation helps reduce errors and increase efficiency along with Windows Azure to help you reduce operational costs and save time.
Optimizes workflows: Azure automation allows you to leverage the existing workflows or customize them to design your own workflows. You can monitor and maintain Azure resources and also create and deploy your own runbooks, as needed. Going through a few Azure Automation Tutorials you can easily create different types of runbooks including Graphical, PowerShell, and Python.
Integration: Azure Automation works seamlessly with websites, VMs, servers, storage, and other Azure services. It can also be used with any third-party applications, service offerings, or public internet APIs.
Reliable service : Azure efficiently handles systems, tools, and departments improving your
performance and saving time.
The Special Feature Of Azure Automation
Microsoft Azure Automation has been developed as a simple and speedy cloud platform. It comes packed with significant features such as:
It Integrates with other systems or existing systems by building PowerShell integration modules.
It accelerates the flexible workflow process.
It improves reliability in service among different tools, systems, and departments.
It reduces manual activities in detecting errors & corrections.
In addition to the above Azure Automation features, the service also offers:
Runbooks are the special feature of Azure Automation. It helps in automating those tasks that are time-consuming, requires time to run and execute, and has possibilities of getting frequent errors.
Graphical Authoring is another special feature of Azure Automation that allows you to add activities from the library that are already there in runbooks and link them to form a workflow. One does not need to write any complex PowerShell scripts.
Design and Build an Azure Automation
Runbooks in Azure Automation might not have access to resources in other clouds or your on-premises environment because they run on the Azure cloud platform. You can use the Hybrid Runbook Worker feature of Azure Automation to run runbooks directly on the machine hosting the role and against resources in the environment to manage those local resources. Runbooks are stored and managed in Azure Automation and then delivered to one or more assigned machines.
Potential use cases
To execute Azure Automation runbooks directly on an existing Azure virtual machine (VM) or on-premises Arc-enabled server.
To overcome the Azure Automation sandbox limitation - the common scenarios include executing long-running operations beyond three-hour limit for cloud jobs, performing the resource-intensive automation operations, interacting with local services running on-premise or in hybrid environment, run scripts that require elevated permissions and so on.
To overcome organization restrictions to keep data in Azure due to governance and security reasons - as you can't execute Automation jobs on the cloud, you can run it on an on-premises machine that is onboarded as a Hybrid Runbook Worker.
To automate operations on multiple non-Azure resources running on-premises, Hybrid, or multi-cloud environments. You can onboard one of those machines as Hybrid Runbook Worker and target automation on the remaining on-premises machines.
To access other services privately from the Azure Virtual Network (VNet) without the need to open an outbound connection to the internet, you can execute runbooks on a Hybrid Worker connected to the Azure VNet.
The Hybrid Runbook Worker architecture consists of the following:
Automation Account: A cloud service that automates configuration and management across your Azure and non-Azure environments.
Hybrid Runbook Worker: A computer that is configured with the Hybrid Runbook Worker feature and can execute runbooks directly on the computer and against the resources in the local environment.
Hybrid Runbook Worker Group: Group with multiple Hybrid runbook workers for higher availability and scale to run a set of runbooks.
Runbook: A collection of one or more linked activities that together automate a process or operation.
On-premises machines and VMs: On-premises computers and VMs with Windows or Linux operating system hosted in a private local-area network.
Components applicable for extension-based approach
Hybrid Runbook Worker VM Extension: A small application installed on a computer that configures it as a Hybrid Runbook Worker.
Arc-enabled Server: Azure Arc-enabled servers allows you to manage your Windows and Linux physical servers and virtual machines hosted outside of Azure, on your corporate network, or other cloud providers. This management experience is designed to be consistent with how you manage native Azure virtual machines.
Components applicable for agent-based approach (V1)
Log Analytics Workspace: A Log Analytics workspace is a data repository for log data collected from resources that run in Azure, on-premises or in another cloud provider.
Automation Hybrid Worker solution: With this, you can create Hybrid Runbook Workers to run Azure Automation runbooks on your Azure and non-Azure computers.
User Hybrid Runbook Worker
Each user Hybrid Runbook Worker is a member of a Hybrid Runbook Worker group that you specify when you install the worker. A group can include a single worker, but you can include multiple workers in a group for high availability. Each machine can host one Hybrid Runbook Worker reporting to one Automation account; you can't register the hybrid worker across multiple Automation accounts. A hybrid worker can only listen for jobs from a single Automation account.
System Hybrid Runbook Worker
For machines hosting the system Hybrid Runbook Worker managed by Update Management, they can be added to a Hybrid Runbook Worker group. But you must use the same Automation account for both Update Management and the Hybrid Runbook Worker group membership.
Runbook worker types
There are two types of Runbook workers - System and User.
System - supports a set of hidden runbooks used by the Update Management feature that are designed to install user-specified updates on Windows and Linux machines. This type of Hybrid Runbook Worker isn't a member of a Hybrid Runbook Worker group, and therefore doesn't run runbooks that target a Runbook Worker group.
User - supports user-defined runbooks intended to run directly on the Windows and Linux machine that are members of one or more Runbook Worker groups.
The extension-based Hybrid Runbook Worker only supports the user Hybrid Runbook Worker type and doesn't include the system Hybrid Runbook Worker required for the Update Management feature.
A Hybrid Runbook Worker doesn't have many of the Azure sandbox resource limits on disk space, memory, or network sockets. The limits on a hybrid worker are only related to the worker's own resources, and they aren't constrained by the fair share time limit that Azure sandboxes have.
The following table shows the limits applicable for Hybrid Runbook Workers. If you have more than 4,000 machines to manage, we recommend creating another Automation account.
Increased demands for processing large number of jobs can be solved by organizing multiple hybrid workers into Hybrid Worker Groups. Runbooks are executed on each hybrid worker using queuing mechanisms. The hybrid worker checks the Automation account once every 30 seconds and picks up four jobs to execute. If the rate of pushing jobs is higher than four jobs per 30 seconds, then there is a high possibility that another hybrid worker in the Hybrid Worker group has picked up the job.
Multiple Hybrid Worker Groups can execute runbooks automation tasks using different Run As accounts.
To control the distribution of runbooks on Hybrid Runbook Workers and when or how the jobs are triggered, you can register the hybrid worker against different Hybrid Runbook Worker groups within your Automation account. Target the jobs against the specific group or groups to support your execution arrangement.
Applicable only for agent-based approach (V1) - the Log Analytics Agent for Windows and Linux have very minimal impact on the machine performance. Scale up your workers by configuring to run on more powerful machines with higher performance including memory, CPU, and IOPs.
A Hybrid Runbook Worker Group with more than one machine configured with Hybrid Worker Role provides high availability because runbooks will start only on servers that are running and healthy.
The extension-based (V1) Hybrid Runbook Worker only supports the user Hybrid Runbook Worker type and doesn't include the system Hybrid Runbook Worker required for the Update Management feature.
Applicable only for agent-based approach (V1) - Currently, mappings between Log Analytics Workspace and Automation account are supported in several regions.
Encryption of sensitive assets in Automation: An Azure Automation Account can contain sensitive assets such as credentials, certificate, connection, and encrypted variables that might be used by the runbooks. Each secure asset is encrypted by default using a Data Encryption key that is generated for each Automation Account. These keys are encrypted and stored in Azure Automation with an Account Encryption Key (AEK) that can be stored in the Key vault for customers who want to manage encryption with their own keys. By default, AEK is encrypted using Microsoft-managed keys.
Runbook permission: By default, runbook permissions for a Hybrid Runbook Worker run in a system context on the machine where they're deployed. A runbook provides its own authentication to local resources. Authentication can be configured using managed identities for Azure resources or by specifying a Run As account to provide a user context for all runbooks.
Network planning :
If you use a proxy server for communication between Azure Automation and machines running the Hybrid Runbook Worker, ensure that the appropriate resources are accessible. The timeout for requests from the Hybrid Runbook Worker and Automation services is 30 seconds. After three attempts, the request fails.
Hybrid Runbook Worker requires outbound internet access over TCP port 443 to communicate with Automation. If you use a firewall to restrict access to the Internet, you must configure the firewall to permit access. For agent-based (V1) computers with restricted internet access, use Log Analytics gateway to configure communication with Azure Automation and Azure Log Analytics Workspace.
There is a CPU quota limit of 5% while configuring extension-based Linux Hybrid Runbook worker. There is no such limit for Windows extension-based Hybrid Runbook Worker.
Azure Security baseline for Automation: The Azure security baseline for Automation contains recommendations on how to increase overall security configuration to protect your asset following the best-practice guidance.
Azure Automation allows integration with popular source control systems, Azure DevOps, and GitHub. With Source Control, you can integrate the existing development environment that contains your scripts and custom code that have been previously tested in an isolated environment.
Azure Automation costs are priced for job execution per minute. Every month, the first 500 minutes of process automation are free. Use the Azure pricing calculator to estimate costs.
For agent-based approach (V1) - Azure Log Analytics Workspace might generate additional costs related to the amount of log data stored in the Azure Log Analytics. The pricing model is based on consumption. The costs are associated for data ingestion and data retention. For ingesting data into Azure Log Analytics, use Capacity Reservation or Pay-As-You-Go model that include 5 gigabytes (GB) free per billing account per month. Data retention for the first 31 days are free of charge.