AWS Networking & CDN
Network Firewall
Managed stateful network firewall for VPC traffic filtering and inspection
AWS Network Firewall is a managed, stateful network firewall and intrusion prevention service that provides fine-grained control over network traffic entering and leaving your VPCs. It supports stateless packet filtering, stateful traffic inspection, and Suricata-compatible IDS/IPS rules, making it the primary choice for deep packet inspection within AWS-native architectures.
Network Firewall Architecture and Deployment
Network Firewall deploys firewall endpoints within your VPC. Traffic must be explicitly routed through these endpoints using route table manipulation. It integrates with AWS Firewall Manager for centralized policy management across accounts.
| Component | Description | Key Detail |
|---|---|---|
| Firewall | Top-level resource; logical firewall for a VPC | One per VPC; spans multiple AZs via separate endpoints |
| Firewall Endpoint | ENI-like resource in a dedicated firewall subnet | One per AZ; subnet should be a /28 minimum |
| Firewall Policy | Container for rule groups; defines processing order | Stateless rules first, then stateful rules |
| Stateless Rule Group | Packet-level rules (5-tuple matching) | Pass/drop/forward-to-stateful; evaluated in priority order |
| Stateful Rule Group | Connection-level rules with Suricata support | Domain list, standard rules, or Suricata IPS rules |
| Rule Group | Reusable set of rules; can be shared across policies | Managed rule groups available from AWS and Marketplace |
The deployment model requires routing traffic through the firewall endpoint. For a public-facing VPC, you create a firewall subnet in each AZ, place the IGW in a separate route table, and use Ingress Routing to force all traffic from the IGW through the firewall endpoint before it reaches your application subnets.
Network Firewall scales automatically - you do not manage the underlying instances. The firewall endpoint is highly available within each AZ. You are responsible for placing firewall subnets in each AZ you use and updating route tables correctly.
Rule Types: Stateless, Stateful, and Suricata
Network Firewall processes traffic through two rule stages. Understanding when each applies is critical for designing effective firewall policies.
| Rule Type | Matching | Actions | Use Case |
|---|---|---|---|
| Stateless | Protocol, source/dest IP, source/dest port | Pass, Drop, Forward to stateful | High-throughput allow/deny for known trusted traffic; bypasses stateful inspection for performance |
| Stateful (5-tuple) | Same as stateless but tracks connection state | Pass, Drop, Alert | Protocol-aware connection filtering |
| Stateful (domain list) | HTTP Host header or TLS SNI | Allow or Deny domains | Block/allow specific domains without full Suricata rules |
| Suricata IPS rules | Full Suricata rule syntax; payload inspection | Alert, Drop, Pass | Advanced threat detection; CVE signatures; custom signatures |
# Example Suricata rule to block DNS over HTTPS (DoH)
alert tls any any -> any 443 (msg:"Potential DoH"; tls.sni; content:"dns.google"; nocase; sid:1000001; rev:1;)
# Example domain list rule group (via AWS Console/API)
# Type: HTTP_HOST / TLS_SNI
# Target domains: .example-malware.com, .phishing-domain.net
# Action: DENYLIST
# Route table entry to force traffic through firewall endpoint
# In the subnet route table:
# Destination: 0.0.0.0/0 -> vpce-xxxx (firewall endpoint ENI)TLS inspection (decryption and re-encryption) requires a separate TLS certificate configuration and significantly increases complexity and cost. Without TLS inspection, stateful rules can only match on TLS SNI (the hostname in the ClientHello) not on the encrypted payload. Most customers start without TLS inspection and add it only for specific traffic categories.
Centralized vs Distributed Deployment
Network Firewall can be deployed in each VPC (distributed) or in a centralized inspection VPC with traffic routed via Transit Gateway (centralized).
| Pattern | Architecture | Trade-offs |
|---|---|---|
| Distributed | Firewall deployed in each VPC | Simpler routing; more total cost; policy management via Firewall Manager |
| Centralized egress | All VPCs route 0.0.0.0/0 through TGW to inspection VPC | Single policy enforcement point; complex routing; potential bottleneck |
| Centralized ingress | Inspection VPC behind ALB/IGW; traffic inspected before reaching app VPCs | Protects against external threats; less common pattern |
| East-west inspection | All inter-VPC traffic routed through TGW to inspection VPC | Inspects lateral movement; significant TGW data costs |
AWS Firewall Manager lets you centrally deploy and enforce Network Firewall policies across all accounts in an AWS Organization. Policies can be in "monitor" mode (log but don't block) or "enforced" mode. This is the recommended management approach for multi-account environments.
Network Firewall vs Security Groups vs WAF vs Shield
| Service | Layer | What It Protects Against | Limitations |
|---|---|---|---|
| Security Groups | L4 (ENI/instance) | Unauthorized port/protocol access | Stateful but no deep inspection; no domain filtering |
| Network ACLs | L3/L4 (subnet) | IP/port-based blocking at subnet boundary | Stateless; no connection tracking; coarse controls |
| Network Firewall | L3-L7 (VPC) | Advanced threats, domain filtering, IPS signatures | Requires routing changes; does not inspect encrypted payloads without TLS inspection |
| WAF | L7 (HTTP) | OWASP Top 10, bot traffic, rate limiting at app layer | HTTP/HTTPS only; attached to ALB/CloudFront/API GW |
| Shield Advanced | L3/L4 | DDoS mitigation | DDoS only; not a general-purpose firewall |
| GuardDuty | Network logs (VPC Flow, DNS) | Threat intelligence; anomaly detection | Detection only; no blocking; uses existing logs |
A defense-in-depth architecture uses all layers: Shield Advanced at the edge, WAF on HTTP endpoints, Network Firewall for VPC-level inspection, and Security Groups as the last line of defense at each instance.
Network Firewall Pricing
| Component | Cost | Notes |
|---|---|---|
| Firewall endpoint | $0.395/hr per AZ (~$285/month for 3 AZs) | Charged whether or not traffic flows through it |
| Traffic processing | $0.065/GB | All traffic inspected by the firewall |
| TLS inspection | Additional endpoint + processing charges | Roughly doubles the cost per AZ |
At $0.395/hr per endpoint, running Network Firewall in 3 AZs costs ~$854/month in endpoint fees alone before any traffic charges. Evaluate whether the inspection requirements justify this cost vs simpler controls. For many workloads, Security Groups + WAF + GuardDuty provide sufficient protection at a fraction of the cost.
Interview Focus Points
- 1Explain the difference between stateless and stateful rule groups in Network Firewall.
- 2How do you route traffic through Network Firewall in a VPC? Walk through the route table changes required.
- 3When would you use Network Firewall vs WAF vs Security Groups? How do they complement each other?
- 4What is the difference between centralized and distributed Network Firewall deployment with Transit Gateway?
- 5How does Suricata rule integration work in Network Firewall? Give an example of a rule you would write.
- 6How do you inspect encrypted HTTPS traffic with Network Firewall?
- 7How does AWS Firewall Manager help manage Network Firewall policies across a multi-account AWS Organization?
- 8A company needs to block all traffic to known malicious domains from all VPCs. What is the most cost-effective architecture?
- 9What are the cost components of Network Firewall and when might simpler alternatives be more appropriate?