This chapter covers the Azure hub-and-spoke network topology, a fundamental design pattern for enterprise networking in Azure. Understanding this topology is critical for the AZ-104 exam, particularly under objective 4.4 (Design and implement a hub-and-spoke network topology). You can expect 2-4 questions on this topic across the exam, often scenario-based, testing your ability to design, configure, and troubleshoot hub-and-spoke deployments. Mastery of this pattern is essential for passing the networking domain.
Jump to a section
Imagine a major airline operating a hub-and-spoke model. The airline has one central hub airport (e.g., Atlanta) and many spoke airports (e.g., small cities). Passengers traveling from a small city (spoke A) to another small city (spoke B) must first fly into the hub (Atlanta), then take a connecting flight to their destination. The hub provides centralized services: baggage handling, security, customs, and maintenance. Without the hub, you would need direct flights between every pair of cities, which is inefficient and expensive. In Azure, the hub virtual network acts like Atlanta: it hosts shared services (Azure Firewall, VPN gateway, ExpressRoute gateway, DNS, etc.). Spoke virtual networks are like small cities: they contain application workloads (VMs, App Services). Traffic from one spoke to another must go through the hub (via peering or forced tunneling), just as passengers connect through Atlanta. The hub enforces security policies (firewall inspection) and provides centralized connectivity to on-premises (via VPN/ExpressRoute). Without the hub, you would need complex peering between every pair of spokes (full mesh), which doesn't scale. The hub's centralization allows you to manage network controls in one place, just as the airline consolidates operations at one airport.
What is Hub-and-Spoke Network Topology?
The hub-and-spoke topology is a network architecture where a central virtual network (the hub) acts as a connectivity and security aggregation point for multiple peer virtual networks (spokes). The hub typically hosts shared networking resources such as Azure Firewall, Azure VPN Gateway, ExpressRoute Gateway, Azure Bastion, and DNS servers. Spokes are isolated virtual networks that contain application workloads (e.g., VMs, App Service Environments, AKS clusters). Traffic between spokes must traverse the hub, enabling centralized inspection and policy enforcement.
Why Use Hub-and-Spoke?
Without a hub-and-spoke, you would need either a full mesh of VNet peerings (N*(N-1)/2 connections) or a single large VNet containing all resources. Full mesh doesn't scale beyond a few VNets (Azure supports up to 500 peerings per VNet, but management complexity grows). A single large VNet violates the principle of isolation and makes it impossible to apply different security policies per workload. Hub-and-spoke solves these issues by:
Centralizing shared services (firewall, VPN, ExpressRoute) in the hub.
Allowing spokes to be isolated and independently managed.
Reducing peering complexity: each spoke peers only with the hub.
Enabling forced tunneling (default route 0.0.0.0/0 via hub) to inspect all egress traffic.
How It Works Internally
Hub-and-spoke relies on Azure Virtual Network Peering (VNet Peering) to connect the hub with each spoke. VNet Peering is a non-transitive relationship by default: if Spoke A is peered to Hub and Spoke B is peered to Hub, Spoke A cannot directly communicate with Spoke B unless you explicitly enable transit routing through the hub. Transit routing is achieved by:
Configuring the hub's virtual network gateway (VPN/ExpressRoute) to advertise routes to spokes.
Using User-Defined Routes (UDRs) in spoke subnets to force traffic to the hub's firewall or NVA.
Enabling 'Use Remote Gateways' on spoke peerings and 'Allow Gateway Transit' on hub peering.
When a VM in Spoke A sends a packet to a VM in Spoke B: 1. The packet leaves Spoke A's subnet and hits the effective routes. If a UDR points the destination to the hub's firewall, the packet is forwarded to the hub. 2. The hub's firewall (or NVA) inspects the packet, applies rules, and forwards it to Spoke B via the hub-to-Spoke B peering. 3. Spoke B's subnet receives the packet and delivers it to the destination VM.
If the hub has a VPN/ExpressRoute gateway, spoke traffic destined to on-premises also flows through the hub gateway. The hub gateway advertises on-premises routes to spokes via BGP (if dynamic routing) or via UDRs (if static).
Key Components, Values, and Defaults
VNet Peering: Regional or global. Regional is free for egress within same region (ingress is free). Global peering has same bandwidth limits but data transfer costs apply.
Gateway Transit: Only available if hub has a VPN/ExpressRoute gateway. Spokes must use 'Use Remote Gateways' to route through hub gateway. Hub must enable 'Allow Gateway Transit'.
UDRs: Route tables associated with subnets. Typical UDR: destination 0.0.0.0/0 with next hop 'Virtual Appliance' (firewall private IP). Also UDRs for on-premises ranges pointing to hub gateway.
Azure Firewall: Managed firewall service. Supports DNAT, SNAT, network rules, application rules, threat intelligence. Default SKUs: Standard ($1.25/hr + $0.016/GB processed), Premium (additional $0.50/hr).
VPN Gateway: Supports S2S, P2S, VNet-to-VNet. Default SKUs: VpnGw1-5. Max throughput: 1.25 Gbps (VpnGw1) to 10 Gbps (VpnGw5). Active-Active mode available.
ExpressRoute Gateway: Max throughput: 10 Gbps (UltraPerformance). Requires ExpressRoute circuit.
Azure Bastion: Managed jump server. Deployed in hub for centralized access to spoke VMs. Supports RDP/SSH over TLS. Pricing: $0.19/hr + $0.07/hr per GB outbound data.
Configuration and Verification Commands
Create hub VNet and spoke VNets:
az network vnet create --name HubVNet --resource-group RG --address-prefix 10.0.0.0/16 --subnet-name GatewaySubnet --subnet-prefix 10.0.1.0/27
az network vnet create --name SpokeAVNet --resource-group RG --address-prefix 10.1.0.0/16 --subnet-name Workload --subnet-prefix 10.1.0.0/24Create peering from hub to spoke:
az network vnet peering create --name HubToSpokeA --resource-group RG --vnet-name HubVNet --remote-vnet SpokeAVNet --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transitCreate peering from spoke to hub:
az network vnet peering create --name SpokeAToHub --resource-group RG --vnet-name SpokeAVNet --remote-vnet HubVNet --allow-vnet-access --allow-forwarded-traffic --use-remote-gatewaysCreate route table and UDR:
az network route-table create --name SpokeARouteTable --resource-group RG --location eastus
az network route-table route create --name DefaultRoute --resource-group RG --route-table-name SpokeARouteTable --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4
az network vnet subnet update --name Workload --resource-group RG --vnet-name SpokeAVNet --route-table SpokeARouteTableVerify effective routes:
az network nic show-effective-route-table --name myNic --resource-group RG --output tableInteraction with Related Technologies
Azure DNS: Hub can host private DNS zones (e.g., privatelink.blob.core.windows.net) and spokes can use hub's DNS servers via DNS forwarding or Azure DNS Private Resolver.
Azure Policy: Can enforce hub-and-spoke topology, e.g., require specific UDRs, prevent direct peering between spokes.
Azure Monitor: Network Watcher (NSG flow logs, connection monitor) to troubleshoot routing issues.
Azure Virtual WAN: Managed alternative to hub-and-spoke. Microsoft manages the hub and routing. For AZ-104, you need to know when to use VWAN vs manual hub-and-spoke.
Scaling and Limitations
Maximum VNet peerings per VNet: 500 (regional or global).
Maximum UDRs per route table: 400.
Gateway transit is only supported for VPN or ExpressRoute gateways, not for NVAs.
For spoke-to-spoke traffic through an NVA, you must configure UDRs in both spokes pointing to the NVA's private IP in the hub. The NVA must have IP forwarding enabled.
If you use Azure Firewall in the hub, ensure you configure DNAT rules for inbound traffic and SNAT rules for outbound. Azure Firewall automatically SNATs traffic to its private IP; you can disable SNAT for specific destinations.
Design IP address spaces
Plan non-overlapping IP ranges for hub and each spoke. Hub typically uses /16 (e.g., 10.0.0.0/16), spokes use /16 or /20 (e.g., 10.1.0.0/16, 10.2.0.0/16). Ensure no overlap with on-premises ranges. Overlap causes routing conflicts and prevents peering. Use RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or public IP ranges if needed.
Create hub VNet with gateway subnet
Create the hub VNet with at least one subnet (e.g., `GatewaySubnet` of size /27 or larger). GatewaySubnet must be named exactly `GatewaySubnet`. Deploy VPN or ExpressRoute gateway into this subnet. Also create subnets for Azure Firewall (e.g., `AzureFirewallSubnet` /26) and Azure Bastion (`AzureBastionSubnet` /26). These subnets have specific naming requirements.
Create spoke VNets with workload subnets
Create spoke VNets with non-overlapping address spaces. Each spoke should have at least one subnet for workloads. Avoid using a default /16 for all spokes; instead, use smaller ranges to conserve IP space. Deploy VMs, App Services, or other resources into these subnets. Ensure NSGs are applied for basic traffic filtering.
Configure VNet peerings
Create two peering connections per spoke: one from hub to spoke and one from spoke to hub. On the hub-to-spoke peering, enable `Allow Gateway Transit` if the hub has a gateway. On the spoke-to-hub peering, enable `Use Remote Gateways` to route spoke traffic through the hub's gateway. Also enable `Allow Forwarded Traffic` on both peerings to allow traffic from the firewall to reach spokes.
Deploy and configure Azure Firewall
Deploy Azure Firewall in the hub's `AzureFirewallSubnet`. Configure a static public IP for outbound/inbound. Create network rules (allow/deny based on source, destination, port) and application rules (FQDN filtering). Add a default route (0.0.0.0/0) in spoke route tables pointing to the firewall's private IP. Optionally, configure DNAT rules for inbound services.
Configure user-defined routes in spokes
Create route tables for each spoke's workload subnet. Add a route for 0.0.0.0/0 with next hop type `VirtualAppliance` and next hop IP set to the firewall's private IP. Also add routes for on-premises prefixes (if using VPN/ER) pointing to the hub gateway (next hop type `VirtualNetworkGateway`). Associate the route table with the workload subnet.
Test and verify connectivity
Deploy test VMs in hub and spokes. Use `az network nic show-effective-route-table` to verify routes. Ping or use `Test-NetConnection` (PowerShell) to test connectivity. Verify spoke-to-spoke traffic goes through firewall (check firewall logs). Verify spoke-to-on-premises traffic goes through hub gateway. Troubleshoot by checking NSGs, route tables, and peering status.
Enterprise Scenario 1: Multi-Tier Application Isolation
A financial services company deploys a three-tier application (web, app, database) in separate spoke VNets. The hub contains Azure Firewall and a VPN gateway for hybrid connectivity. The web tier is in Spoke A, app tier in Spoke B, database in Spoke C. Traffic flows: internet -> Azure Firewall (DNAT) -> Web VM -> App VM -> DB VM. All east-west traffic is inspected by the firewall. The company uses Azure Policy to enforce that all spokes have a route table pointing to the hub firewall. They also use Azure DevOps to automate deployment of new spokes with pre-configured UDRs. Performance considerations: the firewall processes all inter-spoke traffic, so they sized the firewall to handle up to 30 Gbps (Premium SKU). Misconfiguration: if the UDR is missing, traffic bypasses the firewall, violating compliance.
Enterprise Scenario 2: Global Hub-and-Spoke with ExpressRoute
A multinational corporation has on-premises data centers in US and Europe connected via ExpressRoute to a hub VNet in East US and another hub in West Europe. Each hub has spokes in its region. Spokes in the same region communicate through the local hub. Cross-region spoke-to-spoke traffic goes through the local hub, over ExpressRoute to the other hub (or via global VNet peering). The challenge is routing: they use BGP communities to control which routes are advertised. They deploy Azure Route Server in the hub to simplify BGP peering with NVAs. Common issue: asymmetric routing when on-premises routes are not properly advertised to both hubs, causing traffic to drop. They resolve by ensuring consistent route advertisement and using UDRs to force traffic through the correct gateway.
Enterprise Scenario 3: Hub-and-Spoke for Azure Virtual Desktop (AVD)
A large enterprise deploys AVD in multiple spoke VNets across regions. The hub hosts Azure Bastion for jump access, Azure Firewall for outbound internet filtering, and ExpressRoute gateway for on-premises connectivity. AVD session hosts in spoke subnets need to reach on-premises file shares and Active Directory. The hub provides DNS resolution via Azure DNS Private Resolver. They use forced tunneling (0.0.0.0/0 via firewall) to inspect all internet-bound traffic from AVD. Performance: each AVD session host generates ~2-3 Mbps, so they monitor firewall throughput. Misconfiguration: if the DNS resolver is not in the hub, spoke VMs can't resolve on-premises names, causing logon failures. They also ensure that the AVD subnet has a route to the Azure Firewall's private IP for internet access.
What AZ-104 Tests on Hub-and-Spoke (Objective 4.4)
The exam tests your ability to design and implement a hub-and-spoke topology, focusing on: (1) VNet peering configuration (allow gateway transit, use remote gateways), (2) User-defined routes for traffic redirection, (3) Azure Firewall deployment and rule configuration, (4) Gateway transit limitations, (5) Spoke-to-spoke connectivity patterns, and (6) Integration with on-premises via VPN/ExpressRoute.
Common Wrong Answers and Why
'Spoke-to-spoke traffic flows directly via VNet peering': Wrong. By default, VNet peering is non-transitive. You must use a hub firewall/NVA with UDRs to enable spoke-to-spoke communication. Many candidates assume peering is transitive.
'You can use gateway transit with any NVA': Wrong. Gateway transit is only supported with VPN or ExpressRoute gateways, not with NVAs or Azure Firewall. For NVA transit, you must use UDRs.
'Global VNet peering supports gateway transit': Wrong. Gateway transit is only supported for regional VNet peering. Global peering does not support gateway transit.
'UDRs can override the default system route for virtual network traffic': Wrong. UDRs cannot override the system route for traffic within the same VNet (e.g., between subnets). They can only override routes for destinations outside the VNet.
Specific Numbers and Terms
GatewaySubnet must be /27 or larger.
AzureFirewallSubnet must be /26 or larger.
AzureBastionSubnet must be /26 or larger.
Maximum VNet peerings per VNet: 500.
Maximum UDRs per route table: 400.
Gateway transit: only for VPN/ExpressRoute gateways.
Use Remote Gateways: only works if hub has a gateway and Allow Gateway Transit is enabled.
Edge Cases and Exceptions
If you use Azure Firewall in the hub, you must enable 'Allow Forwarded Traffic' on both peerings.
For forced tunneling via Azure Firewall, you must add a default route (0.0.0.0/0) in spoke UDRs pointing to the firewall. But if the firewall itself sends traffic to internet, it uses its own public IP (SNAT).
If you have multiple hubs (e.g., for disaster recovery), you need to manage routing carefully to avoid loops.
When using ExpressRoute with hub-and-spoke, ensure that on-premises routes are advertised to spokes via BGP or UDRs. Spokes should not have direct ExpressRoute connections.
How to Eliminate Wrong Answers
If a question says 'spoke A can directly communicate with spoke B via VNet peering', it's wrong unless explicitly stated that transit is enabled.
If a question mentions 'gateway transit' for an NVA, it's wrong.
If a question says 'global peering supports gateway transit', it's wrong.
Look for keywords: 'Allow Gateway Transit', 'Use Remote Gateways', 'Virtual Appliance', 'Azure Firewall', 'forced tunneling'.
Hub-and-spoke uses VNet peering (non-transitive) to connect hub and spokes.
To enable spoke-to-spoke communication, use a hub firewall/NVA with UDRs.
Gateway transit is only supported for VPN/ExpressRoute gateways, not NVAs.
Gateway transit is only for regional peering, not global peering.
Azure Firewall requires UDRs to inspect traffic; it does not automatically route.
GatewaySubnet must be /27 or larger; AzureFirewallSubnet must be /26 or larger.
Maximum VNet peerings per VNet is 500; maximum UDRs per route table is 400.
Use 'Allow Gateway Transit' on hub peering and 'Use Remote Gateways' on spoke peering.
For forced tunneling, add a default route (0.0.0.0/0) in spoke UDRs pointing to the firewall.
Azure Policy can enforce hub-and-spoke compliance (e.g., require UDRs, deny direct peering).
These come up on the exam all the time. Here's how to tell them apart.
Manual Hub-and-Spoke
You create and manage all VNets, peerings, UDRs, and NVAs manually.
Full control over routing, firewall rules, and network configuration.
Requires careful planning and ongoing management; prone to misconfiguration.
Supports any NVA (e.g., third-party firewalls) in the hub.
Cost-effective for small to medium deployments; no additional service cost.
Azure Virtual WAN
Microsoft manages the hub (virtual hub) and routing automatically.
Simplified connectivity: spokes connect to virtual hub via VNet connections.
Built-in routing, security (Azure Firewall Manager), and monitoring.
Supports only Azure Firewall or third-party NVAs integrated via NVA in the virtual hub.
Best for large-scale, multi-region deployments; incurs virtual hub hourly cost.
Mistake
VNet peering is transitive by default.
Correct
VNet peering is non-transitive. If VNet A is peered to VNet B, and VNet B is peered to VNet C, VNet A cannot communicate with VNet C unless you configure transit routing (e.g., via a hub firewall or NVA).
Mistake
You can use gateway transit with any network virtual appliance.
Correct
Gateway transit is only supported with Azure VPN Gateway or ExpressRoute Gateway. For NVAs or Azure Firewall, you must use UDRs to route traffic through the appliance.
Mistake
Global VNet peering supports gateway transit.
Correct
Gateway transit is only supported for regional VNet peering (same Azure region). Global VNet peering does not support gateway transit.
Mistake
UDRs can override the system route for traffic within the same VNet.
Correct
UDRs cannot override the system route for traffic within the same VNet (e.g., between subnets). They only apply to traffic destined outside the VNet.
Mistake
Azure Firewall automatically routes traffic between spokes without UDRs.
Correct
Azure Firewall does not automatically route traffic. You must configure UDRs in spoke subnets to send traffic to the firewall's private IP. The firewall then inspects and forwards traffic based on its rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Configure UDRs in each spoke's workload subnet to route traffic to the hub firewall's private IP. For example, add a route for 0.0.0.0/0 with next hop 'VirtualAppliance' and IP of the firewall. Also, ensure the firewall has rules to allow traffic between spokes. On the VNet peerings, enable 'Allow Forwarded Traffic' so the firewall can forward packets between spokes. The firewall must have IP forwarding enabled (default for Azure Firewall).
No. Gateway transit is a feature of VPN/ExpressRoute gateways that allows spokes to use the hub's gateway for on-premises connectivity. Azure Firewall is not a gateway; it is a firewall service. To route spoke traffic through the hub's VPN/ER gateway, you must enable gateway transit on the hub peering and use remote gateways on the spoke peering. For traffic inspection, you still need UDRs pointing to the firewall.
'Allow Gateway Transit' is configured on the hub's side of the peering. It allows the hub to share its VPN/ExpressRoute gateway with peered spokes. 'Use Remote Gateways' is configured on the spoke's side of the peering. It tells the spoke to use the hub's gateway for connectivity to on-premises or other VNets. Both must be enabled for gateway transit to work.
Yes, you can use global VNet peering to connect hubs and spokes across regions. However, gateway transit is not supported with global peering. If you need cross-region gateway connectivity, you must use regional peering or deploy a separate gateway in each region. Global peering also incurs data transfer costs.
Add a UDR in each spoke's workload subnet with destination 0.0.0.0/0 and next hop 'VirtualAppliance' pointing to the hub firewall's private IP. The firewall must have a default route to the internet (via its public IP). This is called forced tunneling. Ensure the firewall's network rules allow outbound traffic.
Azure supports up to 500 VNet peerings per virtual network. This includes both regional and global peerings. If you need more, consider using Azure Virtual WAN or multiple hubs.
Yes, you can have multiple hubs, each with its own spokes. Hubs can be connected via VNet peering or ExpressRoute/VPN. This is common for multi-region deployments. However, routing becomes more complex; you must manage UDRs and BGP carefully to avoid loops.
You've just covered Hub-and-Spoke Network Topology on Azure — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?