Transit Gateway: Centralize outbound internet traffic in AWS Organization

What is Transit Gateway?

Transit Gateway is a powerful service offered by Amazon Web Services (AWS) that simplifies network management, improves security, and reduces operational overhead and costs. It offers organizations a centralized hub for network connections, enabling them to connect their Amazon Virtual Private Clouds (VPCs), on-premise networks, and remote offices to a single network transit hub. By leveraging the benefits of Transit Gateway, organizations can simplify their network management, improve security, increase scalability, and reduce cost, making it an essential tool for any organization looking to streamline their AWS infrastructure.

In this article, we will dive into the details of Transit Gateway and how it can be used to centralize internet traffic and reduce costs within an AWS organization with multiple accounts and VPCs without compromising VPC isolation.

Centralize outbound internet traffic from multiple AWS accounts with Transit Gateway

Without Transit Gateway each VPC and each account needs to have at least one NAT gateway for outbound internet, however here we will show you how to use Transit Gateway to route the outbound traffic toward centralized NAT gateways in a single account. We recommend one NAT gateway per Availability Zone, so for example, if you use ‘eu-west-1a’ and ‘eu-west-1b’ you should have 2 NAT gateway instances in the Admin account.

For this demo, we will use a single NAT gateway in ‘eu-west-1a’ that will be placed in our Admin account along with the Transit Gateway, but you can use any AWS account in your Organization. We need to share the Transit Gateway with the other accounts (we will call them Application accounts in this article) by using AWS Resource Access Manager (AWS RAM). This will allow the Application accounts to attach their VPCs to the shared Transit Gateway. Once Transit Gateway is shared with the Application accounts that will use it, Transit Gateway Attachments should be created in each of these accounts. So instead of having a NAT gateway and Elastic IP in each private subnet in every Application account, the traffic will be sent to Transit Gateway Attachments which will be using the centralized NAT gateway in our Admin account to distribute the traffic. Follow along with the blog to find out more about the details.

1. Setting up the Transit Gateway in the Admin account and sharing it with the Application accounts

The first step in setting up AWS Transit Gateway architecture is to set up the Admin account. This is the account that will own the Transit Gateway and will be responsible for managing it. Here are the steps to set up the Admin account:

Set up a Transit Gateway in the Admin AWS account:

To set up a Transit Gateway in the Admin AWS account, you need to go to the AWS Transit Gateway console and follow the steps to create a new Transit Gateway. During the setup process, you will need to specify the VPCs that you want to attach to the Transit Gateway. In this case, you should attach a VPC with a NAT gateway to the Transit Gateway.

Share the Transit Gateway with other accounts:

After you have set up the Transit Gateway in the Admin account, the next step is to share it with the other accounts that will be using it. This is where AWS Resource Access Manager (RAM) comes in. RAM allows you to share AWS resources like Transit Gateway across multiple accounts without having to create multiple copies of the resource.

To share the Transit Gateway with other accounts using RAM, you need to follow these steps:

• Create a resource share in the Admin account:

In the AWS RAM console, you need to create a resource share for the Transit Gateway in the Admin account. During the creation process, you will need to specify the accounts that you want to share the Transit Gateway with.

• Accept the resource share in the other accounts:

After you have created the resource share in the Admin account, the next step is to accept the share in the other accounts that will be using the Transit Gateway. To do this, you need to go to the AWS RAM console in each account and accept the share.

Once the Transit Gateway has been shared with the other accounts, those accounts can then attach their VPCs to the Transit Gateway and start using it for communication between VPCs and on-premises resources. We are doing so with Transit Gateway Attachments in each account, as per the steps below.

2. Setting up Transit Gateway Attachments and configuring routing in the Application accounts

Attach VPCs to the Transit Gateway:

• In each of the Application accounts, navigate to the Transit Gateway Attachments section in the VPC console.

• Click on “Create Transit Gateway Attachment” and select the Transit Gateway and VPC you want to attach.

• Choose the appropriate subnet and security group settings and click “Create Attachment”. Repeat this step for each VPC that you want to attach to the Transit Gateway.

Set up routing for Private Subnets:

Setup routing for all private subnets in each Application account, where the CIDR should be pointing at “local” (as it is by default) and 0.0.0.0/0 should be routed towards the Transit Gateway.

Set up routing for Public Subnets:

Set up routing for the public subnets in each App account, where the CIDR should be pointing at “local” and 0.0.0.0/0 should be routed towards a local Internet Gateway.

After this is done, we need some routing adjustments in the Admin account:

3. Setting up routing in the Admin account

VPC Route tables

First, we need to configure the routes pertaining to the CIDR of our Application account/accounts that we are currently integrating with the Transit Gateway in the following VPC Route tables:

• Egress-Public-RT

In this route table, we need to create a default route with the destination set to 0.0.0.0/0 associated with the internet gateway.

Then we need to add the CIDR pertaining to each of the VPCs that will be using the Transit Gateway infrastructure. The target will be the ID of our Transit Gateway.

• Egress-Private-RT

In this route table, we need to create a default route with the destination set to 0.0.0.0/0 associated with the NAT gateway.

Then we need to add the CIDR pertaining to each of the VPCs that will be using the Transit Gateway infrastructure. The target will be the ID of our Transit Gateway.

In our case 172.41.0.0/16 is the CIDR pertaining to the VPC that we are using in the Admin account, which explains why the Target is local and the other CIDRs belong to each VPC in the Application accounts. It is important to note that you can’t have overlapping CIDR blocks (using the same IP range), for example, here we have 172.41.0.0/16 as the Admin VPC, hence we can’t have the same CIDR in any of the Application VPCs if we want to connect them through the Transit Gateway.

Add Transit Gateway attachments to Transit Gateway route tables

Transit Gateway service has its own routing which needs to be configured. We can start by creating the following route tables – Egress-RouteTable and App-RouteTable and associating them with our Transit Gateway.

• App-RouteTable

Create App-RouteTable, then create Associations for each Application VPC in App-RouteTable by adding the new Transit Gateway Attachment and the VPC ID

• Egress-RouteTable

Create Egress-RouteTable, then create Route for each Application in Egress-RouteTable by adding the new VPC CIDR block and the new Transit Gateway Attachment as a static route.

By following these steps, you should have successfully set up Transit Gateway attachments and routing in the Application accounts to centralize the outbound internet traffic within your AWS Organization with NAT gateway in the Admin account.

This will not only centralize maintenance and improve security but also significantly reduce costs by eliminating multiple NAT gateway instances.

For more configuration details and routing best practices please refer to this AWS Document.

Conclusion

In conclusion, utilizing Transit Gateway can greatly optimize network management in a multi-account environment.

Huge companies with thousands of accounts such as Adobe are using it, claiming better management of IP space which comes with super fast go-to-market for their products because of the ease of infrastructure deployment.

As with most of the services in AWS, Transit Gateway is no exception when it comes to monitoring, hence it can be seamlessly integrated with CloudWatch in order to retrieve metrics. Also, Transit Gateway Flow Logs can be captured for detailed analysis of the traffic going from and to your Transit Gateway.