Combining firewall protection and SD-WAN connectivity in Azure virtual WAN
Virtual WAN (vWAN) introduces new security and connectivity features in Azure, including the ability to operate managed third-party firewalls and SD-WAN virtual appliances, integrated natively within a virtual WAN hub (vhub). This article will discuss updated network designs resulting from these integrations and examine how to combine firewall protection and SD-WAN connectivity when using vWAN. The objective is not to delve into the specifics of the security or SD-WAN connectivity solutions, but to provide an overview of the possibilities. Firewall protection in vWAN In a vWAN environment, the firewall solution is deployed either automatically inside the vhub (Routing Intent) or manually in a transit VNet (VM-series deployment). Routing Intent (managed firewall) Routing Intent refers to the concept of implementing a managed firewall solution within the vhub for internet protection or private traffic protection (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch), or both. The firewall could be either an Azure Firewall or a third-party firewall, deployed within the vhub as Network Virtual Appliances or a SaaS solution. A vhub containing a managed firewall is called a secured hub. For an updated list of Routing Intent supported third-party solutions please refer to the following links: managed NVAs SaaS solution Transit VNet (unmanaged firewall) Another way to provide inspection in vWAN is to manually deploy the firewall solution in a spoke of the vhub and to cascade the actual spokes behind that transit firewall VNet (aka indirect spoke model or tiered-VNet design). In this discussion, the primary reasons for choosing unmanaged deployments are: either the firewall solution lacks an integrated vWAN offer, or it has an integrated offer but falls short in horizontal scalability or specific features compared to the VM-based version. For a detailed analysis on the pros and cons of each design please refer to this article. SD-WAN connectivity in vWAN Similar to the firewall deployment options, there are two main methods for extending an SDWAN overlay into an Azure vWAN environment: a managed deployment within the vhub, or a standard VM-series deployment in a spoke of the vhub. More options here. SD-WAN in vWAN deployment (managed) In this scenario, a pair of virtual SD-WAN appliances are automatically deployed and integrated in the vhub using dynamic routing (BGP) with the vhub router. Deployment and management processes are streamlined as these appliances are seamlessly provisioned in Azure and set up for a simple import into the partner portal (SD-WAN orchestrator). For an updated list of supported SDWAN partners please refer to this link. For more information on SD-WAN in vWAN deployments please refer to this article. VM-series deployment (unmanaged) This solution requires manual deployment of the virtual SD-WAN appliances in a spoke of the vhub. The underlying VMs and the horizontal scaling are managed by the customer. Dynamic route exchange with the vWAN environment is achieved leveraging BGP peering with the vhub. Alternatively, and depending on the complexity of your addressing plan, static routing may also be possible. Firewall protection and SD-WAN in vWAN THE CHALLENGE! Currently, it is only possible to chain managed third-party SD-WAN connectivity with Azure Firewall in the same vhub, or to use dual-role SD-WAN connectivity and security appliances. Routing Intent provided by third-party firewalls combined with another managed SD-WAN solution inside the same vhub is not yet supported. But how can firewall protection and SD-WAN connectivity be integrated together within vWAN? Solution 1: Routing Intent with Azure Firewall and managed SD-WAN (same vhub) Firewall solution: managed. SD-WAN solution: managed. This design is only compatible with Routing Intent using Azure Firewall, as it is the sole firewall solution that can be combined with a managed SD-WAN in vWAN deployment in that same vhub. With the private traffic protection policy enabled in Routing Intent, all East-West flows (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch) are inspected. Solution 2: Routing Intent with a third-party firewall and managed SD-WAN (2 vhubs) Firewall solution: managed. SD-WAN solution: managed. To have both a third-party firewall managed solution in vWAN and an SD-WAN managed solution in vWAN in the same region, the only option is to have a vhub dedicated to the security solution deployment and another vhub dedicated to the SD-WAN solution deployment. In each region, spoke VNets are connected to the secured vhub, while SD-WAN branches are connected to the vhub containing the SD-WAN deployment. In this design, Routing Intent private traffic protection provides VNet-to-VNet and Branch-to-VNet inspection. However, Branch-to-Branch traffic will not be inspected. Solution 3: Routing Intent and SD-WAN spoke VNet (same vhub) Firewall solution: managed. SD-WAN solution: unmanaged. This design is compatible with any Routing Intent supported firewall solution (Azure Firewall or third-party) and with any SD-WAN solution. With Routing Intent private traffic protection enabled, all East-West flows (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch) are inspected. Solution 4: Transit firewall VNet and managed SDWAN (same vhub) Firewall solution: unmanaged. SD-WAN solution: managed. This design utilizes the indirect spoke model, enabling the deployment of managed SD-WAN in vWAN appliances. This design provides VNet-to-VNet and Branch-to-VNet inspection. But because the firewall solution is not hosted in the hub, Branch-to-Branch traffic will not be inspected. Solution 5 - Transit firewall VNet and SD-WAN spoke VNet (same vhub) Firewall solution: unmanaged. SD-WAN solution: unmanaged. This design integrates both the security and the SD-WAN connectivity as unmanaged solutions, placing the responsibility for deploying and managing the firewall and the SD-WAN hub on the customer. Just like in solution #4, only VNet-to-VNet and Branch-to-VNet traffic is inspected. Conclusion Although it is currently not possible to combine a managed third-party firewall solution with a managed SDWAN deployment within the same vhub, numerous design options are still available to meet various needs, whether managed or unmanaged approaches are preferred.Network Redundancy from On-Premises to Azure VMware and VNETs
Establishing redundant network connectivity is vital to ensuring the availability, reliability, and performance of workloads operating in hybrid and cloud environments. Proper planning and implementation of network redundancy are key to achieving high availability and sustaining operational continuity. This guide presents common architectural patterns for building redundant connectivity between on-premises datacenters, Azure Virtual Networks (VNets), and Azure VMware Solution (AVS) within a single-region deployment. AVS allows organizations to run VMware-based workloads directly on Azure infrastructure, offering a streamlined path for migrating existing VMware environments to the cloud without the need for significant re-architecture or modification. Connectivity Between AVS, On-Premises, and Virtual Networks The diagram below illustrates a common network design pattern using either a Hub-and-Spoke or Virtual WAN (vWAN) topology, deployed within a single Azure region. ExpressRoute is used to establish connectivity between on-premises environments and VNets. The same ExpressRoute circuit is extended to connect AVS to the on-premises infrastructure through ExpressRoute Global Reach. Consideration: This design presents a single point of failure. If the ExpressRoute circuit (ER1-EastUS) experiences an outage, connectivity between the on-premises environment, VNets, and AVS will be disrupted. Let’s examine some solutions to establish redundant connectivity in case the ER1-EastUS experiences an outage. Solution1: Network Redundancy via VPN In this solution, one or more VPN tunnels are deployed as a backup to ExpressRoute. If ExpressRoute becomes unavailable, the VPN provides an alternative connectivity path from the on-premises environment to VNets and AVS. In a Hub-and-Spoke topology, a backup path to and from AVS can be established by deploying Azure Route Server (ARS) in the hub VNet. ARS enables seamless transit routing between ExpressRoute and the VPN gateway. In vWAN topology, ARS is not required. The vHub's built-in routing service automatically provides transitive routing between the VPN gateway and ExpressRoute. Note: In vWAN topology, to ensure optimal route convergence when failing back to ExpressRoute, you should prepend the prefixes advertised from on-premises over the VPN. Without route prepending, VNets may continue to use the VPN as the primary path to on-premises. If prepend is not an option, you can trigger the failover manually by bouncing the VPN tunnel. Solution Insights: Cost-effective and straightforward to deploy. Latency: The VPN tunnel introduces additional latency due to its reliance on the public internet and the overhead associated with encryption. Bandwidth Considerations: Multiple VPN tunnels might be needed to achieve bandwidth comparable to a high-capacity ExpressRoute circuit (e.g., over 10G). For details on VPN gateway SKU and tunnel throughput, refer to this link. Solution2: Network Redundancy via SD-WAN In this solution, SDWAN tunnels are deployed as a backup to ExpressRoute. If ExpressRoute becomes unavailable, SDWAN provides an alternative connectivity path from the on-premises environment to VNets and AVS. In a Hub-and-Spoke topology, a backup path to and from AVS can be established by deploying ARS in the hub VNet. ARS enables seamless transit routing between ExpressRoute and the SDWAN appliance. In vWAN topology, ARS is not required. The vHub's built-in routing service automatically provides transitive routing between the SDWAN and ExpressRoute. Note: In vWAN topology, to ensure optimal convergence from the VNets when failing back to ExpressRoute, prepend the prefixes advertised from on-premises over the SDWAN to make sure it's longer that ExpressRoute learned routes. If you don't prepend, VNets will continue to use SDWAN path to on-prem as primary path. In this design using Azure vWAN, the SD-WAN can be deployed either within the vHub or in a spoke VNet connected to the vHub the same principle applies in both cases. Solution Insights: If you have an existing SDWANs no additional deployment is needed. Bandwidth Considerations: Vendor specific. Management consideration: Third party dependency and need to manage the HA deployment, except for SD-WAN SaaS solution. Solution3: Network Redundancy via ExpressRoute in Different Peering Locations Deploy an additional ExpressRoute circuit at a different peering location and enable Global Reach between ER2-peeringlocation2 and AVS-ER. To use this circuit as a backup path, prepend the on-premises prefixes on the second circuit; otherwise, AVS or VNet will perform Equal-Cost Multi-Path (ECMP) routing across both circuits to on-prem. Note: Use public ASN to prepend the on-premises prefix as AVS-ER will strip the private ASN toward AVS. Refer to this link for more details. Solution Insights: Ideal for mission-critical applications, providing predictable throughput and bandwidth for backup. Could be cost prohibitive depending on the bandwidth of the second circuit. Solution4: Network Redundancy via Metro ExpressRoute Metro ExpressRoute is the new ExpressRoute configuration. This configuration allows you to benefit from a dual-homed setup that facilitates diverse connections to two distinct ExpressRoute peering locations within a city. This configuration offers enhanced resiliency if one peering location experiences an outage. Solution Insights Higher Resiliency: Provides increased reliability with a single circuit. Limited regional availability: Availability is restricted to specific regions within the metro area. Cost-effective Conclusion: The choice of failover connectivity should be guided by the specific latency and bandwidth requirements of your workloads. Ultimately, achieving high availability and ensuring continuous operations depend on careful planning and effective implementation of network redundancy strategies.
Announcing the general availability of Route-Maps for Azure virtual WAN.
Route-maps is a feature that gives you the ability to control route advertisements and routing for Virtual WAN virtual hubs. Route-maps lets you have more control of the routing that enters and leaves Azure Virtual WAN site-to-site (S2S) VPN connections, User VPN point-to-site (P2S) connections, ExpressRoute connections, and virtual network (VNet) connections. Why use Route-maps? Route-maps can be used to summarize routes when you have on-premises networks connected to Virtual WAN via ExpressRoute or VPN and are limited by the number of routes that can be advertised from/to virtual hub. You can use Route-maps to control routes entering and leaving your Virtual WAN deployment among on-premises and virtual-networks. You can control routing decisions in your Virtual WAN deployment by modifying a BGP attribute such as AS-PATH to make a route more, or less preferable. This is helpful when there are destination prefixes reachable via multiple paths and customers want to use AS-PATH to control best path selection. You can easily tag routes using the BGP community attribute in order to manage routes. What is a Route-map? A Route-map is an ordered sequence of one or more rules that are applied to routes received or sent by the virtual hub. Each Route-map rule comprises of 3 sections: 1. Match conditions Route-maps allows you to match routes using Route-prefix, BGP community and AS-Path. These are the set of conditions that a processed route must meet in order to be considered as a match for the rule. Below are the supported match conditions. Property Criterion Value (example) Interpretation Route-prefix equals 10.1.0.0/16,10.2.0.0/16,10.3.0.0/16,10.4.0.0/16 Matches these 4 routes only. Specific prefixes under these routes won't be matched. Route-prefix contains 10.1.0.0/16,10.2.0.0/16, 192.168.16.0/24, 192.168.17.0/24 Matches all the specified routes and all prefixes underneath. (Example 10.2.1.0/24 is underneath 10.2.0.0/16) Community equals 65001:100,65001:200 Community property of the route must have both the communities. Order isn't relevant. Community contains 65001:100,65001:200 Community property of the route can have one or more of the specified communities. AS-Path equals 65001,65002,65003 AS-PATH of the routes must have ASNs listed in the specified order. AS-Path contains 65001,65002,65003 AS-PATH in the routes can contain one or more of the ASNs listed. Order isn't relevant. 2. Actions to be performed Route-Maps allows you to Drop or Modify routes. Below are the supported actions. Property Action Value Interpretation Route-prefix Drop 10.3.0.0/8,10.4.0.0/8 The routes specified in the rule are dropped. Route-prefix Replace 10.0.0.0/8,192.168.0.0/16 Replace all the matched routes with the routes specified in the rule. As-Path Add 64580,64581 Prepend AS-PATH with the list of ASNs specified in the rule. These ASNs are applied in the same order for the matched routes. As-Path Replace 65004,65005 AS-PATH will be set to this list in the same order, for every matched route. See key considerations for reserved AS numbers. As-Path Replace No value specified Remove all ASNs in the AS-PATH in the matched routes. Community Add 64580:300,64581:300 Add all the listed communities to all the matched routes community attribute. Community Replace 64580:300,64581:300 Replace community attribute for all the matched routes with the list provided. Community Replace No value specified Remove community attribute from all the matched routes. Community Remove 65001:100,65001:200 Remove any of the listed communities that are present in the matched routes’ Community attribute. 3. Apply to a Connection You can apply route-maps on each connection for the inbound, outbound, or both inbound and outbound directions. Where can I find Route-maps? Route-Maps can be found in the routing section of your virtual WAN hub. How do I troubleshoot Route-maps? The Route-Map Dashboard lets you views the routes for a connection. You can view the routes before or after a Route-Map is applied. Demo
BGP Routing from and to VPN Gateway
Hello All, I am setting up a lab concerning vWAN connection to onprem via SDWAN and I have some issues getting the routing to work properly. I have a hub which symbolizes the on-premises hub with a VPN gateway (gw-onprem) and a VM (on-prem-hubvm) deployed. Attached to the onprem-hub is a) on-prem spoke with a VM (on-prem VM). b) two vnets that symbolize the sdwan. Both of which have a VPN gateway as well as one VM each deployed (gw-sd-1/2) The SDWan Gateways are connected via s2s to two different vWAN hubs in two different locations. The vWAN has a third Hub which is not directly connected to on-prem What I am trying to lab is what direction the traffic is tacking from the vWAN Hubs to the last on-premise VM. The traffic currently goes all the way through the s2s vpn connection, but it gets dropped afterwards. I am struggling to set-up the routing from the sd-gw's to the on-premises machine. The routing needs to work through BGP The goal of the Lab is to see which path to on-premises is preferred if the hub preference is AS Path (shortest BGP Path). BGP is enabled on all VPN Gateways The SD GWs are peered to the onprem Hub GW but no vnet peering. The on-premises Vnets are peered. Somehow the VPN Gateways are not learning the routes to on-premises. I tried pointing the way with UDRs but somehow it also isnt working I've tried setting up UDRs so that the traffic would be the following vWAN Hub -> sd GW > sd VM > GW-onprem (> on-prem-hubvm) > on-prem VM
Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.
Automated Deployment of Cross-Tenant Azure Virtual Hubs Virtual Networks Connection
In modern cloud infrastructure, interconnecting resources across different Azure tenants is essential for various business scenarios, such as mergers, acquisitions, or multi-departmental collaborations. This article will walk you through creating a Virtual Hub in a Virtual WAN and connecting to a Virtual Network in a different tenant from the hub using Bicep and Azure Pipelines. The pipeline will be using a Service Principal to create and access resources in the two Tenants. The client ID and secret need to be stored in a Key Vault, the details of which would be passed as parameters to the pipeline. Mutli-Tenant SPN Setup and Access As mentioned in the Azure Documentation, we would be using the below command in the pipeline to setup the connection between the hub and virtual network: az network vhub connection create --resource-group "[resource_group_name]" --name "[connection_name]" --vhub-name "[virtual_hub_name]" --remote-vnet "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgName/providers/Microsoft.Network/virtualNetworks/vnetName" Since a service principal is being used to run the pipelines, the SPN would need contributor access on the appropriate subscriptions on both the main tenant and the remote tenant. This can be achieved using the following steps: 1. Create Service Principal and Assign Roles We will use a single SPN for the creation of VWAN, Vhub and the connection to the remote virtual network. Create the service principal in the Tenant that will contain Virtual WAN and the hub and provide contributor access on the subscription level. 2. Setting Up Multi-Tenant SPN Run the URL below to create the SPN in the other tenant: https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id} Organization would be the Tenant ID of the remote Vnet, and client ID is the Application ID of the SPN. Assign the SPN Contributor access on the subscription where the Vnet resides. Note: The contributor access on the Subscription is the lowest possible access required for multi-tenant setup. Contributor access on the Resource Group level would not work. Code Explanation The code and parameter files can be found here. There are 3 main Azure Bicep files that manages the creation of the resources: Network.bicep The file retrieves the required modules to create a single VWAN and multiple hubs in the VWAN, along with a virtual network and resource group(s). The naming convention is fixed based on environment (TST, PROD etc.) and region of resource (west us, east us etc.) It also contains the following code to create a connection between the virtual network (either provide ID of the VNET or parameters for the creation of the VNET) in the same tenant as the hub. The parameter file used is ‘network.main.parameters.json’ The below code would only run if createHubVirtualNetworkConnection is set to True. By default, the parameter is set to False. module connectVnetHub '../Modules/VirtualHub/connectVnet.bicep' = if (createHubVirtualNetworkConnection){ name: 'connect-vnet-to-hub' scope: resourceGroup(vwan.subscriptionID, vwan.resourceGroupName) params: { vhubName: 'vwanhub-${env}-${stage}-${vnet.location}-001' virtualNetworkID: (createVnet) ? virtualnetwork.outputs.resourceId : vnet.id connectionName: '${purpose}-vnet-${env}' } dependsOn: [ vWan vwanHub virtualnetwork ] } The above module calls the below bicep file to create the connection: param vhubName string param virtualNetworkID string param connectionName string resource vhub 'Microsoft.Network/virtualHubs@2023-04-01' existing = { name: vhubName } resource connectVnet 'Microsoft.Network/virtualHubs/hubVirtualNetworkConnections@2023-04-01' = { name: connectionName parent: vhub properties: { remoteVirtualNetwork: { id: virtualNetworkID } } } RemoteVnetSubnet.bicep This Bicep file creates multiple Resource Groups, VNETs and Subnets as mentioned in the parameter file. Parameter file name is network.remote.parameters.json. VhubRemoteVnetMapping.bicep This file calls the module to connect the remote VNET(s) to the Vhub. The appropriate Virtual Hub is selected based on the region. For example, a VNET created in east us will be connected to the hub is east us. The multi-tenant SPN needs to be passed as a parameter which is required to run the PowerShell script in the module. The SPN details is stored in a Key Vault and the below code is used to retrieve the Client ID and secret: param keyVaultName string param keyVaultResourceGroup string param keyVaultSubscription string resource keyVault 'Microsoft.KeyVault/vaults@2023-02-01' existing = { name: keyVaultName scope: resourceGroup(keyVaultSubscription, keyVaultResourceGroup) } The following code can connect multiple VNETs to the right virtual hub: targetScope='subscription' param vnets object [] = [] param vwan object param env string = 'main' param stage string = 'prod' module connectRemoteVnetVhub '../Modules/VirtualHub/connectRemoteVnet.bicep' = [for i in range(0, length(vnets)): { name: 'connect-${vnets[i].vnetName}-to-vhub' scope: resourceGroup(vwan.subscriptionID, vwan.resourceGroupName) params: { remoteResourceGroup: vnets[i].resourceGroupName remoteSubscriptionID: vnets[i].subscriptionID remoteTenant: vnets[i].tenantID remoteVnetName: vnets[i].vnetName vhubName: 'vwanhub-${env}-${stage}-${vnets[i].location}-001' subscriptionID: vwan.SubscriptionID tenantID: vwan.tenantID clientID: keyVault.getSecret('clientid-Main') clientSecret: keyVault.getSecret('clientsecret-Main') connectionName: '${vnets[i].vnetName}-dns-connection' location: vnets[i].location } }] The module basically contains a deployment script resource that runs a bash script to connect the VNET and the hub. resource deploymentScript 'Microsoft.Resources/deploymentScripts@2023-08-01' = { name: 'connectRemote${remoteVnetName}toVhub' location: location kind: 'AzureCLI' properties: { arguments: '${tenantID} ${remoteTenant} ${remoteSubscriptionID} ${subscriptionID} ${remoteResourceGroup} ${remoteVnetName} ${connectionName} ${vhubName}' environmentVariables: [ { name: 'parentResourceGroupName' value: resourceGroup().name } { name: 'clientID' value: clientID } { name: 'clientSecret' value: clientSecret } ] azCliVersion: '2.54.0' scriptContent: ''' az login --service-principal -u $clientID -p $clientSecret --tenant $2 az account set --subscription $3 az login --service-principal -u $clientID -p $clientSecret --tenant $1 az account set --subscription $4 az extension add --name virtual-wan -y --version 0.3.0 az network vhub connection create --resource-group $parentResourceGroupName --name $7 --vhub-name $8 --remote-vnet "/subscriptions/${3}/resourceGroups/${5}/providers/Microsoft.Network/virtualNetworks/${6}" ''' retentionInterval: 'P1D' } } Azure Pipeline Explanation Even though the SPN created earlier has access to both the main and remote Tenant, it would be a much more secure option to minimize the use of the multi-tenant SPN to just create the VHUB VNET connection due to its elevated access. Hence, we need to create an additional SPN that has the required access only on the remote Tenant. This new SPN then should be used to deploy only the remote VNET(s) and subnets and use the Multi-tenant SPN to create the main tenant resources and the connection. The pipeline will retrieve the SPN Client ID and secret from the Key Vault, run a validation on the Bicep code and deploy the resources. Appropriate parameters need to be passed to the pipeline to run the appropriate bicep file. It has to be run 3 times by selecting the following values: Iteration 1 (To deploy VWAN, VHUB in Main Tenant): Tenant Name: Main Purpose of Deployment: Main Network Deployment Subscription ID: Details of the subscription where the VWAN, VHUB and VNET will reside in the Main Tenant. Iteration 2 (To deploy Remote VNET): Tenant Name: Remote Purpose of Deployment: Remote Network Deployment Subscription ID: Details of the subscription where the remote VNET will reside in the remote Tenant. Iteration 3 (To create the cross-tenant VHUB VNET Connection): Tenant Name: Main Purpose of Deployment: Vnet-Hub-Connection Subscription ID: Details of the subscription where the VWAN, VHUB and VNET will reside in the Main Tenant. Note: Ensure that the Tenant ID for the main and remote Tenant, Client ID and Client Secret of the SPNs created are stored in the Key Vault before running the pipeline. The below format should be followed while creating the secrets in the key vault: $clientIDSecretName = "clientid-${{ parameters.tenantName }}" $clientSecretSecretName = "clientsecret-${{ parameters.tenantName }}" $tenantIDSecretName = "tenantid-${{ parameters.tenantName }}" where the Parameter 'tenantName' would be either 'Main' or 'Remote'. All the above-mentioned code and parameter files can be found here. Azure Documentation References Process: https://learn.microsoft.com/en-us/azure/virtual-wan/cross-tenant-vnet-az-cli Multi-Tenant SPNs: https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant Tenant wide Admin Consent: Grant tenant-wide admin consent to an application - Microsoft Entra ID | Microsoft LearnManaged SD-WAN in vWAN: throughput considerations and underlay options
Discover how to simplify large-scale branch connectivity by leveraging the power of SD-WAN and vWAN to create a cloud-oriented network that delivers optimized inter-region performance and resiliency. Get insights on the deployment process for managed SD-WAN in vWAN, as well as on throughput considerations and scaling options. Finally, explore the various underlay options available for managed SD-WAN in vWAN deployments.A Guide to Azure Data Transfer Pricing
Understanding Azure networking charges is essential for businesses aiming to manage their budgets effectively. Given the complexity of Azure networking pricing, which involves various influencing factors, the goal here is to bring a clearer understanding of the associated data transfer costs by breaking down the pricing models into the following use cases: VM to VM VM to Private Endpoint VM to Internal Standard Load Balancer (ILB) VM to Internet Hybrid connectivity Please note this is a first version, with a second version to follow that will include additional scenarios. Disclaimer: Pricing may change over time, check the public Azure pricing calculator for up-to-date pricing information. Actual pricing may vary depending on agreements, purchase dates, and currency exchange rates. Sign in to the Azure pricing calculator to see pricing based on your current program/offer with Microsoft. 1. VM to VM 1.1. VM to VM, same VNet Data transfer within the same virtual network (VNet) is free of charge. This means that traffic between VMs within the same VNet will not incur any additional costs. Doc. Data transfer across Availability Zones (AZ) is free. Doc. 1.2. VM to VM, across VNet peering Azure VNet peering enables seamless connectivity between two virtual networks, allowing resources in different VNets to communicate with each other as if they were within the same network. When data is transferred between VNets, charges apply for both ingress and egress data. Doc: VM to VM, across VNet peering, same region VM to VM, across Global VNet peering Azure regions are grouped into 3 Zones (distinct from Avaialbility Zones within a specific Azure region). The pricing for Global VNet Peering is based on that geographic structure. Data transfer between VNets in different zones incurs outbound and inbound data transfer rates for the respective zones. When data is transferred from a VNet in Zone 1 to a VNet in Zone 2, outbound data transfer rates for Zone 1 and inbound data transfer rates for Zone 2 will be applicable. Doc. 1.3. VM to VM, through Network Virtual Appliance (NVA) Data transfer through an NVA involves charges for both ingress and egress data, depending on the volume of data processed. When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via an NVA (firewall...) in the hub VNet, it incurs VM to VM pricing twice. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 2. VM to Private Endpoint (PE) Private Endpoint pricing includes charges for the provisioned resource and data transfer costs based on traffic direction. For instance, writing to a Storage Account through a Private Endpoint incurs outbound data charges, while reading incurs inbound data charges. Doc: 2.1. VM to PE, same VNet Since data transfer within a VNet is free, charges are only applied for data processing through the Private Endpoint. Cross-region traffic will incur additional costs if the Storage Account and the Private Endpoint are located in different regions. 2.2. VM to PE, across VNet peering Accessing Private Endpoints from a peered network incurs only Private Link Premium charges, with no peering fees. Doc. VM to PE, across VNet peering, same region VM to PE, across VNet peering, PE region != SA region 2.3. VM to PE, through NVA When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via a firewall in the hub VNet, it incurs VM to VM charges between the VM and the NVA. However, as per the PE pricing model, there are no charges between the NVA and the PE. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 3. VM to Internal Load Balancer (ILB) Azure Standard Load Balancer pricing is based on the number of load balancing rules as well as the volume of data processed. Doc: 3.1. VM to ILB, same VNet Data transfer within the same virtual network (VNet) is free. However, the data processed by the ILB is charged based on its volume and on the number load balancing rules implemented. Only the inbound traffic is processed by the ILB (and charged), the return traffic goes direct from the backend to the source VM (free of charge). 3.2. VM to ILB, across VNet peering In addition to the Load Balancer costs, data transfer charges between VNets apply for both ingress and egress. 3.3. VM to ILB, through NVA When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via a firewall in the hub VNet, it incurs VM to VM charges between the VM and the NVA and VM to ILB charges between the NVA and the ILB/backend resource. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 4. VM to internet 4.1. Data transfer and inter-region pricing model Bandwidth refers to data moving in and out of Azure data centers, as well as data moving between Azure data centers; other transfers are explicitly covered by the Content Delivery Network, ExpressRoute pricing, or Peering. Doc: 4.2. Routing Preference in Azure and internet egress pricing model When creating a public IP in Azure, Azure Routing Preference allows you to choose how your traffic routes between Azure and the Internet. You can select either the Microsoft Global Network or the public internet for routing your traffic. Doc: See how this choice can impact the performance and reliability of network traffic: By selecting a Routing Preference set to Microsoft network, ingress traffic enters the Microsoft network closest to the user, and egress traffic exits the network closest to the user, minimizing travel on the public internet (“Cold Potato” routing). On the contrary, setting the Routing Preference to internet, ingress traffic enters the Microsoft network closest to the hosted service region. Transit ISP networks are used to route traffic, travel on the Microsoft Global Network is minimized (“Hot Potato” routing). Bandwidth pricing for internet egress, Doc: 4.3. VM to internet, direct Data transferred out of Azure to the internet incurs charges, while data transferred into Azure is free of charge. Doc. It is important to note that default outbound access for VMs in Azure will be retired on September 30 2025, migration to an explicit outbound internet connectivity method is recommended. Doc. 4.4. VM to internet, with a public IP Here a standard public IP is explicitly associated to a VM NIC, that incurs additional costs. Like in the previous scenario, data transferred out of Azure to the internet incurs charges, while data transferred into Azure is free of charge. Doc. 4.5. VM to internet, with NAT Gateway In addition to the previous costs, data transfer through a NAT Gateway involves charges for both the data processed and the NAT Gateway itself, Doc: 5. Hybrid connectivity Hybrid connectivity involves connecting on-premises networks to Azure VNets. The pricing model includes charges for data transfer between the on-premises network and Azure, as well as any additional costs for using Network Virtual Appliances (NVAs) or Azure Firewalls in the hub VNet. 5.1. H&S Hybrid connectivity without firewall inspection in the hub For an inbound flow, from the ExpressRoute Gateway to a spoke VNet, VNet peering charges are applied once on the spoke inbound. There are no charges on the hub outbound. For an outbound flow, from a spoke VNet to an ER branch, VNet peering charges are applied once, outbound of the spoke only. There are no charges on the hub inbound. Doc. The table above does not include ExpressRoute connectivity related costs. 5.2. H&S Hybrid connectivity with firewall inspection in the hub Since traffic transits and is inspected via a firewall in the hub VNet (Azure Firewall or 3P firewall NVA), the previous concepts do not apply. “Standard” inter-VNet VM-to-VM charges apply between the FW and the destination VM : inbound and outbound on both directions. Once outbound from the source VNet (Hub or Spoke), once inbound on the destination VNet (Spoke or Hub). The table above reflects only data transfer charges within Azure and does not include NVA/Azure Firewall processing costs nor the costs related to ExpressRoute connectivity. 5.3. H&S Hybrid connectivity via a 3rd party connectivity NVA (SDWAN or IPSec) Standard inter-VNet VM-to-VM charges apply between the NVA and the destination VM: inbound and outbound on both directions, both in the Hub VNet and in the Spoke VNet. 5.4. vWAN scenarios VNet peering is charged only from the point of view of the spoke – see examples and vWAN pricing components. Next steps with cost management To optimize cost management, Azure offers tools for monitoring and analyzing network charges. Azure Cost Management and Billing allows you to track and allocate costs across various services and resources, ensuring transparency and control over your expenses. By leveraging these tools, businesses can gain a deeper understanding of their network costs and make informed decisions to optimize their Azure spending.Achieve high-bandwidth, private, and seamless Microsoft Azure connectivity
Multicloud computing is revolutionizing enterprise IT, enabling businesses to harness the strengths of different public cloud providers for greater agility, performance, and cost efficiency. However, without the right connectivity strategy, organizations risk increased complexity, higher latency, and security vulnerabilities—ultimately undermining the benefits of a multicloud approach. Together, Microsoft and Equinix provide a complete platform for multicloud networking with all the ingredients you need to achieve a best-case mix of performance, security, cost-effectiveness, and flexibility. Join us for a two-part webinar series where Equinix and Microsoft experts will guide you through best practices for seamless, secure, and high-performance multicloud networking. Learn how to optimize connectivity, reduce data egress costs, and unlock the full potential of Azure and Equinix’s global interconnection ecosystem. Webinar 1: Key Considerations for Optimized Microsoft Azure Connectivity Summary Achieve high-bandwidth, private, and seamless Microsoft Azure connectivity. As organizations modernize their IT infrastructure, hybrid cloud has emerged as the preferred solution for ensuring scalability, security, and performance. However, just as critical as deciding where to place specific workloads is determining how everything will be connected. Join experts from Microsoft, Equinix and Enterprise Strategy Group as they reveal five key cloud migration considerations for 2025 to help you: Prioritize essential network capabilities Manage top cost drivers Improve network scalability and simplicity Increase app performance Our speakers: Jim Frey – Principal Analyst, Enterprise Strategy Group Jim has over 30 years of experience in networking and software product development, including senior leadership roles in partner marketing at Kentik Technologies. He has also held executive positions in industry research, marketing, and product management. Jim holds a BSc in Engineering from the Colorado School of Mines and an MSc in Computer and Information Sciences from Rensselaer Polytechnic Institute. Kevin Lopez – Director of Solution Sales, Microsoft Azure Kevin is a seasoned leader with over 30 years in sales and business development. He joined Microsoft in 2007 and has held various roles, including Technical Architect and Azure Global Black Belt team member. Currently, he leads the Azure Network Security Global Black Belt team for the Americas is involved in Microsoft Worldwide Learning and social change initiatives. Brian Petit – Principal Solution Architect, Equinix Brian is a hybrid multicloud network professional with decades of experience in data networking infrastructure design, deployment, and applications. As the Senior Principal Solutions Architect dedicated to Microsoft at Equinix, he has responsibility for overall platform integration and alignment with Azure. Learn how to optimize hybrid cloud connectivity with Microsoft Azure ExpressRoute in Equinix. Reserve your spot: Date: Thursday, March 13, 2025 Time (AMER): 10:00 AM Pacific Daylight Time Time (EMEA): 11:00 AM Central European Time Time (APAC): 11:00 AM Singapore Time Duration: 1 hour Webinar 2: Explore Microsoft Azure ExpressRoute use cases and reference architectures Summary Explore Microsoft Azure ExpressRoute use cases and reference architectures Migrating to Azure while managing a hybrid multicloud strategy can be complex, with challenges around network performance, security, and cost optimization. In this technical webinar, Microsoft and Equinix experts will showcase real-world Azure ExpressRoute customer use cases, demonstrating how businesses are overcoming these hurdles to migrate faster, more securely, and cost-effectively—all while maintaining seamless connectivity between on-prem, Microsoft Azure and other clouds. Learn how to: Leverage cloud-adjacent architectures Minimize egress costs Improve network performance Ensure data sovereignty and compliance Our speakers: Mays Algebary – Global Black Belt, Microsoft Azure Mays is a cloud network security professional with a decade of experience safeguarding enterprise infrastructures. As a Global Black Belt at Microsoft, she is an expert in zero-trust architectures, secure cloud networking, and migration strategies. Mays works closely with organizations to strengthen their security posture, minimize risks, and ensure seamless, high-performance cloud connectivity. Brian Petit – Sr. Principal Solution Architect, Equinix Brian is a hybrid multicloud network professional with decades of experience in data networking infrastructure design, deployment, and applications. As the Senior Principal Solutions Architect dedicated to Microsoft at Equinix, he has responsibility for overall platform integration and alignment with Azure. RSVP today to learn how Equinix and Azure can help you migrate with confidence, ensuring seamless connectivity, performance, and security across your hybrid multicloud infrastructure. Reserve your spot: Date: Thursday, March 20, 2025 Time (AMER): 10:00 AM Pacific Daylight Time Time (EMEA): 11:00 AM Central European Time Time (APAC): 11:00 AM Singapore Time Duration: 30 minutesvWAN to vWAN Connectivity Options
Option 1: IPSec Tunnels using Azure Virtual Network Gateways In this option users can simply provision Azure Virtual Network Gateways on each vhub in each vWAN environment to connect both vWANs together. It's important to note that today you cannot change the vWAN virtual Network Gateway ASN, which is 65515. This is hardcoded inside the vhub gateway config. At a later date, there should be an option to change the virtual network gateway ASN. For this reason, you cannot do BGP over IPSEC due to BGP loop prevention and seeing its own ASN in the path. The remote vhub will receive routes from the source vhub with 65515 in the AS-PATH and BGP will drop that. Therefore, if you want to connect two different vWAN environments, the tunnels need to be static, no BGP option. The other thing to note is max throughput you can get per tunnel is around 2.4Gbps, and this is an SDN limitation. This can be increased by adding more tunnels. Pros: Uses Azure native VPN gateways for each respective vhub and vWAN Cheaper than using dedicated high bandwidth links like ExpressRoute Cons: Cannot use BGP due to the vHub gateway ASN hard-coded with 65515 VPN tunnel throughput is max 2.4Gbps per tunnel depending on ciphers Option 2: ExpressRoute Circuits using MSEE hair pinning This is another option using Azure native solutions. If there is already an Express-Route circuit provisioned, we can simply hook the other vhubs in each vWAN environment to the use the same express-route circuit. Like regular hub+spoke, when multiple vnets are connected to the same circuit, the egress point is the MSEE at the peering pops. Traffic between each vhub in different vWANs will simply hairpin down to the Azure MSEEs and each pop location before traveling to the remote vhub and vwan environment. Side note, I wrote another blog with my colleague Daniel Mauser on MSEE hairpin alternatives here Pros: Minimal setup required with existing express-route circuits Higher bandwidth then SDWan or IPSEC tunnels Cons: Latency can be an issue as the egress point is the peering pop This can tax the remote gateway for ingress flows if fast-path is not available Cost of running the Express-Route circuit Option 3: SDWan Tunnels with BGP+IPSEC Inside the vHubs This option is good for users who are already running their own SDWAN devices today to connect to on-prem WAN links or don't need the extra bandwidth of Express-Route. Deploying SDWan partner devices in each respective vhub to build the connections between vWans, users can run BGP over IPSEC to make the connectivity. In order to make the routing work, inside the SDWAN operating system, it's necessary to do "AS-Path Replace or AS-Path Exclude" BGP commands for the vhub 65520 and Route Server 65515 ASNs. The command for example would be "as-path exclude 65520 65515" or similar depending on the vendor. You would then need to apply that inbound route-map to each BGP peer. That way, the remote vWAN vhub won't drop the route, because it won't see its own ASN in the path. This is the same behavior is option 1, except here we have the ability to do BGP manipulation on third party devices unlike the Azure Virtual Network Gateways. The SDWANs can use different ASNs and do eBGP, or they could also be the same ASN and have an iBGP session. Pros: More granular control and options to manipulate routing Potential for more optimal throughput and tunning Some devices can also double duty and do inspection Cons: Complexity to setup and maintain Only certain SDWan devices are supported inside the vhubt today Potentially more expensive than Azure Virtual Network Gateways SDWan devices cannot be combined with NVAs inside the vhub Option 4: SDWan Tunnels with BGP+IPSEC with SDWan devices BGP peered in Spokes This would be the similar to option 3, except we have the SDWAN device in a spoke vnet that is vnet peered to each vhub. We then would BGP peer the SDWAN device to the Route Server instances inside the vhub. This is a good for scenarios where users have SDWAN devices that cannot be deployed inside vhubs, but still support BGP. Like above, we need to apply inbound route-maps to each SDWan device and do the "same as-path exclude or as-path replace on both 65520 and 65515 ASNs" so the receiving end does not drop the routes. Pros: More granular control and options to manipulate routing Potential for more optimal throughput and tunning Some devices can also double duty and do inspection Flexibility for deployment outside the vhubs Cons: Complexity to setup and maintain Potentially more expensive than Azure Virtual Network Gateway Side note regarding non vWAN vnets that you wish to connect to vWAN environments for new deployments! The following steps would need to be enabled on both the vhub and regular Azure Vnet with the Express-Route Gateway to allow the hair-pinning!
