Microsoft AZ-700: Hub-and-Spoke and Virtual WAN Design

Hub-and-spoke and Azure Virtual WAN can both centralize connectivity, but they do so with different operational models. The design choice affects routing, branch integration, security insertion, DNS, private connectivity, scale, automation, and who owns the network fabric. For Microsoft AZ-700 candidates, the useful skill is not memorizing which diagram belongs to which service; it is choosing an architecture from traffic flows and operating requirements.

The Microsoft AZ-700 exam remains current, with Microsoft’s July 27, 2026 skills outline still centered on core networking, routing, connectivity, monitoring, and network security. That makes architecture trade-offs more important than a product-comparison checklist.

Start with traffic and ownership

List branch, on-premises, spoke, internet, private endpoint and cross-region traffic flows. Name the team that owns routing, firewall insertion, DNS and shared services. Record scale expectations for subscriptions, VNets, branches and regions. Define whether the network platform is centrally managed or intentionally delegated.

A topology should follow operational responsibility. Two diagrams can look similar while creating very different change and troubleshooting models.

When a hub uses an Azure Firewall or third-party NVA, the route design should state exactly which traffic must traverse the appliance and how return traffic stays symmetric. Default routes and propagated routes can create surprising bypass or hairpin behavior. Use route tables and effective-route inspection during validation. Security insertion should be an intentional service path, not a side effect of whichever route currently has the strongest preference.

Classic hub-and-spoke offers explicit control

A hub VNet can host shared connectivity, firewalls, DNS and management services. VNet peering connects spokes, but transitive routing is not automatic. User-defined routes and security appliances often shape spoke-to-spoke or hybrid paths. Teams must manage hub capacity, route tables and peering relationships as the environment grows.

Classic hub-spoke is attractive when architects need direct control and the scale remains manageable. The trade-off is that the organization owns more of the routing and service-insertion design.

Virtual WAN routing intent and hub route-table associations can simplify large fabrics, but they also centralize policy. Document which spokes and branches associate with which route tables and which prefixes are propagated. Changes should be reviewed for cross-region and cross-branch impact. A managed fabric reduces manual peering but does not remove the need to understand who can reach whom and through which security path.

Virtual WAN provides a managed transit fabric

Virtual WAN hubs can centralize branch, VNet and remote-user connectivity. Managed routing reduces some manual peering and route-table work. Integration with VPN, ExpressRoute and security services can simplify large distributed estates. Architecture still requires deliberate routing intent, segmentation and regional planning.

Virtual WAN does not eliminate networking design; it changes where that design is expressed. Teams still need to understand propagation, associations, secure hubs, and how traffic traverses the managed fabric.

Compare scale and operational effort

In production, Count how many hubs, peerings, route tables and appliances a classic design will require. Estimate branch and multi-region growth. Consider whether platform teams can automate and observe the custom topology reliably. Include service limits and operational review effort in the architecture decision.

A small environment can become difficult if its hub-spoke design grows through ad hoc exceptions. Conversely, a managed transit service may be unnecessary overhead for a simple network with limited connectivity.

Branch connectivity rarely has one profile. Small sites may use VPN, large sites may prefer ExpressRoute, and mobile users may rely on different remote-access services. Architecture should support the service mix without turning every branch into a unique exception. Standardize connection patterns, routing expectations, DNS, security, and monitoring so operations teams can troubleshoot a branch from known baselines.

Plan routing as policy

Document which prefixes each spoke or branch may learn. Control propagation so segmentation intent survives route exchange. Account for default routes, firewall paths and asymmetric-routing risks. Test the route a packet actually takes, not only the intended logical diagram.

Routing is the mechanism that turns topology into behavior. The Azure Networking Design Patterns article is useful background for failure modes that appear when route ownership is unclear.

Insert security without creating black boxes

Decide where firewall inspection is required and which flows can remain direct. Keep security-policy ownership aligned with routing ownership. Understand how secure hubs or third-party appliances affect route propagation. Virtual WAN and VPN Security adds security-boundary context, while the transit design still has to make route propagation, inspection, and failure behavior explicit.

Central inspection can simplify governance, but it can also add latency, cost and failure dependencies. Not every flow needs the same security path.

