Edit

Share via

Virtual WAN network topology in an Azure landing zone

This article explains how to design and implement an Azure Virtual WAN network topology within an Azure landing zone. Azure Virtual WAN is a Microsoft-managed networking service that provides global, dynamic, and transitive connectivity across Azure regions and on-premises environments. This guidance is important because it simplifies connectivity, reduces operational complexity, and enables scalable architectures for enterprise-scale deployments.

Diagram that illustrates a Virtual WAN network topology in an Azure landing zone.

Figure 1: Virtual WAN network topology. Download a Visio file or PDF file of this architecture.

Create hub-and-spoke network architecture

Azure Virtual WAN simplifies end-to-end network connectivity in Azure, and to Azure from on-premises, by creating a hub-and-spoke network architecture. The architecture easily scales to support multiple Azure regions and on-premises locations (any-to-any connectivity) as shown in the following figure:

Diagram that illustrates a global transit network with Virtual WAN.

Figure 2: Global transit network with Virtual WAN.

Azure Virtual WAN any-to-any transitive connectivity supports the following paths within the same region and across regions:

  • Virtual network to virtual network
  • Virtual network to branch
  • Branch to virtual network
  • Branch to branch

Constraints: Virtual WAN hubs only support Microsoft-managed resources such as:

  • Virtual network gateways (point-to-site VPN, site-to-site VPN, and Azure ExpressRoute)
  • Azure Firewall via Firewall Manager
  • Route tables
  • Some network virtual appliances (NVA) for vendor-specific SD-WAN capabilities

Plan your Virtual WAN deployment

  1. Use one or more Virtual WAN Hubs per Azure region. Use a Virtual WAN hub per Azure region. The goal is to connect multiple application landing zones together across Azure regions by way of a common global Azure Virtual WAN. Virtual WAN is subject to Azure subscription limits. You can deploy multiple Azure Virtual WAN hubs in the same region to scale beyond the single hub limits.

  2. Use the connectivity subscription. Place all Virtual WAN resources, Azure Firewall, and the Azure DDoS standard protection plan in the connectivity subscription of your Azure landing zone.

  3. Use Azure DDoS Protection. Create a single Azure DDoS Network Protection plan in the connectivity subscription. All application landing zone virtual networks and platform virtual networks should use this plan. You can share an Azure DDoS Network Protection plan across all virtual networks in a single Microsoft Entra tenant to protect resources with public IP addresses. See Azure DDoS Protection. An Azure DDoS Network Protection plan includes protection for 100 public IP addresses. These public IP addresses span all protected virtual networks associated with the DDoS protection plan. Any other public IP addresses beyond the initial 100 are charged separately. For more information on Azure DDoS Network Protection plan pricing, see the Azure DDoS Protection pricing page or the FAQ. Review the supported resources of Azure DDoS Protection plans. Azure DDoS Protection plans defend against attacks at Layers 3 and 4 (network and transport layers). For protection at Layer 7 (application layer), such as HTTP-based threats, consider deploying Azure Web Application Firewall (WAF).

  4. Use a single resource group. The Virtual WAN portal experience requires that all Virtual WAN resources deploy together into the same resource group. Deploy all Virtual WAN resources in the same resource group within the connectivity subscription. This structure streamlines deployment and lifecycle management.

  5. Deploy required shared services. Deploy required shared services, like DNS servers, in a dedicated spoke virtual network. Customer-deployed shared resources can't be deployed inside the Virtual WAN hub itself.

  6. Plan for subscription limits and scalability. Don't create more than 500 virtual network connections per Virtual WAN virtual hub. If you need more than 500 virtual network connections per Virtual WAN virtual hub, you can deploy another Virtual WAN virtual hub. Deploy it in the same region as part of the same Virtual WAN and resource group. Plan your deployment carefully, and ensure that your network architecture is within the Azure Virtual WAN limits.

Connect on-premises locations and branches

  1. Use ExpressRoute. You can connect ExpressRoute circuits to a Virtual WAN hub by using a Local, Standard, or Premium SKU. For deployments in the same city, consider ExpressRoute Metro. ExpressRoute Standard or Premium circuits, in locations supported by ExpressRoute Global Reach, can connect to a Virtual WAN ExpressRoute gateway. They have all the Virtual WAN transit capabilities (VPN-to-VPN, VPN, and ExpressRoute transit). ExpressRoute Standard or Premium circuits that are in locations not supported by Global Reach can connect to Azure resources but can't use Virtual WAN transit capabilities.

    Diagram of a sample network topology.

    Figure 3: Sample network topology.

  2. Connect branches and remote locations. Connect branches and remote locations to the nearest Virtual WAN hub via Site-to-Site VPN, or enable branch connectivity to Virtual WAN via an SD-WAN partner solution. Virtual WAN integrates with various SD-WAN providers. Many managed service providers offer managed services for Virtual WAN.

  3. Connect individual users. Connect users to the Virtual WAN hub via a Point-to-Site VPN. Point-to-Site VPN provides secure remote access for users who need to connect from various locations.

Configure routing and traffic segmentation

Configure virtual hub routing to segment traffic between VNets and branches. Use Virtual WAN hub routing features to control traffic flow between VNets and branches. Create custom route tables to enforce security and compliance requirements. Ensure all Azure traffic remains on the Microsoft backbone network for optimal performance. For internet-bound traffic, configure outbound filtering through Azure Firewall.

Implement security controls

  1. Consider network virtual appliances (NVAs). You can deploy NVA firewalls into a Virtual WAN hub that performs both SD-WAN connectivity and Next-Generation Firewall capabilities. You can connect on-premises devices to the NVA in the hub and also use the same appliance to inspect all North-South, East-West, and Internet-bound traffic. When you're deploying partner networking technologies and NVAs, follow the partner vendor's guidance to ensure there are no conflicting configurations with Azure networking.

  2. Consider secured virtual hubs. A secured virtual hub is an Azure Virtual WAN Hub with associated security and routing policies configured by Azure Firewall Manager. Review the latest constraints before deployment. Virtual WAN hub-to-hub traffic that goes through Azure Firewall in both source hubs and target hubs (secured virtual hubs) is supported when you enable routing intent and policies. Use Virtual WAN hub routing intent and routing policies to support traffic that goes between secured hubs. Virtual WAN secured virtual hubs don't support Azure DDoS standard protection plans. For more information, see Azure DDoS Protection, Azure Firewall Manager known issues, and Hub virtual network and secured virtual hub comparison.

Manage and monitor your deployment

Configure Azure Monitor insights to monitor the end-to-end topology of your Virtual WAN. Insights in Azure Monitor for Virtual WAN provide visibility into network status, connection health, and key metrics for proactive management. Configure alerts for critical thresholds to detect and respond to issues before they affect users.

Migrate existing hub-and-spoke topologies

For brownfield scenarios where you're migrating from a hub-and-spoke network topology not based on Virtual WAN, see Migrate to Azure Virtual WAN.