Lesson 271 · AWS Learning Path

AWS 271: Transit Gateway routing and segmentation

Anil Jalela · Published Mar 23, 2026 · 12 min read

Why this lesson matters

A diagram with lines between VPCs does not prove reachability or isolation. Transit Gateway (TGW) evaluates a packet using the route table associated with its source attachment. The selected destination attachment then delivers the packet into another routing domain, and the reply performs its own independent lookups. Centralized inspection can add two more TGW crossings and multiple VPC route tables.

This lesson turns connectivity intent into a deterministic route proof. You will model production, nonproduction, shared services, inspection, on-premises, Direct Connect, VPN backup, and inter-Region peering. For every approved and denied flow, you will identify the exact lookup, next hop, return path, security control, telemetry, and owner. No AWS route or attachment is changed.

Outcomes

By the end, you can:

• distinguish TGW route-table association from propagation;
• perform longest-prefix and equal-prefix route selection correctly;
• use separate route domains to model trust boundaries;
• calculate static, propagated, prefix-list, and blackhole behavior;
• trace forward and return paths through VPC and TGW route tables;
• design centralized inspection with appliance mode and AZ symmetry;
• prove peering, Direct Connect, VPN, IPv4, IPv6, and failover paths;
• use Flow Logs and route evidence to diagnose no-route, blackhole, MTU, TTL, and bypass faults;
• govern route changes, drift, exceptions, and rollback; and
• complete a 15-flow segmentation matrix suitable for architecture review.

Five facts that prevent most mistakes

TGW routes are reachability policy, not application authorization. Security groups, NACLs, firewalls, host controls, TLS, and application identity remain separate.

A deterministic route-proof algorithm

For each source-destination flow:

1. Record source/destination IP, ports/protocol, address family, accounts, VPCs, subnets, AZ IDs, and attachment IDs.
2. Inspect the source workload subnet route table. Apply longest prefix and identify its target.
3. Confirm the source VPC has a TGW attachment subnet in that AZ and that required attachment-subnet routes exist.
4. Identify the TGW route table associated with the source attachment.
5. Search for the exact destination plus covering routes. Apply longest prefix, then documented route-type priority for equal CIDRs.
6. If the target is inspection, perform all inspection-VPC subnet/firewall route lookups and the second TGW lookup.
7. Inspect the destination VPC attachment and target subnet path.
8. Evaluate NACL, security group, firewall, host listener, DNS, and application authorization.
9. Repeat steps 2-8 in reverse for the response; do not write “same route back.”
10. Match the prediction to TGW/VPC Flow Logs, firewall logs, route state, and a positive or intentionally denied probe.

Classify the result as allowed and direct, allowed after inspection, denied by no route, denied by blackhole, denied by security control, or misrouted/asymmetric.

Association and propagation by example

Assume attachments prod-a, prod-b, dev-a, shared, inspection, and dxgw.

Propagation is not inherently bidirectional. If production learns shared services but shared services does not have a route back to production, the request may arrive and the response fails. If both propagate broadly into one default table, isolation disappears.

Route evaluation

TGW first selects the most specific destination. For identical CIDRs, current documented priority starts with static routes, then prefix-list referenced routes, followed by propagated route types in their service order. A static route for the same prefix suppresses the propagated route from the active TGW table; removing it can reveal the propagated route again.

Examples:

Prefix-list referenced routes simplify shared destination management but still require change control around the managed prefix list. A prefix-list entry change can alter several route tables without editing each route.

Segmentation patterns

Isolated spokes

Spoke attachments associate with a table containing only shared services, inspection, and approved hybrid routes. Spoke CIDRs propagate to a services/return table but not to peer-spoke source tables. Spokes cannot initiate to each other.

Environment route domains

Production and nonproduction use different associated tables and never receive each other's propagations. Shared services propagate only approved service CIDRs into both. Add blackholes for broad opposite-environment aggregates as defense in depth, while checking more-specific exceptions.

Services-only initiation

Spokes can call shared DNS, patching, repositories, or identity services. If shared services must initiate management connections back, its associated table needs spoke routes and its security policy must allow only management sources/ports. Route symmetry alone does not justify broad administrative access.

Quarantine

Move a compromised attachment to a quarantine-associated table containing only forensic/remediation destinations. This is a high-impact action requiring prebuilt routes, tested automation, identity controls, rollback, and evidence preservation. Disabling or deleting the attachment can destroy useful traffic evidence and recovery access.

