Azure Arc Connectivity Options: Choosing the Right Path for Your On-Premises Servers

Osama ShaikhOsama Shaikh
7 min read

In this post, we'll explore the private connectivity options available for integrating on-premises servers with Azure via Azure Arc. Connecting servers to Azure Arc can involve interacting with a significant number of endpoints—ranging from 15 URLs for basic onboarding to over 150 URLs when utilizing all features and extensions, such as SQL Server, Azure Defender, and Kubernetes.

Azure Arc provides a versatile platform that allows you to manage servers running outside of Azure (whether on-premises or in other cloud environments) as if they were native Azure resources. When connecting these servers to Azure, you can choose from several connectivity options:

  • Public (Default option)

  • Private Link (Partially private)

  • Proxy (Onprem)

  • Proxy (Azure)

  • Arc Gateway (Preview)

1. Public Connectivity

Overview: Public connectivity involves direct internet connections where servers communicate with Azure services over the public internet. This option is typically the easiest to set up, as it doesn’t require any changes to existing network infrastructure or private networking configurations.

Use Cases:

  • Quick Deployment: Ideal for rapid deployments or testing environments where security is not the primary concern.

  • Remote Locations: Suitable for remote sites where private networking options like VPNs or ExpressRoute are not feasible.

Security Considerations:

  • Network Security: Servers must be protected by firewalls and other security measures to mitigate internet-based threats.

  • Encryption: Implement TLS 1.2 or higher for data in transit to ensure secure communication.

Advantages:

  • Cost-Effective: No additional costs associated with setting up private network connections.

Disadvantages:

  • Security Risks: Direct internet connections are more vulnerable to security threats.

  • Performance Variability: Potential for variable latency and bandwidth depending on internet conditions.

Configuration: No specific configuration is required other than whitelisting at least 15+ public endpoint URLs.

Overview: Private Link establishes a secure, private connection to Azure services through a private endpoint in your virtual network. This setup ensures that traffic between the server and Azure remains within the Microsoft backbone network, avoiding the public internet.

Use Cases:

  • High Security Requirements: Suitable for environments that require stringent security and compliance, such as healthcare and government sectors.

  • Regulatory Compliance: Helps meet regulatory mandates that require private network communication for sensitive data.

Security Considerations:

  • Private Network: Minimizes exposure to internet-based threats by keeping traffic within a private network.

  • Public Authentication Traffic: Note that traffic for authentication (Microsoft Entra ID) and Azure Resource Manager still routes through the public internet, which should be secured.

Advantages:

  • Enhanced Security: Provides an additional layer of security by isolating traffic from the public internet.

  • Reliable Performance: Offers more consistent and reliable performance by leveraging the Microsoft backbone network.

Disadvantages:

  • Complexity: More complex to set up and manage, requiring network configuration changes and potentially additional infrastructure.

  • Security: Although there will be still few Microsoft Entra & Azure Resource manager URLs go via public endpoint

  • Cost: Involve additional expenses maintaining private endpoint connections.

