Skip to content
AWS NFW Walkthrough

Traffic path

Mesh first (NFW off)

Section titled “Mesh first (NFW off)”

Spokes and peer associate to no_inspection. Traffic is TGW-only — no hairpin through the inspection VPC.

After Allow (NFW on)

Section titled “After Allow (NFW on)”

Host syd-dev.lab.demo calls http://akl-dev.lab.demo/.

Cross-Region east-west is double-inspected: Syd NFW then Akl NFW (and the reverse on return). Icons from aws-icons.
Traffic path after Allow: double-inspect on both hubs The Sydney column reads downward: the demo host sends to its spoke VPC route table, which sends the Auckland dev CIDR to the Transit Gateway attachment. On the Transit Gateway the spoke association is the inspection route table; egress follows 0.0.0.0/0 through the Sydney firewall endpoint, then leaves via TGW peering. Traffic crosses peering at the bottom, then the Auckland column reads upward: the peer association is the inspection route table, the Auckland firewall endpoint inspects again, the no-inspection route table sends the local spoke CIDR to the spoke attachment, and the spoke route table delivers to the Auckland demo host. ap-southeast-2 · Sydney syd-dev demo host curl http://akl-dev.lab.demo/ 10.255.1.10 spoke VPC route table 10.254.1.0/24 → TGW attachment spoke RT syd Transit Gateway inspection RT: 0.0.0.0/0 → NFW endpoint inspection syd firewall endpoint first hop (also same-Region hairpin) insp VPC ap-southeast-6 · Auckland akl-dev demo host replies from :80 10.254.1.10 spoke VPC route table return 10.255.1.0/24 → TGW spoke RT no-inspection RT 10.254.1.0/24 → spoke attachment post-NFW akl firewall endpoint second hop for this flow insp VPC akl Transit Gateway peer association = inspection RT inspection TGW peering double-inspect: both hubs

Sydney’s firewall is on this path: egress follows 0.0.0.0/0 on the inspection RT into the local endpoint, then leaves via the peer. Auckland inspects on arrival. Return traffic mirrors the same pattern. That is double-inspect
What this lab ships. Peer on inspection route tables; both hubs inspect every cross-Region hop. Same-Region traffic hairpins through one local NFW..

Same-Region dev ↔ prod (e.g. 10.255.1.0/24 ↔ 10.255.2.0/24) hairpins through that Region’s NFW only — one firewall sees both directions. See Inspection model.

What Allow passes

Section titled “What Allow passes”

Deny keeps stateful default drop (no PASS groups). Allow attaches Suricata groups from modules/network-firewall/rules.tf (IP sets of /32s — not whole spoke /24s):

Group Intent
peer_dev Dev Syd ↔ Akl: ICMP; TCP 80/53; UDP 53
peer_dev_ssh Dummy jumps .180–.199: TCP 22
same_region_demo Dev ↔ prod same Region: ICMP; TCP 80
svc_prod_http Prod app sets: TCP 80/443 both ways
svc_prod_db Prod app → same-Region DB :5432
svc_prod_dns Prod clients → DNS /32s :53
svc_prod_metrics Prod monitors → apps :9100
svc_prod_ldap / ntp / dummy_batch Dummy targets / CIDRs (demo hosts outside those sets still drop)

Demo host IPs fall inside those lab IP sets so peer-dev, same-region-demo, and prod-http succeed after Allow. Unmatched traffic still drops (dummy CIDRs/ports, prod ICMP across Regions, and so on) — same contrast as Allow.

DNS

Section titled “DNS”

hub-peering creates private zone lab.demo (owned in Syd-dev) and associates it to spoke VPCs. Prod names require enable_prod_workloads=true.

Name Points at
syd-dev.lab.demo Sydney dev host
akl-dev.lab.demo Auckland dev host
syd-prod.lab.demo Sydney prod host
akl-prod.lab.demo Auckland prod host

DHCP option sets add search domain lab.demo on the spokes.

Logs

Section titled “Logs”

Each hub exports Network Firewall
AWS Network Firewall. Managed Suricata-based packet inspection service, typically placed in an inspection VPC.
Network Firewall docs CloudWatch groups via Terraform: flow_log_group_name and alert_log_group_name (e.g. /aws/network-firewall/nfw-lab-syd/flow). Prefer flow after Allow; alert shows blocked / drop in Deny. Cross-Region success means entries in both hubs’ flow groups.