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
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.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.
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!Introducing Copilot in Azure for Networking: Your AI-Powered Azure Networking Assistant
As cloud networking grows in complexity, managing and operating these services efficiently can be tedious and time consuming. That’s where Copilot in Azure for Networking steps in, a generative AI tool that simplifies every aspect of network management, making it easier for network administrators to stay on top of their Azure infrastructure. With Copilot, network professionals can design, deploy, and troubleshoot Azure Networking services using a streamlined, AI-powered approach. A Comprehensive Networking Assistant for Azure We’ve designed Copilot to really feel like an intuitive assistant you can talk to just like a colleague. Copilot understands networking-related questions in simple terms and responds with actionable solutions, drawing from Microsoft’s expansive networking knowledge base and the specifics of your unique Azure environment. Think of Copilot as an all-encompassing AI-Powered Azure Networking Assistant. It acts as: Your Cloud Networking Specialist by quickly answering questions about Azure networking services, providing product guidance, and configuration suggestions. Your Cloud Network Architect by helping you select the right network services, architectures, and patterns to connect, secure, and scale your workloads in Azure. Your Cloud Network Engineer by helping you diagnose and troubleshoot network connectivity issues with step-by-step guidance. One of the most powerful features of Copilot in Azure is its ability to automatically diagnose common networking issues. Misconfigurations, connectivity failures, or degraded performance? Copilot can help with step-by-step guidance to resolve these issues quickly with minimal input and assistance from the user, simply ask questions like ”Why can’t my VM connect to the internet?”. As seen above, upon the user identifying the source and destination, Copilot can automatically discover the connectivity path and analyze the state and status of all the network elements in the path to pinpoint issues such as blocked ports, unhealthy network devices, or misconfigured Network Security Groups (NSGs). Technical Deep Dive: Contextualized Responses with Real-Time Insights When users ask a question on the Azure Portal, it gets sent to the Orchestrator. This step is crucial to generating a deep semantic understanding of the user’s question, reasoning over all Azure resources, and then determining that the question requires Network-specific capabilities to be answered. Copilot then collects contextual information based on what the user is looking at and what they have access to before dispatching the question to the relevant domain-specific plugins. Those plugins then use their service-specific capabilities to answer the user’s question. Copilot may even combine information from multiple plugins to provide responses to complex questions. In the case of questions relevant to Azure Networking services, Copilot uses real-time data from sources like diagnostic APIs, user logs, Azure metrics, Azure Resource Graph etc. all while maintaining complete privacy and security and only accessing what the user can access as defined in Azure Role based Access Control (RBAC) to help generate data-driven insights that help keep your network operating smoothly and securely. This information is then used by Copilot to help answer the user’s question via a variety of techniques including but not limited to Retrieval-Augmented Generation (RAG) and grounding. To learn more about how Copilot works, including our Responsible AI commitments, see Copilot in Azure Technical Deep Dive | Microsoft Community Hub. Summary: Key Benefits, Capabilities and Sample Prompts Copilot boosts efficiency by automating routine tasks and offering targeted answers, which saves network administrators time while troubleshooting, configuring and architecting their environments. Copilot also helps organizations reduce costs by minimizing manual work and catching errors while empowering customers to resolve networking issues on their own with AI-powered insights backed by Azure expertise. Copilot is equipped with powerful skills to assist users with network product information and selection, resource inventory and topology, and troubleshooting. For product information, Copilot can answer questions about Azure Networking products by leveraging published documentation, helping users with questions like “What type of Firewall is best suited for my environment?”. It offers tailored guidance for selecting and planning network architectures, including specific services like Azure Load Balancer and Azure Firewall. This guidance also extends to resilience-related questions like “What more can I do to ensure my app gateway is resilient?” involving services such as Azure Application Gateway and Azure Traffic Manager, among others. When it comes to inventory and topology, Copilot can help with questions like “What is the data path between my VM and the internet?” by mapping network resources, visualizing topologies, and tracking traffic paths, providing users with clear topology maps and connectivity graphs. For troubleshooting questions like “Why can’t I connect to my VM from on prem?”, Copilot analyzes both the control plane and data plane, offering diagnostics at the network and individual service levels. By using on-behalf-of RBAC, Copilot maintains secure, authorized access, ensuring users interact only with resources permitted by their access level. Looking Forward: Future Enhancements This is only the first step we are taking toward bringing interactive, generative-AI powered capabilities to Azure Networking services and as it evolves over time, future releases will introduce advanced capabilities. We also acknowledge that today Copilot in preview works better with certain Azure Networking services, and we will continue to onboard more services to the capabilities we are launching today. Some of the more advanced capabilities we are working on include predictive troubleshooting where Copilot will anticipate potential issues before they impact network performance. Network optimization capabilities that suggest ways to optimize your network for better performance, resilience and reliability alongside enhanced security capabilities providing insights into network security and compliance, helping organizations meet regulatory requirements starting with the integration of Security Copilot attack investigation capabilities for Azure Firewall. Conclusion Copilot in Azure for Networking is intended to enhance the overall Azure experience and help network administrators easily manage their Azure Networking services. By combining AI-driven insights with user-friendly interfaces, it empowers networking professionals and users to plan, deploy, and operate their Azure Network. These capabilities are now in preview, see Azure networking capabilities using Microsoft Copilot in Azure (preview) | Microsoft Learn to learn more and get started.
