Since its introduction in November of 2018, the Transit Gateway, or TGW, has become an essential component to countless AWS customers, especially for those who must scale their networks to support and connect workloads across multiple AWS accounts, VPCs, and regions. Prior to the Transit Gateway, VPCs could be connected to one another via a VPC peering connection to route traffic between them. A VPC peering connection establishes a non-transitive one-to-one relationship between two VPCs. What does that mean?

Using a visual example, here we see that VPC-A has a peering connection with VPC-B and VPC-C. Thus, resources in VPC-A and VPC-B can communicate and resources in VPC-A and VPC-C can communicate. But since there is no direct VPC peering connection between VPC-B and VPC-C, resources in those VPCs cannot communicate with one another.

Though AWS customers appreciated the ability to connect VPCs with peering connections, as the number of VPCs and the need for peering connections increased, it became readily apparent that managing point-to-point network connections across multiple VPCs was complex, even unsustainable. Consider this diagram that shows the number of VPC peering connections that would be needed to fully mesh seven VPCs. Imagine trying to scale and manage such a network to support 50, 100 or thousands of VPCs? The AWS Transit Gateway is a regional resource that introduces a hub and spoke architecture to support highly scalable and easy-to-manage networks. The Transit Gateway functions as the hub through which traffic is routed to each connected network or spoke. A spoke can be a VPC, an on-prem data center, or remote office. To support global networks, inter-region peering can be used to connect Transit Gateways in multiple regions together, thereby establishing network connectivity for VPCs and AWS regions across the globe.

The data that traverses a TGW network is automatically encrypted and does not travel over the public Internet. We know it is possible to combine private VIFs with Direct Connect Gateways to access multiple VPCs in multiple AWS regions within the same account, and that's a great feature. But what about those multi-account, multi-region, multi-VPC AWS environments? Is it possible to use a Direct Connect connection to attach on-prem networks to a Transit Gateway-based global AWS network? The answer is a resounding yes. By means of creating a Transit VIF and attaching it to a Direct Connect Gateway. A Transit VIF will enable you to connect and access up to three Transit Gateways per Direct Connect Gateway over a private dedicated connection as shown in this diagram. Before we jump into a final architecture example, here are a few bullet points you should remember.

One, each Transit VIF supports up to three Transit Gateways. Each Transit Gateway can be attached to 20 Direct Connect Gateways. Three, each Transit Gateway can support up to 5,000 attachments and 50 peering connections. And four, a single Direct Connect supports one Transit VIF and a combination of up to 50 public and private VIFs. Finally, a Transit Gateway is able to route to and from Direct Connect Gateway attachments, even those located across the Transit Gateway peering connection. Practically any network connected via a Direct Connect Gateway that is attached to a Transit Gateway is reachable over the Transit Gateway network, and this allows AWS customers to architect very intricate and robust networks. Let's consider the following architecture. On the left, we have an AWS Transit Gateway network that spans three regions. The Transit Gateways are peered and thus an AWS resource and any VPC could communicate with resources in any region across the AWS network.

On the right, we have three geographically dispersed data centers, each connected to an AWS Direct Connect, which utilizes a Transit VIF attached to a Direct Connect Gateway, which is itself attached to a Transit Gateway. This type of architecture could allow a resource in any corporate data center to access an AWS resource in any region. And because the corporate data centers all use Direct Connect with Transit VIFs, this configuration would allow the corporate data centers to communicate with one another using the AWS Transit Gateway network.