Azure Arc

Azure Arc projects on-premises, multicloud, and edge resources into Azure Resource Manager so they can be governed, secured, and managed with the same control plane as Azure-native resources, extending Azure Policy, Microsoft Defender for Cloud, and Azure Monitor to hybrid estates.

When to use

Bringing non-Azure servers, Kubernetes clusters, and data services under consistent Azure governance and security. Use this skill when you need one pane of glass and policy plane across hybrid / multicloud machines.

Do not use this skill for Azure-native VMs (use ARM directly), Intune-managed endpoints (intune-device-mgmt), or Azure Stack HCI deployment.

Pick the Arc capability by resource type

Rule of thumb: start with Arc-enabled servers for hybrid posture - it's the highest-value, lowest-friction step. The Connected Machine agent gives you Defender for Cloud and Azure Policy across the hybrid estate for the price of an outbound HTTPS connection.

Approach

1. Plan the onboarding scope and identity — Decide which subscriptions / resource groups own the Arc resources. Define the target resource group per region / per business unit. Pre-create service principals if onboarding at scale via script. Verify: target RG exists with the Azure Connected Machine Onboarding role assigned to the onboarding identity.
2. Plan network and proxy requirements — Connected Machine agent needs outbound HTTPS (443) to a defined list of Microsoft endpoints. If servers are behind a corporate proxy, configure the agent for proxy + auth. Some endpoints require firewall allowlisting. Verify: a pilot server can reach *.his.arc.azure.com, *.guestconfiguration.azure.com, *.dp.kubernetesconfiguration.azure.com (for K8s); agent install completes.
3. Onboard servers at scale — Pilot 5-10 servers manually (one Windows, one Linux). Then script the rollout: GPO / Ansible / Configuration Manager for Windows; cloud-init / Ansible for Linux. The agent script accepts service principal + tags. Verify: Arc resource appears in the target RG; Connected status; tags applied.
4. Govern with Azure Policy + machine configuration — Assign Azure Policy initiatives (e.g. Azure Security Benchmark) at the RG / subscription scope. Machine configuration (formerly guest configuration) audits in-OS settings on Arc machines just like Azure VMs. Verify: ASB initiative shows compliance state for Arc machines; in-OS audit returns results (e.g. password complexity).
5. Extend Defender for Cloud — Enable Defender for Servers Plan 2 on the subscription that contains the Arc resources. Defender deploys MDE, file integrity monitoring, and adaptive controls to the Arc machines. Verify: Defender for Servers shows Arc machines as protected; MDE shows them onboarded.
6. Unify monitoring + updates — Send Arc machines' logs to Log Analytics via Azure Monitor Agent (extension). Use Azure Update Manager to assess and deploy updates from Azure across the hybrid fleet.
7. Grant access via Azure RBAC — Arc machines are ARM resources. Use Azure RBAC + PIM for who can manage them. The Arc agent also enables a managed identity on the machine for outbound calls to Azure services.

Guardrails

• Secure the Connected Machine agent and its outbound connectivity; scope its managed identity to least privilege. A compromised agent identity = lateral path into Azure.
• Plan network/proxy and firewall requirements before broad onboarding. Failed agents silently never report - looks like the estate is healthy when it's blind.
• Use Arc to unify security posture - don't leave hybrid servers outside Defender for Cloud. A "we'll get to hybrid later" gap is where ransomware lives.
• Arc Policy = on-prem Policy. Same policies you apply to Azure VMs should hit Arc machines. Assign at the management group / subscription level for inheritance.
• Tag Arc resources consistently with Azure-native ones. Otherwise cost reports, ownership, and Defender prioritisation break.
• Defender for Servers Plan 2 is per-machine-billed. Cost-aware onboarding; pilot first.

Common anti-patterns

• "Onboard servers without firewall planning" - Agents fail silently; estate looks unmanaged. Allowlist first.
• "Manual onboarding for 5,000 servers" - Not maintainable. Script with SP + tags.
• "Defender for Servers Plan 1 only" - Plan 1 lacks MDE / vuln management /file integrity. Plan 2 for production.
• "Use Arc agent as a remote-execution back door" - Tempting but breaks the security model. Use Run Command via ARM, governed by RBAC.
• "Tag Arc machines differently from Azure VMs" - Reports diverge. Same tagging scheme.
• "Don't onboard servers in legacy DCs because they're going away" - They're not going away as fast as you think; unmanaged DCs are the breach origin.

Example prompts

• Onboard on-premises servers to Azure with Arc and extend Defender for Cloud to them.
• How do I govern multicloud machines from Azure using Azure Arc?
• Deploy the Azure Arc agent at scale via service principal and apply security policy.
• Bring Arc-enabled Kubernetes clusters under central governance with Flux GitOps.
• Apply the Azure Security Benchmark initiative to Arc-enabled servers.
• Plan network and proxy requirements before broad Arc onboarding.

Microsoft Learn

• Azure Arc overview: https://learn.microsoft.com/azure/azure-arc/overview
• Arc-enabled servers: https://learn.microsoft.com/azure/azure-arc/servers/overview
• Defender for Cloud + Arc: https://learn.microsoft.com/azure/defender-for-cloud/quickstart-onboard-machines
• Arc network requirements: https://learn.microsoft.com/azure/azure-arc/servers/network-requirements
• Onboard at scale: https://learn.microsoft.com/azure/azure-arc/servers/onboard-service-principal
• Arc-enabled Kubernetes: https://learn.microsoft.com/azure/azure-arc/kubernetes/overview
• Azure Update Manager: https://learn.microsoft.com/azure/update-manager/overview
• Machine configuration: https://learn.microsoft.com/azure/governance/machine-configuration/overview/01-overview-concepts