Now that we have an understanding of the Virtual WANS, Virtual Hubs, and how they work together, let's move on to how to add a Network Virtual Appliance to a Virtual Hub. We'll start with what an SD-WAN is and how it fits with a Network Virtual Appliance. A software defined WAN or SD-WAN allows for the management of different types of WAN transports, including site to site VPNs, MPLS, cellular, and other connections. There are many different forms an SD-WAN can take. Too many to go over in this lecture, but at a high level, they all have a hardware device or Virtual Appliance deployed on premises that manages connectivity while optimizing bandwidth and costs.

Software manages connectivity to all the locations, hence the name software defined WAN. SD-WAN simplifies network management by automatically creating the connections between locations. They often have advanced features such as cost-based routing, compression, and WAN acceleration. So if an organization has an SD-WAN infrastructure in place, how do we connect these locations into our Virtual WAN? That is what a Network Virtual Appliance is for. A Network Virtual Appliance, or NVA, is a gateway appliance provided by an Azure networking partner to extend an SD-WAN infrastructure into Azure. It's a virtual version of the Customer Premises Equipment, or CPE, that organizations already use for WAN connectivity.

With this configuration, the NVE is deployed directly into the Virtual WAN hub. At the time of this recording, there are three providers that support implementing the NVE directly into the Virtual Hub. They include Barracuda, Cisco, and VMware. These three providers offer NVAs available for Azure Virtual WAN. An NVA is a managed application provided by a third party and built for Azure Virtual WAN. The NVA is available from the Azure Marketplace. It works with unit-based capacity and billing and provides health metrics with Azure Monitor. The third party license could be billed directly to the customer such as with a licensing key or through the Azure Marketplace.

There's also a cost to running the Virtual Appliance in Azure, as well as the network activity on the device. When the NVA is deployed, it creates two resource groups, a customer resource group that acts as a place holder for the managed application. Anything the NVA partner wants to expose to the customer is available in this resource group. There's also a managed resource group. This is controlled by the publisher of the managed application and contains the NVA application itself. Let's review the example coming up.

Our sites are connected by an SD-WAN solution that offers a Virtual WAN NVA. Because of that, we don't need the site to site connections like we deployed in the previous lab. We have a Virtual WAN along with a hub to VNet connections, providing connectivity between our regions. Coming up, we'll add an NVA to the environment. Once added, the SD-WAN service needs to be configured to connect the Virtual Appliance to the existing infrastructure. The steps to complete the connection will differ for each provider. One last item to note before we move on. You may want to leverage an NVA that's not one of the three partners with an integrated Virtual Hub offering. Citrix, Meraki, Check Point, Riverbed, and Silver Peak are all examples of providers that offer WAN acceleration and optimization, but are not integrated with Virtual Hubs. All these, and more, have the option for connecting to Azure, just with a slightly different configuration.

To accomplish connectivity between On-Premises and Azure with these platforms, we use something called the indirect interconnect model. In this model, all the remote sites are connected to the enterprise SD-WAN solution with Customer Premises Equipment or CPEs. Also, all the VNets in Azure are connected to the Virtual WAN. A VNet with a virtual CPE provided by the vendor is added to Azure. The virtual CPE is then connected to the Virtual WAN with an IPSec tunnel.

In this configuration, we still leverage the third party SD-WAN to connect the On-Premises sites to Azure. Careful planning is required for redundancy since all the On-Premises connections go through the virtual CPE. For the example coming up next, we'll use the Barracuda CloudGen WA Gateway with a direct connection to the Virtual Hub. The steps will be similar for the other providers. The virtual network cannot have any virtual gateways such as ExpressRoute or VPN when deploying an NVA in an Azure Virtual WAN hub. Those gateways aren't needed because the NVA takes care of connectivity. Let's move on to the Azure Portal for an example of how to deploy an NVA in an Azure Virtual WAN.