Skip to content
AWS NFW Walkthrough

Architecture

Overview

Section titled “Overview”

Hub accounts own a Transit Gateway
AWS Transit Gateway. Regional hub that attaches VPCs and can peer to Transit Gateways in other Regions.
Transit Gateway docs and inspection VPC
Hub VPC that holds the Network Firewall endpoint and Transit Gateway attachment used to hairpin spoke traffic for inspection. per Region. Dev and prod workload accounts attach spokes via RAM
AWS Resource Access Manager. Shares the regional Transit Gateway so workload accounts can attach spokes.
RAM docs. Hubs peer with TGW. Network Firewall
AWS Network Firewall. Managed Suricata-based packet inspection service, typically placed in an inspection VPC.
Network Firewall docs is attached after the mesh works. Cross-Region inspection 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 shape in both Regions. The firewall is attached last, so this topology works as TGW-only first. Icons from aws-icons.
Dual-hub topology across Sydney and Auckland Two Regions side by side. Each Region holds a hub account with a Transit Gateway and an inspection VPC containing Network Firewall and its firewall endpoint. Below the hub, a dev workload account and a prod workload account each own a spoke VPC with a demo host, attached to the hub Transit Gateway through a RAM share. The two hub Transit Gateways are joined by Transit Gateway peering, with ASN 65001 in Sydney and 65002 in Auckland. ap-southeast-2 · Sydney ASN 65001 syd-hub account Transit Gateway spoke + peer RTs inspection VPC · 10.255.0.0/24 Network Firewall policy + rule groups Firewall endpoint per AZ, in its subnet RAM share → dev + prod syd-dev account dev spoke demo host 10.255.1.0/24 syd-prod account prod spoke demo host 10.255.2.0/24 ap-southeast-6 · Auckland ASN 65002 akl-hub account Transit Gateway spoke + peer RTs inspection VPC · 10.254.0.0/24 Network Firewall policy + rule groups Firewall endpoint per AZ, in its subnet RAM share → dev + prod akl-dev account dev spoke demo host 10.254.1.0/24 akl-prod account prod spoke demo host 10.254.2.0/24 TGW peering 65001 ↔ 65002 hub-peering stack

Build order

Section titled “Build order”
Hub peering is applied once for dev, then re-applied after the prod spokes exist. Icons from aws-icons.
Build order and the two staged Network Firewall flags Eight stages left to right: hubs, dev workloads, prod workloads, hub peering, prove mesh, Network Firewall deny, Network Firewall allow, validate. Underneath, three phases show the hub flags. Mesh covers the first five stages with enable_network_firewall false and firewall_rules_enabled false. Deny covers the sixth stage with enable_network_firewall true and firewall_rules_enabled false. Allow covers the last two stages with both flags true. Build order mesh first, firewall last 1 2 3 4 5 6 7 8 Hubs TGW + insp VPC Workloads dev spoke + host Workloads prod spoke + host Hub peering re-apply after prod Prove mesh ping · curl · dig NFW deny default drop NFW allow PASS rule groups Validate alert + flow logs Mesh — TGW only enable_network_firewall = false firewall_rules_enabled = false Deny nfw = true rules = false Allow nfw = true rules = true

CIDRs and ASNs

Section titled “CIDRs and ASNs”
Item Value
Sydney inspection 10.255.0.0/24
Sydney dev / prod 10.255.1.0/24 / 10.255.2.0/24
Auckland inspection 10.254.0.0/24
Auckland dev / prod 10.254.1.0/24 / 10.254.2.0/24
Sydney / Auckland ASN 65001 / 65002

Stacks

Section titled “Stacks”
Stack Creates
*/hub TGW, inspection VPC, inspection / no-inspection RTs, RAM to dev + prod, optional NFW
*/workload-dev Dev spoke + demo host
*/workload-prod Prod spoke + demo host
hub-peering TGW peer, remote spoke routes, private zone lab.demo, DHCP search domain

Staged NFW

Section titled “Staged NFW”

Hub flags (persist in each hub terraform.tfvars), as phased in Build order above:

Stage enable_network_firewall firewall_rules_enabled
Mesh false false
Deny true false
Allow true true

When NFW is off, spoke and peer associations use no_inspection. When NFW is on, spokes and the peer move to inspection — see Inspection model.

Inspection today

Section titled “Inspection today”
Flow Where it is inspected (NFW on)
Same-Region (e.g. Syd-dev ↔ Syd-prod, different accounts) Local hub NFW once, both directions through the same firewall
Cross-Region Both hub NFWs (source and destination)

Details: Inspection model. Hop-by-hop: Traffic path.

Out of scope

Section titled “Out of scope”
  • Firewall Manager central policy
  • Cloud WAN
  • Multi-AZ / production hardening