Hi all, welcome back to the AWS networking series. This is actually part 3 of just Transit Gateway. I know some of you might be thinking, why are we still talking about Transit Gateway? But please bear with me. TGW is such an important concept, and it shows up in almost every architecture you come across.
So far, we've covered what a Transit Gateway is, how to create one, how route tables work, and how to manage associations and propagations. We also looked at how to create a VPN and attach it to the TGW, and we went through the process of sharing a TGW with other AWS accounts using AWS Resource Access Manager (RAM). In this post, we'll look at how to peer a Transit Gateway with another TGW, even when they are in different regions. So let's get to it.
If you're completely new to Transit Gateway, I highly recommend checking out the earlier introductory posts listed below.
Suresh Vina
As always, if you find this post helpful, press the ‘clap’ button. It means a lot to me and helps me know you enjoy this type of content. If I get enough claps for this series, I’ll make sure to write more on this specific topic.
Transit Gateway Inter-Region Peering Concepts
You can peer both intra-Region and inter-Region Transit Gateways and route traffic between them. To do that, we need to create a peering attachment on our Transit Gateway. The peer TGW can be in our own account or in another AWS account. Once we create the peering attachment request, the owner of the peer TGW (also called the accepter TGW) needs to accept it before it becomes active.
To actually route traffic between the TGWs, we need to manually add a static route in the route table that points to the peering attachment. This isn’t dynamic, so don’t forget this step.
One more thing to note is that Inter-Region TGW peering uses the same network infrastructure as VPC peering. That means traffic between Regions is encrypted using AES-256 at the virtual network layer. It’s also encrypted at the physical layer when it crosses network links outside AWS’s physical control.
Topology Overview and Peering Scenario
For the purpose of this example, we’ll use a setup where our primary AWS account has a VPC in the London region (the account we've been using throughout this series). Our goal is to peer this Transit Gateway with another TGW that belongs to a different AWS account, and the corresponding VPC is in the Frankfurt region.
We’ve already gone through how to create a Transit Gateway, how to create VPC and VPN attachments, and how to associate those attachments with a TGW route table. We also covered the important point that we need to update our subnet route tables (which are separate from the Transit Gateway route tables) so they know how to reach the far end of the VPC CIDR by pointing to the correct TGW attachment.
Creating the Peering Request
To create a peering between two Transit Gateways across accounts and regions, we start by treating the peering just like any other TGW attachment. So, head over to Transit Gateway Attachments and select 'Create transit gateway attachment'.
Next, we’re creating a new Transit Gateway attachment from the London region to the Frankfurt region in another AWS account.
We select the type as 'Peering Connection' and provide the account ID of the other AWS account. We also specify the Frankfurt region and select the Transit Gateway ID in that region. This is the only part that’s slightly different from a VPC or VPN attachment.
Once we create the attachment, it shows up with the status 'Pending Acceptance'. This is expected. The request has now gone to the other AWS account, which owns the Frankfurt TGW. That account needs to log in and manually accept the request.
In the Frankfurt account, we now go and accept the peering request. After acceptance, the state will move to 'Available'. At this stage, the peering is active, but traffic won’t flow until we associate it with a route table.
Route Table Association
Next, we associate the peering attachment with the route table on the Frankfurt side. This allows the TGW in Frankfurt to know what traffic to forward through this TGW peering link. So, select your TGW route table and create a new association.
We do the same thing on the London side. We associate the peering attachment with the London TGW route table. Remember, attachments must be explicitly associated with a TGW route table to be used for routing (unless you use the default route table).
Adding a Static Route
Now we add a static route in the Frankfurt TGW route table that points to the CIDR block of the London VPC. We choose the peering attachment as the target. This route tells the Frankfurt TGW how to reach the remote VPC.
We repeat the process in the London TGW. We add a static route pointing to the Frankfurt VPC CIDR block and target it to the same peering attachment. This step is important, as the TGW routing is not dynamic.
VPC Subnet Route Tables
With TGW route tables updated, we now update the VPC subnet route table in Frankfurt. We point the 10.200.0.0/16 CIDR block (which belongs to London) to the Frankfurt TGW. This allows resources in the Frankfurt VPC to route traffic to London.
We do the same thing in the London VPC route table. We add a route for 10.210.0.0/16, which belongs to Frankfurt, and set the target as the TGW (TGW VPC attachment to be specific). This completes the full routing between the two VPCs using the TGWs.
Testing and Verification
At this point, both VPCs should be able to talk to each other using the Transit Gateway peering. Just remember, TGW peering behaves like any other attachment, but we must take care of all the associations and static route entries manually.
Please remember that there are costs associated with data transfer between AWS regions. This is something you definitely want to factor into your overall AWS design. Inter-region data transfer is not free and can add up quickly, especially if large volumes of traffic are involved or if you're building architectures that rely heavily on cross-region communication.
