When discussing Azure networking, a question that frequently comes up is how to connect different Azure regions. More specifically, this question typically boils down to how to connect VNETs that are in different regions.
There are three options to achieve this connection, which we’ll discuss in this post:
- Global VNET peering
- VNET-to-VNET connection
- Expressroute
Although we’ll be exploring all three options through the lens of cross-region connectivity, all three solutions also work for connecting VNETs in the same region. One area where the solution might be a bit different is the explanation of global VNET peering and on-premises connectivity.
The content in this post remains relatively high-level on purpose. I purposefully didn’t want to go into the details of how this impacts the hub-and-spoke reference model. If that is of interest to you, let me know via a comment, because I’m always interested in new topics.
In this post, I also express my opinion in a couple places. Please note that this is my personal opinion, not necessarily the opinion of Microsoft, and that technological evolution might cause my opinion to change.
With that, let’s start at option 1: Global VNET peering
Global VNET peering
Global VNET peering is the easiest way to connect networks in different regions together. It’s also the way I personally recommend to connect VNETs in different regions together. Global VNET peering will create a connection over the Azure backbone directly between the two peered VNETs. Generally speaking, you should expect the highest bandwidth and lowest latency connection when you connect two VNET together using VNET peering.
When VNETs are peered, Azure will also handle the routing automatically for you. VNETs that are peered, can communicate with all resources in the peered VNET. VNET peering however isn’t transitive. This means that when VNET A is connected to VNET B and VNET B is connected to VNET C, VNET A and VNET C won’t be connected and they won’t have connectivity.
What about on-prem connectivity?
A question that often pops up is how to think about connectivity back to on-prem when using global VNET peering. Azure supports gateway transit, which means that you could connect VNETs in two different Azure regions back to on-prem using a single VPN tunnel in one of those regions. The following picture explains that architecture:
I generally advise against this solution for a couple of reasons:
- Region 1 is a single point of failure. In case region 1 has an outage, all traffic between on-prem and region 1 and region 2 will be lost.
- Typically, the network path going from region 2 to on-prem via region 1 isn’t as optimized as going directly from region 2 to on-prem directly. This will likely introduce additional latency.
- Your VPN gateway in region 1 will become a choke point in terms of bandwidth. This is a lesser concern, since Azure now has VPN gateway devices that can do VPN tunnels up to 10Gbps.
There are however valid use cases where this architecture has merit. There are cases where you need to use multiple Azure regions for a single deployment. This could for instance be the availability of certain SKUs or services in only select locations, while the bulk of your application runs in another region. However, I like to keep these as exceptions, not as the rule.
My preferred solution for connection two Azure regions that have VNET peering between them is to simply connect both to on-prem via their own VPN tunnel. This is better from an availability perspective, and will like have better latency and bandwidth performance.
There’s one final thing that’s important to point out about the design above. In option 1 we were able to use gateway transit to reach on-prem via the VPN gateway in the other VNET. This is not possible if the VNET has a gateway deployed in it. For example, imagine that the VPN between region 1 and on-prem fails. You can still connect to region 2 using its VPN connection, but you won’t be able to reach region 1 using region 2’s VPN and rely on gateway transit. (it could be done by setting up an additional router, but that goes out of scope for this blog post)
VNET-to-VNET connection
A second way to connect two VNETs in different locations is by using a VNET-to-VNET connection. A VNET-to-VNET connection is essentially a VPN between the two different Azure locations. The VNET-to-VNET connection is established on a VPN gateway. This means your traffic will incur two additional traffic hops as compared to global VNET peering (the two gateways on each end). This also means you will incur additional latency, and the VPN gateways can become a bandwidth chokepoint.
The one benefit of using a VNET-to-VNET connection is that the traffic between the different Azure regions will be encrypted using IPSEC. VNET peering runs over the Microsoft backbone unencrypted, while a VNET-to-VNET connection uses IPSEC to connect the two VNETs together.
The VPN Gateways that are used for the VNET-to-VNET connection can be reused as regular VPN Gateways as well and provide connectivity back to on-prem. In case you are using BPG with VPN Gateways, in this scenario you can achieve a fallback VPN option in case one of the connections is down.
Expressroute
A final way you can connect VNETs in multiple Azure regions together is by using Expressroute. Each VNET that is connected to an Expressroute circuit, becomes part of the same routing domain. This means that each VNET that is connected to Expressroute, regardless of whether it is in the same region or in a different region, will have connectivity to each other.
The downside of this connection model is that all the traffic is hairpinned over the Expressroute peering location. This means you introduce additional network latency.
The connection between the two gateways would happen at the peering location, but would not go over the peered network. Meaning, the connection stays on the Microsoft network, but the hairpin happens at the peering location.
Summary
In this post we explored three different ways to connect VNETs in different Azure regions together. We discussed global VNET peering, VNET-to-VNET connection and Expressroute. In the global VNET peering section we took a slight detour and also discussed two option in which you can connect back to on-premises.
I hope this helps you in understanding the different options to connect your VNETs together.