Connectivity is the part of a landing zone that platform teams should own and almost never hand out. The first big decision is the topology: do you build and operate a classic hub-and-spoke network yourself, or let Microsoft run the backbone for you with Azure Virtual WAN? Both are valid. The right answer depends on scale, operational appetite, and how much routing control you actually need.
Short version: hub-and-spoke gives you maximum control and minimum magic. Virtual WAN gives you managed scale and global reach with fewer knobs. Most organizations should start with one hub and only reach for Virtual WAN when scale or geography forces it.
The two topologies at a glance
Hub-and-spoke
You deploy a hub virtual network that hosts shared services — Azure Firewall or an NVA, DNS, ExpressRoute/VPN gateways — and peer each workload VNet (a “spoke”) into it. You own the route tables, the peering, and the egress path. It is well understood, transparent, and infinitely tunable. It is also yours to operate: every new region or large-scale spoke count means more peering and routing to manage by hand (or by code).
Azure Virtual WAN
Virtual WAN is a Microsoft-managed networking service. You create virtual hubs (one per region), and Azure handles the hub-to-hub backbone, transit routing, and branch/VPN/ExpressRoute aggregation. Spokes connect to a virtual hub and get any-to-any connectivity without you building a full mesh of peerings. You trade some routing control for managed scale and global transit.
flowchart LR
subgraph HS["Hub-and-Spoke (self-managed)"]
direction TB
H["Hub VNet
Firewall · DNS · Gateway"]
H --- S1["Spoke: Prod"]
H --- S2["Spoke: Non-prod"]
H --- S3["Spoke: Shared"]
end
subgraph VW["Virtual WAN (Microsoft-managed)"]
direction TB
VH["Virtual Hub
(managed routing)"]
VH --- V1["Spoke: Prod"]
VH --- V2["Spoke: Non-prod"]
VH --- BR["Branch / VPN / ER"]
end
How to choose
Run your scenario through these five lenses.
1. Scale and number of regions
One or two regions and a manageable number of spokes? Hub-and-spoke is simple and cheap. Many regions, global transit, or hundreds of spokes and branch sites? Virtual WAN’s managed any-to-any routing earns its keep and saves you from hand-building a peering mesh.
2. Routing control
If you need granular, custom control — specific UDRs, service chaining through multiple NVAs, exotic egress paths — hub-and-spoke gives you every knob. Virtual WAN supports custom route tables, but within a more opinionated, managed model. Heavy bespoke routing leans hub-and-spoke.
3. Operational appetite
Hub-and-spoke is more to run: you own gateway scaling, route propagation, and regional expansion. Virtual WAN offloads the backbone to Microsoft. If your platform team is small, the managed option reduces toil.
4. Branch and remote connectivity
Connecting lots of physical sites, SD-WAN, or many VPN endpoints is exactly what Virtual WAN was built for — it aggregates branch connectivity natively. A handful of site-to-site tunnels is fine on a classic hub.
5. Cost model
Hub-and-spoke costs are mostly the resources you deploy (gateways, firewall, peering egress). Virtual WAN adds hub and connection-unit and data-processing charges. At small scale hub-and-spoke is usually cheaper; at large multi-region scale Virtual WAN can be cheaper per unit of capability once you price in the operational effort it removes.
Decision summary
Quick guide
- Choose hub-and-spoke for one or few regions, maximum routing control, bespoke NVA chains, or tight cost control at modest scale.
- Choose Virtual WAN for many regions, global transit, large spoke/branch counts, or a small team that wants Microsoft to run the backbone.
- Don’t over-engineer. A single hub with a firewall and central DNS covers most organizations for a long time.
- Migration is feasible. Starting hub-and-spoke and moving to Virtual WAN later is a known path — so optimize for today, not a hypothetical future.
Tip: whichever you pick, define it once in the platform connectivity subscription and let workloads inherit it. Private Endpoints, Private DNS, and egress control should never be a per-team decision.
Rule of thumb: let scale and geography make the call. If you can’t articulate a concrete reason you need Virtual WAN, you probably don’t yet — and hub-and-spoke will teach you exactly where the limits are.
This is the connectivity layer of the foundation covered in Azure Landing Zones: A Practical Architect’s View. Up next in the series: identity foundations for platform teams.