Centralized east-west inspection

A common chain is:

spoke A subnet -> TGW
  -> spoke A associated table: destination/default -> inspection attachment
  -> inspection TGW subnet route -> firewall endpoint in same AZ
  -> post-inspection subnet route -> TGW
  -> inspection attachment associated table: destination -> spoke B attachment
  -> spoke B subnet

The return chain must select the same stateful firewall endpoint/AZ. Enable appliance mode on the inspection VPC attachment and deploy healthy endpoints in each enabled AZ. Appliance mode provides flow stickiness when source and destination traffic enters the inspection VPC through the same TGW attachment; it cannot repair a path that enters through an internet gateway and returns through TGW or uses multiple TGWs with independent flow state.

For AWS Network Firewall, use per-AZ TGW attachment subnet route tables that send traffic to that AZ's firewall endpoint, plus firewall-subnet return routes to TGW. For Gateway Load Balancer/self-managed appliances, include GWLB endpoint/appliance routes, source/destination checks where applicable, health and autoscaling, NAT decisions, and MTU.

Prove no direct spoke-to-spoke route is more specific than the inspection route. Test both directions, each AZ, endpoint failure, scaling, and fail-open/fail-closed behavior.

Centralized egress and ingress boundaries

For centralized egress, spoke defaults can target TGW, then an egress/inspection VPC. The TGW table targets that VPC; VPC routing passes through firewall/NAT and internet gateway. Return traffic from NAT follows connection state, but subnet and TGW return routes must still target the originating spoke.

Internet ingress is more complex because internet-gateway edge association, load balancer/NAT behavior, firewall endpoints, and TGW appliance-mode guarantees must align. Do not reuse an east-west diagram as proof for north-south traffic. Document source preservation, NAT, asymmetric possibilities, and whether the flow enters and leaves inspection through the same TGW attachment.

TGW itself does not perform NAT. Overlapping VPCs require renumbering, PrivateLink/service abstraction, or deliberate translation appliances with translated-prefix routing and state ownership.

Hybrid route preference and backup

Direct Connect gateway and Site-to-Site VPN routes can propagate into TGW tables. For equal prefixes, TGW route evaluation prefers attachment types according to documented order; the lower-priority backup might not be displayed while the preferred route exists. That does not prove the backup works.

A hybrid failover plan must show:

• BGP advertisements and withdrawals on both DX and VPN;
• which TGW tables receive each propagation;
• customer-router preference and return routing;
• VPN tunnel/MTU/capacity versus normal DX demand;
• application retry/session behavior; and
• evidence when the DX route is withdrawn and VPN route becomes active.

Avoid a static TGW route that permanently outranks the intended dynamic failover unless its lifecycle is automated and tested.

Peering segmentation

TGW peering does not propagate routes. On each TGW, create explicit static routes for remote prefixes pointing to the peering attachment, in every source-associated table that should reach them. The remote TGW needs return routes to the local prefixes.

Use non-overlapping summaries only when every covered prefix belongs behind that peer; otherwise a broad summary attracts traffic to nowhere or bypasses controls. Peering does not support TGW security-group referencing or ECMP, and inter-Region data-transfer/cost ownership applies. Negative tests must prove that unapproved local route tables lack the peering route.

IPv4, IPv6, and prefix ownership

Keep separate matrices for IPv4 and IPv6. A dual-stack attachment or BGP peer does not create the missing VPC/TGW/security route family automatically. Blackhole and inspection policy must cover both families, or IPv6 can become an uninspected bypass.

Maintain a prefix registry with owner, account, environment, Region, VPC/attachment, routability, propagation targets, overlap status, reservation, and lifecycle. Reject an acquisition CIDR that overlaps an attached VPC before attachment rather than discovering ambiguity during migration.

Read-only evidence collection

Use exact route-table IDs from an approved inventory:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws ec2 describe-transit-gateway-route-tables --output json

TGW_RTB_ID="tgw-rtb-replace-with-approved-id"
aws ec2 get-transit-gateway-route-table-associations \
  --transit-gateway-route-table-id "$TGW_RTB_ID" --output json
aws ec2 get-transit-gateway-route-table-propagations \
  --transit-gateway-route-table-id "$TGW_RTB_ID" --output json
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id "$TGW_RTB_ID" \
  --filters Name=state,Values=active,blackhole --output json

