Aviatrix AWS Transit Gateway Orchestrator FAQ

AWS TGW simplifies, abstracts, and extends the latest AWS Transit Gateway service. The Aviatrix platform makes Transit Gateway-based Transit architecture deployable by overcoming Transit Gateway limitations.

The AWS TGW is illustrated in the diagram below.

In the above diagram, AWS VPCs are grouped into four domains: Dev domain, Prod domain, Shared Service domain and Aviatrix Edge domain. Each VPC in the same domain can communicate with each other via AWS Transit Gateway. VPCs in Prod domain cannot communicate with VPCs in Dev Domain, while all VPCs in Dev domain and Prod domain can communicate with Shared service domain and Aviatrix Edge domain.

Through the Aviatrix Transit GW in the Aviatrix Edge domain, Spoke VPCs can communicate with on-prem over Direct Connect.

In the deployment, the VPC in the Aviatrix Edge domain is a Spoke VPC from the Transit Gateway point of view. However, it serves as Transit VPC from the Aviatrix Transit Network point of view. No Aviatrix gateways are deployed in Spoke VPCs except in the Transit VPC.

Aviatrix Transit GW serves as hub connecting to Azure and GCP networks.

The AWS TGW leverages the Aviatrix Transit Network workflow for the hybrid connectivity function to an on-prem data center and branches. It enables the AWS TGW to connect with on-prem over Direct Connect or Internet.

The Aviatrix AWS TGW feature can also be used as a stand-alone function for orchestrating VPC to VPC connections.

When using the AWS TGW feature for hybrid connectivity, no gateways are deployed in the Spoke VPCs for hybrid function.

Transit VPC refers to the transit deployment model where an Aviatrix Gateway is deployed in a Spoke VPC. This is now called "advanced mode" in the AVX Transit.

The AWS TGW can be deployed with some Spoke VPCs run Aviatrix gateways. When is the right use case to run Aviatrix Spoke gateway?

AWS CloudFormation for Transit Gateway is a resource construct for Transit Gateway. So is the Terraform example.

They are all useful solutions, but these constructs may not be sufficient to run your network.

For example, a Transit Gateway does not propagate routes from on-prem to the VPC route table, meaning there is no guarantee that your VPC instances can reach a specific on-prem server or host. Even if you hard coded the list of CIDRs to shuffle them down to Transit Gateway, what happens when a new VLAN or Subnet is stood up on-prem. Who is going to notify you?

A modern distributed network either requires BGP to dynamically propagate the routes or a CoPilot that dynamically updates the routes. No matter what approach you use, it is the only way to guarantee the network actually functions. At Aviatrix, we choose a software defined approach with our platform. Unless you plan to develop a platform like ours, you should consider using our product.

Learn more about Transit Gateway limitations.

The TGW/Transit Segmentation Interoperability feature enables you to extend your AWS TGW network domains into other CSPs. When you are setting up your multicloud transit structure, you can attach an AWS TGW domain to an Aviatrix Transit network domain. Attachments in the AWS TGW network domains can then communicate with Aviatrix Spoke gateways and Site2Cloud connections in the same and in connected Transit network domains.

See Implementing Network Segmentation in an Aviatrix-Managed Network for information about Network Domains and Connection Policies.

When an Aviatrix Transit Gateway is created, the Default_Domain is created and a route table corresponding to the Default_Domain is created on the Transit Gateway. If you do not plan on building any network segmentation, you can use Default_Domain for inter Spoke VPC and hybrid communications.

When an Aviatrix Transit Gateway is created, the Shared_Service_Domain is created and a route table corresponding to the Shared_Service_Domain is created on Transit Gateway.

You can attach a Spoke VPC to this domain and host your shared service instances such as your DevOps tools.

Shared_Service_Domain is always connected to Default_Domain and Aviatrix_Edge_Domain.

When an Aviatrix Transit Gateway is created, the Aviatrix_Edge_Domain is created and a route table corresponding to the Aviatrix_Edge_Domain is created on the Transit Gateway.

Aviatrix_Edge_Domain is designated for connecting VPCs managed by the AWS TGW to on-prem network. There must be one VPC attached to this domain. In the VPC, an Aviatrix Transit GW is deployed and used for data traffic forwarding between Spoke VPCs and on-prem network.

Aviatrix_Edge_Domain is always connected to the Shared_Service Domain and the Default_Domain.

