{"id":11738,"date":"2026-10-07T00:30:08","date_gmt":"2026-10-07T00:30:08","guid":{"rendered":"https:\/\/www.prepaway.com\/certification\/microsoft-az-104-virtual-wan-design-choices\/"},"modified":"2026-10-07T00:30:08","modified_gmt":"2026-10-07T00:30:08","slug":"microsoft-az-104-virtual-wan-design-choices","status":"publish","type":"post","link":"https:\/\/www.prepaway.com\/certification\/microsoft-az-104-virtual-wan-design-choices\/","title":{"rendered":"Microsoft AZ-104: Virtual WAN Design Choices"},"content":{"rendered":"

Azure Virtual WAN is a Microsoft-managed networking service for connecting branches, virtual networks, remote users, ExpressRoute circuits, and network virtual appliances through managed virtual hubs. It can simplify global transit compared with building and operating large custom hub-and-spoke route tables, but the managed control plane introduces its own design choices around hub placement, Standard versus Basic tier, routing tables, routing intent, secured hubs, inter-hub traffic, branch connectivity, and migration from existing networks.<\/p>\n

Microsoft’s current Virtual WAN guidance describes routing intent as a declarative way to send private and internet traffic through a security solution in a secured virtual hub. Routing intent is available on Standard Virtual WAN and can steer traffic through Azure Firewall, supported NVAs, or supported security SaaS paths. Microsoft also warns that the route-table changes made by routing intent aren’t automatically restored when routing intent is removed, so architects should treat enablement as a material routing change.<\/p>\n

Virtual WAN design belongs inside Azure Architecture in Practice<\/a>.<\/p>\n

Choose Virtual WAN for managed transit<\/h3>\n

Virtual WAN can reduce the amount of custom peering, route-table, gateway, and branch connectivity logic the platform team operates directly.<\/p>\n

network topology<\/a> remains useful for many estates, but Virtual WAN is compelling when global branch\/VNet transit and managed routing become more valuable than custom hub control.<\/p>\n

Use the service because it simplifies a defined transit problem, not because it is the newest networking pattern.<\/p>\n

Use Standard when advanced routing is required<\/h3>\n

Basic Virtual WAN has more limited connectivity capabilities.<\/p>\n

Standard supports broader hub connectivity, including VNet, site-to-site, point-to-site, ExpressRoute, inter-hub transit, and routing-intent scenarios.<\/p>\n

Architecture should verify current tier capabilities before migration because changing the transit model later can affect many connected networks.<\/p>\n

Place hubs near workloads and branches<\/h3>\n

Virtual hubs are regional resources.<\/p>\n

Global estates can deploy multiple hubs and use Microsoft’s managed inter-hub connectivity.<\/p>\n

Azure regions<\/a> should be selected from latency, data residency, recovery, capacity, and branch-location requirements rather than one central corporate location alone.<\/p>\n

Use routing intent for declarative inspection<\/h3>\n

Routing intent can steer private traffic and internet traffic through a configured security solution in the virtual hub.<\/p>\n

This reduces manual route-table management and enables inter-hub inspection when configured consistently across hubs.<\/p>\n

Because the change affects route programming broadly, test prefixes, symmetry, and application paths before enabling it across production hubs.<\/p>\n

Understand secured-hub dependencies<\/h3>\n

Routing intent requires a secured virtual hub with Azure Firewall or a supported NVA\/security provider.<\/p>\n

Azure Firewall egress<\/a> can become the internet security path, while private routing policy can steer east-west and branch traffic through the chosen security solution.<\/p>\n

The security appliance’s scale, policy, and failure behavior become part of the Virtual WAN service level.<\/p>\n

Plan branch connectivity by type<\/h3>\n

Branches can connect through site-to-site VPN, ExpressRoute, SD-WAN\/NVA integrations, or other supported paths.<\/p>\n

VPN Gateway design<\/a> and ExpressRoute resiliency<\/a> still matter at the edge of Virtual WAN.<\/p>\n

Virtual WAN simplifies hub routing but does not remove the physical or provider failure domains outside Azure.<\/p>\n

Use route tables only where policy requires them<\/h3>\n

Custom route tables can provide segmentation and routing control in Virtual WAN, but complex associations and propagations can recreate the very operational burden the service was meant to reduce.<\/p>\n

Routing intent has prerequisites around existing custom routes\/tables in the hub.<\/p>\n

Keep route domains simple enough that operators can explain where a connected VNet or branch advertises and receives prefixes.<\/p>\n

Plan migration from traditional hubs<\/h3>\n

Existing hub-and-spoke environments may already contain gateways, Azure Firewall, Route Server, NVAs, DNS, and UDRs.<\/p>\n

Move connectivity in stages, compare effective routes, preserve overlapping connectivity only where loops are impossible, and validate DNS plus security paths during coexistence.<\/p>\n

A global \u201cbig bang\u201d transit migration creates too much blast radius for most enterprises.<\/p>\n

Operate the managed network with evidence<\/h3>\n

Monitor hub routing state, connections, gateway health, security provider health, route tables, and application reachability.<\/p>\n

For AZ-700<\/a>, the durable decision is transit complexity \u2192 tier \u2192 hub regions \u2192 connection types \u2192 routing\/security policy \u2192 migration \u2192 monitored effective paths.<\/p>\n

Virtual WAN reduces infrastructure management only when the routing intent remains understandable.<\/p>\n

Internet routing policy is local to each hub; a default route for internet traffic doesn’t simply propagate across hubs. Global designs should therefore define where each region’s internet traffic is inspected and whether forced tunnel to on-premises is justified.<\/p>\n

Private routing can also include non-RFC1918 prefixes when configured explicitly. Enterprises that use unusual internal ranges or provider-assigned address space should document those prefixes so routing intent doesn’t leave a subset of traffic bypassing the expected security path.<\/p>\n

Virtual WAN cost should be evaluated with hub, gateway, routing, data-processing, firewall, and connection charges in the context of operational savings. A managed topology can cost more in service charges while saving engineering effort and reducing routing complexity.<\/p>\n

The architecture is successful when new regions, branches, and workload VNets can connect through a repeatable model without each connection requiring a custom set of UDRs and one-off transit troubleshooting.<\/p>

Virtual WAN is attractive when the platform team wants Microsoft to operate the hub router and gateway infrastructure, but that convenience changes troubleshooting. Teams need to understand Virtual WAN route tables, connection associations, propagation, routing intent, and hub state rather than relying on familiar UDRs in every VNet.<\/p>\n

Hub placement should reflect regional workload and branch distribution. A single global hub can create unnecessary latency and regional dependency, while too many hubs increase cost and policy complexity. Use enough hubs to meet latency, resilience, data-sovereignty, and scale requirements.<\/p>\n

Inter-hub connectivity is managed by Virtual WAN, but inspection across hubs requires deliberate routing-intent configuration. Microsoft notes that inter-hub security inspection depends on routing intent being enabled consistently where the security policy expects it.<\/p>\n

Routing intent changes should be treated like a major network release because the platform programs routes on behalf of connected networks. Capture current route tables and effective paths before enabling it, then validate representative branch, VNet, internet, and inter-hub flows.<\/p>\n

Secured virtual hubs can centralize Azure Firewall or supported NVA\/SaaS inspection, but the security solution still needs capacity planning, logging, policy ownership, and resilience. The managed routing layer cannot compensate for an undersized or misconfigured firewall.<\/p>\n

Custom route tables remain useful for segmentation, but avoid recreating a large manual transit fabric inside Virtual WAN. If every spoke requires custom associations and static routes, the architecture may be fighting the service instead of benefiting from it.<\/p>\n

Virtual WAN migration should include overlapping routing periods only when loop prevention is understood. Old hub-and-spoke UDRs, Route Server, VPN gateways, and Virtual WAN can interact in ways that create asymmetric or blackholed traffic.<\/p>\n

Branch onboarding should be automated where possible. Standard site definitions, BGP, connection policy, DNS, monitoring, and routing validation can make a new branch repeatable rather than a one-off network project.<\/p>\n

Cost review should consider operational labor as well as service charges. Managed hubs and gateways can be more expensive than hand-built infrastructure while reducing route-table maintenance and platform engineering effort. The correct comparison is total operating cost for the required scale.<\/p>\n

Virtual WAN is mature when a network team can add a new region, spoke, branch, or security policy through a known pattern and predict the routes that will result without manually tracing a web of UDRs.<\/p>\n

Virtual WAN route-table design should clearly define which connections associate with and propagate to each table. Segmentation requirements such as production versus shared services should be modeled deliberately instead of relying on default propagation that every team interprets differently.<\/p>\n

Hub capacity and gateway scale should be reviewed as the estate grows. More branches, VNet connections, routes, and secured traffic can require larger gateway or routing units depending on current service guidance. Managed does not mean capacity planning disappears.<\/p>\n

Operations should export or document route configuration before major changes because Microsoft warns that removing routing intent does not automatically restore the previous default route-table configuration. Reversibility must be designed explicitly.<\/p>\n

Multi-hub estates should standardize routing intent, security policy, and branch onboarding patterns by region. Inconsistent hub behavior can make the same application path work in one geography and bypass or fail inspection in another.<\/p>\n

The best Virtual WAN architecture reduces routing configuration without reducing understanding. Teams should be able to predict connectivity from a connection’s hub, route-table association, propagation, and security policy rather than treating the service as opaque managed magic.<\/p>\n

Virtual WAN can also simplify point-to-site user connectivity by providing managed VPN capabilities in the hub, but user authentication, address pools, DNS, and access policy still need enterprise design. Remote-user reach should not automatically equal branch-network reach.<\/p>\n

ExpressRoute connections to Virtual WAN should be planned with circuit diversity and recovery just as in a traditional hub. The managed hub does not eliminate provider, peering-location, or on-premises router failure domains.<\/p>\n

Network virtual appliances in the hub should be selected from supported integration patterns and tested for scaling, HA, route exchange, and policy lifecycle. The Virtual WAN control plane can steer traffic to the appliance, but it cannot make a weak NVA design resilient.<\/p>\n

Logging and topology documentation should let operators trace a connection from branch or spoke into the hub, through any security solution, toward the destination hub or VNet. This is the minimum evidence required to troubleshoot a managed transit network confidently.<\/p>\n

Virtual WAN creates the most value when the enterprise has enough branch, region, or transit complexity that a managed hub fabric reduces custom routing effort measurably.<\/p>","protected":false},"excerpt":{"rendered":"

Azure Virtual WAN is a Microsoft-managed networking service for connecting branches, virtual networks, remote users, ExpressRoute circuits, and network virtual appliances through managed virtual hubs. It can simplify global transit compared with building and operating large custom hub-and-spoke route tables, but the managed control plane introduces its own design choices around hub placement, Standard versus Basic tier, routing tables, routing intent, secured hubs, inter-hub traffic, branch connectivity, and migration from existing networks. Microsoft’s current Virtual WAN guidance describes routing intent as a declarative way to send private and internet traffic…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11738","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t