Its Day 44 of my 100 Days of Cloud Journey, and today I’m looking at Azure Arc.
Azure Arc is a service that provides you with a single management plane for services that run in Azure, On Premises, or in other Cloud Providers such as AWS or GCP.
The majority of companies have resources both in on-premise and in come cases multiple cloud environments. While monitoring solutions can provide an overview of uptime and performance over a period of time, control and governance of complex hybrid and multi-cloud environments is an issue. Because these environments span multiple cloud and data centers, each of these environments operate their own set of management tools that you need to learn and operate.
Azure Arc solves this problem by allowing you to manage the following resources that are hosted outside of Azure:
- Servers – both physical and virtual machines running Windows or Linux in both on-premise and 3rd party Cloud providers such as AWS or GCP.
- Kubernetes clusters – supporting multiple Kubernetes distributions across multiple providers.
- Azure data services – Azure SQL Managed Instance and PostgreSQL Hyperscale services.
- SQL Server – enroll SQL instances from any location with SQL Server on Azure Arc-enabled servers.
For this post, I’m going to focus on Azure Arc for Servers, however there are a number of articles relating to the 4 different Azure Arc supported resource types listed above – you can find all of the articles here.
Azure Arc currently supports the following Windows and Linux Operating Systems:
- Windows Server 2012 R2 and later (including Windows Server Core)
- Ubuntu 16.04 and 18.04 (x64)
- CentOS Linux 7 (x64)
- SUSE Linux Enterprise Server (SLES) 15 (x64)
- Red Hat Enterprise Linux (RHEL) 7 (x64)
- Amazon Linux 2 (x64)
In order to register a Physical Server or VM with Azure Arc, you need to install the Azure Connected Machine agent on each of the operating systems targeted for Azure Resource Manager-based management. This is an msi installer which is available from the Microsoft Download Center.
You can also generate a script directly from the Azure Portal which can be used on target computers to download the Azure Connected Machine Agent, install it and connect the server/VM into the Azure Region and Resource Group that you specify:
The server then gets registered in Azure Arc as a connected machine:
OK, so now we’ve got all of our servers connected into Azure Arc, what can we do with them? Is it just about visibility?
No. When your machine is connected to Azure Arc, you then have the following capabilities:
- Protect Servers using Microsoft Defender for Endpoint, which is part of Microsoft Defender for Cloud
- Collect security-related events in Microsoft Sentinel
- Automate tasks using PowerShell and Python
- Use Change Tracking and Inventory to assess configuration changes in installed software and operating system changes such as registry or services
- Manage operating system updates
- Monitor system performance using Azure Monitor and and collect data which can be stored in a Log Analytics Workspace.
- Assign policy baselines using Azure Policy to report on compliance of these connected servers.
Conclusion
We can see how useful Azure Arc can be in gaining oversight on all of your resources that are spread across multiple Cloud providers and On Premise environments. You can check out the links provided above for a full list of capabilities, or else this excellent post by Thomas Maurer is a great starting point in your Azure Arc leaning journey.
Hope you enjoyed this post, until next time!
Michael Durkan 