Multicloud Transit Network Design Patterns

This document describes how to configure your VPC/VNets for a variety of single and multi-region scenarios.

Single Region Transit VPC/VNet Design

The use case for this design is if you have one connection from an on-prem network to the cloud (Direct Connect/ExpressRoute/InterConnect/FastConnect) or the Internet to a VPC/VNet.

The Aviatrix Multicloud Transit Network solution provides default network segmentation.

Since Spoke VPC/VNets have no connectivity to each other via a Transit Gateway, there is no need to create multiple Transit Groups for network isolation purposes.

In AWS, you can set up connectivity between the Shared Service VPC/VNet and Spoke VPC/VNets, and between Spoke VPC/VNets, using AWS peering.

The Transit Gateway in this scenario is only used for traffic between on-prem and cloud (Spoke VPC/VNets). Cloud-to-cloud traffic, such as Shared Service VPC/VNet to Spoke VPC/VNets does not go through the Transit Gateway. Decoupling the different traffic streams reduces the performance bottleneck and removes the single failure point.

A Spoke network can be deployed in different regions and different clouds (AWS and Azure).


Multi-Region Transit VPC Design

If you have data centers in multiple regions and its corresponding cloud service provider regions, you build network redundancy to reach the cloud by leveraging VPN Gateway (VGW/VPN Connect) termination.

In the diagram below, which uses AWS as an example, there are two Transit Gateways (primary and HA), one in each region. The VPN Gateway or VGW has an on-premises to the cloud (Direct Connect/ExpressRoute/InterConnect/FastConnect) or to one datacenter. The same VGW is also used for backup connectivity over the Internet from the second datacenter. If a data center loses connectivity to the VGW, the backup link can take over and use the alternate route.

One Aviatrix Controller manages both Transit Gateways. If you need connectivity between any two Spoke VPC/VNets in each region, you can build an AWS Peering.


Connected Transit Design

If you want to build a Transit Network where all Spoke VPC/VNets are connected via a Transit Gateway, you can accomplish that by enabling the Connected Transit property for the Transit Gateway. When Connected Transit is enabled, you do not need to build additional tunnels between shared service VPC/VNet to other VPC/VNets.

connected transit4

10Gbps Transit VPC/VNet Design

If you have applications that need 10Gbps bandwidth, you can place these applications in a VPC/VNet that terminates on the VPN Gateway/VGW with the 10Gbps VIF DX. Place the Aviatrix Transit Gateway in a separate VPC/VNet and connect it to the VPN Gateway/VGW through the normal Multi-Cloud Transit Network.


Alternatively, you can place the high bandwidth application in a separate VPC/VNet that terminates directly on a VIF or network interface, as shown below.


Distributed Egress Control with Aviatrix

If you are using a NAT Gateway as your egress control for Internet access, you can use Aviatrix FQDN Filtering (Legacy) to improve egress control.

As of Controller 7.1 and CoPilot 3.11, Distributed Cloud Firewall with WebGroups is the recommended method for configuring and implementing Egress Security.

The content in this section describes Egress functionality available in the Aviatrix Controller prior to Controller 7.1/CoPilot 3.11.

Aviatrix provides L7 FQDN to whitelist and blacklist public sites that applications in a Spoke VPC/VNet need to make API calls. The function is embedded in the Aviatrix Gateway. It is transparent to user instances and requires neither agents nor certs.


SD-WAN Integration

The Aviatrix Multicloud Transit Network integrates with SD-WAN cloud instances with BGP over LAN where both BGP routes and data packets are exchanged between Aviatrix Transit Gateways and SD-WAN gateways deployed in the same Transit VPC/VNet, as shown in the diagram below.