Understanding Hub and Spoke Architecture in Azure

techhadoop azure, , , ,

The Hub and Spoke—the gold standard of enterprise networking in Azure. It’s the architectural equivalent of a major airport hub (the Hub) connecting to various smaller regional airports (the Spokes).

In this setup, you centralize shared services to save money and improve security, while letting individual workloads live in their own isolated Spokes.

The Architecture Breakdown

ComponentResponsibilityTypical Resources
The HubCentral connectivity & security.Azure Firewall, VPN Gateway, ExpressRoute, Centralized Logging.
The SpokesSpecific workloads/applications.App Services, VMs, AKS Clusters, Databases.
The GlueConnecting the two.VNet Peering (Non-transitive by default).

1. How Private Endpoints fit into Hub & Spoke

This is where most engineers get a headache. You have two main choices for where to put your Private Endpoints:

Option A: The “Distributed” Model (Endpoints in Spokes)

You put the Private Endpoint directly in the same VNet as the VM/App that needs it.

  • Pros: Easier to set up initially; traffic stays within the Spoke.
  • Cons: Harder to manage at scale if you have 50 Spokes.

Option B: The “Centralized” Model (Endpoints in the Hub)

You put all Private Endpoints in a dedicated “Shared Services” subnet in the Hub.

  • Pros: One place to manage all private IPs; better for shared databases.
  • Cons: Requires “Transitive Routing”—traffic must go from Spoke A -> Hub -> Private Endpoint.

2. The DNS Challenge in Hub & Spoke

If your Private DNS Zone lives in the Hub, but your VM lives in the Spoke, the Spoke VM won’t be able to resolve the name unless you do one of these:

  1. Link the DNS Zone to every Spoke: You must create a Virtual Network Link between the Hub’s Private DNS Zone and every Spoke VNet.
  2. Centralized DNS Resolver: Use the Azure DNS Private Resolver in the Hub. Spokes point to the Hub’s IP for DNS, and the Hub handles the lookup.

3. Troubleshooting Hub & Spoke with Network Watcher

When a VM in a Spoke can’t talk to a Database in the Hub (or another Spoke), here is your checklist:

A. The “Gatekeeper” (VNet Peering)

Check the Peering status. If it doesn’t say Connected, nothing else matters.

  • Crucial Setting: For Spokes to use a VPN/ExpressRoute in the Hub, you must enable “Use Remote Gateways” on the Spoke and “Allow Gateway Transit” on the Hub.

B. The “Traffic Cop” (Next Hop)

In a Hub and Spoke, you often want traffic to go through an Azure Firewall in the Hub.

  • Use Network Watcher Next Hop: If the Next Hop is “Internet” instead of the “Virtual Appliance” (Firewall IP), your User-Defined Route (UDR) is missing or wrong.

C. The “Blind Spot” (Non-Transitivity)

VNet Peering is NOT transitive.

  • If Spoke A is peered to the Hub, and Spoke B is peered to the Hub, Spoke A cannot talk to Spoke B through the Hub automatically.
  • The Fix: You must use an NVA (Network Virtual Appliance) or Azure Firewall in the Hub to route that traffic, or peer Spoke A and B directly.

Summary Checklist for “Defense in Depth” Setup

  • [ ] Hub VNet: Contains Firewall and VPN/ER Gateway.
  • [ ] Spoke VNets: Peer to Hub with “Use Remote Gateways” enabled.
  • [ ] DNS: Private DNS Zones live in the Hub and are linked to all Spokes.
  • [ ] Routing: UDRs on Spoke subnets force 0.0.0.0/0 traffic to the Hub Firewall.
  • [ ] Monitoring: Network Watcher is enabled in both the Hub and Spoke regions.

You can route Spoke-to-Spoke traffic through a central Firewall, or your Spokes mostly be isolated from one another.

Leave a comment