Some Updates for Global Azure Virtual Network (VNet) Peering in Azure

Last year, I wrote a blog post discussing Global VNet Peering in Azure to highlight the capabilities and limitations. The use of global peering at that time was significantly different in capability from local peering and required careful consideration before including in the design. Microsoft is continually adding and updating capabilities of the Azure platform, and the information from my original post requires updates to describe the current state of VNet peering.

The virtual networks can exist in any Azure public cloud region, but not in Azure national clouds.

Update – Global VNet peering is now available in all Azure regions, including Azure national clouds. You can create peering between VNets in any region in Azure Government, and peering can exist between US DoD and US Gov regions. The peering can span both regions and subscriptions.

In Azure commercial, a peering can also be created between VNets in different Azure Active Directory tenants using PowerShell or command-line interface (CLI). This requires configuring an account with access in both tenants with at least the minimum required permissions on the VNets (network contributor role). In Azure Government, this is not currently possible and peered VNets must exist under the same Azure Active Directory tenant.

Resources in one virtual network cannot communicate with the IP address of an Azure internal load balancer in the peered virtual network.

Update – This limitation existed with the available load balancer at that time. Load balancers are now available in “Basic” and “Standard” tiers. The Basic load balancer is not accessible from a globally peered VNet. The “Standard” load balancer is accessible across global peering and has other additional features. A design can generally be adapted to replace Basic load balancers with Standard load balancers in high availability deployments where implementing global peering. Basic load balancers are a free resource. Standard load balancers are charged based on the number of rules and data processed.

Several Azure services also utilize a Basic load balancer and are subject to the same constraints. Please verify that the resources you are using for your specific design are supported.

You cannot use remote gateways or allow gateway transit. To use remote gateways or allow gateway transit, both virtual networks in the peering must exist in the same region.

Update – This is no longer accurate. A globally peered VNet can now use a remote gateway.

Transferring data between peered VNets does incur some cost. The cost is nominal within the same region. Cost may become significant when moving between regions and through gateways.

In summary, there have been significant updates to Global VNet Peering since my original post. The current capability now more closely aligns with local peering. These changes simplify network connectivity between regions, and the inclusion of multi-region redundancy makes disaster recovery more feasible.