This is the third blog post of a three-part series. Before you begin reading, I would suggest reading the first two posts Networking to and within the Azure Cloud, part 1 and Networking to and within the Azure Cloud, part 2.

Hybrid networking is a nice thing, but the question then is how do we define hybrid networking? For me, in the context of the connectivity to virtual networks, ExpressRoute’s private peering or VPN connectivity, it is the ability to connect cross-premises resources to one or more Virtual Networks (VNets). While this all works nicely, and we know how to connect to the cloud, how do we network within the cloud? There are at least 3 Azure built-in ways of doing this. In this series of 3 blog posts, my intent is to briefly explain:

1. Hybrid networking connectivity options
2. Intra-cloud connectivity options
3. Putting all these concepts together

Putting it all together – connection to the cloud and within the cloud

While all these methods and connectivity options are interesting separately, when they are most powerful is when they are combined.

Transit VNet with Gateway Sharing

The topology below shows a simple hub & spoke topology. Even if VNet peering itself is NOT transitive, transit routing is allowed for gateways (VPN and ExpressRoute). There is an example of combining VNet peering alongside with Gateway Sharing, but using ExpressRoute:

Transit VNet with Gateway Sharing, 1 ExpressRoute circuit in 2 regions

However when combining this with the usage of more than one Azure region (remember, VNet peering is within a single region), you could easily create a topology like this one:

In the image above, you have every VNet within West US and East US able to talk to each other without never leaving the Microsoft backbone network, at high speeds, limited by the ExpressRoute Gateway created on each Hub VNet, that is 1, 2, or 10 Gbps depending on the ExpressRoute gateway SKU. With that being the case, note that packets are physically routed between West US region and Chicago when going to East US. This makes sense because Chicago is between these two regions.

Transit VNet with Gateway Sharing, 2 ExpressRoute circuits in 2 regions

With another topology where perhaps connectivity to ExpressRoute is needed in more than in Chicago or the resiliency of a single ExpressRoute circuit is not enough, despite the SLA, you could create the following topology:

In this case, cross-premises connectivity might have a better latency, if premises are located in the Western part of the United States, and in the Eastern part of the United States. Also, there are 2 ExpressRoute locations through which the packets between the VNets in West US and East US could go through. Since these regions are close to the circuit locations, the added latency should not constitute an issue on the latency. Moreover, this gives a higher potential uptime because of the use of 2 separate ExpressRoute circuits, in 2 distinct locations across the continental US.

Transit VNet with Gateway Sharing, 3 ExpressRoute circuits in 3 regions

This model could scale to more circuits and more regions, but I believe this gives a good understanding of the kinds of topologies we can create using the Azure Networking toolbox.

Local circuits are important in that case to make sure we have optimal routing. On that specific topic, I encourage you to read the article Optimize ExpressRoute Routing. The article discusses the optimal routing for Virtual Networks, which is useful to understand how to make sure that packets routed from West US destined to North Europe would not go through the Tokyo ExpressRoute circuit. Using weights assigned to connections is how you can actually achieve this.

Transit VNet with BGP Enabled VPN Gateway Sharing and VPN Transit Routing

Another interesting use case of VPN transit, with BGP routing would allow topologies like the image below. For more information please read the Overview of BGP with Azure VPN Gateways.

In this last case, it is possible for on premises users that are located in the Western part of the US to use the VPN on the left to reach on premises users connected to the VPN to the North Europe VNet, located on the right, effectively leveraging the Azure backbone between their own facilities without using some kind of proxy mechanisms. This would otherwise be required to allow that scenario.