Azure Arc — Manage On-Premises and Multi-Cloud Resources

January 10, 2026 · 6 min read

DevOps & Cloud Learning Hub

You have 40 servers in your on-premises data center, 15 VMs running in AWS, a Kubernetes cluster in GCP, and your Azure environment. Four different management consoles. Four different patching workflows. Four different places to check compliance. Azure Arc collapses all of that into a single pane of glass — the Azure portal — by projecting non-Azure resources as first-class Azure resource objects. No migration required. No re-platforming. Just extend Azure's management plane to wherever your infrastructure lives.

What Is Azure Arc?

Azure Arc is a bridge that extends Azure Resource Manager (ARM) to any infrastructure. When you Arc-enable a server, Kubernetes cluster, or database, it gets an Azure resource ID, shows up in the Azure portal, and can be targeted by Azure Policy, Azure Monitor, Microsoft Defender for Cloud, and RBAC — just like a native Azure resource.

Arc Capability	What It Manages	Key Benefit
Arc-enabled servers	Physical servers, on-prem VMs, AWS EC2, GCP Compute	Unified inventory and patching
Arc-enabled Kubernetes	Any CNCF-conformant cluster	GitOps, Policy, Monitoring
Arc-enabled data services	SQL Managed Instance, PostgreSQL	Cloud-managed databases anywhere
Arc-enabled App Service	App Service, Functions, Logic Apps	PaaS on your infrastructure

Arc-Enabled Servers

Onboarding a server to Azure Arc installs the Azure Connected Machine Agent. This lightweight agent maintains a persistent connection to Azure and enables extensions like Log Analytics, Defender, and Guest Configuration.

Onboard a Single Linux Server

# Download and run the onboarding script on the target server
wget https://aka.ms/azcmagent -O install_linux_azcmagent.sh
bash install_linux_azcmagent.sh

# Connect the server to Azure
azcmagent connect \
  --resource-group "rg-arc-servers" \
  --tenant-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --location "eastus" \
  --subscription-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --resource-name "server-dc-web01" \
  --tags "Environment=Production,Team=Platform,Location=DataCenter-East"

# Verify the connection
azcmagent show

Onboard a Windows Server

# Download the agent installer
Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent -OutFile AzureConnectedMachineAgent.msi

# Install silently
msiexec /i AzureConnectedMachineAgent.msi /l*v installationlog.txt /qn

# Connect to Azure
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
  --resource-group "rg-arc-servers" `
  --tenant-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
  --location "eastus" `
  --subscription-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Onboard at Scale

For hundreds of servers, generate a service principal and use the onboarding script in your existing automation tool (Ansible, Chef, SCCM):

# Create a service principal for Arc onboarding
az ad sp create-for-rbac \
  --name "sp-arc-onboarding" \
  --role "Azure Connected Machine Onboarding" \
  --scopes "/subscriptions/<sub-id>/resourceGroups/rg-arc-servers"

# Use the service principal in automated onboarding
azcmagent connect \
  --service-principal-id "<appId>" \
  --service-principal-secret "<password>" \
  --resource-group "rg-arc-servers" \
  --tenant-id "<tenant>" \
  --location "eastus" \
  --subscription-id "<sub-id>"

Arc-Enabled Kubernetes

Connect any CNCF-conformant Kubernetes cluster — EKS, GKE, on-prem Rancher, k3s — to Azure and manage it through Azure's Kubernetes management plane.

# Register required providers
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.ExtendedLocation

# Connect an existing Kubernetes cluster
az connectedk8s connect \
  --name "k8s-dc-east-prod" \
  --resource-group "rg-arc-kubernetes" \
  --location "eastus" \
  --tags "Environment=Production Cluster=DataCenter-East"

# Verify the connection
az connectedk8s show \
  --name "k8s-dc-east-prod" \
  --resource-group "rg-arc-kubernetes" \
  --query "{Name:name, Status:connectivityStatus, Version:agentVersion}"

# Enable GitOps with Flux v2
az k8s-configuration flux create \
  --name "cluster-config" \
  --cluster-name "k8s-dc-east-prod" \
  --resource-group "rg-arc-kubernetes" \
  --cluster-type connectedClusters \
  --namespace "flux-system" \
  --scope cluster \
  --url "https://github.com/org/k8s-manifests" \
  --branch "main" \
  --kustomization name=infra path=./infra prune=true \
  --kustomization name=apps path=./apps prune=true dependsOn=infra

Azure Policy for Arc Resources

Once resources are projected into Azure, you can enforce compliance the same way you do for native resources.

