Skip to content
AWS NFW Walkthrough

AWS NFW Walkthrough

Build the Sydney–Auckland TGW mesh first, prove connectivity, then attach Network Firewall (deny → allow) with cross-Region traffic double-inspected on both hubs.
Get StartedView on GitHub

Why this lab

Section titled “Why this lab”

Dual-hub designs put a Transit Gateway
AWS Transit Gateway. Regional hub that attaches VPCs and can peer to Transit Gateways in other Regions.
Transit Gateway docs and Network Firewall
AWS Network Firewall. Managed Suricata-based packet inspection service, typically placed in an inspection VPC.
Network Firewall docs in each Region. This walkthrough drives the disposable Terraform lab jajera/aws-nfw-lab.

Focus What you prove
Cross-Region 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. — both hubs see the flow
Same-Region One local NFW hairpin (e.g. Syd-dev ↔ Syd-prod)
Mesh first TGW + spokes + peering, prove before NFW
Then NFW Attach deny → allow; read flow logs to prove where

What you build:

  • Greenfield inspection + spoke VPCs (dev and prod) in Sydney and Auckland
  • Demo hosts with HTTP and DNS; private zone lab.demo
  • Hub-to-hub TGW peering; workloads attach only via RAM to their regional hub
Where traffic gets inspected is the whole point of the lab — the band at the bottom is what the walkthrough proves. Icons from aws-icons.
Dual-hub lab topology, and where traffic gets inspected Two Regions side by side. Each holds a hub account with a Transit Gateway and an inspection VPC containing Network Firewall, RAM-shared to a dev spoke and a prod spoke with their CIDRs. The hubs are joined by Transit Gateway peering between ASN 65001 and 65002. A band along the bottom states the two inspection rules this lab ships: a cross-Region flow goes spoke, source firewall, peer, destination firewall, spoke, so it is inspected in both hubs; a same-Region flow between dev and prod stays local and is inspected once, in both directions, by the same firewall. ap-southeast-2 · Sydney ASN 65001 syd-hub TGW peer + spoke RTs inspection VPC · 10.255.0.0/24 Network Firewall attached last: deny → allow RAM syd-dev 10.255.1.0/24 syd-prod 10.255.2.0/24 own accounts spoke + demo host ap-southeast-6 · Auckland ASN 65002 akl-hub TGW peer + spoke RTs inspection VPC · 10.254.0.0/24 Network Firewall attached last: deny → allow RAM akl-dev 10.254.1.0/24 akl-prod 10.254.2.0/24 own accounts spoke + demo host TGW peering 65001 ↔ 65002 Cross-Region spoke → source NFW → peer → destination NFW → spoke inspected in both hubs Same Region dev spoke → local NFW → prod spoke one firewall, both directions

What you will do

Section titled “What you will do”

Hubs

Sydney → Auckland → Validate, then the same for Workloads.

Workloads

Attach each spoke and demo host; validate both before peering.

Peer and prove

Hub peering, lab.demo DNS, then ping / curl / dig across Regions.

Prove where

Read flow logs to confirm cross-Region traffic hits both hubs.

Expectation Notes
Own VPCs Lab creates all four VPCs; nothing reused from the account
Cross-Region path TGW peering; workloads never attach to the remote hub
Cost while running TGW attachments + NFW endpoints + NAT (spokes) bill hourly

Read in this order

Section titled “Read in this order”
  1. Architecture
  2. Inspection model
  3. Traffic path
  4. Demo roles
  5. Deploy and operate

References

Section titled “References”