Introduction

Every Azure environment starts small, often with just a few virtual networks, a gateway for hybrid connectivity, and maybe one Network Virtual Appliance in a hub. This setup works fine at first. But as the business grows—opening new regions, adding more workloads, and needing branch office connectivity—you’ll find yourself managing many VNets and a complicated web of peering connections. Recognising this growth helps you prepare for future complexity and makes your planning easier.

Cloud architects face a key decision: should we keep the traditional hub-and-spoke design, or switch to Azure Virtual WAN? This choice can help you create a strong, scalable network that meets your organisation’s needs.

This decision is important. If you choose wisely, your network will grow smoothly with minimal extra work. If you choose poorly, you might create unnecessary complexity and costs, or end up with a design that can’t handle your growth, leading to a difficult re-architecture later. Careful decision-making can lead to smoother operations and peace of mind.

Microsoft’s Cloud Adoption Framework (CAF) considers network design as a key part of its Ready methodology, especially when planning network topology and connectivity for landing zones. CAF does not offer a single “correct” answer; instead, it gives a decision framework based on your needs – like whether you have single-region, multi-region, or global deployments and what kind of connectivity you need for branch offices. This helps architects decide between a hub-and-spoke model and Virtual WAN.

In this post, we will explain both models clearly—not just what they are, but how they behave as your environment grows. We will compare them based on important factors like routing complexity, cost, scalability limits, and operational overhead. We will align our discussion with CAF guidance, giving you a clear framework to choose the best network design for your needs today and as you grow.

Azure Hub and Spoke

The Hub-and-Spoke model is one of the most widely recognised network architectures within the Azure cloud platform, operating on a fundamental principle: the centralisation of network connectivity services within a single virtual network, referred to as the hub, while connecting individual workload networks, known as spokes, through Virtual Network (VNet) peering.

In accordance with the Cloud Adoption Framework (CAF), a dedicated subscription for networking, designated as “connectivity,” is established, and the hub virtual network is created within this subscription. All auxiliary network services, including ExpressRoute circuits, VPN Gateways, Firewalls, Private DNS Resolvers, and Azure Virtual Network Manager (AVNM), are hosted within this network and subscription.

The hub virtual network serves as the central point for connectivity and control. Typically, it houses shared resources such as:

• Centralised Firewall: Azure Firewall or a third-party Network Virtual Appliance (NVA) for network egress or ingress inspection.
• Gateway: VPN or ExpressRoute Gateway to facilitate on-premises and hybrid connectivity
• Network shared services, including Private DNS resolvers and dedicated private endpoint subnets, etc.

Each spoke virtual network represents an isolated workload or environment, such as a production application, a development environment, or application landing zones designated for specific business units. Spokes connect to the hub through VNet peering, allowing regulated traffic flow between spokes and outward connections to the internet or on-premises environments.

Key Characteristics of Hub and Spoke topology:

• Centralised control: Security, connectivity, and governance policies are managed in one place (the hub), reducing duplication across spokes
• Workload isolation: Spokes remain logically separated from each other, limiting blast radius if one is compromised
• Automation routing and peering: Route tables and peering connections are configured and maintained by the cloud team — full control with use of AVNM Services. AVNM helps to reduce the manual overhead of applying UDRs to the spoke VNets.
• Peering limits: Azure imposes limits on VNet peering connections per VNet (default 500, extendable via support request), which can become a scaling constraint in very large environments
• Cost-efficient at moderate scale: You pay for peering bandwidth and the resources in the hub (e.g., Firewall, Gateway) rather than a managed platform fee.

Where is this model Suited For

The hub and spoke network topology is best suited for the following scenarios:

1. Hub-and-spoke works well for organisations with a single region or a small number of regions, and moderate VNet counts.
2. Teams that want granular control over routing and security policy — without the added cost or abstraction of a fully managed networking platform like Azure Virtual WAN.
3. With full control over the choice of Firewall appliance. You can manage your existing on-premises firewall appliances from a single pane.

Limitations – Hub and Spoke topology:

The below lists out this topology’s limitations:

1. Scalability Concerns: As the number of spoke virtual networks grows, the Single (Hub) VNet peering limits. A standard Azure virtual network supports up to 500 virtual network peerings by default, which can be increased to 1,000 peerings using Azure Virtual Network Manager connectivity configurations. This may require creating an additional Hub or migrating to vWAN.
2. Managing multi-region connections can be complex, especially when implementing hub-and-spoke topologies across different regions. This setup necessitates establishing hub-to-hub peering through global VNet peering. Additionally, deploy VPN or ExpressRoute gateways at each regional hub.

Azure Virtual WAN (vWAN)

Azure Virtual WAN is another option in Azure cloud networking topology that consolidates various networking, security, and routing functionalities into a single interface.

Azure Virtual WAN is Microsoft’s fully managed, cloud-native networking service designed to simplify large-scale, global connectivity. vWAN provides Microsoft-managed virtual hubs that handle routing, connectivity, and traffic management as a platform capability—reducing the operational burden of scaling a DIY hub-and-spoke design.

The service provides the following key features:

• Branch connectivity via SD-WAN or VPN CPE automation.
• Site-to-site and remote user VPN connectivity.
• Private connectivity through VPN and ExpressRoute interconnectivity.
• Intra-cloud transitive connectivity for virtual networks.
• Integrated routing, Azure Firewall, and encryption for private connections.

The Azure Virtual WAN architecture follows a hub-and-spoke model, allowing for scalable branch, user, and virtual network connectivity. Azure regions act as hubs, interconnected in a full mesh structure for seamless any-to-any connectivity. Users can manually set up spoke connectivity or use automated solutions from partner SD-WAN/VPN devices for easier integration with Azure Virtual WAN.

