Intersite Connectivity Architecture – Intersite Connectivity

So far, you covered different connectivity methods by which you can establish connectivity between Azure-to-Azure and Azure to on-premises. When you explore enterprise environments, you will see that all three of these co-exist and work hand in hand to enable seamless intersite connectivity. Before you explore the architecture, it’s important that you understand the concept of a gateway transit.

A gateway transit is a feature you enabled while you enable peering. To explain gateway transits in layman’s terms, assume that you are booking a ticket from Singapore to Washington, DC. If you are taking British Airways, you need to get off at London, and board the next flight. Here London is a transit point, and Washington, DC, is your destination. You wanted to travel from Singapore to Washington, and in between you landed at the London airport. Nevertheless, you will reach your final destination. Gateway transit works the same way; you can utilize the gateway in the peered network as a transit point. From that transit point, your network traffic can travel to on-premises or any other location that is on the other side of the VPN gateway. When you configure gateway transit, you can communicate with resources that are outside the peered network. For example, you could establish connectivity from your peered network to the following:

• To on-premises via S2S
• To another virtual network
• To a client that is connected to P2S
• ExpressRoute connection

In all the aforementioned scenarios, the gateway transit will allow you to get access to the resources by sharing the gateway. This also helps in billing optimization; you don’t need to add a gateway to all the networks for on-premises connectivity. Instead, you could add a gateway to a single virtual network and peer the rest of the virtual networks to the virtual network that has the gateway. As you enable gateway transit, all peered networks will be able to share the gateway and reach resources that are there on-premises. This architecture is known as a hub-spoke architecture (refer to Figure 4.17).

FIGURE 4.17 Hub-spoke architecture using a gateway transit

While creating the virtual network peering, you get the option to use the remote virtual network’s gateway or route server. This can be enabled to activate the gateway transit feature, as shown in Figure 4.18. You need to make sure that the reciprocal connection is configured accordingly, and the remote network has a gateway deployed in it.

Now that you have a clear understanding about gateway transit, let’s discuss the co-existing connections. In Figure 4.19 you can see peering, S2S connection, P2S connection, and ExpressRoute circuit, all of them coexisting in the same architecture.

Some of the inferences you can make from the figure include the following:

• Virtual networks Spoke-VNet-1, Spoke-VNet-2, and Spoke-VNet-3 are peered with the Hub-VNet. You have gateway transit enabled, which means all spoke virtual networks will be able to share the gateways deployed in Hub-VNet.
• Hub-VNet has an ExpressRoute gateway that is connected to the on-premises HQ building. The circuit can provide a low-latency direct connection to the on-premises. As the spoke networks are peered to the hub and gateway transit is enabled, all spoke virtual networks will be able to use the ExpressRoute connection to on-premises.

FIGURE 4.18 Enabling gateway transit

FIGURE 4.19 Intersite connectivity architecture

• We have a VPN gateway in the Hub-VNet that has established S2S connections with the HQ building and another site in on-premises. Though HQ already has ExpressRoute, you have added a VPN S2S connection as a backup option that also can be utilized by applications that don’t require low latency. The low-latency ExpressRoute will be used by applications that require faster connection, and the rest of the connections will be established using the VPN S2S connection. Here also since the gateway transit is enabled, all the spoke virtual networks will be able to use a VPN gateway and establish connections with the on-premises Site 1 and HQ building.
• You have a client computer connected to the VPN gateway using a P2S connection.

The purpose of this architecture was to show the effective utilization of VPN gateways, peering, and ExpressRoute connections. By combining them, you will be able to implement highly available intersite architecture. This architecture can be further improvised by replacing the hub virtual network with the virtual WAN service. This service can help in setting up site connectivity to and through Azure. In the next section, we will cover an overview of the virtual WAN service.