The Pros and Cons to Azure's VNet Peering
The other day I was asked to design a solution that required VNet peering, after some further digging and research into this feature I thought I'd share some of my findings with you all.
Before we dive into the pros and cons, lets take a moment to quickly recap on what VNet peering actually is.
What is VNET Peering?
VNet peering is a fairly new feature -- introduced August 2016 -- within Microsoft Azure that connects two VNets, providing low latency and high speed connectivity between your Azure virtual networks.
Let us first look at the pros to VNet peering,
- Subscriptions - VNets within different subscriptions can be linked. This can be useful in situations in which a single organization has multiple Azure subscriptions for budgetary or logistical reasons.
- Latency - Traffic routes through the internal Azure backbone, allowing low latency. The network latency for a round trip between two virtual machines in peered virtual networks is the same as for a round trip within a local virtual network.
- Bandwidth - There isn't any additional restriction on bandwidth. The network throughput is only limited based on the virtual machines permitted bandwidth.
- ARM to ASM - ASM (Azure Service Management) aka classic VNets can be peered with ARM (Azure Resource Manager) VNets. However they must both be in the same subscription.
- Cost - There is a small cost for ingress/egress traffic ; £0.0061 per GB ingress and £0.0061 per GB egress. Far cheaper then the traditional alternative of a VPN connection between each of the VNets.
- NSG - Network Security Groups (NSGs) are supported, providing you with the ability to deny/permit both ingress and egress traffic.
- Transitive Routing - Transitive routing*, though not enabled by default can be enabled via the "Allow Forwarded Traffic" option, within the spoke VNet. This configuration option is necessary when configuring virtual networking appliances within your hub VNet, so that transit traffic can route through the hub.
- Gateway Transit - Traffic can be routed though the gateway (VPN/ExpressRoute) of a peered VNet. This provides the ability to build hub and spoke based topologies, where the spoke VNets all use the gateway of the hub.
*An example of transitive routing is when you have VNet A connected to VNet B. VNet B is connected to VNet C. For traffic from VNet A to reach VNet C traffic would to be transitively routed via VNet B.
And now for the cons,
- Different Regions - Each VNet peer must reside within the same region.
- Overlapping Address Space - Each VNet peer should not have an overlapping IP address space.
- ASM to ASM - ASM (Azure Service Management) to ASM (Azure Service Management) VNets cannot be peered.
- Remote Gateway - A VNet that is using the remote gateway of a peered VNet cannot have a local gateway configured as well. In other words a single virtual network can have only one gateway. It can either be a local gateway or a remote gateway (in the peered virtual network).
Why does this matter? Each VNet can have a maximum of a SINGLE policy VPN gateway assigned. Now, lets imagine you need to connect multiple remote offices into a single VNet, with each remote office only supporting policy based VPNs (think Cisco ASA). Being able to configure multiple remote gateways would allow you to place each of your policy VPN gateways into different VNets, or in other words build a reverse hub and spoke based topology (below is an example).
VNet peering does come with some cons, mainly the inability to configure multiple remote gateways per VNet. However, there are many pros, such as cost reduction on traditional peering methods, low latency and the ability to perform transitive routing. To summarize VNet peering is a great option over traditional VNet to VNet VPN methods, and is something you should be fully aware of when designing your Azure cloud environments.