With the release of Azure Virtual WAN, Microsoft now supports SD-WAN functionality of out the box for the “middle-mile” transport. Meaning that traffic from one location to another can benefit of using Azure’s core backbone network to transport data between multiple locations.
Azure Virtual WAN does not provide any intelligence on the edge or branch side, but is leaving that up to the different SD-WAN vendors in the market such as VMware or Citrix which support Azure VWAN.
Azure Virtual WAN does not require any SD-WAN capabilities on the edge to function, and Azure VWAN can be used in combination with regular VPN connectivity using IPSec or P2S VPN.
Azure Virtual WAN can also connect to a Azure VNET but only within a single region and not across regions, and therefore Global VNET Peering is not supported.
It is important to understand what kind of capabilities that Azure VWAN is focused on and what it is not focused on. Azure VWAN is not focused on handling regular internet traffic going out to SaaS services from clients or branches, and it is still best to have split tunneling or local breakout to the internet directly for that purpose. So for instance traffic headed to Office 365, GSuite or other Saas Services traffic should still be outside of the VWAN.
If you want to have Site-to-Site connecivity between Branches or Branch to Azure VNET where you have multiple sites and want to improve connectivity with reduced latecy between locations then Azure VWAN might be something that you should look closer into.
Azure VWAN consist of multiple components, where you have the virtual hub which is a logical object and consists of various service endpoints to enable connectivity from your on-premises network, and all vNets sites connect into a virtual hub.. Then you have Sites which typically represent the different sites/branches you want to connectio to a hun There can only be one hub per Azure region. A hub gateway is not the same as a virtual network gateway that you use for ExpressRoute and VPN Gateway. Virtual Network Gateway VPN is limited to 30 tunnels. For connections, you should use Virtual WAN for large-scale VPN connection. You can connect up to 1000 branch connections with 2 Gbps in the hub
Also the way it routes the traffic is a bit different from regular VPN Gateway, for instance for a branch-to-branch connection the traffic would follow this pattern: branch device ->ISP->Microsoft edge->Microsoft DC (hub VNet)->Microsoft edge->ISP->branch device. Since all hub adresses are advertised locally to each Edge.
This means that same logic would apply for a point-to-site connection where the VPN connection from a client would go from the closest Microsoft Edge and from there on to the Microsoft DC. A connection coming into Virtual WAN VPN is always an active-active tunnel (which is not the default setting for VPN Gateway)
So do I need an SD-WAN solution for this?
For using Azure VWAN you do not need an SD-WAN solution, even though many of the SD-WAN partners have an automated setup with azure VWAN to setup connections and handle traffic flow. SD-WAN in this case will not deliver any better performance since in this case Microsoft VWAN will be the traffic handler for traffic between branches and or Azure Virtual Networks.
You can see the list of supported partners here –> https://docs.microsoft.com/nb-no/azure/virtual-wan/virtual-wan-locations-partners
SD-WAN however becomes a more important topic if we are looking into handling regular internet traffic or looking into how we can reduce MPLS cost, increase availability and performance for branch to Internet or to other sites. Which we will be looking closer into a bit later, but there are some interesting vendors in this space which are developing pretty cool solutions here, such as Citrix, VMware, Aryaka & Silverpeak.