Skip to content
AWS NFW Walkthrough

Inspection model

Overview

Section titled “Overview”

This lab ships double-inspect for cross-Region east-west traffic.

Flow Inspected by Sees both directions?
Same Region, spoke ↔ spoke (dev ↔ prod, different accounts) Local hub NFW Yes — one firewall, full state
Cross Region Both hub NFWs (source and destination) Each hub sees the hop through that Region

Before NFW exists, spokes and the peer associate to no_inspection and nothing is inspected — that is the plain TGW mesh stage.

Same Region

Section titled “Same Region”
Bidirectional arrows on purpose: one firewall evaluates both halves of the session, so state is complete. Icons from aws-icons.
Same Region — one local firewall sees both directions Inside ap-southeast-2, the dev spoke sends to the Transit Gateway, whose spoke association is the inspection route table, so traffic hairpins to the Sydney Network Firewall. After inspection the no_inspection route table forwards to the prod spoke. Every arrow is bidirectional because the reverse direction takes the identical path, so one firewall evaluates both halves of the session and keeps full state. The dev and prod spokes live in different accounts. ap-southeast-2 · Sydney dev and prod are separate accounts syd-dev spoke 10.255.1.0/24 syd TGW spoke on inspection RT syd NFW both directions, full state no_inspection → destination spoke syd-prod spoke 10.255.2.0/24 Every hop is bidirectional: the return direction takes the identical path, so a single firewall evaluates the whole session.

Cross-account inside a Region is the common case for dev ↔ prod here, and it keeps full stateful inspection because one firewall handles both directions.

Cross Region

Section titled “Cross Region”
Two highlighted firewalls per lane, in both directions — that is what double-inspect means here. Icons from aws-icons.
Cross Region — both hubs inspect, in each direction Two lanes of chips over Region bands. The upper lane runs left to right for syd-dev to akl-dev: the Sydney spoke, the Sydney Transit Gateway on its inspection route table, the Sydney Network Firewall, TGW peering, the Auckland Transit Gateway on its inspection route table, the Auckland Network Firewall, then the Auckland spoke reached via no_inspection. The lower lane runs right to left for akl-dev to syd-dev through the mirror of the same chips. Both firewall chips are highlighted in each lane, so each direction crosses two firewalls. ap-southeast-2 · Sydney ap-southeast-6 · Auckland syd-dev → akl-dev syd-dev spoke syd TGW inspection RT syd NFW inspect peer TGW peering akl TGW inspection RT akl NFW inspect akl-dev no_inspection akl-dev → syd-dev syd-dev no_inspection syd NFW inspect syd TGW inspection RT peer TGW peering akl NFW inspect akl TGW inspection RT akl-dev spoke Egress follows 0.0.0.0/0 through the local firewall before the peer — that is double-inspect. So a successful cross-Region probe leaves alert and flow log entries on both hubs.

Once NFW is on in both hubs, hub-peering associates the peering attachment to each hub’s inspection RT. Egress follows 0.0.0.0/0 through the local firewall before crossing the peer. Same-Region destinations still hairpin locally the same way.

Expect flow logs on both hubs for a successful cross-Region probe.

Policy settings that still matter

Section titled “Policy settings that still matter”
Setting Why
stream_exception_policy = "CONTINUE" Keeps evaluating midstream / return packets instead of treating them as broken streams
PASS rules written both ways (plus reverse ports, flow:stateless) Each hub can match the direction it sees on a double-inspect hop

See Traffic path for the hop-by-hop route table decisions, and NFW → Validate to prove it in Network Firewall
AWS Network Firewall. Managed Suricata-based packet inspection service, typically placed in an inspection VPC.
Network Firewall docs flow logs.