The AWS Transit Gateway (TGW) was introduced to eliminate complexity involved in peering many VPCs together. In the pre-AWS Transit Gateway (TGW) world, if you had to connect many VPCs, you were required to use a complex mesh of VPC peerings. To be accurate n (n-1)/2, where n is the number of VPCs.

AWS Transit Gateway (TGW) was introduced to make peering of VPCs easier. But, it does not make routing easy. When attaching the AWS Transit Gateway (TGW) to a VPC, it does not propagate routes to the VPCs. Similarly, creating propagation across route tables in the AWS Transit Gateway (TGW) does not automatically populate routes into the respective tables.

The formula of how many route tables need to be managed, reviewed and updated when using an AWS Transit Gateway (TGW) is equal to: n ( s + r - 1), where n is the number of VPCs attached to the AWS Transit Gateway (TGW), s is the number of subnets in each VPC and r is the number of route tables in the AWS Transit Gateway (TGW).

Let’s take an example of a mid-size environment: if you have 20 VPCs with 4 subnets in each spread across 3 route tables, the total number of routes you need to manage, update and troubleshoot is:

20 (4 + 3 – 1) = 120 route entries.

This formula and example above does not include VPN and/or Direct Connect links from on-premises to the AWS Transit Gateway (TGW). Those bring in a new set of routes to manage and inherent limits to overcome.

Operationalizing such an environment requires a stateful orchestrator that can intelligently compare routes, understand your cross-domain policies, and manage the routing correctly. The orchestrator should also let you visualize the environment and troubleshoot connectivity issues. Aviatrix TGW Orchestrator has all these capabilities; hence AWS enlisted Aviatrix to collaborate with on making AWS Transit Gateway easier.

For more information, check out: https://docs.aviatrix.com/HowTos/tgw_faq.html