Multicloud Transit Network Design Patterns

This document describes multiple regions and its corresponding CSP regions and the related VPC design.

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 Internet to a VPC/VNet.

Aviatrix’s Multicloud Transit Network solution provides default network segmentation, a Spoke VPC/VNet has no connectivity to another Spoke VPC/VNet via the Transit GW. For example, you do not need to spin up a Dev Transit Group and a Production Transit Group as none of the Spoke VPC/VNets in either group can communicate with each other. As such, you do not need to spin up multiple Transit Groups for network isolation purpose. See the diagram below.

To set up connectivity between Shared Service VPC/VNet and Spoke VPC/VNets, and between Spoke VPC/VNets, choose AWS Peering for AWS or Aviatrix Encrypted Peering from the Controller.

Notice Transit GW 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 GW. Decouple the different traffic streams reduces the performance bottleneck and removes the single failure point.

A Spoke network can be deployed in a different region and different cloud (AWS and Azure).

images0

Multi-Regions Transit VPC Design

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

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

Note one Aviatrix Controller manages both Transit Groups. If you need connectivity between any two Spoke VPC/VNets in each region, you can build an AWS Peering or Aviatrix Encrypted Peering from the Controller.

images1

Connected Transit Design

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

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 GW in a separate VPC/VNet and connect it to the VPN Gateway/VGW through the normal Multi-Cloud Transit Network.

images3

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.

images4

Distributed Egress Control with Aviatrix

If you are using a NAT Gateway as your egress control for Internet access, consider using Aviatrix FQDN to improve egress control.

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.

images5

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.

sd_wan_integ