How many route table updates will I have to manage for large Transit Gateway deployments?

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 together, you be 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 a 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). This brings in a new set of routes to manage and inherent limits to overcome.

As you can see, operationalizing this environment requires a stateful orchestrator that can intelligently compare routes, understand your cross-domain policies and manage the routing correctly. This orchestrator should also let you visualize the environment and troubleshoot connectivity issues. This is why AWS enlisted Aviatrix to collaborate with on making AWS Transit Gateway easier.

For more information, please go to: https://docs.aviatrix.com/HowTos/tgw_faq.html