Search exact destination and covering routes; broad results can be truncated. Also inspect VPC subnet route tables, attachment options/AZs, Flow Logs, Network Firewall/GWLB route tables, hybrid BGP telemetry, RAM ownership, and CloudTrail changes. Redact IDs, CIDRs, accounts, security topology, and hybrid details.

Flow Logs as route evidence

TGW Flow Logs expose source/destination attachment, VPC, subnet, ENI, AZ, address, port, protocol, direction, bytes, packets, and TCP flags. Route-specific counters identify:

• packets-lost-no-route: the source-associated TGW table had no usable match;
• packets-lost-blackhole: the selected route deliberately dropped traffic;
• packets-lost-mtu-exceeded: packet exceeded the supported path MTU; and
• packets-lost-ttl-expired: routing loop or excessive hops consumed TTL.

Correlate with VPC Flow Logs and firewall logs. Flow Logs are delayed evidence, can show NODATA or SKIPDATA, and do not prove application response content.

Diagnose from the first failed lookup

Do not add 0.0.0.0/0, propagate every attachment, disable the firewall, or remove blackholes merely to make a test pass. Those actions erase the segmentation objective.

Fifteen-flow segmentation workbook

Use production A/B, development A/B, shared DNS, shared patching, inspection, on-premises, VPN backup, and remote-Region attachments. Evaluate at least these flow classes: prod-to-prod, prod-to-dev, dev-to-prod, prod/dev-to-shared services, shared management initiation, on-premises-to-prod/dev, DX and VPN failure, remote-Region prod, centralized egress, and quarantine.

For each flow record:

Submit the 15 completed rows, route-table association/propagation matrix, exact static/blackhole routes, prefix registry, diagrams, negative tests, and rollback plan. Every denied flow needs evidence of the intended deny rather than absence of a screenshot.

Change safety and rollback

Treat route changes as production software. Use reviewed infrastructure as code, semantic diff, policy checks, reachability tests, maintenance window, canary attachment/flow, telemetry gates, explicit rollback, and independent approval for broad routes. Detect out-of-band changes with CloudTrail/Config/event automation.

Before changing association, capture old/new table IDs and routes. Before propagation, calculate every source domain that will learn the prefix. Before adding a summary, enumerate all addresses it covers. Before blackholing, search for more-specific exceptions. Roll back one controlled change and verify route convergence and application recovery.

Cost and no-change evidence

Segmentation tables do not usually add TGW attachment hours by themselves, but they change traffic paths and therefore data-processing, inspection, NAT, inter-AZ, inter-Region, VPN/DX, and logging charges. A forced inspection path can process the same application flow through TGW and middleboxes multiple times. Model bytes at each billable boundary and the default or custom metering policy owner.

This lesson creates nothing. Prove identical before/after attachment, association, propagation, route, Flow Log, and firewall inventories. Never delete shared routes during cleanup; only an approved build process may reverse changes it created.

Knowledge check

1. Which table evaluates traffic from an attachment?

The single TGW route table associated with that source attachment.

1. Does propagating A into B's table also give A a route to B?

No. A's associated table independently needs a destination route.

1. Which wins: /8 blackhole or /16 active route?

The more-specific /16 for matching addresses.

1. Why can centralized inspection fail only in one direction?

Return traffic can choose another AZ/endpoint or bypass route; appliance mode and full per-AZ routing must preserve symmetry.

1. Do TGW peer routes propagate?

No; both sides need explicit static routes.

1. What directly proves a route blackhole drop?

The selected blackhole route plus TGW Flow Log packets-lost-blackhole evidence.

Lesson acceptance

The lesson is complete only when the learner can:

• execute the ten-step route-proof algorithm in both directions;
• calculate association, propagation, longest-prefix, route-type priority, static, prefix-list and blackhole behavior;
• design production/nonproduction/shared/hybrid/quarantine route domains;
• prove centralized inspection symmetry and absence of bypass paths;
• model DX/VPN failover, peering, overlap, IPv4 and IPv6 correctly;
• diagnose no-route, blackhole, MTU, TTL, asymmetric and route-leak failures from evidence;
• complete all 15 flow rows, including denied and degraded paths;
• produce change, rollback, monitoring, cost, RACI and decommission evidence; and
• attest that no route, propagation, association, attachment, firewall, or production resource changed.

Official sources

• How Transit Gateway works and route evaluation
• Transit Gateway route tables
• VPC attachments and route requirements
• Transit Gateway Flow Logs
• Avoiding asymmetric routing with AWS Network Firewall
• Centralized network security architecture
• Transit Gateway pricing