The virtual HUB is the core of Azure Virtual WAN (vWAN). This Microsoft-managed resource automatically routes traffic between connected Virtual Networks (VNets), branch offices, and remote users without requiring customers to deploy a Virtual Network. Organisations can efficiently deploy multiple hubs across different regions or the same region, all interconnected through Microsoft’s global backbone, eliminating the need for manual configuration of inter-hub peering or routing

Key Characteristics of Azure vWAN topology:

• Routing Intent & Routing Policies: This capability enables organisations to define high-level routing intent, such as directing all internet and private traffic through a firewall, thereby reducing the complexity of managing route tables.
• Any-to-Any Connectivity: Azure VNets, branches, and users can communicate through the hub without manually configuring peering relationships between each pair.
• Higher Scale Ceilings: Designed to accommodate a significant number of VNets and branch connections, surpassing the limits of traditional VNet peering.
• Built-in Global Transit Architecture: Multiple regional hubs connect automatically, making it ideal for organisations with global operations in the same region and different regions.
• Premium Pricing Model: Users are billed for the vWAN hub itself (hourly, along with scale units) and for the resources within it. Although generally more expensive than a traditional hub-and-spoke model at smaller scales, the potential operational savings can offset the costs as complexity increases.

Where is this model Suited For

Azure Virtual WAN is particularly advantageous for organisations with a global or multi-region presence, numerous branch offices with remote connectivity, or those integrating Software-Defined WAN (SD-WAN) solutions. It is beneficial in environments where the operational burden of manually managing routing in a hub-and-spoke configuration has become cumbersome. While it sacrifices some detailed routing control, it substantially simplifies management at scale.

The key connectivity types supported within a vWAN hub include:

• VNet Connections: These link spoke VNets to the hub, functioning similarly to peering but managed directly by the platform.
• Site-to-Site VPN: This option provides Connectivity for branch offices.
• ExpressRoute: Offers private and dedicated hybrid Connectivity.
• Point-to-Site VPN: Allows remote users to connect.
• Azure Firewall (via Secured Virtual Hub): Integrates centralised traffic inspection directly within the hub.
• Third-party firewalls: VWAN supports hosting partners’ firewall network virtual appliances in the secure hub.

Limitations – vWAN topology

The following lists this topology’s limitations:

1. Limited Third-Party NVA Support: The vWAN hub supports only a specific set of vendors that integrate with the Secured Virtual Hub model. Organisations with an existing investment in an unsupported NVA vendor may need to deploy it in a separate VNet outside the hub, adding architectural complexity and partially offsetting vWAN’s simplicity benefits.
2. Reduced Routing Granularity: Virtual hubs are Microsoft-managed, which means you don’t get the same level of low-level control over route tables that hub-and-spoke offers. Routing Intent simplifies configuration significantly, but organisations with highly specific or non-standard routing requirements may find it more restrictive than manually crafted UDRs in a traditional hub.
3. Cost at Smaller Scale: vWAN uses a premium pricing model—you pay for the virtual hub itself (hourly + scale units) in addition to the resources deployed within it (Azure Firewall, gateways, etc.). For organisations with a modest number of VNets or a single-region footprint, this cost often isn’t justified compared to a well-managed hub-and-spoke design using standard VNet peering.

Zero Trust principles apply to both network topologies in the Azure cloud.

An end-to-end Zero Trust strategy assumes that security breaches are inevitable. That means you must verify each request as if it originates from an uncontrolled network. Networking still plays an important role in Zero Trust by connecting and protecting infrastructure, applications, and data. 

The following provides high-level information on how to achieve Zero Trust principles with the Hub and Spoke & Azure vWAN topology:

Zero Trust Principle	Definition	Met by Azure Hub-and-Spoke	Met by Azure Virtual WAN
Verify explicitly	Always authenticate and authorise based on all available data points.	Azure Firewall or a third-party NVA deployed manually in the hub VNet performs the same TLS inspection and traffic verification. Functionally equivalent to vWAN, but the firewall/NVA and its rules must be deployed and maintained by the team rather than provisioned as part of a managed hub. Identity-based verification still relies on Conditional Access, same as vWAN.	Azure Firewall (integrated into the Secured Hub) or third-party partners’ NVA verifies risk and threats based on available network-layer data with TLS inspection. The firewall doesn’t perform user authentication — Conditional Access handles identity-based authentication and authorisation.
Use least privileged access	Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection.	Outside the scope of network infrastructure. Delivered through identity solutions — PIM, Conditional Access, and related controls.	Outside the scope of network infrastructure. Delivered through identity solutions — PIM, Conditional Access, and related controls.
Assume breach	Minimise blast radius and segment access. Verify end-to-end encryption and use analytics to get visibility, drive threat detection, and improve defenses.	Achieves the outcome — spoke isolation and blast radius containment — but relies on manually configured User-Defined Routes (UDRs) on every spoke to force traffic through the hub firewall/NVA, plus NSGs for additional segmentation. This gives more granular control over routing behaviour, but it also means the “assume breach” containment is only as strong as the UDR configuration is consistently applied and maintained across every spoke — a manual process that becomes harder to audit as the number of spokes grows.	Spoke VNets have no access to other spokes unless traffic is routed through the firewall integrated into the vWAN hub. The firewall defaults to deny-all, so a breach in one workload has limited ability to spread — only resources in the same workload are exposed. Routing enforcement is largely automatic via Routing Intent.

Conclusion:

Thank you for taking the time to read this post. The choice of Azure cloud network topology depends on each organisation’s specific requirements and security compliance needs. I hope this post helps you determine which model best fits your needs.

Additional blog post to compare the cost of these topologies. Please visit Jose Moreno’s blog post for a comparison of the different options.