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.
The virtual networks can exist in any Azure public cloud region, but not in Azure national clouds.
Global VNet peering has been rolled out to all Azure public regions, but may not be available for your targeted Azure environment. Verifying the availability of Azure resources in your target environment and regions should always be a part of designing your solution.
Resources in one virtual network cannot communicate with the IP address of an Azure internal load balancer in the peered virtual network. The load balancer and the resources that communicate with it must be in the same virtual network.
Load balancers aren’t just used for load balancing web server and application traffic. Some IaaS deployments are dependent on internal load balancers. These include high availability configurations of network virtual appliances (a “load balancer sandwich”) and SQL Server Always On availability groups deployments in Azure.
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.
A virtual network can only have one gateway, either local or remote. Unlike local peering, a global peering cannot be configured to allow remote gateways.
Although not a technical limitation, the cost of network traffic between VNets may be a factor. For any given data transfer between peered VNets, there will be a charge for the data egress from the source VNet and a charge for the data ingress to the destination VNet. Inbound and outbound data traffic between peered VNets in the same region has a negligible charge. For data transfer between globally peered VNets, this charge may be considerably higher and is dependent on the zones. See the virtual network pricing details or using the pricing calculator to estimate your total Azure cost.
When designing connectivity between your Azure regions, you now have Global VNet peering to consider as an easy to implement and low-latency solution for virtual network connectivity. Under the right circumstances, it definitely has the potential to simplify or supplement existing regional connectivity.
