This chapter covers the hub-spoke network topology in Azure, a fundamental design pattern for implementing a secure, scalable, and cost-effective network architecture in enterprise environments. For the AZ-305 exam, hub-spoke topology is a core topic within Objective 4.2 (Design a network infrastructure), appearing in approximately 15-20% of questions related to network design. You will be expected to understand the components, traffic flows, peering configurations, and how to integrate with on-premises networks using VPN or ExpressRoute. Mastering this pattern is essential for designing solutions that meet requirements for isolation, centralized inspection, and hybrid connectivity.
Jump to a section
Imagine a major airline operating from a central hub airport (like Atlanta Hartsfield-Jackson). All flights from spoke cities (e.g., Savannah, Augusta, Columbus) must connect through the hub to reach other destinations. The hub provides shared infrastructure: gates, security, baggage handling, and air traffic control. Each spoke has a single route to the hub, and all inter-spoke traffic transits the hub. This model centralizes security screening (network security groups, firewalls) and simplifies routing: only the hub needs complex routing tables. If a spoke needs to reach the internet, it goes through the hub's shared internet gateway (Azure Firewall). The hub also hosts shared services like baggage claim (shared services like Active Directory, DNS). If the hub goes down, spokes can't communicate, so redundancy (multiple hub regions) is critical. In Azure, the hub virtual network contains shared resources (VPN gateway, ExpressRoute gateway, Azure Firewall, management jump boxes). Spoke virtual networks peer with the hub (VNet peering) and route all inter-spoke and internet-bound traffic through the hub. This design reduces complexity, enforces security policies centrally, and allows spokes to be isolated from each other while still communicating via the hub.
What Is Hub-Spoke Topology and Why Does It Exist?
Hub-spoke topology is a network architecture where a central hub virtual network (VNet) connects to multiple spoke VNets via VNet peering. All inter-spoke traffic, as well as traffic to and from on-premises or internet, transits the hub. This design centralizes shared services (firewall, VPN gateway, ExpressRoute gateway, Active Directory, DNS) in the hub, while spokes host application workloads (e.g., web servers, databases). The primary reasons for adopting hub-spoke include: - Centralized security: Network security groups (NSGs), Azure Firewall, or third-party NVA can inspect all traffic. - Cost savings: Shared gateways (VPN/ExpressRoute) avoid per-spoke gateway costs. - Simplified management: Routing tables are concentrated in the hub; spokes have simple default routes. - Isolation: Spokes can be isolated from each other (no direct peering), ensuring compliance and security boundaries.
How Hub-Spoke Works Internally
At the packet level, traffic between spokes follows this path: 1. A VM in Spoke A sends a packet to a VM in Spoke B. 2. Because Spoke A does not have a direct peering to Spoke B, the packet is routed to the hub via the peering connection. 3. The hub's route table (or Azure Firewall) forwards the packet to Spoke B via its peering. 4. The packet traverses the Azure backbone; no public internet exposure occurs.
For outbound internet traffic: 1. Spoke VM sends packet to default gateway (0.0.0.0/0) which is redirected to the hub via a forced tunneling route (e.g., route table with next hop of Azure Firewall). 2. Azure Firewall performs SNAT and sends the packet to the internet. 3. Return traffic arrives at the firewall, which performs DNAT and forwards to the spoke VM.
For on-premises traffic via ExpressRoute/VPN: 1. Traffic from spoke to on-premises is routed to the hub (via peering). 2. The hub's gateway (ExpressRoute or VPN) forwards the traffic to on-premises. 3. Return traffic enters via the hub gateway and is routed back to the spoke.
Key Components, Values, Defaults, and Timers
VNet Peering: Global VNet peering enables connections across regions. Default settings allow forwarding (gateway transit) to be enabled on the hub side, and use remote gateways on the spoke side. There is no charge for peering within a region, but cross-region peering incurs egress fees.
Route Tables: User-defined routes (UDRs) are often applied to spoke subnets to force traffic to the hub. For example, a route for 0.0.0.0/0 with next hop of Azure Firewall's private IP. Default route propagation must be disabled to avoid conflicts.
Azure Firewall: A fully stateful firewall with built-in high availability (99.95% SLA). It supports application rules (FQDN-based) and network rules (IP/port-based). Forced tunneling can route all internet traffic through the firewall.
VPN Gateway: Supports site-to-site (S2S), point-to-site (P2S), and VNet-to-VNet connections. Default SKU (Basic) does not support BGP; for production, use VpnGw1 or higher. Gateway subnet must be /27 or larger.
ExpressRoute Gateway: Provides dedicated private connection to on-premises. Bandwidth ranges from 50 Mbps to 10 Gbps. Gateway SKUs: ErGw1 (1 Gbps), ErGw2 (2 Gbps), ErGw3 (10 Gbps).
BGP: When using VPN or ExpressRoute with BGP, routes are advertised to on-premises. The hub-spoke topology leverages route propagation to distribute spoke prefixes to on-premises via the hub gateway.
Configuration and Verification Commands
To create a hub-spoke topology using Azure CLI:
# Create hub VNet
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
# Create spoke VNet
az network vnet create --name SpokeVNet --resource-group RG --address-prefix 10.1.0.0/16 --subnet-name Workload --subnet-prefix 10.1.0.0/24
# Peer hub to spoke (allow gateway transit)
az network vnet peering create --name HubToSpoke --resource-group RG --vnet-name HubVNet --remote-vnet SpokeVNet --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit
# Peer spoke to hub (use remote gateways)
az network vnet peering create --name SpokeToHub --resource-group RG --vnet-name SpokeVNet --remote-vnet HubVNet --allow-vnet-access --allow-forwarded-traffic --use-remote-gateways
# Add route table to spoke workload subnet to force internet traffic to Azure Firewall
az network route-table create --name SpokeRouteTable --resource-group RG
az network route-table route create --name DefaultRoute --resource-group RG --route-table-name SpokeRouteTable --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.2.4
az network vnet subnet update --resource-group RG --vnet-name SpokeVNet --name Workload --route-table SpokeRouteTableTo verify peering status:
az network vnet peering show --name HubToSpoke --resource-group RG --vnet-name HubVNet --query 'peeringState'Expected output: "Connected"
Interaction with Related Technologies
Azure DNS: Hub can host a private DNS zone (e.g., contoso.com) that spokes can resolve via the hub's DNS server or Azure Private DNS zones linked to the hub.
Azure Bastion: Deployed in the hub to provide secure RDP/SSH access to spoke VMs without public IPs.
Azure Private Link: Used to expose PaaS services (e.g., Azure SQL, Storage) privately within the hub, accessible by spokes via peering.
Azure Virtual WAN: A managed hub-spoke service that automates many configurations. It provides a centralized hub with integrated SD-WAN, VPN, ExpressRoute, and firewall capabilities. For AZ-305, understand when to use Virtual WAN vs. manual hub-spoke: Virtual WAN is recommended for large-scale, multi-region deployments with many spokes (e.g., >30) or when using third-party SD-WAN.
Design the Hub VNet
Start by defining the hub VNet address space, typically a /16 (e.g., 10.0.0.0/16) to allow room for subnets. Create subnets for shared services: GatewaySubnet (min /27), AzureFirewallSubnet (min /26), AzureBastionSubnet (min /26), and optionally a management subnet. The hub must not overlap with any spoke or on-premises address spaces. For production, avoid using /16 for hub if you have many spokes; a /20 or /21 is often sufficient. Ensure the hub is in the same region as most spokes to minimize cross-region peering costs and latency.
Create Spoke VNets
Each spoke VNet should have a non-overlapping address space (e.g., 10.1.0.0/16, 10.2.0.0/16). Spokes host application workloads; they do not need their own gateway subnets (they use the hub's gateway). However, if a spoke requires isolated outbound internet (e.g., for updates), you can add a NAT gateway or Azure Firewall in the spoke, but this deviates from pure hub-spoke. Best practice: keep all internet-bound traffic flowing through the hub for central inspection. Spoke subnets should be sized based on workload needs; use /24 or smaller for production workloads.
Configure VNet Peering
Create two-way peering between hub and each spoke. On the hub side, enable 'Allow gateway transit' so spokes can use the hub's VPN/ExpressRoute gateway. On the spoke side, enable 'Use remote gateways' to leverage the hub's gateway. Also enable 'Allow forwarded traffic' on both sides to allow traffic that enters the hub from one spoke to be forwarded to another spoke. Without this, traffic between spokes will be dropped. Peering is a one-to-one relationship; you must create a peering from hub to spoke and another from spoke to hub. Verify peering state shows 'Connected' before proceeding.
Configure Routing
To force inter-spoke and internet traffic through the hub, add user-defined routes (UDRs) to spoke subnets. Create a route table for each spoke (or reuse one) with a route for 0.0.0.0/0 pointing to the Azure Firewall private IP (or NVA). Also add a route for the hub address space (e.g., 10.0.0.0/16) with next hop of 'Virtual network' to prevent unnecessary hops. For inter-spoke traffic, the hub's firewall must have rules to allow forwarding. If using Azure Firewall, enable forced tunneling (via route table on AzureFirewallSubnet) to inspect all outbound traffic. On the hub, ensure the firewall's route table has a default route to the internet (next hop 'Internet').
Deploy Shared Services
Deploy the VPN gateway, ExpressRoute gateway, Azure Firewall, and any other shared services (e.g., Active Directory domain controllers, DNS servers) in the hub. The VPN/ExpressRoute gateway requires a dedicated GatewaySubnet. Azure Firewall requires AzureFirewallSubnet. Azure Bastion requires AzureBastionSubnet. Ensure these subnets are sized correctly (e.g., GatewaySubnet /27, AzureFirewallSubnet /26). Once deployed, configure the VPN/ExpressRoute connection to on-premises. The gateway will propagate routes from on-premises to the hub, and via peering, to spokes. Spokes will learn on-premises routes automatically if 'Use remote gateways' is enabled.
Enterprise Scenario 1: Multi-Tier Application with Centralized Security
A financial services company hosts a three-tier web application (web, app, database) in separate spoke VNets. The hub contains an Azure Firewall for inspecting all traffic: inbound (from internet via Azure Front Door), outbound (to internet for updates), and inter-spoke (web to app, app to database). The firewall rules enforce least-privilege access. The hub also has an ExpressRoute gateway for hybrid connectivity to the corporate datacenter. In production, this design scales to 20 spokes across two regions. A common issue is misconfigured UDRs: if the spoke's route table does not include a route for the hub address space with next hop 'Virtual network', traffic from spoke to hub might be sent to the firewall instead, causing asymmetric routing. Engineers must also ensure the firewall's network rules allow traffic between spoke VNet address ranges, or inter-spoke traffic will be dropped. Performance is typically limited by the firewall SKU; for high throughput (e.g., 30 Gbps), use Azure Firewall Premium with multiple instances or a third-party NVA.
Enterprise Scenario 2: Global E-Commerce Platform with Virtual WAN
A global e-commerce company uses Azure Virtual WAN to connect 50+ spokes across three continents. Each region has a Virtual WAN hub with integrated SD-WAN, VPN, and ExpressRoute. Spokes are connected via VNet connections (similar to peering but managed by Virtual WAN). The hub provides centralized routing and security using Azure Firewall Manager. This deployment solves the problem of managing hundreds of peering connections manually. A common pitfall is forgetting that Virtual WAN uses a different routing model: spokes cannot have UDRs that override the hub's routing; route tables must be configured at the hub level. If a spoke needs custom routing, it must be done via Virtual WAN's route tables and associations. Scale considerations: Virtual WAN supports up to 2000 VNet connections per hub, but performance depends on the hub's SKU (Standard or Premium).
Scenario 3: Hybrid Cloud with Regulatory Compliance
A healthcare provider requires all patient data (PHI) to stay within a designated region and be inspected by a third-party NVA for compliance. They deploy a hub-spoke topology with the NVA in the hub. All spokes are in the same region to avoid cross-region data transfer. The NVA performs deep packet inspection (DPI) and logs all traffic to a SIEM. A frequent misconfiguration is not enabling 'Allow forwarded traffic' on the peering, causing inter-spoke traffic to be dropped silently. Another issue is asymmetric routing when the NVA is not properly configured to forward traffic back to the correct spoke. Engineers must ensure the NVA's network interface has IP forwarding enabled, and the UDRs point to the NVA's private IP. For high availability, deploy two NVAs in an active-passive configuration with a load balancer.
Exactly What AZ-305 Tests on Hub-Spoke Topology
The AZ-305 exam (Objective 4.2: Design a network infrastructure) tests your ability to recommend an appropriate network topology based on requirements. Key areas: - When to use hub-spoke vs. Virtual WAN vs. simple VNet peering: The exam expects you to choose hub-spoke when you need centralized security inspection, shared gateways, or a hub that acts as a connectivity point for many spokes. Virtual WAN is for large-scale, multi-region deployments with many spokes and integrated SD-WAN. - VNet peering configuration: You must know that 'Allow gateway transit' is set on the hub, and 'Use remote gateways' is set on the spoke. Also that 'Allow forwarded traffic' must be enabled on both sides for inter-spoke traffic. - Routing: The exam tests UDRs with next hop of Virtual Appliance (NVA) or Azure Firewall. Know that forced tunneling (0.0.0.0/0 route) can be applied to spoke subnets to route internet traffic through the hub. - Gateway subnets: Must be named 'GatewaySubnet' exactly, and must be /27 or larger. The exam may ask about the minimum size for a gateway subnet. - Azure Firewall: Know that it requires a subnet named 'AzureFirewallSubnet' with a /26 minimum. It supports application rules (FQDN) and network rules (IP/port). - ExpressRoute with hub-spoke: You must understand how on-premises routes are propagated to spokes via the hub gateway and BGP.
Common Wrong Answers and Why Candidates Choose Them
'Spokes can communicate directly via VNet peering without going through the hub': Candidates often assume that if two spokes are peered to the same hub, they can automatically communicate. In reality, without explicit peering between spokes, traffic must go through the hub. The exam tests whether you know that inter-spoke traffic requires a route through the hub.
'The hub must have a VPN gateway for all spokes to communicate': This is wrong because spokes can communicate via the hub's firewall without a VPN gateway. The gateway is only needed for on-premises connectivity. Candidates confuse the need for a gateway with the need for a firewall.
'All spokes must be in the same region as the hub': While cross-region peering is supported, it incurs egress costs and higher latency. The exam may present a scenario requiring cost optimization, and the correct answer might be to place spokes in the same region as the hub. However, it is not a requirement.
'Azure Virtual WAN replaces hub-spoke entirely': Virtual WAN is a managed service that implements hub-spoke, but it is not a replacement; it is an alternative for specific use cases (large scale, SD-WAN integration). The exam tests when to choose one over the other.
Specific Numbers, Values, and Terms That Appear on the Exam
GatewaySubnet minimum size: /27
AzureFirewallSubnet minimum size: /26
AzureBastionSubnet minimum size: /26
VNet peering: two-way peering required
Maximum number of VNet peerings per VNet: 500 (default limit, can be increased)
Azure Firewall SLA: 99.95%
ExpressRoute gateway SKUs: ErGw1 (1 Gbps), ErGw2 (2 Gbps), ErGw3 (10 Gbps)
VPN gateway SKUs: Basic (no BGP), VpnGw1, VpnGw2, VpnGw3, etc.
Edge Cases and Exceptions
Forced tunneling with Azure Firewall: If you force-tunnel all internet traffic to the firewall, you must ensure the firewall itself can reach the internet (via a default route to 'Internet'). Otherwise, the firewall cannot send traffic out.
Spoke with its own internet breakout: If a spoke requires direct internet access (e.g., for Windows Update), you can add a NAT gateway to the spoke subnet and override the UDR for specific prefixes. The exam may test this as an exception.
Multiple hubs: In a multi-region scenario, you might have a hub per region. Spokes connect to their regional hub, and hubs are peered together. The exam may ask about routing between spokes in different regions via hub-to-hub peering.
How to Eliminate Wrong Answers Using the Underlying Mechanism
Always trace the packet path. If a question asks about connectivity between two spokes, ask: Does the route table in the source spoke have a route to the destination spoke's address space? If not, traffic will be dropped. If the route points to the hub, does the hub have a route to the destination? If the hub uses Azure Firewall, does the firewall have a rule allowing the traffic? If any of these is missing, the answer that claims connectivity is wrong.
Hub-spoke topology centralizes shared services (gateways, firewalls) in a hub VNet, with spoke VNets connected via VNet peering.
VNet peering is non-transitive; spokes cannot communicate directly unless traffic is routed through the hub.
Enable 'Allow gateway transit' on the hub peering and 'Use remote gateways' on the spoke peering to share VPN/ExpressRoute gateways.
Enable 'Allow forwarded traffic' on both peerings to permit inter-spoke traffic through the hub.
GatewaySubnet must be exactly named and at least /27 in size; AzureFirewallSubnet must be /26 or larger.
User-defined routes (UDRs) on spoke subnets force traffic to the hub's firewall or NVA for inspection.
Azure Virtual WAN is a managed alternative for large-scale deployments with many spokes and integrated SD-WAN.
Cross-region peering incurs egress costs; place hub and spokes in the same region for cost optimization.
Azure Firewall requires a default route (0.0.0.0/0) with next hop 'Internet' on its own subnet to reach the internet.
For hybrid connectivity, on-premises routes propagate to spokes via the hub gateway and BGP when using ExpressRoute or VPN with BGP.
These come up on the exam all the time. Here's how to tell them apart.
Hub-Spoke with VNet Peering
Manual configuration of VNet peerings and route tables
Cost-effective for small to medium deployments (<30 spokes)
Full control over routing and firewall placement
Requires manual management of gateway transit settings
Supports custom NVAs in the hub
Azure Virtual WAN
Managed service with automated hub and spoke connectivity
Designed for large-scale (hundreds of spokes) and multi-region
Integrated SD-WAN, VPN, ExpressRoute, and firewall management
Routing is managed via hub route tables and associations
Limited to Azure Firewall in the hub; custom NVAs not supported in the hub (can be in spokes)
Mistake
Hub-spoke topology requires a VPN gateway in every spoke.
Correct
Only the hub needs a VPN or ExpressRoute gateway. Spokes use the hub's gateway via 'Use remote gateways' in VNet peering. Placing a gateway in each spoke defeats the cost-saving purpose of hub-spoke.
Mistake
Spokes can communicate directly with each other using VNet peering if they are both peered to the hub.
Correct
VNet peering is non-transitive by default. Spokes cannot communicate directly unless they are explicitly peered. Traffic between spokes must traverse the hub (via Azure Firewall or a routing NVA) with appropriate forwarding rules.
Mistake
The hub must be in the same region as all spokes.
Correct
Global VNet peering allows spokes in different regions to connect to a hub. However, cross-region peering incurs egress charges and higher latency. For cost-sensitive designs, co-locate hub and spokes in the same region.
Mistake
Azure Firewall automatically routes traffic between spokes.
Correct
Azure Firewall only inspects traffic that is explicitly routed to it. You must configure UDRs on spoke subnets to send inter-spoke traffic to the firewall's private IP. Additionally, the firewall must have network or application rules allowing the traffic.
Mistake
You can use the same GatewaySubnet for both VPN and ExpressRoute gateways.
Correct
Each gateway type requires its own GatewaySubnet. You cannot share a single subnet for both VPN and ExpressRoute gateways. They must be separate subnets, each at least /27.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The GatewaySubnet must be at least /27 (e.g., 10.0.1.0/27 with 32 addresses). This is a hard requirement; smaller subnets will cause gateway deployment failures. For production, a /26 is recommended to accommodate future growth and maintenance.
Yes, global VNet peering allows spokes in any region to connect to a hub in another region. However, cross-region peering incurs egress charges and higher latency. For cost-sensitive or latency-sensitive workloads, place the hub in the same region as the spokes.
Spokes use the hub's VPN or ExpressRoute gateway. On the spoke peering, enable 'Use remote gateways'. The hub gateway propagates on-premises routes to the spoke via BGP (if enabled) or via static routes. Ensure the spoke's route table has a route to on-premises prefixes with next hop of the hub (or let BGP propagate).
'Allow gateway transit' is set on the hub VNet peering to allow spokes to use the hub's gateway. 'Use remote gateways' is set on the spoke VNet peering to accept the hub's gateway routes. Both must be configured for spokes to access on-premises via the hub gateway.
Not necessarily, but it is a best practice for security. If you only need connectivity, you can configure the hub's route table to forward traffic between spokes directly (next hop 'Virtual network'). However, this bypasses inspection. For production, use Azure Firewall or an NVA to enforce security policies.
Yes, but it deviates from the pure hub-spoke model. You can add a NAT gateway or a firewall in the spoke and override the UDR for 0.0.0.0/0 to point to that resource. However, this means internet traffic is not centrally inspected. The exam may test this as an exception for specific requirements (e.g., Windows Update direct access).
The default limit is 500 peerings per VNet. This can be increased by requesting a quota increase. For large deployments with many spokes, consider using Azure Virtual WAN which has higher limits (up to 2000 VNet connections per hub).
You've just covered Hub-Spoke Network Topology — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?