What is the difference between static and propagated routes?

Static routes are manually configured entries that direct traffic for a specific CIDR to a specific attachment (VPC, VPN, Direct Connect). Propagated routes are automatically learned from VPN connections or Direct Connect gateways using BGP. When both exist for the same CIDR, static routes take precedence. Propagated routes simplify management for dynamic environments, but static routes give you explicit control over traffic paths.

How do I implement network segmentation with Transit Gateway?

Create multiple route tables — for example, one for production, one for development, and one for shared services. Associate each VPC attachment with the appropriate route table. Only add routes between segments that should communicate. The shared-services route table would have routes to both production and development, but the production table would not have routes to development. This prevents lateral movement between environments while allowing both to reach shared services.

Transit Gateway Route Builder

NetworkingAWS

Build Transit Gateway route table entries with static routes and propagations.

Last verified: May 2026

Transit Gateway Configuration

Build Transit Gateway route table entries with static routes, associations, and propagations.

Required Fields

TransitGatewayRouteTableIdRoutes[0].DestinationCidrBlockRoutes[0].TransitGatewayAttachmentId

{
  "TransitGatewayRouteTableId": "tgw-rtb-0a1b2c3d4e5f6a7b8",
  "Routes": [
    {
      "DestinationCidrBlock": "10.0.0.0/8",
      "TransitGatewayAttachmentId": "tgw-attach-0aaa1111bbbb2222c",
      "Type": "static",
      "State": "active"
    },
    {
      "DestinationCidrBlock": "172.16.0.0/12",
      "TransitGatewayAttachmentId": "tgw-attach-0bbb2222cccc3333d",
      "Type": "static",
      "State": "active"
    },
    {
      "DestinationCidrBlock": "0.0.0.0/0",
      "TransitGatewayAttachmentId": "tgw-attach-0ccc3333dddd4444e",
      "Type": "static",
      "State": "active"
    }
  ],
  "Associations": [
    {
      "TransitGatewayAttachmentId": "tgw-attach-0aaa1111bbbb2222c",
      "ResourceType": "vpc",
      "ResourceId": "vpc-0abc123def456789a"
    },
    {
      "TransitGatewayAttachmentId": "tgw-attach-0ccc3333dddd4444e",
      "ResourceType": "vpn",
      "ResourceId": "vpn-0def456abc789012b"
    }
  ],
  "Propagations": [
    {
      "TransitGatewayAttachmentId": "tgw-attach-0bbb2222cccc3333d",
      "ResourceType": "vpc",
      "ResourceId": "vpc-0fed987cba654321b"
    }
  ]
}

Generated Output

Output will appear here...

About This Tool

AWS Transit Gateway acts as a regional hub that connects VPCs, VPN connections, Direct Connect gateways, and peering attachments through a centralized routing model. Each attachment associates with one or more route tables, and traffic flow depends on route table entries — static routes, propagated routes, and blackhole routes. The Transit Gateway Route Builder helps you define route table configurations with proper CIDR destinations, attachment targets, and propagation settings so you can visualize and validate your hub-and-spoke or mesh network topology before deployment.

Real-World Scenario

Your team is consolidating 30 VPCs onto a Transit Gateway with hub-and-spoke topology including a centralized inspection VPC running a firewall appliance fleet. The builder generates: separate route tables for prod, dev, and shared-services; static routes from prod and dev pointing 0.0.0.0/0 to the inspection VPC; selective propagation rules so the inspection VPC sees both prod and dev routes for return traffic. End-to-end TGW config defined in 30 minutes vs the 2-3 days of trial-and-error to figure out the right combination of associations, propagations, and static routes.

When to Use This Tool

•Designing hub-and-spoke network topologies with isolated route tables for production, development, and shared-services VPCs
•Configuring route table entries that direct traffic from spoke VPCs through a centralized inspection VPC running firewall appliances
•Building blackhole routes to prevent specific CIDR ranges from being routable across the transit gateway

Pro Tips

TIP

Multiple route tables on a single TGW are the killer feature. Most teams default to 'one route table for everything' and lose the segmentation benefit. Use separate route tables for prod, dev, shared-services to enforce that prod ↔ dev traffic isn't routable even if VPC peering is misconfigured.

TIP

Static routes ALWAYS win over propagated. If you're seeing unexpected traffic flows on a TGW connected to both DX and VPN, check for static routes that override BGP-propagated routes. The TGW console doesn't always make this priority obvious.

TIP

Blackhole routes are perfect for kill-switch scenarios. Need to immediately stop traffic to a CIDR (compromised on-prem subnet, decommissioned partner)? Add a blackhole route on the relevant route tables. Faster and more reliable than racing to update firewall rules across 20 VPCs.

How It Works Under the Hood

The builder constructs Transit Gateway route table configurations: route table itself, attachment associations (which attachments use this table), propagation rules (which attachments push their routes), and static routes (CIDR + target attachment + blackhole/active flag). Output is generated as aws ec2 create-transit-gateway-route + associate-transit-gateway-route-table commands and Terraform aws_ec2_transit_gateway_route_table resources.

Frequently Asked Questions

What is the difference between static and propagated routes?: Static routes are manually configured entries that direct traffic for a specific CIDR to a specific attachment (VPC, VPN, Direct Connect). Propagated routes are automatically learned from VPN connections or Direct Connect gateways using BGP. When both exist for the same CIDR, static routes take precedence. Propagated routes simplify management for dynamic environments, but static routes give you explicit control over traffic paths.
How do I implement network segmentation with Transit Gateway?: Create multiple route tables — for example, one for production, one for development, and one for shared services. Associate each VPC attachment with the appropriate route table. Only add routes between segments that should communicate. The shared-services route table would have routes to both production and development, but the production table would not have routes to development. This prevents lateral movement between environments while allowing both to reach shared services.

Related Learning Guides

AWS Transit Gateway Patterns28 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.