For information about how to deploy the AWS TGW in Aviatrix, see Overview of AWS Transit Gateway Orchestrator Features.

Here are some design patterns that address your requirements.

Yes, you can change your design any time.

Unlike a VPC, where once you have created it and launched instances in the VPC you cannot delete the VPC or move the instances easily, a Transit Gateway and its attachments can all be changed without making changes to the instances and VPC CIDRs. Simply detach the VPCs from the current Transit Gateway, launch a new Transit Gateway, and build it out again.

The Aviatrix AWS TGW manages the entire life cycle of the network, including Network Domains, all Transit Gateway and attachments should be created and managed by AWS TGW.

Transit Gateway significantly simplifies building VPC connections. But the Transit Gateway itself is functionally incomplete for hybrid connection. For example, the Transit Gateway does not propagate routes to Spoke VPCs, which means using a Transit Gateway alone does not offer a functional hybrid solution.

The example below illustrates how CSR based Transit VPC provides an end-to-end solution while a Transit Gateway alone leaves Spoke VPC route table all empty.

The missing function of Transit Gateway is listed as below:

While you may think you can gather the on-prem routes and program the Spoke VPC tables, it is in reality not so simple. The on-prem routes change from time to time as new networks are added or removed, which means you need a reliable way to monitor the route changes, handle exceptions and deal with errors and duplicate routes — essentially a function carried by BGP or AWS TGW.

Aviatrix AWS TGW fulfills the need to propagate on-prem routes to the Spoke VPCs. This function is either carried by BGP or is software defined. In the Aviatrix case, it is software defined and performed by the Aviatrix Controller. The diagram below shows how the CSR Transit VPC, the Transit Gateway and the Aviatrix AWS TGW compare for route propagation function. As can be seen, in the CSR Transit VPC case, CSR propagates on-prem routes to Spoke VPC via BGP to VGW; the Transit Gateway has no route propagation to Spoke VPC. The Aviatrix Controller propagates routes to Spoke VPC through a software-defined mechanism.

An Aviatrix Gateway deployed at the edge/transit VPC provides the following values:

In some cases, you absolutely can. For example, if you have a group of VPCs that need to be connected to each other, you can attach each VPC to the same TGW route table with propagation enabled. Then program each VPC route table with the default route (0.0.0.0/0) to point to TGW.

But in other cases you may not. Using the above example, if there is public subnet in a Spoke VPC, then you cannot simply program each route table with the default route pointing to TGW, as a public subnet already must have its default route pointing to the IGW.

Even a Spoke VPC route table for private subnet may already have the default route point to an AWS NAT gateway. This is quite a common situation and as it happens, you cannot program the default route to the TGW.

However, in the example scenarios above, you maybe able to program RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) routes of the Spoke VPCs to point to TGW. This is a viable solution you can use to address the issues mentioned above and one that works in a lot of situations.

Yes. The Aviatrix platform allows you set up a VPN attachment from CoPilot directly.

Yes. If you would like to connect your Direct Connect directly into Transit Gateway, the Aviatrix platform allows you to configure an association between the Direct Connect Gateway and AWS Transit Gateway in Aviatrix CoPilot.

AWS Serverless TGW Orchestrator is a solution published by AWS. It orchestrates VPC attachment to a TGW by programming both the TGW route table and VPC route table. The deployment is a Cloudformation Template that contains many AWS services such as Amazon DynamoDB, Amazon EventBridge, Amazon Simple Notification, AWS Lambda function.

Edge Segmentation allows you to further specify on each edge connection which domain it can communicate with.

When you create a Transit Gateway, you can go to CloudFabric > Gateways > select the Transit Gateways tab > select the Transit Gateway > select the Settings tab > open the CSP Related Settings section > find AWS TGW Edge Segmentation and click on the Connection dropdown menu to select a connection.

When this option is selected, you can then use Build Your Domain Connection Policies to specify which Network Domain this edge connection can communicate with, as shown in the diagram below.

In the above diagram, Site 1 can communicate with Prod domain but not with Dev domain and Shared Service domain. Site 2 can communicate with Dev domain but not with Prod domain and Shared Service domain. Site 3 can communicate with Shared Service domain but not with Dev domain and Prod domain.

Edge Segmentation works across Connection Policies for AWS TGW Peered Network Domains.

Multicast capability function is able to be turned on when users launch AWS TGW. This is API support only.