Hub-and-Spoke vs Virtual WAN: Which to Pick

When designing a robust and scalable network architecture in Azure, organizations frequently find themselves evaluating two primary models for connecting their virtual networks: the traditional Hub-and-Spoke topology and Azure Virtual WAN (VWAN). Both offer centralized connectivity, shared services, and improved network control, but they achieve these goals through distinct mechanisms and are optimized for different scales and complexities. Choosing the right architecture is critical for long-term operational efficiency, cost management, and security posture.

This article delves into the nuances of Azure's Hub-and-Spoke and Virtual WAN models, providing a detailed comparison to guide architects, network engineers, and cloud specialists in making an informed decision. We will explore their core components, implementation considerations, and best practices, aiming to equip you with the knowledge to select the optimal design for your organization's unique requirements, whether you're managing a small regional footprint or a globally distributed enterprise network.

Why this matters

The choice between Hub-and-Spoke and Virtual WAN significantly impacts an organization's cloud networking strategy, with far-reaching implications for compliance, cost, risk, and productivity. A well-designed network is fundamental to the reliable operation of cloud-native applications and the efficient consumption of Azure services. Conversely, a poorly chosen or implemented architecture can lead to network bottlenecks, security vulnerabilities, increased operational overhead, and higher-than-anticipated costs.

For organizations subject to strict regulatory compliance (e.g., GDPR, HIPAA, FedRAMP), a centralized network architecture ensures that traffic inspection, logging, and access controls are consistently applied, aiding in auditability. Cost optimization is another critical factor; while initial setup might seem complex, the right architecture can reduce data egress costs, optimize VPN/ExpressRoute gateway consumption, and simplify routing. From a security perspective, centralizing network security appliances (like Azure Firewalls) in a hub or a Virtual WAN hub effectively enforces a perimeter, bolstering the Zero Trust principle by inspecting all east-west and north-south traffic. Finally, a scalable and manageable network reduces administrative burden, improves developer productivity by providing consistent connectivity patterns, and minimizes downtime caused by network misconfigurations, thereby reducing operational risk.

Key concepts

• Hub-and-Spoke Topology: A traditional network design where a central "hub" Virtual Network (VNet) acts as a central point of connectivity to on-premises networks via ExpressRoute or VPN Gateways, and to other "spoke" VNets via VNet peering. Shared services (e.g., Azure Firewall, Active Directory Domain Controllers, monitoring solutions) are typically hosted in the hub.
• Virtual Network Peering: A mechanism to connect two Azure Virtual Networks seamlessly, allowing resources in both VNets to communicate directly using private IP addresses. Peering is non-transitive, meaning spokes cannot directly communicate with each other through the hub unless specific User Defined Routes (UDRs) are configured or the hub hosts a routing appliance.
• Azure VPN Gateway: Enables secure, cross-premises connectivity between Azure VNets and on-premises networks over the public internet. Supports Site-to-Site VPN, Point-to-Site VPN, and VNet-to-VNet connections. Resides within a dedicated subnet in an Azure VNet.
• Azure ExpressRoute: Extends an on-premises network into the Microsoft cloud over a private connection, facilitated by a connectivity provider. Offers higher bandwidth, lower latency, and greater reliability than internet-based VPN connections.
• Azure Virtual WAN (VWAN): A Microsoft-managed networking service that provides optimized, automated, and global connectivity for branches, users, and VNets. It offers a single operational interface for various networking services, including site-to-site VPN, ExpressRoute, Point-to-Site VPN, and secure access (Azure Firewall Manager integration).
• Virtual Hub: The core component of Virtual WAN. It's a Microsoft-managed VNet where various gateways (VPN, ExpressRoute, User VPN) and Azure Firewall reside. It simplifies routing and connectivity across global networks.
• Routing Intent and Routing Policies (VWAN): VWAN allows you to define routing intent for virtual hubs, directing traffic from spokes to a centralized security appliance (like Azure Firewall) within the hub, or between spokes.

Step-by-step implementation

Implementing either a Hub-and-Spoke or Virtual WAN architecture typically begins with core networking components. Here, we'll outline the initial steps for setting up a basic Hub-and-Spoke.

1. Create the Hub Virtual Network (VNet): This will house your shared services and gateway.

Navigate to the Azure portal. Search for "Virtual networks" and click "Create". Provide a name (e.g., `hub-vnet`), select a region and resource group, and define an address space (e.g., `10.0.0.0/16`). Add a subnet for the gateway (e.g., GatewaySubnet, 10.0.0.0/27).

1. Create Spoke Virtual Networks (VNets): These will host your applications and services.

Repeat the VNet creation process for each spoke (e.g., `spoke-app-vnet`, `spoke-db-vnet`). Ensure each spoke has a non-overlapping address space (e.g., 10.1.0.0/16, 10.2.0.0/16).

1. Peer the Spoke VNets to the Hub VNet:

For each spoke VNet, go to its "Peerings" section. Click "Add" and configure peering from the spoke to the hub, and from the hub to the spoke. Ensure "Allow virtual network access" is enabled in both directions. For hub-and-spoke, typically "Allow forwarded traffic" and "Allow gateway transit" are enabled on the hub's peering configuration to the spoke, and "Use remote gateways" is enabled on the spoke's peering configuration to the hub if the spoke needs to reach on-premises networks via the hub's gateway.

1. Deploy a VPN or ExpressRoute Gateway in the Hub: (Example for VPN Gateway)

In the `hub-vnet`, navigate to "Virtual network gateways" and click "Create". Select "VPN", a suitable SKU (e.g., VpnGw1), and connect it to your GatewaySubnet.

