Skip to content

PATTERN Cited by 1 source

Pre-inspection / post-inspection route tables (TGW)

Pre-inspection / post-inspection route tables is the routing pattern that implements centralised network inspection on top of AWS Transit Gateway using two separate TGW route tables with opposite roles:

  • Pre-inspection RT — all VPC and Direct Connect Gateway attachments are associated here. Its default route (0.0.0.0/0) points at the firewall's TGW attachment, forcing every packet into the inspection engine.
  • Post-inspection RT — only the firewall's TGW attachment is associated. It holds per-destination static routes back to each VPC / on-prem CIDR, so that packets inspected-and- permitted by the firewall are released to their original destination.

The result: every cross-VPC, VPC-to-on-prem, and VPC-to-internet packet makes two TGW hops — in to the firewall, back out to its destination — and the inspection is structurally unavoidable.

Why two route tables

A single TGW route table doesn't work because TGW routes are per-RT, and you need opposite routing logic for "traffic entering the hub" vs "traffic leaving the firewall":

  • Entering attachments need: "anything anywhere → firewall".
  • Leaving the firewall needs: "known CIDR X → attachment X".

Putting both on one RT either loops traffic back to the firewall after it's already inspected, or fails to catch it on the way in. Two RTs with distinct associations cleanly separate the two phases.

Canonical shape (2025-11-26 post)

 ┌──────────────────────────────────────────────┐
 │ Transit Gateway                              │
 │                                              │
 │   Pre-inspection RT (associated with all     │
 │   VPC + DXGW attachments)                    │
 │     0.0.0.0/0  →  Firewall attachment        │
 │                                              │
 │   Post-inspection RT (associated ONLY with   │
 │   the firewall attachment)                   │
 │     10.0.0.0/16    →  EVS VPC attach         │
 │     172.21.0.0/16  →  Workload VPC attach    │
 │     172.23.0.0/16  →  Egress VPC attach      │
 │     172.24.0.0/16  →  Ingress VPC attach     │
 │     10.0.0.0/8     →  DXGW attach (on-prem)  │
 │                                              │
 │   Firewall attachment (Appliance Mode ON,    │
 │   resource-type Network Function)            │
 └──────────────────────────────────────────────┘

Setup sequence:

  1. Create the TGW with Default route table association and Default route table propagation explicitly deselected — this prevents a silent misconfiguration where new attachments get auto-associated to a default RT and skip inspection.
  2. Create the two empty RTs explicitly and associate them with the TGW.
  3. Attach all VPCs + the DXGW. Associate all of them with the pre-inspection RT.
  4. Create the AWS Network Firewall using the native TGW attachment option — this auto-provisions the inspection VPC subnets / route tables / firewall endpoints, creates the TGW attachment of resource-type Network Function, and enables Appliance Mode automatically.
  5. Associate the firewall attachment with the post-inspection RT.
  6. Populate the pre-inspection RT with a default route to the firewall attachment.
  7. Populate the post-inspection RT with per-destination static routes back to each VPC / DXGW attachment.

VPC-side route tables also need updates: each VPC needs a default route 0.0.0.0/0 → TGW on its private subnets (so egress hits the firewall); Ingress / Egress VPCs need specific RFC-1918 routes back to TGW so inbound return traffic also transits the firewall.

Why this specific split is the idiom

  • New-VPC inspection is automatic. Attach any new VPC to the TGW and associate it with the pre-inspection RT (the only "entry point" RT available) — the default route immediately sends its traffic through the firewall. No firewall-side config change required for new spokes.
  • Post-inspection RT is never associated with a source attachment. This is structural: a source attachment on the post-inspection RT would bypass the firewall because that RT's routes point straight at destination VPCs. The single- association-only rule makes misconfiguration harder.
  • Emergency bypass is one route edit. If the firewall is misbehaving and blocking production, swapping the pre-inspection RT's default route from firewall → a specific destination VPC lifts the inspection for the blast duration without tearing down any attachments.
  • Appliance Mode on the firewall attachment is mandatory. Without it, two directions of the same flow may hit different- AZ firewall endpoints and lose stateful session state. The native-TGW-attachment path enables this automatically.

Caveats

  • Asymmetric-routing risk if an operator forgets to put the return-path RFC-1918 routes on the Ingress / Egress VPC RTs — one-way inspection passes traffic out through the firewall but bypasses it on the way back, breaking stateful rules. The 2025-11-26 post's Table 1 explicitly colour-codes these return routes (green) to flag them.
  • Intra-VPC east-west is not inspected by this pattern. Only traffic that leaves the VPC (hits TGW) is inspected. Intra-VPC inspection requires a different mechanism (e.g. a per-VPC Network Firewall endpoint or VPC-native security groups).
  • Overlay routes need help. If spokes include overlay networks (e.g. EVS's NSX, third-party SD-WAN), the spoke VPC's RT has to know routes to the overlay CIDR first — see VPC Route Server. Otherwise the packet doesn't make it out of the source VPC to TGW and this pattern never engages.
  • Hub failure-blast-radius. A bad RT edit takes every inspected flow down at once; stage changes carefully.
  • Operational-visibility gap pre-native-attachment. The inspection VPC that the native attachment creates is AWS-managed; you don't see its subnet / endpoint layout the way you would with a hand-built inspection VPC. Trade visibility for reduced setup toil.

Seen in

Last updated · 200 distilled / 1,178 read