# A Practical Guide to AWS Transit Gateway

## **Introduction**

As cloud architectures grow in complexity, the limitations of VPC peering become evident. AWS Transit Gateway provides a scalable and efficient solution to interconnect multiple VPCs. In this article, I will demonstrate how to set up a Transit Gateway to enable seamless communication between instances running across multiple VPCs.

## **Setting Up AWS Transit Gateway**

To begin, I will create a **Transit Gateway** with **default route propagation and route association enabled**. This configuration allows the default Transit Gateway route table to automatically learn how to send traffic to the connected VPCs, eliminating the need for manual route entries.

### **Step 1: Creating the Transit Gateway**

When setting up the Transit Gateway, the following options are enabled:

* **Route propagation**: This ensures that the Transit Gateway automatically understands the routes to the connected VPCs.
    
* **Route association**: This helps in dynamically learning the routes as VPCs get attached.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743220117967/3fe3f8a3-29ef-4cfa-a4e2-df4e775f43fc.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743220165212/374920b7-3952-4a5a-babd-2674f23e37da.png align="center")

## **Creating Transit Gateway Attachments**

Once the Transit Gateway is created, the next step is to create attachments for each VPC. AWS provides multiple attachment options based on requirements, such as VPN, Direct Connect, and VPC attachments. In this example, I am focusing on VPC attachments.

Since I have three VPCs, I will create three **Transit Gateway Attachments**, one for each VPC:

* **Attachment 1** (VPC 1)
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743220273204/aebc5a4d-c1ba-4292-b5b0-32a92f4ce775.png align="center")

* **Attachment 2** (VPC 2)
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743220322401/ea94b858-350b-472e-aeff-6e7a9466cbb3.png align="center")

**Attachment 3** (VPC 3)

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743221326383/e7a1e853-0e13-4ac1-9b44-09fef567e810.png align="center")

All Attachments

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743222570314/2b50292f-b6e7-45ec-bdf9-54445bc88000.png align="center")

## **Configuring Route Tables**

### **Step 2: Checking Routes within the Transit Gateway Route Table**

Once the attachments are established, I will check the **Transit Gateway Route Table** to confirm that the routes are correctly propagated.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743222598198/8c1ef6e7-1c98-4a87-bfa1-fb31e22c0343.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743222613194/6ff2ffe7-7275-47b5-b088-2bd740135131.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743222648244/529e2576-98a0-49af-9287-7cf57ce91882.png align="center")

### **Step 3: Updating Subnet Route Tables**

For instances in each VPC to communicate, I need to update the **subnet route tables** within each VPC. Static entries for the network and the Transit Gateway must be added.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743222990668/c35a5341-c03e-4393-be7a-f766491ec389.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223009830/a31a15c0-13fd-4a5d-8fed-2b2f6fb31b41.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223034387/061f7b45-4f17-4cc9-bf0e-255d7468936c.png align="center")

## **Validating Connectivity**

### **Step 4: Testing Inter-VPC Communication**

After configuring the route tables, I will test connectivity between instances in different VPCs. Successful communication confirms the correct setup of the Transit Gateway and routing tables.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223122863/89742639-92c5-41d3-b1a9-c2a64d3dd777.png align="center")

### **Step 5: Identifying and Fixing Routing Issues**

If an instance cannot reach another VPC, I will check its **subnet route table** to ensure that the appropriate routes exist.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223171660/086d6c0d-5b46-4ea1-9f29-f0c8790c4a7a.png align="center")

If a required route is missing, adding it will restore connectivity.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223314185/f7999739-8f34-4fb0-844d-f78f326a7ef6.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223354762/8106e437-1e50-402a-b6af-1277e75faf96.png align="center")

## **Understanding Transit Gateway Elastic Network Interfaces (ENIs)**

AWS Transit Gateway creates **Elastic Network Interfaces (ENIs)** in all the subnets where attachments are configured. If a subnet is not explicitly mentioned during attachment creation, the Transit Gateway will not be available for that subnet.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1743223530046/ba384af9-75eb-4f9d-8a5f-5c31b1820540.png align="center")

## **Conclusion**

AWS Transit Gateway simplifies network management in multi-VPC environments, overcoming the limitations of VPC peering. By leveraging **route propagation and association**, we can build a highly scalable and efficient architecture. Proper **route table configuration** and **attachment management** are key to ensuring seamless communication between VPCs.

With this setup, multiple VPCs can securely communicate without the complexity of maintaining numerous peering connections. AWS Transit Gateway provides a robust, centralized networking solution that scales with enterprise cloud architectures.