A multi-region design needs a clear answer for what happens when a hub, circuit, or region becomes unavailable. Virtual WAN can provide managed transitive connectivity, while classic architectures may require explicit secondary hubs and route changes. Test the degraded topology and measure convergence. Recovery planning should include stateful network appliances and private endpoints because traffic restoration alone may not restore application dependencies.

Integrate hybrid connectivity intentionally

ExpressRoute and VPN solve different bandwidth, reliability and cost requirements. Design redundancy across circuits, gateways and regions where the business requires it. Account for route exchange between on-premises and Azure transit. Test failover from an application perspective.

Hybrid networking is not complete when the tunnel is green. DNS, routing, security and application dependencies must also recover.

DNS and private connectivity shape the topology

Private endpoints can introduce DNS dependencies that cross hub and spoke boundaries. Central resolvers or Azure DNS Private Resolver designs need clear forwarding ownership. Name-resolution paths should be documented separately from IP routing. Test private service resolution from each relevant network context.

Many ‘network’ incidents in hub-spoke estates are actually DNS-path incidents. Architecture reviews should make that dependency visible.

Organizations often move from a custom hub-spoke estate toward Virtual WAN gradually. Define coexistence boundaries, avoid overlapping route authority, and decide which new connections land on the target architecture. Move representative workloads first and validate routing, security, DNS, and monitoring. A migration that leaves permanent dual transit paths without clear ownership can be harder to operate than either architecture by itself.

Monitor the fabric and the service

Collect route, gateway, connection, firewall and flow telemetry. Define alerts around customer-impacting conditions rather than every state change. Correlate network events with application latency and availability. Use controlled failover tests to validate monitoring and response.

AZ-700 expects operational awareness as well as design. A network that cannot explain why traffic changed path is not truly manageable.

Architecture decisions affect gateway, hub, firewall, data-processing, peering, and egress costs as well as engineering effort. Compare total operating cost, not just one service’s hourly price. A custom hub can be cost-effective for a contained estate if the team can automate it safely; Virtual WAN can reduce operational complexity as connectivity scales. Revisit the decision when branch count, regions, security insertion, or organizational ownership changes materially.

Classic hub-spoke favors explicit control and can suit contained environments. Virtual WAN favors managed transit and can simplify broad branch/multi-region connectivity. Hybrid designs can exist during migration but need a clear end state. Record the decision criteria so future teams know when the architecture should be revisited.

Within Microsoft Azure certifications, AZ-700 is the networking-focused path and connects design choices to adjacent infrastructure roles. The strongest design is the one whose routing, security and operational model can still be explained after the environment doubles in size.

Addressing and route summarization should be considered before choosing either transit model. Hub-and-spoke environments with overlapping prefixes, poorly planned spoke CIDRs, or inconsistent on-premises advertisements become difficult to migrate into a managed transit fabric. A clean address plan improves route propagation, firewall policy, DNS forwarding, and troubleshooting. If overlap cannot be removed, document where translation or isolation is required instead of assuming the transit service will solve the ambiguity.

Operational ownership is often the deciding factor between architectures that are technically capable of the same flow. A networking team comfortable with infrastructure-as-code, custom routing, and appliance operations may prefer a controlled hub design; a distributed organization may gain more from Virtual WAN’s managed connectivity model. AZ-700 reasoning should therefore include who will operate the network after deployment, how changes are approved, and how quickly the team can explain a failed path during an incident.

Private connectivity can strongly influence the transit decision. Private endpoints, service endpoints, Azure DNS Private Resolver, and centrally hosted DNS forwarders may depend on hub reachability and specific route paths. Map those dependencies before changing the transit fabric so a migration does not restore application IP connectivity while breaking name resolution or access to private services. In complex estates, test a representative set of private PaaS services from each connectivity domain, including branches and on-premises networks.

Governance should also define how new spokes and branches are onboarded. A repeatable intake should allocate address space, establish route association and propagation, attach security controls, configure DNS, enable monitoring, and validate expected flows before production use. Without that standard, both classic hub-spoke and Virtual WAN designs accumulate one-off exceptions that undermine the architecture. AZ-700 design maturity is visible in how predictably the network can add another workload or site without inventing a new connectivity pattern.

A sound design also leaves enough address and route-table headroom for the next region or branch, so ordinary growth does not force an emergency transit redesign. Route-scale assumptions should be tested before expansion so address growth and propagation limits remain architectural choices rather than emergency constraints.