Transit Gateway (TGW)
A Transit Gateway is a network object that provides connectivity among other network objects that would otherwise require admin overhead to set up and maintain. It’s a transit hub that’s high available and scalable by default and reduces network complexity.
For each network object you want to be part of the routing you create attachments, each with exactly one route table. Valid attachments are:
-
VPCs
-
Site-to-site VPNs
-
Direct Connect Gateways
-
A peering connections to another transit gateway
Peering attachments enable cross-region and cross-account traffic routing
Normally, if you have Dx and or a Site-to-site VPN (maybe in true HA), plus a number of VPCs that need to communicate to each other, the network architecture is a monster:
-
A VPC Peering configuration for each VPC to all the others
-
at least 2 Dx Gateways to at least 2 customer gateways on-prem
-
same for Site-to-site VPN tunnels
Transit gateways allow for a much cleaner and maintainable network architecture:
Attachments must be configured in a subnet within each AZ where you need connectivity.
Transit Gateways support multiple route tables
Equal-Cost Multi Path (ECMP)
You can use AWS Transit Gateway to scale an AWS Site-to-Site VPN throughput beyond a single IPsec tunnel’s maximum limit of 1.25 Gbps limit.
Before the launch of AWS Transit Gateway, virtual private gateways were the only choice for VPN connectivity, other than third-party solutions. Virtual private gateways with a VPN are suitable for single-VPC connectivity. When connecting multiple VPCs to the on-premises environment, each VPC must have a separate VPN connection through a respective virtual private gateway, or follow the transit VPC architecture.
With Transit Gateways and ECMP you can:
-
Simplify the network architecture
-
have routing support for multipl IPSec tunnel (dynamic routing in the transit gateway configuration MUST be enabled).
The VPN tunnels are used in parallel, you establish multiple VPN tunnels to an ECMP-enabled transit gateway.
