Hub-and-spoke at scale — Virtual WAN hubs and routing intent, Azure Virtual Network Manager groups, connectivity, security admin rules, UDR management and IPAM
Two ways to run many VNets — Virtual WAN (Basic hubs do site-to-site VPN only; Standard hubs add transit, ExpressRoute, P2S, Firewall and NVAs; hub space /24 minimum, /23 advised; routing intent with one internet and one private policy) and Azure Virtual Network Manager (static or Policy-driven network groups, mesh or hub-and-spoke, security admin rules evaluated before NSGs, routing configurations, IPAM, and per-region deployment).
markdownreferencev16XK4-42N8stage: designtrust: officialservice: networkinginterface: iacinterface: portalAzure Virtual WANBasic Virtual WAN site-to-site onlyStandard Virtual WANupgrade Basic to Standard Virtual WANvirtual hub address space /24/23 recommendedrouting intentInternet Traffic Routing PolicyPrivate Traffic Routing Policysecured virtual hubAzure Virtual Network Managernetwork group static dynamic membershipAzure Policy network groupconnectivity configuration mesh hub-and-spokeconnected groupsecurity admin rulesAlways Allowsecurity admin rules before NSGone security admin configuration per regiondeployment commit regionsconfigurations don't take effect until deployedrouting configuration UDR managementIPAM IP address poolsnetwork manager scope management group
Hub-and-spoke at scale
Hand-built hubs (peering, UDRs, a firewall: reference/networking/vnets-subnets-and-peering.md) work for a few VNets. Past that, Microsoft offers a managed hub (Virtual WAN) and a manager for your own hubs (Virtual Network Manager). The hub's reading: pick Virtual WAN when branches, VPN and ExpressRoute dominate; pick Virtual Network Manager when you keep your own hub VNets and want policy-driven peering, security rules and routes across many subscriptions.
Virtual WAN
| Type | Hubs can do |
|---|---|
| Basic | Site-to-site VPN only; no gateway scale units |
| Standard | ExpressRoute, point-to-site, site-to-site, transit between VNets and between hubs (each hub has a router; Standard hubs are full mesh), Azure Firewall, NVAs |
- Basic upgrades to Standard (delete any existing hub routes first); there is no way back.
- A hub's address space is at least /24; Microsoft advises /23 or larger at creation. It mustn't overlap connected VNets or branches.
- Routing intent: at most one Internet and one Private routing policy per hub, each with a single next hop (Azure Firewall, an NVA or a SaaS security solution in the hub). The internet policy advertises 0.0.0.0/0 to every spoke, gateway and NVA; the private policy sends all branch, VNet and inter-hub traffic through the next hop. A hub with Azure Firewall or a security NVA is a secured hub.
- DDoS Protection plans don't cover Virtual WAN (
reference/networking/firewall-and-ddos.md).
Azure Virtual Network Manager
- Scope: management groups and/or subscriptions the manager may configure. Above 15,000 subscriptions, Microsoft's policy integration works at subscription and resource group scopes only.
- Network groups: global sets of VNets, joined statically (you pick them) or dynamically (an Azure Policy definition and assignment add matching VNets). Cross-tenant VNets join only statically. A VNet can be in many groups.
- Connectivity configurations: hub-and-spoke (peerings to a hub VNet, optionally using its gateway) or mesh (a connected group, a construct of its own rather than peerings, where every member reaches every other directly; overlapping members' traffic is dropped). With delete existing peerings on, the manager removes peerings that don't match the configuration, including hand-made ones.
- Security admin rules apply to VNets and are evaluated before NSGs.
Allowhands the flow on to NSGs;Always AllowandDenystop evaluation, so an NSG can't override them. Use them for organisation-wide guardrails, and leave application rules to NSGs. - Routing configurations create and maintain UDRs on target groups' subnets from route rules (for example, send spokes to a firewall). IPAM pools hand out non-overlapping CIDRs and track reservations.
- Nothing takes effect until you deploy it to chosen regions. Only one security admin configuration and one routing configuration per region can be deployed from a manager at a time (put more rules in more rule collections); several connectivity configurations can coexist. A VNet that joins a group later gets the group's already-deployed configurations automatically in that region (static members at once, Policy-added members after minutes or longer at large scale).