Overview
Runbook for AWS Network Firewall designs, especially centralized inspection with Transit Gateway and VPC route tables. See also VPC Lattice for service-to-service connectivity.
Quick checklist
- Confirm firewall endpoints exist in every inspected AZ.
- Check route tables: traffic must route through the correct firewall endpoint or TGW attachment.
- Enable flow and alert logs before incident testing.
- Validate stateless default actions and stateful rule-group order.
References
Transit Gateway and Network Firewall
Original references (from Notion)
Original links preserved from your Notion page. All diagrams below use public AWS-hosted URLs (AWS blogs + AWS documentation) so they render without authentication.
Centralized traffic filtering
Deploy centralized traffic filtering using AWS Network Firewall | Amazon Web Services
Deployment models
Deployment models for AWS Network Firewall | Amazon Web Services
Transit Gateway getting started
Tutorials: Get started with AWS Transit Gateway - Amazon VPC
Egress VPC with TGW + CDK
Building an egress VPC with AWS Transit Gateway and the AWS CDK | Amazon Web Services
Outbound inspection (NAT + IGW)
Outbound traffic inspection through a NAT gateway and internet gateway - AWS Prescriptive Guidance
Additional diagrams
Security groups
Control traffic to your AWS resources using security groups - Amazon Virtual Private Cloud
Transit Gateway routing (from Notion)
How AWS Transit Gateway works - Amazon VPC
Transit gateway route tables in AWS Transit Gateway - Amazon VPC
Operational checklist (from Network Firewall parent)
From Network Firewall parent page:
- Verify route tables: subnet → TGW attachment routes
- Verify Network Firewall endpoints are in the correct AZ/subnets
- Verify security groups + NACLs for inspection subnets
- Log destinations: CloudWatch Logs / S3 (enable before incidents)
- Stateless vs stateful rule groups: order + default action
- Test reachability with Reachability Analyzer when possible
Architecture mental model
flowchart TB
subgraph Spokes["Spoke VPCs (workloads)"]
S1[Spoke VPC A]
S2[Spoke VPC B]
end
subgraph Hub["Hub / Inspection VPC"]
TGW_ATT[TGW VPC Attachment]
NFW[AWS Network Firewall endpoints]
NAT[NAT Gateway]
IGW[Internet Gateway]
end
TGW[AWS Transit Gateway]
S1 --> TGW
S2 --> TGW
TGW --> TGW_ATT
TGW_ATT --> NFW
NFW --> NAT
NAT --> IGW
IGW --> Internet((Internet))
S1 -. east-west .-> S2
| Layer | Controls |
|---|---|
| VPC route table | Sends traffic toward TGW (spokes) or toward firewall subnets (hub) |
| TGW route table | Decides which attachment receives traffic (segmentation, egress steering) |
| Network Firewall policy | Allow/deny at L3–L7 (stateless + stateful rule groups) |
| Security groups / NACLs | Endpoint ENI reachability; stateless NACLs can break return traffic |
Golden rules
- Symmetric routing — return path must mirror forward path (especially through firewall + NAT).
- One inspection path per flow — avoid hairpinning or double-NAT unless designed.
- AZ affinity — firewall endpoints and NAT in the same AZ as the traffic source when possible.
- TGW route table = segmentation — separate RTs to block spoke-to-spoke while allowing shared egress.
Deployment patterns
Pattern 1 — Centralized inspection VPC (hub)
All internet-bound and (optionally) east-west traffic is steered to a dedicated inspection VPC with Network Firewall endpoints, then to NAT/IGW.
| Use when | Pros | Cons |
|---|---|---|
| Multi-account / multi-VPC hub-and-spoke | Single policy enforcement point, easier auditing | Inspection VPC is a blast-radius / capacity choke point |
| Regulated egress | Consistent logging and filtering | Cross-AZ charges if not designed carefully |
Reference: Deploy centralized traffic filtering using AWS Network Firewall
Pattern 2 — Distributed (per-VPC) firewall
Network Firewall deployed in each VPC; TGW used only for connectivity.
| Use when | Pros | Cons |
|---|---|---|
| Strong isolation between tenants | No shared inspection choke point | Policy drift across VPCs |
| Lower cross-VPC traffic through hub | Simpler per-VPC routing | Higher operational overhead |
Reference: Deployment models for AWS Network Firewall
Pattern 3 — Egress VPC (TGW + NAT, firewall inline)
Spokes send 0.0.0.0/0 (and RFC1918 if needed) to TGW → hub inspection VPC → NAT → IGW.
| Component | Role |
|---|---|
| Spoke RT | 0.0.0.0/0 → TGW |
| TGW RT (spoke) | Default or hub CIDR → inspection VPC attachment |
| Inspection VPC RT | Firewall subnet → NAT → IGW |
| Hub TGW RT | Routes back to spoke CIDRs |
Reference: Building an egress VPC with AWS Transit Gateway and the AWS CDK
Pattern 4 — East-west inspection between spokes
Spoke A → TGW → inspection VPC (Network Firewall) → TGW → Spoke B.
Requires explicit TGW routes (no silent propagation) and SG rules allowing peer CIDRs after firewall policy permits.
TGW routing deep dive
How TGW decides where to send packets
- Packet arrives at a TGW attachment (VPC, VPN, Direct Connect, peering).
- TGW uses the route table associated with that attachment (association).
- Longest-prefix match selects the target attachment.
- Optional route propagation auto-adds routes (often disabled in production for control).
Docs
- How Transit Gateway works
- Transit gateway route tables
- Enable/disable route propagation
- Blackhole routes
Segmentation example (spokes isolated, shared egress)
| Route table | Associated with | Routes |
|---|---|---|
tgw-rt-spoke-a | Spoke A attachment | 10.0.0.0/16 → hub, 0.0.0.0/0 → hub, no route to Spoke B |
tgw-rt-spoke-b | Spoke B attachment | 10.0.0.0/16 → hub, 0.0.0.0/0 → hub, no route to Spoke A |
tgw-rt-hub | Hub / inspection attachment | 10.1.0.0/16 → A, 10.2.0.0/16 → B |
Mental model: TGW route table = who can talk to whom; VPC route table = how to reach TGW.
Network Firewall essentials
Components
| Component | Purpose |
|---|---|
| Firewall policy | Ordered rule groups + default actions |
| Stateful rule group | Connection-aware allow/deny (Suricata-compatible) |
| Stateless rule group | 5-tuple matching; runs first |
| Firewall | Binds policy to VPC |
| Firewall endpoints | AZ-local ENIs in dedicated subnets |
Docs
Routing in the inspection VPC (typical)
Spoke → TGW → Inspection VPC subnet
→ Route: 0.0.0.0/0 or peer CIDR → Firewall endpoint
→ Firewall endpoint subnet RT → NAT (egress) or back to TGW (east-west)Rule evaluation order (simplified)
- Stateless rules (custom + AWS managed)
- Stateful rules
- Default action in policy (drop or forward)
Enable alert and flow logs to S3 or CloudWatch before go-live.
Hub-and-spoke egress (related concept)
From your Hub-and-spoke network notes — applies directly when adding a firewall:
Part 1 — All VPCs communicate; internet only via hub
| Goal | Route pattern |
|---|---|
| Spoke ↔ Spoke | Spoke RT: peer CIDR → TGW; TGW RT: both spokes in same or hub RT |
| Spoke → Internet | Spoke RT: 0.0.0.0/0 → TGW; Hub: NAT + IGW |
| Hub → Internet | Private RT: 0.0.0.0/0 → NAT; Public RT: 0.0.0.0/0 → IGW |
With firewall: insert Network Firewall between TGW attachment subnets and NAT for egress; update RTs so traffic hits firewall endpoints first.
Part 2 — Spokes isolated (no b ↔ c), shared egress
- Separate TGW route tables per spoke (
tgw-rt-b,tgw-rt-c) - Hub RT has routes to both; spoke RTs have no cross-spoke routes
- Disable automatic propagation if it re-opens east-west paths
Troubleshooting playbook
Symptom: No connectivity spoke → internet
| # | Check |
|---|---|
| 1 | Spoke VPC RT: 0.0.0.0/0 → TGW |
| 2 | TGW RT: route to inspection/hub attachment |
| 3 | Inspection VPC RT: traffic routed to firewall endpoint subnets |
| 4 | Firewall policy: default action not dropping unexpectedly |
| 5 | Post-firewall RT: 0.0.0.0/0 → NAT |
| 6 | NAT in public subnet, EIP attached |
| 7 | Public RT: 0.0.0.0/0 → IGW |
| 8 | SG on firewall endpoint ENIs: allow required ports |
| 9 | NACLs: not blocking ephemeral return ports |
Symptom: Spoke ↔ spoke works when it should not
| # | Check |
|---|---|
| 1 | Separate TGW route tables — no route between spoke CIDRs |
| 2 | Route propagation disabled or scoped |
| 3 | Correct association: each attachment → intended RT only |
Symptom: Intermittent / one-AZ failures
| # | Check |
|---|---|
| 1 | Firewall endpoint per AZ used by workloads |
| 2 | NAT Gateway AZ matches active traffic path |
| 3 | TGW attachment subnets span required AZs |
Tools
- VPC Reachability Analyzer
- VPC Flow Logs
- Network Firewall logging
- TGW Route analyzer (console) for effective routes
Additional reference links
AWS Transit Gateway
| Topic | Link |
|---|---|
| What is a transit gateway? | https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html |
| TGW attachments | https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html |
| Appliance mode | https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-appliance-scenario.html |
| Inter-Region peering | https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html |
| Quotas | https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html |
AWS Network Firewall
Prescriptive & architecture guidance
| Topic | Link |
|---|---|
| Inline traffic inspection (third-party appliances) | https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html |
| Centralized egress with TGW | https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-the-internet.html |
| AWS Security Reference Architecture | https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html |
| Well-Architected — Security pillar | https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html |
Blogs (same series as Notion)
Public architecture diagrams (AWS blogs & documentation)
Related (WAF — application layer, from parent page)
AWS WAF for Application Load Balancers
Note: AWS WAF protects HTTP/S at ALB/API Gateway/CloudFront. Network Firewall operates at VPC perimeter (L3–L7). Use both in layered defense.
Quick comparison: Network Firewall vs WAF vs SG
| Control | Layer | Scope |
|---|---|---|
| Security Group | Instance ENI | Allow/deny per ENI |
| Network ACL | Subnet | Stateless subnet boundary |
| Network Firewall | VPC / TGW hub | Centralized IDS/IPS-style filtering |
| AWS WAF | ALB / CloudFront / API GW | HTTP/S application attacks |
VPC Lattice
Notes for Amazon VPC Lattice service-to-service connectivity, authorization, and observability across VPCs and accounts.
Key concepts
- A service network is the logical boundary for services and resource configurations.
- Clients reach the network through VPC association or a service-network VPC endpoint.
- Use auth policies and observability deliberately; connectivity is not authorization.
When to consider
- Microservices that span VPCs/accounts and need simpler application networking.
- Modernization paths where service discovery, connectivity, and monitoring should be centralized.