An introduction to Networking in the Cloud using AWS Transit Gateways

Not terribly long ago, Amazon introduced Transit Gateways, a nifty service that simplifies AWS networking. A transit gateway (or TGW) acts like a lightweight router that can be used to connect multiple VPCs, potentially in multiple accounts, together in a hub-and-spoke configuration that can enable any subnet to talk to any other subnet.  Transit gateways also support the ability to route to corporate networks using AWS Direct Connect or AWS Site to Site VPN connections.

A Little Graph Theory

If you have a large number of VPCs that are interconnected, one of the best uses for transit gateways is to eliminate VPC peering connections.  Since VPC peers only connect one VPC to another and can’t be used to pass traffic to a more distant VPC, then if you want all of your VPCs to be able to talk to each other you need an increasing number of connections for each new VPC that you add to the network.  (Extra-nerdy detail:  The number of links in a fully meshed network of n nodes is (n²-n)/2.  For a hub and spoke configuration you only need n-1 links.)

The connection between a transit gateway and a VPC is called an attachment.  When used to connect two accounts together, the attachment is initiated in one account and accepted in the other.  The mutually agreeable aspect of the attachment works just like a VPC peering connection does. Also like a peering connection, the cost for the attachment and any charges for data transferred over it are the responsibility of the account that initiated the attachment (aka the “owner” of the attachment).  Either side is free to disconnect the attachment at any time.  

The first release transit gateway required the VPCs to all be in the same region, but with the addition of Transit Gateway Peering, it’s also possible to route private packets between transit gateways in different regions. (for those regions that support it)

Routing

From a connectivity point of view, you might not want the equivalent of a fully meshed network.  Transit Gateway Routing tables give you selective control over which VPCs can communication with which other VPCs.  The TGW solution has the additional advantage that the control over connectivity is easily change and happens in a single, centralized, account. (The one where the TGW is deployed.) There are lots of use cases where this could be important, especially if you’re using a service like AWS Control Tower.

There are three possible kinds of routes in a transit gateway routing table:

• Static routes, that get added and left alone.
• Dynamic routes, that get added when a new CIDR gets added to VPC if automatic propagation of routes has been enabled for an attachment.
• Blackhole Routes that explicitly block the flow of traffic along an attachment.

The content of TGW route tables are controlled by the account that owns the TGW, but the owner of a VPC still has access to VPC routing tables and security groups to control network access even if the TGW is set up in a very permissive way.

Beyond reducing the count of peering connections, Transit Gateway provide a number of interesting opportunities for resource sharing and network simplification.  I’ll talk about a couple of those in a future blog. In the meantime, if you’ve got an interesting application that you’d like to talk about sooner, leave a comment below or feel free to contact us.