AWS Transit Gateway

I’m pretty old school in that I’ve only ever implemented VPC peering when trying to enable resource communication across cloud networks. This has worked fine for the most part, however when it comes to building out a multi-account architecture, things can get messy very quickly. In fact, in some cases, AWS services simply cannot be delivered effectively with standard peering (AWS Network Firewall is a perfect example of this).

In comes AWS Transit Gateway (TGW) to save the day. A quick overview if you’re not already familiar.. TGW provides a completely centralised place to manage all of your connectivity between VPC’s. It’s a hub and spoke design, whereby you configure all of your spoke VPC’s to route traffic into the hub VPC (where your TGW lives), and from there, TGW takes care of the routing for you. This provides a number of benefits. A few of which are:

• Centralised network management
• Simplistic network design (no more managing random VPC peering connections all over the place)
• Increased scalability

This all aligns perfectly with an automated, scalable multi-account architecture. So how do we set this up? Well, lucky for us it’s incredibly simple. Follow these basic steps and you’ll be up and running in no time.

For this tutorial, we’ll assume you have three AWS accounts. One is your “Hub” and the other two are the “Spokes”. We’ll then establish connectivity between two EC2 instances within each of your spoke accounts via TGW.

In the Hub account:

1. Create a Transit Gateway
2. Create a Transit Gateway Attachment
3. Create a Resource Share to both of the spoke accounts via Resource Access Manager (note that this requires the AWS Organizations sharing option to be enabled under Resource Access Manager → Settings)

In Spoke Account A & B:

1. Create a Transit Gateway Attachment linking to the VPC of the spoke account (note, the VPC CIDR blocks must not overlap across accounts)

In the Hub account:

1. Navigate to Transit Gateway Attachments and select the attachments for your spoke accounts
2. Right click and select Accept attachment

In Spoke Account A & B:

1. Amend your VPC route table, add the CIDR for the other spike account and route it to the Transit Gateway
   This is an example configuration for Spoke Account B, where the CIDR for Spoke Account A is 10.0.1.0/24:

By default, during the setup of the Transit Gateway Attachments, each attachment will be automatically added to a default Transit Gateway Route Table and configured correctly, so you should not need to amend it.

You will then need to ensure that your EC2 security groups allow ICMP traffic . For testing purposes, you can allow this from all destinations.

You should then be able to ping Spoke Account B EC2 from Spoke Account A EC2:

That’s all there is to it! You can further refine all of your routing via the Transit Gateway Route Tables in your Hub account. By default, you will have one route table with default routes automatically added for each of your transit gateway attachments.

If you want even more visibility over your TGW routing, you can also use AWS Network Manager. From here, you can create a Global Network and register your TGW to it. This will give you a central place to view all logging metrics, your TGW topology and even provides a route analysis tool which is very useful for troubleshooting connection issues.

Hope you enjoyed this one and thanks again for reading!