Edit

Share via

Azure Private Link in a hub-and-spoke network

This article describes how to use Azure Private Link in a hub-and-spoke network topology. The target audience includes network architects and cloud solution architects. This guide outlines how to use Azure private endpoints to privately access platform as a service (PaaS) resources.

This guide doesn't cover virtual network integration, service endpoints, and other solutions for connecting infrastructure as a service (IaaS) components to Azure PaaS resources. For more information about these solutions, see Integrate Azure services with virtual networks for network isolation.

Azure hub-and-spoke topologies

You can use a hub-and-spoke network topology in Azure to efficiently manage communication services and meet security requirements at scale. For more information, see Hub-and-spoke network topology.

A hub-and-spoke architecture provides the following benefits:

  • Deploys individual workloads between central IT teams and workload teams
  • Saves costs by minimizing redundant resources
  • Manages networks efficiently by centralizing services that multiple workloads share
  • Overcomes limits associated with a single Azure subscription

The following diagram shows a typical hub-and-spoke topology that you can deploy in Azure.

Architecture diagram that shows a hub virtual network and two spokes. One spoke is an on-premises network. The other is a landing zone virtual network.

Download a Visio file of this architecture.

This architecture is one of two network topology options that Azure supports. This classic reference design uses basic network components like Azure Virtual Network, virtual network peering, and user-defined routes (UDRs). When you use a hub-and-spoke topology, you configure the services, and you must ensure that the network meets security and routing requirements.

Azure Virtual WAN provides an alternative for deployments at scale. This service uses a simplified network design. Virtual WAN reduces the configuration overhead associated with routing and security.

Private Link supports different options for traditional hub-and-spoke networks and for Virtual WAN networks.

Private Link provides access to services over a private endpoint network interface. A private endpoint uses a private IP address from your virtual network. You can access various services over that private IP address:

  • Azure PaaS services
  • Customer-owned services that Azure hosts
  • Partner services that Azure hosts

Traffic between your virtual network and the service that you access travels across the Azure network backbone. As a result, you no longer access the service over a public endpoint. For more information, see Private Link.

The following diagram shows how on-premises users connect to a virtual network and use Private Link to access PaaS resources.

Architecture diagram that shows how Azure Private Link connects a virtual network to PaaS resources.

Download a Visio file of this architecture.

You can deploy private endpoints in either a hub or a spoke. A few factors determine which location works best in each situation. Consider the following factors to determine the best configuration for Azure PaaS services and for customer-owned and partner services that Azure hosts.

Determine whether you use Virtual WAN as your network connectivity solution

If you use Virtual WAN, you can only deploy private endpoints on spoke virtual networks that you connect to your virtual hub. You can't deploy resources into your virtual hub or secure hub.

For more information about integrating private endpoints into your network, see the following articles:

Determine whether you use a network virtual appliance such as Azure Firewall

Traffic to private endpoints uses the Azure network backbone and is encrypted. You might need to log or filter that traffic. You might also want to analyze traffic that flows to private endpoints if you use a firewall in the following areas:

  • Across spokes
  • Between your hub and spokes
  • Between on-premises components and your Azure networks

In this case, deploy private endpoints in your hub in a dedicated subnet. This setup provides the following benefits:

  • Simplifies your secure network address translation (SNAT) rule configuration. You can create a single SNAT rule in your network virtual appliance (NVA) for traffic to the dedicated subnet that contains your private endpoints. You can route traffic to other applications without applying SNAT.

  • Simplifies your route table configuration. For traffic that flows to private endpoints, you can add a rule to route that traffic through your NVA. You can reuse that rule across all spokes, virtual private network (VPN) gateways, and Azure ExpressRoute gateways.

  • Enables you to apply network security group rules for inbound traffic in the subnet that you dedicate to a private endpoint. These rules filter traffic to your resources. They provide a single place to control access to your resources.

  • Centralizes management of private endpoints. If you deploy all private endpoints in one place, you can more efficiently manage them in all virtual networks and subscriptions.

Use this configuration when all workloads need access to each PaaS resource that Private Link protects. If your workloads access different PaaS resources, don't deploy private endpoints in a dedicated subnet. Instead, improve security by following the principle of least privilege:

  • Place each private endpoint in a separate subnet.
  • Only give workloads that use a protected resource access to that resource.

Determine whether you use a private endpoint from an on-premises system

If you plan on using private endpoints to access resources from an on-premises system, deploy the endpoints in your hub. This setup provides the following benefits:

  • You can use network security groups to control access to your resources.
  • You can manage your private endpoints in a centralized location.

If you plan on accessing resources from applications that you deploy in Azure, the following factors apply:

  • If only one application needs access to your resources, deploy a private endpoint in that application's spoke.
  • If more than one application needs access to your resources, deploy a private endpoint in your hub.

Flowchart

The following flowchart summarizes options and recommendations. Every customer has a unique environment, so consider your system's requirements when you decide where to place private endpoints.

Flowchart that guides you through the process of deciding whether to place Private Link on a spoke or in the hub of a hub-and-spoke network.

Download a Visio file of this architecture.

Considerations

The following factors can affect your private endpoint implementation. They apply to Azure PaaS services and customer-owned and partner services that Azure hosts.

Networking

When you use private endpoints in a spoke virtual network, the subnet's default route table includes a /32 route, with a next hop type of InterfaceEndpoint.

  • If you use a traditional hub-and-spoke topology, you can view this effective route at the network-interface level of your virtual machines (VMs). For more information, see Diagnose a VM routing problem.

  • If you use Virtual WAN, you can view this route in the virtual hub effective routes. For more information, see View virtual hub effective routes.

The /32 route gets propagated to the following areas:

  • Any virtual network peering that you configure
  • Any VPN or ExpressRoute connection to an on-premises system

To restrict access from your hub or on-premises system to a private endpoint, use a network security group in the subnet where you deploy the private endpoint. Configure appropriate inbound rules.

Name resolution

Components in your virtual network associate a private IP address with each private endpoint. Those components can only resolve that private IP address if you use a specific Domain Name System (DNS) setup. If you use a custom DNS solution, use DNS zone groups. Integrate the private endpoint with a centralized Azure private DNS zone, whether you deploy resources in a hub or a spoke. Link the private DNS zone with all virtual networks that need to resolve your private endpoint DNS name.

In this approach, on-premises and Azure DNS clients can resolve the name and access the private IP address. For a reference implementation, see Private Link and DNS integration at scale.

Costs

  • When you use private endpoints across a regional virtual network peering, peering fees don't apply for traffic to and from private endpoints.

  • Peering costs apply with other infrastructure resource traffic that flows across a virtual network peering.

  • When you deploy private endpoints across different regions, Private Link rates and global peering inbound and outbound rates apply.

For more information, see Bandwidth pricing.

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal author:

  • Jose Angel Fernandez Rodrigues | Senior Specialist GBB

Other contributor:

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps