Transit Network Design Patterns¶
Aviatrix Transit VPC provides a workflow to create a Transit VPC GW with a set of Spoke VPC GWs.
From one Aviatrix Controller, you can setup Transit Groups in a single region or across multiple AWS regions.
Single Region Transit VPC Design¶
The use case for this design is if you have one Direct Connect or Internet to VPC.
Aviatrix Transit VPC solution provides default network segmentation, a Spoke VPC has no connectivity to another Spoke VPC via the Transit GW. For example, you do not need to spin up a Dev Transit Group and a Production Transit Transit Group as none of the Spoke VPCs in either group can communicate with each other. As such, you do not need to spin up multiple Transit Groups for network isolation purpose. A diagram is shown below.
Notice Transit GW is only used for traffic between on-prem and cloud (Spoke VPCs). Cloud to cloud traffic, such as Shared Service VPC to Spoke VPCs does not go through the Transit GW. Decouple the different traffic streams reduces the performance bottleneck and removes the single failure point.
A Spoke VPC can be deployed in a different region and different cloud.
Multi Regions Transit VPC Design¶
If you have datacenters in multiple regions and its corresponding AWS regions, you build network redundancy to reach cloud by leveraging AWS VGW termination,
In the diagram below, there are two Transit Groups, one in each region. The VGW has Direct Connect or Internet to one datacenter, the same VGW is also used as a backup connectivity over Internet from the second datacenter.
Note one Aviatrix Controller manages both Transit Groups. If you need connectivity between any two Spoke VPCs in each region, you can build an AWS Peering or Aviatrix Encrypted Peering from the Controller console.
10Gbps Transit VPC Design¶
If you have applications that need 10Gbps bandwidth, you can place these applications in a VPC that terminates on the VGW with the 10Gbps VIF DX. Place the Aviatrix Transit GW in a separate VPC and connected it to the VGW through the normal Transit VPC workflow
Alternatively, you can place the high bandwidth application in a separate VPC that terminates directly on a VIF, as shown below.
Using Aviatrix for Egress Control¶
If you are using AWS NAT Gateway as your egress control for Internet access, consider using Aviatrix FQDN to improve egress control.
Aviatrix provides L7 FQDN to whitelists and blacklists public sites that applications in a Spoke VPC need to make API calls. The function is embedded in the Aviatrix gateway. It is transparent to user instances and requires no agents nor certs.
Integrating with Egress Firewall -1¶
If you are running AWS Workspace services for your employees and need a full fledged firewall device, place the firewall appliance in shared service VPC or its own VPC. Treat this VPC as one type of shared service VPC that offers egress control for instances in a private subnet of all Spoke VPCs.
In this case, use Aviatrix site2cloud feature to connect to the firewall appliance, as shown in the diagram below.
The advantage of this architecture is that traffic to Internet and on-prem is decoupled. Transit GW only carries traffic between on-prem and cloud.
Integrating with Egress Firewall -2¶
In the above deployment model, each Spoke VPC establishes a site2cloud IPSEC connection to the firewall. Unless there is automation, the process of building many IPSEC connections could be time consuming and difficult to manage.
An alternative and automated way is to connect the firewall to VGW directly, seen the diagram below. This approach requires only 1 connection to/from the firewall device. The drawback of the approach is that Transit GW also carry the Internet bound traffic from Spoke VPC.