Introduction

AWS transit gateway allows you to connect VPCs, direct connects and VPNs through a central hub. Traditionally in networking this is known as the hub and spoke model. In AWS cloud, this simplifies network connectivity and offers scalable and robust way of stiching networks together privately.

In most organisations there are muliple VPCs and accounts used for different purposes, such as stage, dev, pre-prod, prod etc. Also large conglomerates with different line of business may require their VPCs to be privately connected. In the past this private connectivity was achieved with VPC peering.

VPC peering has limiations with transitive connections, i.e. if you have VPC A, B and C and A peers with B and B peers with C, you cannot use the transit between A and B to get from A to C.

Transit gateway solves the issue with transitive connection limitation. Transit gateway is basically a managed hub router that centrally connects to all your VPCs, Direct Connect gateways and VPN connections. These are called attachments.

Attachments

As of writing this, transit gateway supports the following attachments

• VPC attachment
• Direct connect attachment
• VPN attachment
• Connect attachment
• Transit gateway peering (Same region peering is not supported at the moment)

Route table

Transit gateway also supports multiple route tables. This is similar to VRF lite technology you see on traditional network equipment. Currently there is an upper limit of about 20 route tables per transit gateway. The different route tables allows you to support overlapping IPv4 addresses as well as keep different attachments from reaching other directly. Also using multiple route tables, you can implement advanced topologies where you can perform traffic engineering to traffic as it leaves your VPC.

Route propogation and filtering

When automatic route propogation is enabled, as soon as the VPC or VPN is attached the network CIDR is automatically added to the route table with the next hop pointing to the attachment. In networking, it is common practice to filter routes between different devices. These are usually done in the form of prefix lists and route-maps (Cisco) that are applied to neighbouring devices. When a peering device announces a set of prefixes these are already known ahead of time and will allow you to determine where the prefixes are originated from. It appears this functionality is currently missing from TGW, and would be a welcome feature addition. Going through the documentation, you may see information about TGW prefix lists https://docs.aws.amazon.com/vpc/latest/tgw/tgw-prefix-lists.html, however the intended fucntionality for this is not provide route filtering.

SD-WAN

A number of SD-WAN vendors support integration with AWS TGW. These vendors allow their customers to use their familiar SD-WAN orchestration UIs to deploy a TGW into their accounts using the AWS API and attach to VPCs. In the past these SD-WAN solutions would need to peer with each VPC by creating VGW and site-to-site VPN connections. With TGW, the moving parts are significantly reduced thus making the onboarding of VPC to SD-WAN much easier.

Here an example architecture from https://aws.amazon.com/blogs/apn/exploring-architectures-with-cisco-sd-wan-and-aws-transit-gateway/ showing Cisco SD-WAN integration with TGW.

CloudWatch

AWS CloudWatch is integrated with TGW out of the box which is awesome. This gives useful metrics that you can use to build dashboards on. The metrics will give you an insight into TGW level metrics as well as attachment level metrics such as BytesIn, BytesOut etc. More on the supported metrics is available here https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-cloudwatch-metrics.html