Implementing Private Azure ARC Onboarding for On-Premise VMs at Scale

Recently, I worked with a client who needed to onboard a large number of on-premise VMs to Azure ARC while ensuring that all traffic remained private and secure. The solution involved leveraging Azure Private Link and deploying Azure Arc-enabled servers at scale across multiple environments. This blog will walk you through the implementation and architecture used to meet the client’s requirements.

The Client’s Requirements

The client wanted to onboard hundreds of on-premise VMs into Azure Arc, enabling Azure management capabilities like monitoring, with one critical stipulation: all communication between on-premise VMs and Azure must occur over a private connection.

To meet these requirements, we designed a solution based on Azure ARC with Private Link, deploying the infrastructure in a hub-and-spoke architecture.

Management Group Tree and Subscription Organization

The foundation of the implementation was a management group tree that allowed us to effectively organize and govern resources. This structure was inspired by Azure’s ARC landing zone accelerator for hybrid and multicloud environments. Having a Sandbox Management Group and subscription allowed us to test Azure policies and resource deployments before applying them to the Azure ARC subscription under the Landing Zones Management Group.

Hub-and-Spoke Architecture with Private DNS Resolution

We deployed a hub-and-spoke network architecture to facilitate private communication between on-premise resources and Azure. In this setup, the hub VNET hosts key networking services such as a VPN Gateway, Private DNS Resolver, and a dedicated subnet for Private Endpoints. This setup supports both Azure ARC and Azure Monitor services, as we wanted to push logs to Azure Sentinel via the Azure Monitor Private Link Scope.

Key Components:

  • Private DNS Resolver: Deployed in the hub VNET to handle DNS resolution for all private endpoints, including those for Azure ARC services.
  • Private Endpoint Subnet: A dedicated subnet in the hub VNET hosted private endpoints for Azure Arc, ensuring that all Arc-related traffic flowed through secure, private channels.

To ensure that Azure ARC onboarding and management could occur over private connections, we configured Azure Private Link and associated Private DNS zones.

  • Private DNS Zones: We created private DNS zones for Azure Arc’s private endpoints (privatelink.dp.kubernetesconfiguration.azure.com, privatelink.guestconfiguration.azure.com, and privatelink.his.arc.azure.com) within the hub subscription, under a dedicated DNS resource group.
  • DNS Zone Association: These private DNS zones were linked to the hub VNET, enabling on-premise VMs to resolve Azure ARC domains via the private endpoints.
  • Private Link Scope: We defined a private link scope to centralize all private endpoint connections for Azure Arc, ensuring that any on-premise VM connecting to ARC would do so through the private endpoint subnet.

This configuration ensured that the Azure ARC agent running on each on-premise VM communicated with Azure exclusively through Private Link.

DNS Forwarding for On-Premise VMs

A critical aspect of this solution was ensuring that the on-premise VMs could resolve Azure ARC domains privately. To achieve this, we configured on-premise DNS conditional forwarders to forward requests for Azure ARC public domains (dp.kubernetesconfiguration.azure.com, guestconfiguration.azure.com, and his.arc.azure.com) to the Private DNS Resolver inbound IP address in the hub VNET. You can look up the adequate Azure Private Endpoint private DNS zone values for the right Azure service.

  • DNS Forwarding Setup: The on-premise DNS servers were configured with conditional forwarders to direct all DNS queries for Arc-related domains to the inbound IP address of the Private DNS Resolver in the hub VNET.
  • Private Resolution: The Private DNS Resolver then resolved these queries using the private DNS zones linked to the hub VNET, ensuring that all traffic between the on-premise VMs and Azure ARC flowed through the Private Link.

By routing DNS traffic in this way, we could apply the same Private Link strategy to other services like Azure Monitor by simply adding their public domains to the conditional forwarders on the on-premise domain controllers.

Scaling the Solution

Once the architecture was in place, scaling the solution became straightforward. We could:

  • Add new on-premise VMs: New VMs could be onboarded to Azure ARC by connecting them to the existing private link scope. Some older VMs that were onboarded publicly before this project remained connected to Arc, and we later linked them to the Azure ARC Private Link scope.
  • Add new Private Link services: We could easily extend the solution by adding additional services that use Private Link, such as Azure Monitor, Azure Key Vault, and Azure SQL. This would follow the same pattern—creating private DNS zones for these services, associating them with the hub VNET, and updating the on-premise DNS conditional forwarders accordingly.
  • Expand the ARC Landing Zone: The management group tree allowed us to sandbox additional use cases, such as pushing logs to Sentinel or linking Azure ARC VMs to Data Collection Rules via policies before applying changes in production.

This implementation enabled the client to onboard their on-premise VMs to Azure ARC privately and at scale, delivering a solution that is both secure and future-proof.

That’s all, folks!