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:
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:
Flowchart
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.
Considerations
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:
Networking
When you use 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:
o 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 Private Endpoint, use a network security group in the subnet where you've deployed 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, 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 need to 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.
Costs
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.
If you deploy private endpoints across different regions, Private Link rates and global peering inbound and outbound rates apply.