1. Configure Routing: While VNet peering handles basic connectivity, for more complex scenarios (e.g., forcing spoke traffic through a Firewall in the hub), User Defined Routes (UDRs) on spoke subnets will be necessary.

Here's an example of creating a VNet and adding a subnet using Azure CLI:

# Define variables
RESOURCE_GROUP="myHubSpokeRG"
HUB_VNET_NAME="HubVNet"
HUB_VNET_CIDR="10.0.0.0/16"
GATEWAY_SUBNET_NAME="GatewaySubnet"
GATEWAY_SUBNET_CIDR="10.0.0.0/27"
LOCATION="eastus"

# Create Resource Group
az group create --name $RESOURCE_GROUP --location $LOCATION

# Create Hub VNet
az network vnet create \
  --name $HUB_VNET_NAME \
  --resource-group $RESOURCE_GROUP \
  --address-prefix $HUB_VNET_CIDR \
  --location $LOCATION

# Add GatewaySubnet to Hub VNet
az network vnet subnet create \
  --name $GATEWAY_SUBNET_NAME \
  --vnet-name $HUB_VNET_NAME \
  --resource-group $RESOURCE_GROUP \
  --address-prefix $GATEWAY_SUBNET_CIDR

Example configuration

This Bicep snippet illustrates the peering configuration from a spoke VNet to a hub VNet, enabling remote gateway usage for the spoke.

resource hubVnet 'Microsoft.Network/virtualNetworks@2021-08-01' existing = {
  name: hubVnetName
  scope: resourceGroup(hubResourceGroupName)
}

resource spokeVnet 'Microsoft.Network/virtualNetworks@2021-08-01' = {
  name: spokeVnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        spokeVnetCidr
      ]
    }
  }
}

resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2021-08-01' = {
  parent: spokeVnet
  name: 'SpokeToHubPeering'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true // Usually enabled if hub routes traffic
    useRemoteGateways: true     // Important for spokes to use hub's gateway
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
  }
}

resource hubToSpokePeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2021-08-01' = {
  parent: hubVnet
  name: 'HubToSpokePeering'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: true   // Important for spokes to use hub's gateway
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
  }
}

Common pitfalls

• Non-Transitive Peering: A frequent misconception in Hub-and-Spoke is that spokes can communicate with each other directly through the hub via peering. VNet peering is non-transitive, meaning direct Spoke A to Spoke B communication requires UDRs pointing to a routing appliance (like Azure Firewall or NVA) in the hub, or direct peering between spokes (which defeats the centralization purpose).
• IP Address Overlap: Failing to plan VNet CIDR blocks upfront can lead to IP address conflicts, making VNet peering or VPN connectivity impossible without re-architecting.
• Gateway SKU Under-provisioning: Deploying VPN or ExpressRoute gateways with insufficient SKUs can lead to performance bottlenecks, dropped connections, and poor user experience, especially with increasing traffic demands.
• ACL/NSG Misconfigurations: Incorrectly configured Network Security Groups (NSGs) or Azure Firewall rules can inadvertently block legitimate traffic or, conversely, leave critical resources exposed.
• Complexity at Scale (Hub-and-Spoke): As the number of spokes and regions grows, managing VNet peerings, UDRs, and gateway connections in a pure Hub-and-Spoke model becomes increasingly complex and error-prone. This is where VWAN shines.
• Lack of Centralized Security Policy: Without a centralized firewall or security appliance in the hub, security policies might become fragmented across individual spokes, leading to inconsistencies and compliance issues.

Best practices

• Plan IP Subnetting Meticulously: Adhere to a hierarchical IP addressing scheme. Allocate large enough CIDR blocks for Hub and Spoke VNets, with room for future expansion. Avoid overlapping address spaces across your Azure and on-premises networks. This aligns with the Azure Well-Architected Framework's reliability and cost optimization principles.
• Automate Deployments: Utilize Infrastructure as Code (IaC) tools like Azure Resource Manager (ARM) templates, Bicep, or Terraform for all network resource deployments. This ensures consistency, reduces manual errors, and facilitates faster deployments and changes.
• Centralize Network Security: Route all north-south (internet-to-Azure, on-premises-to-Azure) and, where necessary, east-west (spoke-to-spoke) traffic through a centralized network virtual appliance (NVA) like Azure Firewall deployed in the hub (or Virtual Hub for VWAN). This enables consistent security policy enforcement and aids in your Zero Trust strategy.
• Monitor Network Performance and Logs: Implement comprehensive Azure Monitor and Network Watcher configurations to track network performance, diagnose connectivity issues, and audit traffic flow logs. This proactively identifies bottlenecks and security threats.
• Choose the Right Architecture for Scale: For smaller or regional deployments, Hub-and-Spoke is a perfectly valid and cost-effective solution. However, for large-scale, globally distributed networks with many spokes, multiple regions, and complex remote connectivity requirements, Azure Virtual WAN provides significant operational simplification, automated routing, and improved scalability, aligning with the Microsoft Cloud Adoption Framework's governance and management best practices.
• Integrate with Azure Firewall Manager (VWAN): For Virtual WAN deployments, leverage Azure Firewall Manager to centrally manage and enforce security policies across multiple Azure Firewall instances within your virtual hubs. This streamlines security operations for global networks.

Further reading

• Hub-and-spoke network topology in Azure
• What is Azure Virtual WAN?
• Migrate to Azure Virtual WAN
• Connectivity to Azure regions with Virtual WAN
• Designing an Azure Virtual Network architecture