Last week Microsoft just released Azure VNet peering – a highly-requested and long-awaited internetworking feature – into public preview. VNet peering provides the ability to join two VNet’s, or virtual networks, in the same region using Microsoft’s Azure backbone network. Because of this functionality, all resources appear to be on the same network as compared to being on two separate networks that are simply connected. VNet peering is just another giant step in making Microsoft Azure a game-changer for hybrid networks.

Reduced Costs – Traditionally, to get this same functionality, both networks had to incorporate a mechanism known as a gateway. For all simplistic purposes, you could think of a gateway as simply a form of connectivity, such as a network switch connecting two machines. The Azure gateway currently has 3 tiers of speed and the costs of the gateway were dependent on the tier you chose. VNet peering, however, costs nothing.

Improved Performance – When using a gateway, there are elements of latency introduced into your network traffic. This latency in highly-available, highly-transactional scenarios can often be troublesome. Instead of a gateway, VNet peering creates a private connection between the two VNet’s thus rendering the same performance as that of two machines being directly connected to the same network.

Backwards Compatibility – Prior to VNet peering, connecting a classic (Service Manager) VNet to a Resource Manager VNet required creating a gateway between the two networks. This caused much angst among network administrators and was often a deterrent to using Resource Manager for creating new virtual machines. VNet peering now allows network administrators to connect classic VNet’s to VNet’s created through Resource Manager.

Hybrid Connectivity – VNet peering provides an alternative, simpler mechanism for connecting Azure virtual networks to on-premises networks. Traditionally, connecting multiple virtual networks in Azure to local networks required creating a gateway in each virtual network. This only multiplied costs. Now, network administrators can implement what’s known as a hub-and-spoke model. All Azure virtual networks connect to a central VNet through peering; and, the central (hub) VNet uses a single gateway to connect to the on-premises network. The ability for all peered VNets to connect to the on-premises network through the centralized VNet’s gateway is known as transitive communications.

As you consider VNet peering in your customer’s network schemas, there are a couple of limitations of which you should be aware.

  1. VNet peering can be used to connect two virtual networks that were created used Resource Manager; or, it can be used to connect one virtual network created using Resource Manager to another network created using Service Manager. However, VNet peering cannot be used to directly connect two virtual networks created through Service Manager. In order to connect two VNet’s created through Service Manager, you would need to follow the hub-and-spoke model where the hub is a VNet created using Resource Manager.
  2. All connected VNet’s must use unique IP ranges. There cannot be any overlapping IP’s between the connected virtual networks.

For more information check out Microsoft’s official documentation.