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.

Azure's Global Footprint
The above image shows Azure regions and the global footprint.

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.

Improve Networking and Connectivity in Your Environment. Contact AIS Today to Discuss Your Options.

For the latest updates, check out my Global VNet Peering in Azure blog posted 8/9/19.

First announced as a public preview in September 2017, Global VNet Peering is now generally available in all Azure public regions.

Similar to virtual network peering within the same Azure region, Global VNet Peering now lets you seamlessly connect virtual networks in different Azure regions. The connectivity between the peered virtual networks is routed through the Microsoft backbone infrastructure through private IP addresses. VNet peering provides virtual network connectivity without gateways, additional hops, or transit over the public internet. Global VNet Peering can simplify network designs which have cross-regional scenarios for data replication, disaster recovery, and database failover.

While similar, peering within the same region and peering across regions have unique constraints.  These are clearly identified in the Microsoft documentation, so check that out before you get started. Read More…

In a previous blog post I discussed Windows Azure PaaS / IaaS hybrid scenarios. Together with my colleague Jack O’Connell (Infrastructure Specialist extraordinaire), we set up each of the four scenarios outlined in the previous post including:

  • Using Windows Azure Virtual Network to provision a VPN to connect our on-premised infrastructure with a Windows Azure datacenter.
  • Set up front-end and back-end subnets.
  • Provision a set of Azure IaaS Virtual Machines and Azure Web Roles.
  • Install System Center Monitoring Pack for Windows Azure Applications on Azure-based machines.
  • Install System Center Operations on-premises in order to manage Azure-based resources.

Watch the following video for a quick walkthrough of the scenarios in action: