Aviatrix Answers

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

Network Design
5 minute read

The AWS transit gateway (TGW) was introduced to eliminate complexity involved in peering many VPCs together. In the pre-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.

TGW was introduced to make peering of VPCs easier. But, it does not make routing easy. When attaching the TGW to a VPC, it does not propagate routes to the VPCs. Similarly, creating propagation across route tables in the 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 TGW is equal to: n ( s + r - 1), where n is the number of VPCs attached to the TGW, s is the number of subnets in each VPC and r is the number of route tables in the 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 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