Explains Azure hub‑spoke network design, benefits, traffic flow, peering versus VPN Gateway tradeoffs, and practical guidance for centralized security, routing, and scalable connectivity.
This lesson explains the Azure hub‑spoke architecture: what it is, why organizations use it, how traffic flows through it, and how it compares with other VNet connection options. Use this as a practical reference when designing a centralized network topology that balances security, manageability, and cost.
Hub: A central, secured VNet that hosts shared infrastructure and inspection points — for example, VPN Gateway, Azure Firewall or NVAs, DNS, and other centralized services. All spoke-to-spoke or spoke-to-on-premises traffic that requires those shared functions is routed through the hub.
Spokes: VNets for regional, environment, or workload isolation (production, test, dev, team-specific workloads). Spokes peer to the hub and are typically not peered directly with each other. If a workload in one spoke needs to reach another, traffic is forwarded via the hub.
Analogy: think of the hub as a major international airport (e.g., Doha’s Hamad International). The hub accepts incoming flights (traffic), applies security/inspection, and routes passengers (packets) to their final destination spokes.Benefits of a central hub include:
Centralized security and traffic inspection (firewalls, NVAs, NSGs, and UDR-based route control).
Consistent policy enforcement and simplified management.
Cost savings by sharing a single VPN Gateway, ExpressRoute, or firewall across many spokes.
Better scaling as you add more spokes.
Benefit
Impact
Centralized inspection & routing
Easier to enforce security and auditing
Shared Gateways & Firewalls
Lower infrastructure and operational cost
Peered spokes to hub
Simplified connectivity model and policy application
Scales with spokes
Predictable expansion and governance
Always design hub routing and security deliberately:
Identify which traffic must be inspected or allowed to transit the hub.
Configure VNet peering and user‑defined routes (UDRs) to force traffic through inspection appliances (NVAs/Firewall).
Ensure NSGs and firewall policies align with desired ingress/egress paths.
VNet Peering vs. VPN Gateway — choose the right connection for your hub‑spoke design
VNet peering and VPN Gateway are both used to connect VNets, but they differ across several dimensions. Use the table below to match each option to your architecture requirements (performance, encryption, transitivity, cost, and complexity).
Feature
VNet Peering
VPN Gateway
Speed & latency
Very low latency, high throughput. Traffic remains on the Azure backbone.
Higher latency due to IPsec/IKE encryption and tunnel processing.
Encryption
Traffic is private within Azure but not IPsec‑encrypted between VNets by default.
Encrypted tunnels (IPsec/IKE) provide end‑to‑end encryption across public networks.
Cost
Typically lower — mainly data transfer charges.
Higher — includes gateway SKU charges and potentially higher egress/tunnel costs.
Cross-region support
Global VNet peering supports cross-region high-performance connectivity.
Supports cross-region connectivity via gateway-to-gateway or VNet‑to‑VNet tunnels.
Transitivity / routing behavior
Non‑transitive by default. To allow spokes to use a hub VPN Gateway, enable gateway transit settings (see note). Use UDRs to force traffic via hub appliances for inspection.
Can provide transitive routing (site-to-site, VNet-to-VNet). Commonly used for hub-based transitive connectivity and hybrid scenarios.
Setup complexity & deployment time
Simple to configure and fast to provision.
More complex: requires gateway subnet, SKU selection, and tunnel configuration. Provisioning typically takes ~40–45 minutes.
Typical use cases
Internal Azure traffic where low latency and cost are priorities, and IPsec is not required between VNets.
Hybrid connectivity to on‑premises, encrypted cross-cloud tunnels, or scenarios requiring IPsec encryption and gateway functionality.
You can and often should use both approaches together:
Peer spokes to the hub for high-performance internal Azure traffic.
Host a VPN Gateway or ExpressRoute circuit in the hub for encrypted/hybrid connectivity to on‑premises or other clouds.
To let spokes use the hub’s VPN Gateway, enable allowGatewayTransit on the hub peering and set useRemoteGateways on each spoke peering. Plan for gateway provisioning time — creating a VPN Gateway usually takes about 40–45 minutes. For forced inspection, place NVAs/firewall(s) in the hub and use UDRs to route traffic through them.
Define which services belong in the hub (firewall, DNS, VPN/ExpressRoute).
Decide which spokes require hub gateway transit and enable the appropriate peering flags.
Create UDRs on spokes to force traffic through hub inspection points where required.
Ensure NSGs and firewall rules align with permit/deny policies.
Evaluate cost and performance tradeoffs: use peering for internal latency-sensitive traffic; use VPN/ExpressRoute for encrypted hybrid scenarios.
Document IP addressing, routing, and governance to avoid overlapping ranges and unexpected transitive routing.
Summary: The hub‑spoke model centralizes shared services and policy enforcement, simplifies management, and reduces cost while scaling efficiently. Use VNet peering for high-performance internal traffic and VPN Gateway/ExpressRoute when encrypted tunnels or hybrid connectivity and transitive routing are required. With careful peering and routing configuration, a single, well-managed hub can securely and efficiently serve as the transit point for your growing Azure networks.
