← AWS Advanced Networking: networks and production
10 / 10 · 60 MIN

Transit Gateway, return-path and inspection workshop

Resolve fictional tables and explain association, prefix, blackhole and affinity effects.

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]
IN PRACTICE

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

Take this idea with you

Follow the ingress table, select the most specific prefix and repeat analysis for return traffic.

Create account

Reference: How Transit Gateway works · ANS-C01

AWS is a trademark of Amazon.com, Inc. or its affiliates. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by AWS. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.