Microsoft Backbone Network based

VNet Peering inherently permits your Azure Resource Groups between two autonomous distinct VNets to communicate over the Azure provisioned internal Private IP (otherwise also called as the Microsoft backbone network) as though they are on the same virtual network. The connection is seamless with low network latency which implicitly generate higher throughput.

Let us create an Azure Resource Groups as below and create two Virtual Machines as VM1 and VM2, the location of the Resource Group is Central Canada, in this case we are only using the standard VNet peering feature. If you want to connect/ peer between two different VM’s in a Resource Group which are from different regions; this can be achieved by using Global VNet peering mechanism which provision a direct connection between those two VNets.

VM1 is provisioned under the Virtual Network VNet A and VM2 is provisioned in VNet B, each VNet has a specific Subnet which is inherently implied.

By clicking on a particular Virtual Network, VNet A in our case, we need to find the Peerings blade where you can create a new peering mechanism.

When clicked on Add from the VNet A, we need to select the Virtual Network to which the peering needs to be made, in our case VNet B.

Explicitly, the configuration of the network access settings needs to be enabled for communication, and the forwarding the network traffic disabled subsequently.

Similarly to the above step, we need to provision a new VNet Peering from VNet B to VNet A as below, leaving the network access settings enabled and forwarding traffic to be disabled.

Traffic forwarding is not enabled in our case, as we are not exposing the VM to the external web. If you need to access your VM from the public IP address, we need the Traffic forwarding enabled which protects your VM architecture, the front end and back end servers to hide malicious access from the outside world. This mechanism adds an extra layer of security to your existing architecture.