Hands-on with AWS Network Firewall — a complete VPC security architecture

Why I Built This

A year into deep AWS work, I wanted a milestone project that forced me to connect every moving piece of VPC security into one coherent design. AWS Network Firewall (NFW) was the missing thread — I had used WAF and Security Groups heavily, but NFW sits at a different layer and unlocks a class of controls that neither of those tools can provide.

This post walks through the architecture I designed, why each component is placed where it is, and what I learned about traffic inspection at scale.

The Architecture at a Glance

The design covers a multi-AZ VPC with three distinct traffic planes:

• Ingress — internet traffic filtered at Layer 7 before it reaches any application.
• Application — ECS services running in fully private subnets with no direct internet path.
• Egress — all outbound traffic from ECS forced through Network Firewall before reaching the internet.

Each plane has dedicated subnets and route tables, which is the critical constraint that makes firewall traversal enforceable.

Layer by Layer

Layer 7 Ingress — AWS WAF on the ALB

Internet-facing traffic hits a Public Application Load Balancer first. AWS WAF is attached to the ALB, providing Layer 7 inspection: SQL injection protection, rate limiting, geo-blocking, and custom rule sets before a single packet reaches application code.

Placing WAF here rather than on CloudFront alone means that even direct-to-ALB traffic (bypassing CDN) is still inspected.

Application Tier — ECS in Private Subnets

ECS services run in private subnets with no route to an internet gateway. The only outbound path is through the firewall subnets. This enforces a hard perimeter — a misconfigured container cannot phone home unless that traffic is explicitly allowed by a firewall rule.

Each AZ has its own private subnet, its own firewall subnet, and its own NAT Gateway, so the path is symmetric and there is no cross-AZ hairpin for egress.

Egress Inspection — AWS Network Firewall

NFW sits in dedicated firewall subnets — one per AZ. The route tables in the private subnets send all 0.0.0.0/0 traffic to the firewall endpoint in the same AZ. After inspection, allowed traffic exits to the NAT Gateway in the corresponding public subnet.

NFW’s stateful rules engine is what makes this interesting:

• Domain-based filtering — block or allow traffic to specific FQDNs rather than just IP ranges, which is far more maintainable as cloud service IPs rotate.
• Deep packet inspection — inspect HTTP/S, DNS, and other application protocols beyond just IP and port.
• Protocol enforcement — reject non-standard ports or unexpected protocols from services that should only speak HTTPS.
• Stateful tracking — connection state is tracked so return traffic does not need separate allow rules.

Centralised Policy — AWS Firewall Manager

Firewall Manager manages the NFW policies across AZs and subnets from a single control plane. It automatically provisions firewall endpoints when new subnets are added, keeping the policy consistent without manual route table updates.

This is what makes the design scale beyond a single VPC — Firewall Manager can extend the same rule set to new VPCs or accounts as the environment grows.

VPC Endpoints — Keeping AWS Traffic Off the Internet

VPC endpoints for services like S3, ECR, CloudWatch Logs, and Secrets Manager mean that ECS tasks communicating with AWS APIs stay on the AWS private network. This removes a category of traffic from the NFW inspection path entirely and eliminates NAT Gateway charges for AWS-to-AWS traffic.

Route Table Design

The route table configuration is where the architecture either holds or falls apart. Each tier has its own table:

Subnet type	0.0.0.0/0 target
Public	Internet Gateway
Firewall	Internet Gateway (after inspection)
Private	Firewall endpoint (same AZ)

The private subnet’s default route pointing at the firewall endpoint — not the NAT Gateway directly — is what enforces firewall traversal. Remove that single route and traffic bypasses NFW entirely.

What This Architecture Taught Me

Symmetric routing matters more than I expected. In a multi-AZ setup, asymmetric paths (traffic in through AZ-A, response out through AZ-B) break stateful inspection. Every AZ needs its own firewall endpoint, and the route tables must be AZ-aware.

Domain filtering is worth the complexity. IP-based egress rules become unmanageable fast for cloud-native services. NFW’s FQDN matching means you write *.amazonaws.com once and it stays correct even when service IPs change.

Firewall Manager changes the operational model. Without it, adding a new subnet or AZ requires manually updating firewall endpoints and route tables. With it, the policy is declarative and the infrastructure catches up automatically.

VPC endpoints and NFW are complementary, not competing. Endpoint traffic bypasses the internet and bypasses NAT charges; firewall rules for that traffic can be tighter. Non-endpoint traffic is the higher-risk path and gets deep inspection. Model them as two separate traffic classes.

Key Takeaway

AWS Network Firewall fills the gap between Security Groups (instance-level, stateful, no DPI) and WAF (Layer 7, request-level). When you need to enforce what your applications are allowed to call, not just what’s allowed to call them, NFW is the right layer. The operational overhead is real — route tables, firewall subnets, endpoint management — but Firewall Manager brings it back to a manageable surface area.