Azure Virtual WAN configuration best practices

[BeatrizSilveira]

Azure Virtual WAN is a networking service that combines networking, security, and routing features in one managed service. It is a hub-and-spoke architecture managed by Microsoft that integrates with other Azure services, such as VPN gateways and Azure Firewall, and partner solutions. It aims to simplify network management and configuration, and enhance performance and reliability, using Microsoft’s global network.



To learn more about Virtual WAN’s features, see Azure Virtual WAN Overview | Microsoft Learn. For the complete list of supported partner solutions in Virtual WAN, see About NVAs in a Virtual WAN hub.



This article details Virtual WAN configuration best practices to help you make the most of the benefits Virtual WAN provides. These best practices are aligned to the five pillars of the Azure Well-Architected Framework:

• Reliability
• Security
• Cost optimization
• Operational excellence
• Performance efficiency

Reliability



Design checklist

• Leverage Availability Zones resiliency.
• Adopt active-active configuration in Virtual WAN Site-to-Site VPN deployments.
• Use global VPN profile for more reliable point-to-site connections to Virtual WAN.
• Allocate a P2S VPN client address pool with enough IP addresses as two times the number of users connecting at the same time.
• Choose Network Virtual Appliance (NVA) or Software-as-a-service (SaaS) solutions that integrate natively into the virtual hub.
• Review the list of Virtual WAN Known Issues and feature limitations before implementation.

The following table details all the recommendations, and their benefits, mentioned above to optimize your Azure Virtual WAN configuration for reliability.

Recommendation	Benefit
When planning your Virtual WAN deployment, choose an Azure region(s) to create your hub(s) that supports Availability Zones, for a higher service-level agreement (SLA). For more information, see Availability Zone service and region support. Deploy your hub’s Azure Firewall(s) across Availability Zones too, for higher SLA. To do so, use Azure Firewall Manager Portal, PowerShell, or Azure CLI.	Except for Azure Firewall, all services deployed in a Virtual WAN hub (VPN, ExpressRoute, etc.) will be automatically deployed across Availability Zones, if the deployment region supports this feature. Deploying the hub’s services across Availability Zones increases Virtual WAN’s service-level agreement (SLA). For more information, see SLA for Azure Virtual WAN. For information about all Azure SLAs, see SLA summary for Azure services.
Leverage the built-in resiliency of hub VPN gateways by fully adopting an active-active configuration in your Site-to-Site VPN deployments. When creating a VPN connection to an on-premises site, make sure to establish a tunnel between the on-premises device(s) and each VPN gateway instance. It is highly recommended to become familiar with the concepts of VPN connection, link, and tunnel in Virtual WAN. For more information, see Azure Virtual WAN FAQ | Microsoft Learn.	All gateways provisioned in a Virtual WAN hub are in active-active mode, but to take advantage of this built-in resiliency, you must establish a separate tunnel between your on-premises device(s) and each gateway instance. Doing so will ensure your connections to Virtual WAN are resilient and reliable. To learn more about different high availability designs for Site-to-Site VPN in Virtual WAN see: Disaster recovery design for Azure Virtual WAN | Microsoft Learn.
Virtual WAN provides two types of connection profiles for User VPN clients – hub profile and global profile. It is recommended to use a global profile when having multi-hub Virtual WAN deployments, unless there is a specific requirement to restrict access to a certain hub only. For more information on User VPN Profiles in Virtual WAN, see P2S global and hub profiles.	When using a global profile, VPN clients connect to the closest available virtual hub that offers the best network performance, thanks to a built-in traffic manager. This configuration also increases resiliency, as the global profile is capable of redirecting users to a back-up Virtual WAN hub. To learn more about remote user connectivity resiliency in Virtual WAN, see Disaster Recovery design.
To ensure all users can connect, even if one P2S VPN gateway instance is down, allocate a client address pool with a number of IP addresses twice the amount of users connecting at the same time. To learn more about client address pools for Virtual WAN P2S configurations, see About client address pools for P2S User VPN - Azure Virtual WAN | Microsoft Learn.	When creating a P2S VPN gateway, you must configure a client address pool from which IP addresses will be automatically assigned to VPN clients. Assigned address pools are split into half and allocated to each gateway instance. These halves are statically assigned to instances and cannot migrate during maintenance or downtime events. Having a pool of IPs that is twice the number of users ensures all clients are still able to connect in case a gateway instance is down.
Whenever possible, choose to deploy a supported NVA or SaaS solution in the virtual hub over running such services in a spoke. For the list of supported partners, see NVA in Virtual WAN hub and Software-as-a-Service in Virtual WAN.	Supported solutions in the hub have been tested and validated by Microsoft and the partner. Natively integrated solutions leverage on the built-in availability and resiliency of Virtual WAN and integrate more seamlessly with other Virtual WAN features, such as Routing Intent, among other benefits.
Review the list of Virtual WAN known issues and feature limitations (Routing Intent limitations, for example) before implementation. For all the information on recent releases, known issues, and feature limitations, see What's new in Azure Virtual WAN? | Microsoft Learn.	Because Virtual WAN deployments often involve the creation of different network services, reviewing this information prior to implementation helps plan your deployment better and avoid future issues.

