network firewall routing(nat gw, alb)

To answer your two core assumptions directly:

1. No, you do not need two separate NFW endpoints. You only need one NFW endpoint per Availability Zone. A single endpoint can efficiently inspect both ingress and egress traffic. Designing for two endpoints would require deploying two completely separate firewall resources, which unnecessarily doubles your infrastructure costs.

2. Yes, the ALB and NAT Gateway must be in separate subnets. This is critical because they require completely different route table configurations.

Root Cause: Your current setup is failing due to asymmetric routing. The AWS Network Firewall is stateful; it is currently only seeing one half of your traffic flows, causing it to drop the packets.

Solution (Single NFW Architecture): To fix the asymmetric routing and use a single, cost-effective NFW endpoint, position the firewall logically between the IGW and your public resources (ALB / NAT GW).

Update your route tables to exactly match this matrix:

• IGW Ingress Route Table (Edge Association):
  • ALB Subnet CIDR → NFW Endpoint
  • NAT GW Subnet CIDR → NFW Endpoint
• NFW Subnet Route Table:
  • 0.0.0.0/0 → IGW
  • 10.0.0.0/16 → local
• ALB Subnet Route Table:
  • 0.0.0.0/0 → NFW Endpoint (forces return traffic back through the firewall)
  • 10.0.0.0/16 → local
• NAT GW Subnet Route Table:
  • 0.0.0.0/0 → NFW Endpoint (forces outbound internet traffic through the firewall)
  • 10.0.0.0/16 → local
• Private Subnet Route Table (EC2):
  • 0.0.0.0/0 → NAT Gateway
  • 10.0.0.0/16 → local

Once applied, the firewall will correctly see both the forward and return paths for all inbound and outbound connections.

Your dual-endpoint design is valid for inspecting egress traffic before NAT. The issue is asymmetric routing. Your NFW is stateful and only sees one direction of each flow, causing it to drop the return packets.

The problem in your current config:

For inbound (ALB): Traffic arrives via IGW → NFW Ingress → ALB. But the ALB's return traffic goes 0.0.0.0/0 → IGW directly, bypassing the NFW Ingress endpoint. The NFW saw the inbound packet but never sees the outbound reply → drops the flow as it can't match state.

For outbound (EC2): Traffic goes EC2 → NFW Egress → NAT GW → IGW (correct). Return traffic comes from IGW → NAT GW (correct, NAT handles this via connection tracking). But the NAT GW then sends the de-NATed packet to the EC2 private IP via 10.0.0.0/16 → local, bypassing the NFW Egress endpoint on the return. The NFW saw the outbound packet but not the return → drops state.

The fix: ensure symmetric routing through each NFW endpoint.

Subnet                    Destination        Target                   Purpose
─────────────────────────────────────────────────────────────────────────────────
IGW Edge RT               ALB Subnet CIDR    Ingress NFW Endpoint     Forces inbound to ALB through NFW
(associate with IGW)      NAT GW Subnet CIDR Ingress NFW Endpoint     Forces return internet traffic through NFW

NFW Ingress Subnet RT     0.0.0.0/0          IGW                      NFW forwards inspected traffic to/from internet
                          10.0.0.0/16        local

ALB Subnet RT             0.0.0.0/0          Ingress NFW Endpoint     Return traffic from ALB goes back through NFW
                          10.0.0.0/16        local

Private Subnet RT (EC2)   0.0.0.0/0          Egress NFW Endpoint      Outbound traffic inspected before NAT
                          10.0.0.0/16        local

NFW Egress Subnet RT      0.0.0.0/0          NAT GW                   NFW forwards inspected outbound to NAT
                          Private Sub CIDRs  local                    Return from NAT back to EC2

NAT GW Subnet RT          0.0.0.0/0          IGW                      NAT GW reaches internet (DO NOT change this)
                          Private Sub CIDRs  Egress NFW Endpoint      Return traffic from NAT goes back through NFW
                          10.0.0.0/16        local

Key changes from your original:

1. ALB Subnet RT: Changed 0.0.0.0/0 → IGW to 0.0.0.0/0 → Ingress NFW Endpoint. This forces ALB return traffic back through the ingress firewall, completing the symmetric path.

2. NAT GW Subnet RT: Added Private Subnet CIDRs → Egress NFW Endpoint. This forces de-NATed return traffic back through the egress firewall before it reaches the EC2 instances. The 0.0.0.0/0 → IGW route stays because the NAT GW must reach the internet directly.

3. IGW Edge RT: Added NAT GW Subnet CIDR → Ingress NFW Endpoint. This ensures internet-initiated return traffic to the NAT GW public IP also traverses the ingress NFW (covers the case where the IGW receives return packets for the NAT GW).

Traffic flows after fix:

INBOUND (ALB):
Internet → IGW → [Edge RT: ALB CIDR → NFW] → Ingress NFW → ALB → EC2
EC2 → ALB → [ALB RT: 0.0.0.0/0 → NFW] → Ingress NFW → IGW → Internet
                                              ↑ symmetric ↑

OUTBOUND (EC2):
EC2 → [Private RT: 0.0.0.0/0 → NFW] → Egress NFW → NAT GW → IGW → Internet
Internet → IGW → NAT GW → [NAT RT: Private CIDRs → NFW] → Egress NFW → EC2
                                                             ↑ symmetric ↑

Answering your design questions:

1. Do you need two NFW endpoints? For your design (inspect egress BEFORE NAT), yes. Two endpoints give cleaner separation. A single endpoint can work but requires the NFW to sit between the IGW and ALL public resources, which means outbound inspection happens AFTER NAT (you'd only see the NAT GW IP, not the original EC2 source). Your dual-endpoint design preserves original source IP visibility for egress rules.

2. Must ALB and NAT GW be in separate subnets? Yes. They require completely different route tables (ALB needs return through ingress NFW; NAT GW needs direct IGW access for outbound + return through egress NFW for de-NATed traffic).

Additional checks if traffic still fails after route table fixes:

• Verify NFW stateless default action is Forward to stateful rule groups (not Drop)
• Verify NFW stateful default action is Pass (or you have an explicit pass any any rule)
• Verify NFW endpoint is in the same AZ as the ALB/NAT GW subnets
• Check NACLs on all subnets allow traffic (default NACLs allow all; custom NACLs may block)
• Ensure the IGW Edge RT is associated with the Internet Gateway itself, not a subnet

References:

• VPC route table configuration for AWS Network Firewall
• Architecture with an internet gateway and NAT gateway
• Deployment models for AWS Network Firewall