1. Find the table making the decision
A packet enters Transit Gateway through an attachment. That attachment’s association determines the lookup table. Propagation publishes prefixes into tables; it does not choose the ingress lookup table. In the exercise, Apps is associated with RT-Apps and Shared with RT-Shared. A correct route in RT-Shared does not by itself fix lookup for traffic entering through Apps. Record source, destination, ingress attachment and consulted table at each step. This simple record prevents diagnosing whichever table has the most intuitive name instead of the table actually making the decision.
2. Resolve prefixes and blackholes
Start with routes matching the destination address and select the most specific prefix. For 10.84.7.40, /24 outranks /16. If the selected /24 is a blackhole, the packet is dropped; there is no automatic fallback to the usable /16. For identical destinations, this exercise compares only static and propagated routes, preferring static as described in TGW documentation. Do not generalize this small model to all BGP or ECMP selection. The table below drops 10.84.7.40 and selects VPN for 10.84.8.40. Explain the result before checking the solution.
3. Treat return traffic as another lookup
An Apps application sends a SYN that reaches Shared. The reply leaves Shared and enters TGW through the Shared attachment, whose table needs a route to Apps. Do not repeat Apps-table validation and declare the problem solved. Alongside TGW tables, subnets need suitable routes and path controls remain relevant. In this bounded case, the return route is the only identified failure; outside it, no response does not automatically prove asymmetric routing. Define the observation distinguishing a missing route, security filtering, a process without a listener and a functional error.
4. Detect bypassed inspection
In the workshop table, 0.0.0.0/0 points to Inspection, but 10.96.0.0/16 points directly to Payments. A packet for 10.96.2.8 follows /16. Appliance mode on the inspection VPC attachment supports AZ affinity for supported paths; it does not force a packet selecting another route to visit the appliance. If policy requires inspection, the direct path prevents acceptance even when the application responds. Analyze both directions, inspection VPC configuration and appliance failure. Changing the mode on existing attachments may affect ongoing flows and needs planning.
5. Exercise positive and negative segmentation
The intent Apps→Shared allowed and Apps→Restricted forbidden needs evidence for both outcomes. A separate table can contain overly broad propagation or a static route creating unexpected access. A /0 blackhole also does not prevent selection of a more specific permitted /24. Inspect associations and effective routes, then exercise permitted and prohibited flows in relevant directions. A local lookup result is a forwarding decision, not user authentication or proof of every control. Preserve that distinction in security reporting and project acceptance.
6. From tabletop solution to authorized change
Finish the workshop with three deliverables: the table used in each direction, the selected route for each destination and additional evidence required before change. Retain previous configuration and bound the change to the approved service. The local model uses IPv4, prefix matching and static/propagated preference; it does not simulate BGP, health checks, convergence, firewalls or actual packets. A correct result supports discussion of the hypothesis but guarantees neither production service nor recovery time. At handover, assign owners for routes, monitoring, return-path checks and rollback conditions so RUN can repeat diagnosis.
RT-Apps
10.84.0.0/16 propagated VPN
10.84.7.0/24 static BLACKHOLE
lookup 10.84.7.40 -> DROP
lookup 10.84.8.40 -> VPN
0.0.0.0/0 static Inspection
10.96.0.0/16 static Payments
lookup 10.96.2.8 -> Payments [inspection bypass]RT-Apps selects the /24 blackhole for 10.84.7.40; a correct RT-Shared route does not change that lookup.
Common pitfalls
Propagation as association; fallback after blackhole; forward-only validation; appliance mode as mandatory detour; model as actual test.
Related topics: Hybrid DNS · Inspection and auditing
Follow the ingress table, select the most specific prefix and repeat analysis for return traffic.
Reference: How Transit Gateway works · ANS-C01