Azure Virtual WAN, VNet peering, and Azure Route Server all influence connectivity between networks, but they operate at different architectural layers. VNet peering directly connects virtual networks. Virtual WAN provides a managed hub-and-transit architecture for large-scale branch, VNet, VPN, ExpressRoute, and SD-WAN connectivity. Route Server exchanges routes dynamically with network virtual appliances by using BGP.
For AZ-700, the challenge is choosing the right combination rather than treating the services as interchangeable. A simple two-VNet environment does not need Virtual WAN merely because it is managed. A complex hub-and-spoke environment does not become dynamic simply because peering exists. An NVA topology may need Route Server even when the virtual networks are already peered correctly.
The design starts by identifying whether the problem is direct VNet reachability, managed transit at scale, or dynamic route exchange with appliances.
VNet peering creates direct virtual-network connectivity
VNet peering connects two Azure virtual networks so resources can communicate over Microsoft’s backbone using private IP addresses.
It is a strong fit for:
- application tiers split across VNets
- traditional hub-and-spoke networking
- shared-services networks
- regional or global VNet-to-VNet connectivity
- relatively simple environments where routing is intentionally controlled
Peering does not create automatic transitive routing. If VNet A is peered with a hub and VNet B is also peered with the same hub, A and B do not automatically become directly reachable through the hub. Transit requires additional design, often through a gateway, firewall, NVA, or another routing construct.
This non-transitive behavior is one of the defining characteristics of the classic hub-and-spoke topology. The hub centralizes shared services and inspection, while spokes remain isolated unless the architecture deliberately provides transit between them.
Traditional hub-and-spoke gives control but creates routing work
A customer-managed hub VNet commonly contains shared services such as:
- Azure Firewall or third-party NVAs
- VPN Gateway
- ExpressRoute gateway
- DNS or resolver services
- management systems
Spokes peer to the hub and use user-defined routes when traffic must traverse a firewall or appliance.
This model is flexible and transparent. Network teams can define exactly which appliance handles which path. It also scales operationally only to a point. As the number of spokes, regions, branches, and route tables grows, teams can spend significant effort maintaining peering, UDRs, gateway-transit settings, and NVA routing.
The right question is therefore not “is hub-and-spoke old?” It is whether the organization benefits from the control of a customer-managed hub more than it would benefit from a managed transit service.
Address planning is a prerequisite in either model. Overlapping VNet or on-premises prefixes can block peering, complicate route propagation, or force translation designs that make operations harder. Before choosing the transit technology, reserve nonoverlapping address space for regions, spokes, platform services, and future acquisitions or branch networks. A managed routing service cannot remove ambiguity created by overlapping prefixes.
Virtual WAN provides managed hubs and managed transit
Azure Virtual WAN creates Microsoft-managed virtual hubs that can connect VNets, site-to-site VPNs, point-to-site users, ExpressRoute, and supported SD-WAN/NVA scenarios.
The virtual hub router acts as a central routing engine. It can manage route propagation, associations, hub-to-hub transit, and connectivity across multiple attached network types.
Virtual WAN becomes attractive when the organization has:
- many branches
- multiple Azure regions
- several VNets per region
- combined VPN and ExpressRoute connectivity
- a need for managed hub-to-hub transit
- SD-WAN integration
- centralized routing policy at scale
The benefit is operational simplification, not magic. The team still needs an address plan, routing intent, security architecture, DNS, segmentation strategy, and clear ownership for route tables.
A managed hub can reduce the number of individual peering and routing relationships the network team must build manually.
Virtual WAN routing depends on associations and propagation
A Virtual WAN connection participates in route tables through two related concepts.
Association determines which route table a connection uses when deciding where to send traffic.
Propagation determines which route tables learn routes from that connection.
This allows segmentation patterns in which some connections share routes and others remain isolated. For example, production spokes might propagate into one table while a restricted environment uses a different table and reaches shared services only through explicitly allowed paths.
Misunderstanding association and propagation can create surprising reachability. A VNet can be attached to the correct hub and still fail because the required route was not propagated to the route table its peer is using.
Default-route propagation deserves particular care. Advertising 0.0.0.0/0 from a security appliance or branch can intentionally centralize internet egress, but it can also redirect traffic that was expected to use Azure-native service paths. The network team should document which connections are allowed to learn a default route and which route table owns that decision.
Troubleshooting should therefore inspect the effective hub route tables rather than assuming that “connected to Virtual WAN” means “reachable from everything.”
Route Server solves dynamic routing with NVAs
Azure Route Server is designed to exchange routes dynamically between Azure networking and network virtual appliances by using BGP.
Without Route Server, an NVA topology often relies on manually maintained user-defined routes. That can become difficult when on-premises prefixes change, multiple appliances provide redundant paths, or the organization wants routing decisions to react dynamically.
Route Server can peer with supported NVAs so the appliance advertises routes and learns Azure routes dynamically. This is useful for firewalls, SD-WAN appliances, routing appliances, and other NVA-based architectures.
The service does not inspect traffic. It is a routing-control component. Data packets still flow through the selected appliance or network path; Route Server helps Azure and the appliance agree on reachability.
Route Server complements gateways rather than replacing them
A common misunderstanding is that Route Server replaces VPN Gateway or ExpressRoute gateways. It does not.
VPN Gateway terminates IPsec/IKE connectivity. ExpressRoute gateways connect VNets to ExpressRoute circuits. Route Server exchanges routing information with NVAs and supported Azure connectivity components.
Microsoft also documents route exchange scenarios between Route Server, VPN Gateway, and ExpressRoute. These designs require careful BGP and high-availability configuration because route propagation between several dynamic systems can create unexpected path preference or loops if the intent is unclear.
The architecture should define which component owns external connectivity and which component owns route exchange inside Azure.
BGP designs also need stable high availability. Route Server is deployed as a managed service with redundant instances, but the customer NVA side should peer redundantly and avoid a single appliance becoming the only valid next hop. If an appliance advertises routes dynamically, withdrawal behavior during failure should be tested so Azure stops forwarding traffic to a dead path quickly enough for the application requirement.
Choose between customer-managed transit and managed transit
A classic hub-and-spoke architecture is often appropriate when:
- the topology is relatively small
- the network team wants explicit control over every UDR and NVA hop
- a specific firewall or appliance design drives the network
- branch connectivity is limited
Virtual WAN is often stronger when:
- branch and regional scale is large
- the organization needs integrated VPN and ExpressRoute transit
- multiple virtual hubs should exchange routes
- managed routing reduces operational burden
- SD-WAN integration is a major requirement
Neither pattern is universally superior. The tradeoff is primarily between direct customer control and managed connectivity at scale.
Migration between them should also be planned carefully because routes, security inspection, DNS, and gateway connectivity can all change at once.
Security inspection must be explicit in every topology
Connectivity services do not automatically create a security architecture.
With VNet peering, direct traffic can bypass a central firewall unless UDRs or service-specific controls force the intended path. In Virtual WAN, secured virtual hubs can integrate Azure Firewall, but route intent and security policy still need deliberate design. With Route Server and NVAs, BGP may advertise a path through an appliance, but the team must verify high availability and symmetric routing.
Useful questions include:
- Which flows must cross a firewall?
- Which spokes may communicate directly?
- Which branch routes may propagate into which environments?
- Is east-west inspection required?
- Can an NVA failure black-hole traffic?
- Are return routes guaranteed to follow a compatible path?
Routing and security are coupled. A security control protects only the traffic that actually traverses it.
Troubleshooting should start from effective routes, not from intended diagrams. Compare the route table seen by the source subnet with the routes learned by the hub, gateway, Route Server, or NVA. Then verify the return path. Asymmetric routing is particularly dangerous for stateful firewalls because the forward flow can cross the appliance while the response follows another path and is dropped.
Use service roles to keep the design understandable
A clean Azure connectivity architecture assigns each component one primary responsibility.
Use VNet peering for direct VNet-to-VNet connectivity.
Use Virtual WAN when managed hub routing, branch integration, regional transit, and simplified large-scale connectivity are the dominant requirements.
Use Route Server when BGP-based dynamic route exchange with NVAs is needed.
These services can coexist. A large enterprise might use Virtual WAN for global branch and VNet transit while Route Server supports a specialized appliance scenario in one region. Another organization might keep a traditional hub-and-spoke model and add Route Server solely to remove large sets of manually maintained UDRs.
The architecture is strongest when the topology can be explained in terms of those responsibilities rather than as a collection of Azure networking products.