# Assign a policy to audit Arc servers without Log Analytics agent
az policy assignment create \
  --name "audit-arc-no-mma" \
  --display-name "Audit Arc servers without monitoring agent" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-arc-servers" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/d21d1674-58ff-4a76-8e45-2489c0f8a1d6"

# Enforce tag inheritance on Arc resources
az policy assignment create \
  --name "inherit-env-tag" \
  --display-name "Inherit Environment tag from resource group" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-arc-servers" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/cd3aa116-8754-49c9-a813-ad46512ece54" \
  --params '{"tagName": {"value": "Environment"}}'

# Check compliance
az policy state summarize \
  --resource-group "rg-arc-servers" \
  --query "policyAssignments[].{Policy:policyAssignmentId, Compliant:results.nonCompliantResources}"

Monitoring with Azure Monitor

Install the Azure Monitor Agent (AMA) extension on Arc-enabled servers to send logs and metrics to your central Log Analytics workspace.

# Install Azure Monitor Agent on an Arc-enabled Linux server
az connectedmachine extension create \
  --machine-name "server-dc-web01" \
  --resource-group "rg-arc-servers" \
  --name "AzureMonitorLinuxAgent" \
  --publisher "Microsoft.Azure.Monitor" \
  --type "AzureMonitorLinuxAgent" \
  --location "eastus"

# Create a Data Collection Rule
az monitor data-collection rule create \
  --name "dcr-arc-servers" \
  --resource-group "rg-arc-servers" \
  --location "eastus" \
  --data-flows '[{"streams":["Microsoft-Syslog","Microsoft-Perf"],"destinations":["centralWorkspace"]}]' \
  --log-analytics '[{"name":"centralWorkspace","workspaceResourceId":"/subscriptions/<sub>/resourceGroups/rg-management/providers/Microsoft.OperationalInsights/workspaces/law-central"}]' \
  --syslog '[{"name":"syslogDataSource","streams":["Microsoft-Syslog"],"facilityNames":["auth","authpriv","daemon","kern"],"logLevels":["Warning","Error","Critical"]}]'

Inventory and Update Management

Arc-enabled servers automatically report inventory data — installed software, services, registry entries. Combine this with Azure Update Manager for centralized patching.

# Check available updates for an Arc server
az connectedmachine assess-patches \
  --resource-group "rg-arc-servers" \
  --name "server-dc-web01"

# Install critical and security updates
az connectedmachine install-patches \
  --resource-group "rg-arc-servers" \
  --name "server-dc-web01" \
  --maximum-duration "PT2H" \
  --reboot-setting "IfRequired" \
  --linux-parameters classificationsToInclude="Critical,Security"

# List all Arc servers and their status
az connectedmachine list \
  --resource-group "rg-arc-servers" \
  --query "[].{Name:name, OS:osType, Status:status, Version:agentVersion}" \
  --output table

Azure Arc vs Traditional Hybrid

Feature	Azure Arc	VPN/ExpressRoute
Purpose	Management and governance	Network connectivity
Network requirement	Outbound HTTPS (443) only	Dedicated link or tunnel
Data plane access	No (control plane only)	Yes (direct connectivity)
Cost	Free (Arc itself) + extensions	$$ (ExpressRoute) or $ (VPN)
VM migration	Not required	Not required
Workload execution	Stays where it is	Stays where it is
Use together?	Yes — common pattern	Yes — common pattern

The key insight: Arc and VPN/ExpressRoute solve different problems. Arc gives you a management plane. VPN/ExpressRoute gives you a data plane. Most enterprises use both — Arc for governance and monitoring, ExpressRoute for data traffic between on-premises and Azure.

When to Use Azure Arc

You have servers or Kubernetes clusters outside Azure that need centralized management
You want to enforce the same Azure Policy and compliance standards across all environments
Your security team needs a single view of all infrastructure in Microsoft Defender for Cloud
You want to use GitOps to manage Kubernetes clusters regardless of where they run
You need centralized patching and inventory across on-premises and multi-cloud

Azure Arc does not move your workloads. It does not create network tunnels. It simply makes non-Azure resources visible and manageable through Azure's control plane. That distinction matters — Arc is about governance, not migration. Start by onboarding a handful of servers, see the value of unified monitoring and policy compliance, and then expand to the rest of your fleet.

What Is Azure Arc?​

Arc-Enabled Servers​

Onboard a Single Linux Server​

Onboard a Windows Server​

Onboard at Scale​

Arc-Enabled Kubernetes​

Azure Policy for Arc Resources​

Monitoring with Azure Monitor​

Inventory and Update Management​

Azure Arc vs Traditional Hybrid​

When to Use Azure Arc​

Stay Updated