Security



Design checklist

• Leverage secured virtual hub(s). Use Routing Intent to secure private and internet traffic.
• Follow Azure Firewall or third-party security provider configuration best practices.
• Leverage Private Link to connect to Azure PaaS services from Virtual WAN.
• Use Network Security Groups (NSGs) in spoke VNets to control intra-VNet traffic.
• Use site-to-site/user VPN or ExpressRoute to access Virtual WAN connected networks securely and privately.
• Use Azure Firewall DNAT rules, or a similar feature if using a supported NVA, to securely expose non-http(s) applications on the internet. Use Azure Application Gateway to securely expose http(s) applications on the internet.
• Protect public IPs in spoke virtual networks against DDoS attacks using Azure DDoS Network or IP Protection.
• Apply Zero Trust Principles when configuring Virtual WAN.

Recommendations



The following table details all the recommendations, and their benefits, mentioned above to optimize your Azure Virtual WAN configuration for security.

Recommendation	Benefit
Create secured virtual hub(s) by deploying Azure Firewall or a supported partner solution, (NVA or SaaS), in the hub.	In a secured virtual hub, you can enforce a routing policy using Routing Intent to inspect private and internet traffic using he security solution deployed in the hub. This increases the overall security of your Virtual WAN deployment.
Follow Azure Firewall or third-party security provider configuration best practices.	Following your firewall provider’s configuration guidance ensures your Virtual WAN deployment remains secure and reliable.
To secure access to PaaS services from Azure and non-Azure clients, create Private Endpoints to those services in a spoke virtual network connected to any virtual hub. To learn more about how to use Private Link in Virtual WAN, see Share a private link service across Virtual WAN - Azure Virtual WAN | Microsoft Learn.	Azure Private Link allows you to access PaaS services without having a public endpoint on those services. You can continue to leverage Private Link in Virtual WAN, and even secure traffic to private endpoints using Azure Firewall in the hub. To learn more about this scenario, see Secure traffic destined to private endpoints in Azure Virtual WAN | Microsoft Learn.
Use Network Security Groups (NSGs) in spoke virtual networks to control intra-VNet traffic. If there is a requirement to inspect traffic between subnets of the same VNet, add a subnet level UDR for each subnet whose traffic you want to force through the firewall. For example, if you want to inspect traffic between subnet 10.3.0.0/26 and subnet 10.3.1.0/24, add a route table to subnet 10.3.0.0/26 containing a 10.3.1.0/24 UDR with next hop Azure Firewall or NVA Private IP and vice-versa. See Azure virtual network traffic routing | Microsoft Learn to learn more.	Virtual WAN hub can’t attract traffic between two subnets in the same virtual network. For this reason, it is recommended to apply NSGs at subnet level to control traffic between subnets. For more routing considerations, see About virtual hub routing - Azure Virtual WAN | Microsoft Learn. Even though using NSGs to control intra-VNet traffic is less error prone, it is still possible to inspect traffic between subnets of the same VNet using subnet level UDRs.
Whenever possible, use site-to-site/user VPN and/or ExpressRoute to access workloads in spoke virtual networks connected to the virtual hub, including RDP/SSH access. For sites where the above connectivity options are not feasible, consider deploying Azure Bastion in a connected spoke virtual network to access virtual machines. To learn more about how Azure Bastion integrates with Virtual WAN, see Azure Bastion FAQ | Microsoft Learn.	Leveraging site-to-site VPN or User VPN ensures you can securely access your Virtual WAN connected networks over the public internet. Azure ExpressRoute, on the other hand, offers a highly reliable and secure connection that does not traverse the public internet. Azure Bastion lets you securely RDP/SSH to Azure virtual machines, and even on-premises machines, using IP-based connections, without exposing a public IP on target machines.
For publicly facing, non-http(s), workloads running in spoke virtual networks, it is recommended to securely expose them on the internet through a DNAT rule in Azure Firewall (or running in the hub. Deploy Azure Application Gateway in a spoke virtual network to securely expose publicly facing, regional, http(s) applications, also running in spoke virtual networks. You can also leverage Application Gateway’s features to access privately facing http(s) applications. To learn more about Application Gateway’s features, see What is Azure Application Gateway | Microsoft Learn.	Leveraging Azure Firewall and/or Application Gateway to expose your applications ensures client traffic is always inspected before being sent to the application servers, which can be kept private. Azure Firewall offers advanced threat protection features, such as Threat intelligence-based filtering or IDPS, whereas Application Gateway can protect applications against L7 DDoS attacks using WAF, as well as L3 and L4 attacks when combined with Azure DDoS protection. Azure Firewall and Application Gateway can also be combined in the same design to benefit from the features of both services. To learn more about possible designs, see Firewall, App Gateway for virtual networks - Azure Example Scenarios | Microsoft Learn.
Enable Azure DDoS Network Protection in spoke virtual networks containing services with public IPs. Alternatively, enable protection on specific public IPs using DDoS IP Protection. It is not possible to enable DDoS protection on services deployed in the Virtual WAN hub at this time.	Azure DDoS Protection provides always-on traffic monitoring, adaptive real time tuning, metrics and alerts for protected virtual networks and public IPs, to ensure services with public endpoints remain available. To learn more, see Azure DDoS Protection Overview | Microsoft Learn.
In addition to the best practices described in this article, apply Zero Trust principles to your Azure Virtual WAN deployments by following the configuration guidance described here: Apply Zero Trust principles to Azure Virtual WAN | Microsoft Learn.	Increase security even more in your Virtual WAN deployment by applying Zero Trust principles in your configuration – verify explicitly, use least privileged access, and assume breach.

Cost optimization



Design checklist

• Understand Virtual WAN pricing components and data transfer costs.
• Estimate throughput requirements in advance to achieve cost-effectiveness when selecting gateway scale units and virtual hub capacity.
• Monitor and optimize the utilization of hub services to maintain cost-effectiveness.
• Keep in mind security and throughput requirements when selecting an Azure Firewall SKU.
• Optimize VWAN routes to minimize costs. Consider the cost implications of transferring data between different Virtual WAN components.

Recommendations



The following table details all the recommendations, and their benefits, mentioned above to optimize your Azure Virtual WAN configuration for cost optimization.

Recommendation	Benefit
Virtual WAN deployments often involve the creation of different networking services, such as gateways or firewalls. It’s important to be aware of the costs associated with the use of these services, as well as data processing charges. A detailed breakdown of Virtual WAN costs can be found here: About Virtual WAN pricing - Azure Virtual WAN | Microsoft Learn.	By understanding Virtual WAN pricing beforehand, you’re able to plan your deployment better and make an informed decision on what services should be included/excluded from the design, for example, therefore avoiding unexpected costs in the long run.
Estimate throughput requirements in advance to achieve cost-effectiveness when selecting gateway scale units and virtual hub capacity. While the virtual hub router is capable of scaling out, it is important to secure enough minimum capacity when creating the virtual hub. To learn more about virtual hub capacity, see About virtual hub settings - Azure Virtual WAN | Microsoft Learn. To learn more about gateway scale units, see About gateway settings for Virtual WAN - Azure Virtual WAN | Microsoft Learn.	This will allow you to select the appropriate number of scale units for your hub gateways and number of routing infrastructure units for your virtual hub, which can be adjusted if needed and allow you to avoid overspending.
Leverage Virtual WAN metrics to monitor the utilization of hub services to maintain cost-effectiveness. To learn more about supported Virtual WAN metrics and recommended alerts, see Monitoring Virtual WAN - Best practices - Azure Virtual WAN | Microsoft Learn.	By continuously monitoring the utilization of hub services, in particular hub gateways, you’re able to quickly detect if these services are underutilized, and if so, adjust the number of scale units accordingly.
Azure Firewall comes in three SKUs, with different features and pricing associated. Choose the SKU that fulfills your security requirements, as well as throughput needs. For a feature comparison across the three Azure Firewall SKUs, see Choose the right Azure Firewall version to meet your needs | Microsoft Learn.	Selecting the appropriate Firewall SKU ensures you don’t incur unnecessary costs in your Virtual WAN deployment.
Optimize your Virtual WAN environment to minimize costs. Consider the cost implications of transferring data between different Virtual WAN components. For example, clients should access spoke virtual networks in a region primarily through the hub where those spokes are connected in the same region. From a cost perspective (and performance), this is a better approach when compared to accessing a spoke in region B through a hub in region A first, which requires traversing the hubs in both regions. This latter approach implies inter-hub and inter-region processing charges, whereas the former doesn’t. To learn more about Virtual WAN pricing, see About Virtual WAN pricing - Azure Virtual WAN | Microsoft Learn.	Optimizing your Virtual WAN environment ensures your deployment remains cost-effective. By accessing latency-sensitive workloads directly via the hub connected to these spoke virtual networks, you will also experience better traffic performance.

Operational excellence



Design checklist

• Use Infrastructure-as-Code (IaC) technologies to provision and maintain your Virtual WAN deployment.
• Leverage Azure Monitor Insights to keep track of Virtual WAN topology, services deployed, and dependencies.
• Configure Azure alerts to quickly detect and act on connectivity and performance issues.
• Leverage customer-controlled gateway maintenance.
• Assign a /23 subnet when creating virtual hubs.

Recommendations



The following table details all the recommendations, and their benefits, mentioned above to optimize your Azure Virtual WAN configuration for operational excellence.

Recommendation	Benefit
Use Infrastructure-as-Code (IaC) technologies, such as Azure Resource Manager (ARM) templates or Bicep, to provision and maintain your Virtual WAN deployment.	Provides consistency and acts as a safeguard in case there’s a need to redeploy your Virtual WAN.
Leverage Azure Monitor Insights to monitor your Virtual WAN deployment.	Azure Monitor Insights for Virtual WAN provides a centralized view of your Virtual WAN topology, services deployed and dependencies, as well as metrics at hub, gateway, and connection level.
Closely monitor health and utilization metrics for hub services like VPN (point-to-site or site-to-site), ExpressRoute, or Azure Firewall. You can also configure alerts for these metrics. Configure Azure alerts to quickly detect and act on connectivity and performance issues. For a list of recommended alerts, see Monitoring Virtual WAN - Best practices - Azure Virtual WAN | Microsoft Learn. For the complete list of supported Virtual WAN metrics and logs, see Monitoring Azure Virtual WAN - Data reference | Microsoft Learn.	Proactively configuring alerts for key Virtual WAN metrics and logs minimizes the chances of downtime, which is crucial in a production environment.
Configure a maintenance window1 for site-to-site VPN and ExpressRoute gateways. To learn more about this feature, see Azure Virtual WAN FAQ | Microsoft Learn.	Gives customers more control over periodic maintenance updates. Guest OS and Service maintenance events will happen during the window specified by the user.
A Virtual WAN hub requires a /24 minimum subnet size, however, the recommended subnet size at creation is /23, to accommodate the creation of multiple hub services such as gateways, Azure Firewall, the virtual hub router, or NVAs.	The virtual hub’s address space cannot be changed after creation. Thus, to avoid having to redeploy your virtual hub and experiencing downtime, make sure you create your hub with enough address space in advance to enable the creation of planned hub services, as well as to accommodate potential changes to the design in the long run. To learn more about subnet size requirements in Virtual WAN, see Azure Virtual WAN FAQ | Microsoft Learn.

1Customer-controlled gateway maintenance is currently in public preview, and is therefore not recommended for production environments. To learn more about this feature, see Configure customer-controlled maintenance for your Virtual WAN gateways.



Performance efficiency



Design checklist

• Consider the per-hub limits when choosing how many virtual hubs to create in each region.
• Review the routing implications of redundant connectivity when planning for high availability and disaster recovery in Virtual WAN.
• Choose the hub routing preference option that works best for your scenario.
• Prioritize hub-to-hub path over ExpressRoute for VNet-to-VNet connectivity.
• Estimate the need per VPN tunnel when planning for a VPN gateway.
• Use the GCMAES256 algorithm for both IPSec Encryption and Integrity for optimal performance when configuring VPN site-to-site connections.
• Regularly monitor the utilization of virtual hub gateways (VPN or ExpressRoute) and resize when needed.
• Monitor virtual hub capacity.

Recommendations



The following table details all the recommendations, and their benefits, mentioned above to optimize your Azure Virtual WAN configuration for performance efficiency.

Recommendation	Benefit
Evaluate if your regional presence exceeds or is near to reaching the capacity of a single virtual hub. Additional hubs in the same region can be added if there is a requirement to scale beyond the limits of a single hub, or if there’s a requirement for a different hub configuration. To learn more about Virtual WAN limits, see Azure subscription limits and quotas - Azure Resource Manager | Microsoft Learn.	Ensures your Virtual WAN maintains optimal performance.
Review the routing implications of redundant connectivity for VPN (Site-to-Site, Point-to-Site) and ExpressRoute when planning for high availability and disaster recovery in Virtual WAN. Having more than one path to the same network can cause asymmetric routing or lead to suboptimal performance when not properly architected. This is why it is important to review supported designs and their routing implications, detailed in this article: Disaster recovery design for Azure Virtual WAN | Microsoft Learn. Moreover, it is important to test your high availability and disaster recovery mechanisms regularly to ensure they are working as intended.	Ensure you adopt a design that meets your business continuity and disaster recovery (BCDR) requirements, while maintaining optimal performance during steady state.
Review the supported hub routing preference options in Virtual WAN and choose the one that works best for your scenario. To learn more about virtual hub routing preference, see Virtual WAN virtual hub routing preference - Azure Virtual WAN | Microsoft Learn.	The default hub routing preference in Virtual WAN is ‘ExpressRoute’, however, ‘AS Path’ may be the best option to fulfill your specific routing requirements, for example. To make an informed decision on which hub routing preference option fulfills your requirements the best, see Azure Virtual WAN FAQ | Microsoft Learn.
By default, VNet-to-VNet and VNet to Virtual WAN connectivity is disabled through an ExpressRoute circuit. However, when two hubs are connected and there is a single ExpressRoute connected as a bow-tie to both hubs, the ExpressRoute circuit will be the preferred path over hub-to-hub for a VNet connected to the first hub to reach a VNet connected to the second hub. To make sure hub-to-hub is the preferred path, it is recommended to configure AS-Path as the hub routing preference. Alternatively, configure multiple ExpressRoute circuits to connect to each hub. To learn more about this scenario, see Azure Virtual WAN FAQ | Microsoft Learn.	The ExpressRoute path is not ideal for VNet-to-VNet traffic. ExpressRoute gateways have resource limitations (bandwidth, for example) and can therefore become bottlenecks. In addition, ExpressRoute doesn’t offer optimal performance when compared to hub-to-hub. With ExpressRoute there is an extra hop because traffic must pass through the MSEE devices in the peering location. Preferring the hub-to-hub path ensures optimal performance for VNet-to-VNet connectivity. To learn more, see Connectivity between virtual networks over ExpressRoute | Microsoft Learn.
The throughput of a VPN gateway instance is available across all tunnels connecting to that instance. Thus, it is important to select the adequate number of gateway scale units to avoid performance issues down the line. Estimate the need per VPN tunnel when planning for a VPN gateway to ensure your gateway has enough aggregate throughput. For more information on supported scale units in Virtual WAN for VPN gateway, see Azure Virtual WAN FAQ | Microsoft Learn.	Avoid having the gateway become a performance bottleneck in the long run.
Virtual WAN VPN supports many algorithm combinations. The full list of supported parameters can be found here: Virtual WAN site-to-site IPsec policies - Azure Virtual WAN | Microsoft Learn. For optimal performance, the recommended algorithm for both IPSEC Encryption and Integrity is GCMAES256.	Optimal performance in your VPN site-to-site connections in Virtual WAN.
Regularly monitor your virtual hub gateways (VPN or ExpressRoute) to make sure they’re not overutilized and adjust the number of scale units as needed. To do so, leverage on Virtual WAN metrics and logs. Consider configuring alerts for recommended metrics and logs. For more information, see Monitoring Virtual WAN - Best practices - Azure Virtual WAN | Microsoft Learn.	By regularly monitoring hub gateways you’re able detect potential performance bottlenecks early and act on them.
Estimating throughput requirements in advance before configuring your virtual hub capacity is important not only from a cost perspective, but also from a performance standpoint. Moreover, while the virtual hub can automatically scale out, it is still important to regularly monitor virtual hub metrics such as ‘Virtual Hub Data Processed’ or ‘Spoke VM Utilization’. For more information on virtual hub metrics and virtual hub metrics, see Monitoring Azure Virtual WAN - Data reference | Microsoft Learn.	These metrics can help prevent situations, such as nearing the limits of a single hub, and acting on it early by deploying an additional hub, for example. For more information on virtual hub capacity, see About virtual hub settings - Azure Virtual WAN | Microsoft Learn.

Next steps



Now that we've gone through the list of configuration best practices, here's some additional useful resources:



Virtual WAN routing deep dive - Azure Virtual WAN | Microsoft Learn

How to configure Virtual WAN Hub routing policies - Azure Virtual WAN | Microsoft Learn

Continue reading...