Configuration: Leverage an existing circuit connection or IPsec tunnel to route Arc traffic privately. Set up a Private Link scope and configure a private endpoint in a subnet that has line-of-sight to the on-premises gateway VNet. For DNS resolution in a hybrid environment, deploy a DNS forwarder solution on Azure and configure conditional DNS forwarding on the on-premises DNS to forward Azure-related requests to the DNS forwarder VM.

  • Once private link is enabled, one could verify that name resolution for arc related endpoint (4 URL's) for telemetries are routed via private endpoint

3. Proxy Connectivity

Overview: With proxy connectivity, servers connect to Azure services through a proxy server, which acts as an intermediary. This is particularly useful in environments where direct internet access is restricted or where compliance requires that all traffic passes through a proxy.

Use Cases:

  • Controlled Environments: Ideal for environments that restrict direct internet access or require centralized management of outbound traffic.

  • Compliance: Ensures that all traffic adheres to corporate security and compliance policies by routing it through a proxy.

Security Considerations:

  • Traffic Monitoring: Proxies allow for inspection, logging, and monitoring of outbound traffic to detect and respond to suspicious activities.

  • Controlled Access: Proxy servers can enforce policies on what traffic is permitted to reach Azure, enhancing overall security.

  • SSL/TLS Inspection: FW/proxies can inspect SSL/TLS traffic to ensure secure communications and prevent data exfiltration.

Advantages:

  • Enhanced Security: Provides additional security by isolating traffic from the public internet.

  • Compliance: Facilitates compliance with industry regulations and standards.

Disadvantages:

  • Complexity: More complex to set up and manage, requiring changes to network configurations and potentially additional infrastructure.

  • Cost: May involve additional costs for setting up and maintaining the proxy server infrastructure.

Configuration: Azure Arc agent creates four services on your system, including an Arc proxy. Configure your on-premises firewall or proxy IP address in the Arc agent proxy settings, so that all traffic destined for Azure Arc passes through the proxy server, which then communicates with Azure endpoints on behalf of the Arc agent.

azcmagent config set proxy.url "http://ProxyServerFQDNorIP:port"
azcmagent config get proxy.url

Here is screenshot of on-premises server using proxy to facilitate traffic of Arc Agent
Since I have not whitelisted URL for SQL, traffic for Arc extension for SQL is failing

Sample Architecture for Arc server which could leverage onprem proxy solution:

4. Proxy (Private Connectivity)

Overview: In this scenario, the proxy server is hosted on Azure, and traffic from on-premises servers is routed privately to Azure via ExpressRoute or IPsec VPN. This approach ensures that all communication between on-premises servers and Azure remains private, leveraging the secure connection to the Azure-based proxy before reaching Azure services over the Microsoft backbone network.

Use Cases:

  • High-Security Deployments: Suitable for environments that demand to keep traffic off internet or all traffic, ensuring that no data traverses the public internet

  • Centralized Security Management: Ideal for organizations that want to centralize outbound traffic management while ensuring private connectivity.

Advantages:

  • Enhanced Security: Offers a high level of security by ensuring that all traffic from on-premises servers remains off public internet until it connects Arc service,
    traffic can be routed across multiple layers of firewall in customer DMZ before it connects to Arc/Azure endpoint via Azure backbone network

  • Compliance: Meets stringent security and compliance requirements by leveraging private connections.

Disadvantages:

  • Complexity: More complex to set up due to the need for private networking configurations, including ExpressRoute or IPsec VPN.

  • Cost: Higher costs associated with maintaining private connectivity and the Azure-based proxy infrastructure.

Configuration:

  1. Enable Forward Proxy on Azure Firewall (Premium SKU): Configure the proxy service to expose its service over specific ports (e.g., HTTP/HTTPS).

  2. Configure Proxy in Arc Agent: Use the azcmagent utility on your on-premises servers to configure the proxy settings using the IP and port details of the Azure-based proxy.

  3. Verify Traffic: Monitor traffic on the Azure Firewall logs, ensuring that it passes through the proxy as configured. Based on the whitelisted rules, allow traffic to the necessary Arc endpoints.

  4. DMZ Considerations: For added security, route traffic through a DMZ zone firewall before connecting to Arc endpoints via the Microsoft backbone network.
    Sample architecture for secure Arc traffic via proxy which traverse through multiple layers of firewall (ingress, egress) & connect Arc via backbone network

5. Arc Gateway (Preview)

Overview:

Managing Azure Arc often involves dealing with numerous endpoints—15+ for basic scenarios, and over 150 for full extension use. The Arc Gateway simplifies this by reducing the number of URLs that need to be whitelisted in enterprise proxies or firewalls.

Components:

  • Arc Gateway: A centralized front end for all infrastructure traffic between Azure and on-premises servers.

  • Azure Arc Proxy: A component within the Arc agent that routes traffic through the Arc Gateway, reducing the operational burden of managing multiple endpoints.

Use Cases:

  • Simplified Management: Ideal for enterprises that want to reduce the operational complexity associated with managing numerous Arc-related endpoints.

  • Secure, Centralized Traffic Routing: Ensures all Arc traffic is routed through a single, secure gateway.

Advantages:

  • Reduced Complexity: Simplifies endpoint management by limiting the number of required URLs to 7 for all scenarios

  • Improved Security: Centralizes traffic management, enhancing security and reducing the attack surface.

Disadvantages:

  • Limited Availability: As a preview feature, it may not yet be suitable for production environments without thorough testing.

  • Security: All traffic to Arc Gateway would traverse via public endpoint

Configuration:

  1. Create Arc Gateway Resource: Set up the Arc Gateway within your Azure environment.

     az connectedmachine gateway create --name demo-gateway --resource-group demo-arc-gw --location eastus2 --gateway-type public --allowed-features '*' --subscription 'subsid'
    

  2. Enable Association: Associate your Arc-enabled servers with the Arc Gateway.

     az connectedmachine setting update --resource-group demo-arc-gw --subscription subscription-name --base-provider Microsoft.HybridCompute --base-resource-type machines --base-resource-name arcbox-win2k19  --settings-resource-name default --gateway-resource-id '/subscriptions/subsid/resourceGroups/demo-arc-gw/providers/Microsoft.HybridCompute/gateways/demo-gateway'
    
  3. Initiate Arc Proxy Service: Configure the Arc Proxy to leverage the Arc Gateway, reducing the number of required endpoints.

  4. Verify Traffic Routing: Use the azcmagent utility to confirm that traffic is being routed through the Arc Gateway, reducing the list of required endpoints to just four.

  5. Representation of traffic in visual architecture would look similar to this

    Diagram showing the route of traffic flow for Azure Arc gateway.

0
Subscribe to my newsletter

Read articles from Osama Shaikh directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Osama Shaikh
Osama Shaikh

I have been working as App/Infra Solution Architect with Microsoft from 5 years. Helping diverse set of customers across vertical i.e. BFSI, ITES, Digital Native in their journey towards cloud