Key Concepts

4 minute read

The AWS Transit Gateway (TGW) allows you to connect VPCs to each other and also allows you to connect VPCs to on-premise environments. The AWS Transit Gateway (TGW) is designed to replace the older Transit VPC architecture where you deployed third-party instances that performed transitive routing functions.

While both, the AWS Transit Gateway (TGW) and the older Transit VPC constructs allow for connectivity, the routing updates and related challenges are completely different. Let’s take look at the legacy approach of implementing transit using the Transit VPC architecture:

The connectivity to on-premise relies on Direct Connect or IPsec VPN, terminates in a VGW attached to the Transit VPC. A third-party appliance, like a CSR 1000v, then connects the VGW to all the “spoke VPCs”.

In this construct, the on-premise (or Datacenter) environment routes are learned by the VGW through Border Gateway Protocol (BGP). The third-party appliance/instance, also learns these on-premise routes through BGP from the VGW and propagates them to the spoke VPCs’ route tables. So, if we add or remove a subnet in the datacenter or connect a new branch location, these route changes will be propagated all the way to the Spoke VPCs using multiple BGP hops.

Now, let’s look at the newer AWS Transit Gateway (TGW).

The AWS Transit Gateway (TGW) can connect to on-prem environments using VPN (or Direct Connect) and learn routes using BGP. The AWS Transit Gateway (TGW) has internal Route Tables that will get populated with the on-premise routes. But, the AWS Transit Gateway (TGW) does not propagate these routes to the spoke VPC route tables. The VPC route updates need to be done via static route updates.

Similarly, route changes on-premise or VPC changes in the cloud have to be statically maintained when using the AWS Transit Gateway (TGW). In this regard, the native AWS Transit Gateway (TGW) solution alone may not meet all your requirements.