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). |
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.
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:
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.
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, 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.
