top of page

Design and build Azure Private Link in a hub-and-spoke network

Updated: Jun 4

Hub and spoke is a network topology that you can use in Azure. This topology works well for efficiently managing communication services and meeting security requirements at scale. For more information about hub-and-spoke networking models.

By using a hub-and-spoke architecture, you can take advantage of these benefits:

  • Deploying individual workloads between central IT teams and workload teams

  • Saving costs by minimizing redundant resources

  • Managing networks efficiently by centralizing services that multiple workloads share

  • Overcoming limits associated with single Azure subscriptions

This diagram shows a typical hub-and-spoke topology that you can deploy in Azure:

hub-and-spoke topology in Azure

This architecture is one of two options for network topology 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 Hub and Spoke, you're responsible for configuring the services. You also need to 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 also 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

Private Link provides access to services over the Private Endpoint network interface. 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're accessing travels across the Azure network backbone. As a result, you no longer access the service over a public endpoint.

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

azure private link


The following flowchart summarizes the various options and recommendations. Since every customer has a unique environment, consider your system's requirements when deciding where to place private endpoints.

Azure VWAN topology flowchart


A few factors can affect your Private Endpoint implementation. They apply to Azure PaaS services and customer-owned and partner services that Azure hosts. Consider these points when you deploy Private Endpoint:


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

  • If you use a traditional hub-and-spoke topology:

You can see this effective route at the network interface level of your virtual machines.

  • If you use Virtual WAN:

o You can see this route in the virtual hub effective routes.

The /32 route gets propagated to these areas:

  • Any virtual network peering that you've configured

  • Any VPN or ExpressRoute connection to an on-premises system

To restrict access from your hub or on-premises system to the Private Endpoint, use a network security group in the subnet where you've deployed 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 private IP addresses if you use a specific Domain Name System (DNS) setup. If you use a custom DNS solution, it's best to use DNS zone groups. Integrate Private Endpoint with a centralized Azure private DNS zone. It doesn't matter whether you've deployed resources in a hub or a spoke. Link the private DNS zone with all virtual networks that must resolve your Private Endpoint DNS name.

With this approach, on-premises and Azure DNS clients can resolve the name and access the private IP address. For a reference implementation.


  • When you use Private Endpoint across a regional virtual network peering, you're not charged peering fees for traffic to and from Private Endpoint.

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

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

257 views0 comments

Recent Posts

See All


bottom of page