The Virtual Networks in Azure are logically isolated, to allow you to securely connect different Azure resources. The Global VNet peering in Azure provides the possibility of connecting virtual networks residing on different regions of Azure. This article discusses the benefits and current constraints imposed by the Global VNet peering. It will also show the procedure for activating a Global VNet peering.
Figure 1 - Sample connection of two Azure VNet in different regions
When you configure the peering between two virtual networks that reside in different regions of Azure, you expand the logical boundary and virtual machines attested on these VNet can communicate with each other with their own private IP addresses, without having to use gateway and public IP addresses. Furthermore, you can use the hub-and-spoke network model, to share resources such as firewalls or virtual appliances, even connecting virtual networks in different regions of Azure, through the Global VNet peering.
Benefits of Global VNet peering
The main benefits that can be obtained using the Global VNet peering to connect virtual networks are:
- Traffic between the virtual network remains within the Microsoft's backbone network and is therefore totally private.
Figure 2 – Microsoft's backbone network
- You can use a low-latency connectivity and with a high bandwidth.
- Setup is simple and does not require gateway to establish VPN tunnel between different networks.
Current constraints of Global VNet peering
Currently there are some constraints that should be taken into account when making a Global VNet peering:
- In the presence of a Global peering VNET you can not use the remote gateway (option "use remote gateways") and you can't allow the gateway transit (option "allow gateway transit") on the virtual network. These options are currently usable only when you make a virtual network peering with virtual networks residing within the same region of Azure. It follows then the Global VNet peering are not transitive, then the downstream VNet in a region cannot communicate, using this methodology, with the VNet to another region. For example,, assuming a scenario where between the vNet1 and the vNet2 there is a Global VNet peering and between vNet2 and vNet3 there is another Global VNet peering. In this case there will be no communication between the vNet1 and the vNet3. If needed, you can create an additional Global VNET peering to put them in communication.
- For a resource that resides on a virtual network, is not allowed to communicate using the IP address of an internal Azure load balancer that resides on the virtual network in peer. This type of communication is allowed only if the source IP and the IP address of the Load Balancer are in the same VNet.
- The Global VNet peering can be created in all Azure public regions, but not with VNet residing in Azure national clouds.
- The creation of the Global VNet peering is allowed between VNet residing in different subscriptions, as long as they are associated with the same Active Directory tenant.
- The virtual networks can inserted into peering if there is no overlapping in its address space. Furthermore, after the creation of the peering, if you need to modify the address space you must remove the peering.
Global VNet peering configuration
Configuring Global VNet peering is extremely simple. In the following images are documented the steps to connect two virtual networks created in different regions, in this case West Europe and Southeast Australia.
Figure 3 - Adding peering from VNet settings
Figure 4 - Configure the peering parameters
Selecting "Allow virtual network access", allows communication between two virtual networks. With this setting the address space of the VNet in peer is added to the tag Virtual_Network.
Figure 5 – Peering added, in state Initiated
The same operations, documented in Figure 3 and figure 4, must be repeat even on the Virtual Network that resides in the other region and with whom you want to configure the Global VNet peering. The communication will be activated when the status of the peering will be "Connected"on both VNet.
Figure 6 – Peering in state Connected
Selecting a virtual machine, attested on a virtual network configured with the global VNET Peering, you will see a specific route for VNet associated, as shown in the following figure:
Figure 7 – Effective route of the VNet in Global Peering
The Global VNet peering involves costs for inbound and outbound network traffic in transit in the peering and the cost varies depending on the areas covered. For more details you can refer to the official page of costs.
Conclusions
The Global VNet peering allows a great flexibility in managing in a simple and efficient way as various workloads can be connected, allowing to expand the possible implementation scenarios on Azure, without having to consider the geographical boundaries as a limit. Significant benefits can be obtained in particular in data replication and disaster recovery architectures.
