Skip to main content

Command Palette

Search for a command to run...

Controlling Route Propagation in Transit Gateway

Published
3 min readView as Markdown
K

Passionate DevOps/Cloud/Database Architect with a proven track record in automation, cloud optimization, and Database management. Experienced in IT , I specialize in designing and implementing CI/CD pipelines, automating deployments, and leveraging cloud technologies to build scalable, secure, and high-performing infrastructures. Seeking opportunities to drive innovation and efficiency in modern software development environments.

When working with AWS Transit Gateway, enabling default route propagation allows each VPC's routes to be automatically propagated to the Transit Gateway route table. This setup enables seamless connectivity between VPCs, provided that the correct security groups, route tables, and attachments are in place. However, there are scenarios where default propagation is not desired, and manual control over inter-VPC connectivity is necessary.

In this guide, we will demonstrate how to control route propagation and restrict connectivity between specific VPCs.

Scenario Overview

We have the following VPCs in our architecture:

  • Two private spoke VPCs

  • One hub VPC

Objective:

  • Allow both spoke VPCs to connect to the hub VPC.

  • Prevent spoke VPCs from communicating with each other.

Step 1: Creating a Transit Gateway Without Default Route Propagation

Instead of using default route propagation, we disable it to gain full control over routing behavior.

Step 2: Creating Transit Gateway Attachments

We create Transit Gateway attachments for each of the three VPCs (two spoke VPCs and one hub VPC). These attachments establish the necessary connectivity framework without automatically propagating routes.

Step 3: Configuring Custom Route Tables for Transit Gateway

Since default route propagation is disabled, we manually create Transit Gateway route tables for each attachment to define specific routing rules.

Step 4: Manually Configuring Route Propagation

To enforce our desired connectivity, we manually enable route propagation for specific attachments:

  • Spoke VPCs can propagate routes to the hub VPC.

  • Spoke VPCs do not propagate routes to each other, ensuring they remain isolated.

Once the propagation rules are applied, routes are automatically available in the respective route tables.

Step 5: Updating VPC Route Tables and Security Groups

  • We update the VPC route tables where instances are running, ensuring traffic is correctly forwarded to the Transit Gateway.

  • We also modify security groups to allow only the necessary connections.

Step 6: Testing Connectivity

After configuring the route tables and security groups:

  • Instances in the Hub VPC can connect to both Spoke VPCs

Instances in Spoke VPCs cannot communicate with each other ❌ (as expected due to controlled route propagation)

Key Takeaways

Manual route propagation allows fine-grained control over inter-VPC connectivity. ✅ Disabling default route propagation prevents unintended connections. ✅ Using separate Transit Gateway route tables for each attachment ensures custom routing rules. ✅ Security group rules must align with routing configurations for proper connectivity.

By implementing manual route propagation, organizations can enhance network security, optimize routing, and enforce precise connectivity rules within their AWS environment.

More from this blog

AWS-Concepts

26 posts