Hub-spoke topology is the reference architecture for Azure enterprise landing zones. A central hub virtual network hosts shared infrastructure — VPN and ExpressRoute gateways, Azure Firewall or third-party NVA appliances, DNS private resolvers, jump boxes, and CI/CD agents. Spoke virtual networks contain application workloads peered one-to-one with the hub. Traffic between spokes, to the internet, and to on-premises networks flows through the hub where security policy applies consistently. This pattern provides governance, inspection, and connectivity scaling that flat VNet peering meshes cannot match.
Azure VNet peering is non-transitive, identical to AWS VPC behavior. A spoke peered to the hub cannot reach another spoke unless the hub routes traffic between them or separate peering is established. User-defined routes on spoke subnets point default routes and cross-spoke prefixes to the hub firewall's internal IP, forcing traffic through inspection rather than direct Azure backbone delivery. Misconfigured UDRs are the primary cause of asymmetric routing and broken connectivity in hub-spoke deployments.
Hub Design Components
The hub VNet requires adequate address space for gateway subnets, firewall subnets, management subnets, and future expansion. Gateway subnets for VPN and ExpressRoute have specific sizing and naming requirements — plan for dual ExpressRoute circuits and active-active VPN for redundancy. Azure Firewall deployed in the hub provides centralized egress filtering, FQDN-based rules, and threat intelligence feeds. Premium SKU adds TLS inspection and IDPS for deeper traffic analysis at additional cost and complexity.
DNS architecture in the hub includes Azure DNS Private Resolver inbound and outbound endpoints for hybrid resolution. Conditional forwarding rules send on-premises suffix queries to domain controllers via resolver outbound endpoints while cloud workloads resolve Azure Private DNS zones for PaaS private endpoints. Centralizing DNS in the hub simplifies management but creates dependency — deploy resolver endpoints across availability zones for resilience.
Spoke Patterns and Subscription Strategy
Each spoke typically maps to an application, environment, or business unit. Landing zone guidance recommends separate subscriptions per spoke for billing isolation and Azure Policy enforcement. Spoke VNets peer to the hub VNet in the connectivity subscription. Spoke route tables contain UDRs directing 0.0.0.0/0 to the hub firewall private IP as next hop. Without this UDR, spokes use default internet routing that bypasses hub inspection entirely — a security gap that compliance audits flag immediately.
Spoke-to-spoke communication through the hub firewall enables policy enforcement between application tiers in different spokes. For high-volume spoke pairs that would saturate firewall capacity, evaluate Azure Virtual WAN or dedicated VNet peering with compensating controls. Document every exception to hub-routed traffic with risk acceptance from security leadership. Application teams frequently request direct peering for performance; evaluate firewall throughput and latency impact before approving bypass routes.
Azure Firewall and NVA Integration
Azure Firewall as a managed PaaS simplifies operations compared to vendor NVAs requiring VM scale sets, licensing, and patching. Route Server integration allows BGP exchange between NVAs and the hub for dynamic route learning. Third-party firewalls from Palo Alto, Check Point, and Fortinet deploy as VM scale sets behind internal load balancers with UDR next-hop pointing to the ILB frontend IP. NVA designs offer feature parity with on-premises appliances but carry higher operational burden than Azure Firewall.
Forced tunneling sends all internet-bound traffic through on-premises security stacks via ExpressRoute or VPN instead of Azure Firewall. This pattern satisfies organizations with existing proxy and inspection infrastructure but adds latency and WAN dependency for cloud egress. Hybrid designs route RFC1918 traffic through the hub while internet traffic uses forced tunneling — UDR specificity determines which path each prefix takes.
Virtual WAN Alternative
Azure Virtual WAN targets large global deployments with dozens of sites and regions. Microsoft manages hub scale within a virtual hub that supports VPN, ExpressRoute, point-to-site, and spoke VNet connections. Security providers integrate directly into virtual WAN for cloud-native firewall services. Virtual WAN reduces custom hub VNet management but offers less granular control than self-managed hub-spoke with custom NVAs. Organizations with fewer than twenty spokes and single-region concentration typically find manual hub-spoke more cost-effective and transparent.
Migration from classic hub-spoke to Virtual WAN is supported but requires planning around existing ExpressRoute circuits, IP addressing, and firewall policy translation. Evaluate Virtual WAN when multi-region hub connectivity, automated branch connectivity, and managed scale outweigh the flexibility of self-built hub VNets.
Governance and Operations
Azure Policy enforces landing zone standards: required tags, approved regions, denial of public IP creation on production subnets, and mandatory diagnostic settings sending flow logs to centralized storage. Deploy hub-spoke through infrastructure-as-code — Bicep or Terraform modules from the Azure landing zone accelerator provide tested patterns. Change management on UDRs and firewall rules requires impact analysis because a single incorrect route affects every spoke relying on the hub.
Monitor hub firewall health, ExpressRoute circuit utilization, and DNS resolver query volumes. Hub-spoke is the backbone of enterprise Azure networking — implemented with consistent UDRs, centralized inspection, and subscription governance, it scales from initial landing zone to hundreds of application spokes without architectural redesign.
Cost Optimization
Hub-spoke designs incur charges for peering between hub and each spoke, data processing through Azure Firewall, and gateway SKUs in the hub. Model monthly costs before scaling to dozens of spokes — peering charges accumulate linearly while firewall processing charges grow with traffic volume through inspection paths. Virtual WAN pricing differs and may reduce costs at scale through Microsoft's managed hub economics.
Shared service consolidation in the hub reduces duplicate resources across spokes. Centralized Azure Bastion, container registry, and artifact repositories in the hub serve all spokes through peering rather than deploying per-spoke instances. Tag resources with cost center allocations for chargeback reporting that motivates spoke owners to optimize their traffic through the hub.
Review UDR designs periodically for unnecessary hairpinning — traffic between spokes in the same region that routes through the hub firewall for inspection carries double peering charges and firewall processing costs. Risk-accepted direct spoke peering for known-safe traffic patterns between specific application pairs can reduce costs when security policy permits and compensating controls exist.
Disaster Recovery Patterns
Hub-spoke designs require hub availability planning — a hub outage affects every spoke depending on it for connectivity, DNS, and security inspection. Deploy hub resources across availability zones within the region. For regional disaster recovery, replicate hub infrastructure in a secondary region with spoke failover procedures documented and tested. Azure Site Recovery and cross-region VNet peering enable DR architectures extending hub-spoke patterns geographically.
ExpressRoute and VPN gateway redundancy in the hub prevents single-circuit failures from isolating all spokes from on-premises connectivity. Dual circuits from diverse providers through separate peering locations provide maximum resilience. Monitor circuit BGP state and bandwidth utilization with alerts on single-circuit-active conditions.