Transit VIFs and Transit Gateway


Understanding Direct Connect, Implementation and Configuration
Why Direct Connect?
5m 25s
Understanding AWS Direct Connect - Connectivity Options
7m 3s
Securing Network Connectivity with Encryption
Examining AWS Routing
AWS Default Routing
AWS Transit Gateway
Start course
2h 40m

In this section of the AWS Certified Advanced Networking - Specialty learning path, we introduce you to the various tools, technologies, and services used to connect on-premises environments to the AWS Cloud, including Direct Connect and VPNs.

Learning Objectives

  • Identify and describe how Direct Connect and VPNs are used to connect on-premises environments to the AWS Cloud
  • Describe advanced AWS Direct Connect connectivity scenarios, including when to leverage Public, Private, and Transit Virtual Interfaces (VIFs)
  • Understand routing fundamentals for static and dynamic routing in AWS along with industry-standard routing protocols such as Border Gateway Protocol (BGP)
  • Describe how to use encryption to secure traffic as it travels across VPNs and Direct Connect connections


The AWS Certified Advanced Networking - Specialty certification has been designed for anyone with experience designing, implementing, and operating complex AWS and hybrid networking architectures. Ideally, you’ll also have some exposure to the nuances of AWS networking, particularly regarding the integration of AWS services and AWS security best practices. Many exam questions will require advanced level knowledge of many AWS services, including AWS networking services. The AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.


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.


About the Author
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).