AWS Network Firewall + Firewall Manager: Multi-Account Stateful L3-L7 Defense in Production

AWS Network Firewall is the AWS-native stateful L3-L7 firewall for VPCs, powered by Suricata for IDS/IPS rule processing. AWS Firewall Manager is the multi-account policy engine that pushes Network Firewall (plus WAF, Shield Advanced, security-group baselines, and DNS Firewall) policies across every account in your AWS Organization. Together they replace per-account Terraform-driven network defense with a centralized policy backbone that scales from 5 accounts to 500.

This guide is for security architects, network engineers, and platform owners running multi-account AWS estates with regulatory or threat-model requirements that exceed security groups and NACLs. It covers the architectures (distributed vs centralized inspection), Suricata rule design, TLS inspection scope, Firewall Manager multi-account distribution, and how Network Firewall composes with WAF, Shield, and Verified Access.

Need help deploying Network Firewall + Firewall Manager across an Organization? FactualMinds runs network-security engagements that pair Network Firewall, Firewall Manager, Control Tower, and the broader AWS security stack into a coherent multi-account design. See our cloud security service or talk to our team.

Why Network Firewall

The standard AWS network defense — security groups (stateful L4 per-ENI) plus NACLs (stateless L4 per-subnet) plus VPC endpoints — is sufficient for many workloads but does not satisfy four requirements common in regulated estates:

1. Egress filtering by domain. Most outbound traffic should go to a known set of destinations (AWS service endpoints, your CDN, your SaaS vendors). NACLs and security groups can restrict egress by IP/port but not by domain. Network Firewall enforces “egress only to allowed FQDNs.”
2. L7 protocol inspection. Detecting HTTP-based command-and-control beacons, SMB attacks, DNS tunneling — none of these are visible to L4 security groups. Suricata IDS rules in Network Firewall match L7 patterns.
3. East-west inspection. Traffic between VPCs (via Transit Gateway, VPC peering, or a transit VPC) is opaque to security groups attached to the source ENI alone. Network Firewall in a centralized inspection VPC mediates the traffic.
4. Audit-grade logging. Compliance frameworks (PCI DSS Req 1, HIPAA §164.312(e), DORA Article 9, SOC 2 CC6.6) expect application-aware network logs. Network Firewall produces alert and flow logs that map cleanly to these controls.

Architecture options: distributed vs centralized

Two patterns. Pick before deploying.

Distributed inspection

One Network Firewall per VPC, deployed in dedicated firewall subnets across each AZ. Traffic in and out of the VPC routes via the firewall.

Pros: simple per-VPC ownership, isolated blast radius, no Transit Gateway requirement.

Cons: firewall fleet scales linearly with VPC count, per-firewall hourly cost across many small VPCs becomes expensive.

Use when: small AWS estates (1-10 VPCs), simple network topologies, no Transit Gateway in play.

Centralized inspection (recommended for >10 VPCs)

A single inspection VPC hosts the Network Firewall fleet. All other VPCs attach to a Transit Gateway; the Transit Gateway routes traffic through the inspection VPC. New VPCs added to the Organization automatically get inspection by attaching to the same Transit Gateway.

Pros: firewall fleet decoupled from VPC count, lower aggregate cost at scale, single policy management point.

Cons: Transit Gateway is required (with its own per-attachment hourly cost and per-GB data-processing cost), single-point-of-failure design considerations, more complex routing.

Use when: medium-to-large AWS estates (>10 VPCs), already operating Transit Gateway, multi-account environments with Firewall Manager.

The centralized pattern is the AWS reference design and what most regulated multi-account organisations land on.

Step 1: Deploy the centralized inspection VPC

Components:

• A dedicated inspection VPC in your security/networking account.
• Transit Gateway attachments from every workload VPC to the inspection VPC.
• Two subnets per AZ in the inspection VPC: a “transit” subnet for the TGW attachment and a “firewall” subnet for the Network Firewall endpoint.
• Route tables that send outbound traffic from workloads through the firewall subnets.

CloudFormation / Terraform pattern: deploy the inspection VPC as a reference template, attach via Transit Gateway from each new workload VPC, configure the Transit Gateway route tables to route via the inspection VPC’s firewall.

Step 2: Author the rule policy

Network Firewall accepts both stateless rules (5-tuple match, no connection state) and stateful rules (Suricata-compatible, full connection awareness with Suricata signature support).

A typical production rule set:

Stateless rules (low-latency drop early):

• Drop known-bad IPs from a managed threat intelligence feed.
• Drop traffic to unauthorized external regions (geoblocking at the network layer).
• Pass intra-VPC traffic and traffic to AWS service endpoints (skip stateful inspection where it is not needed for performance).

Stateful rules (deep inspection):

• Suricata IDS rules from the AWS-managed rule groups: AbuseChEmergingThreats, ETOpenInsiderThreat, ETOpenP2P, ETOpenScan, ETOpenWorm.
• Domain-based egress allow-list: restrict egress to allow-listed domains (AWS service endpoints, your CDN, your SaaS vendors, package mirrors).
• Custom Suricata rules for application-specific patterns (block unauthorized DNS exfiltration, detect known C2 protocols, alert on SQL-injection patterns missed at L7).

The AWS-managed stateful rule groups update automatically as new threats are added — comparable to AWS WAF managed rule groups but at the network layer.

Step 3: Configure logging

Network Firewall generates two log types:

• Alert logs — every rule match with action (allow / drop / alert).
• Flow logs — every connection (5-tuple, byte/packet counts).

Send both to a centralized S3 bucket (per the standard AWS reference architecture: dedicated log archive account, Object Lock for retention, CloudTrail data events on the bucket). Forward to Security Lake (OCSF format) for SIEM ingestion or to CloudWatch Logs for real-time dashboards.

For audit-grade evidence, enable both log types in production. The flow logs feed traffic-pattern analysis (PCI DSS Req 1.1.6, “documented business justification for use of all services, protocols, and ports”); the alert logs feed incident detection.

Step 4: TLS inspection (optional, plan carefully)

TLS inspection lets Network Firewall decrypt outbound TLS connections, inspect the cleartext, and re-encrypt before forwarding. The configuration:

• Generate or import a CA certificate to AWS Certificate Manager Private CA.
• Configure the Network Firewall policy with a TLS inspection configuration referencing the CA cert.
• Distribute the CA cert to client devices/services as a trusted root.
• Define which destination domains are inspected and which are bypassed.

Tradeoffs:

• Bypass list essential. Pin destinations that must not be inspected (your own service endpoints with mutual TLS, banking partners with cert pinning, Apple/Google/Microsoft software update endpoints). Mis-inspecting these breaks trust.
• Latency. Inspection adds a few milliseconds per connection; usually negligible for batch and back-office traffic.
• Compliance. HIPAA and PCI DSS generally permit TLS inspection with proper key management. Some EU sovereignty frameworks (national-security-grade) discourage breaking end-to-end encryption — confirm with your legal team for sensitive flows.
• Cost. Per-GB of inspected traffic cost is higher than non-inspected.

Most organisations enable TLS inspection on egress traffic for the “go via inspection” path and skip it for intra-VPC, AWS-service-endpoint, and end-customer-facing traffic.

Step 5: Distribute via Firewall Manager

Once the inspection VPC is operational, use Firewall Manager to push Network Firewall policy across the Organization:

aws fms put-policy \
    --policy '{
      "PolicyName": "Org-NetworkFirewall-Egress",
      "ResourceType": "AWS::EC2::VPC",
      "SecurityServicePolicyData": {
        "Type": "NETWORK_FIREWALL",
        "ManagedServiceData": "{\"type\":\"NETWORK_FIREWALL\",\"networkFirewallStatelessRuleGroupReferences\":[...]}"
      },
      "ResourceTags": [{"Key": "RequireFirewall", "Value": "true"}],
      "ExcludeResourceTags": false,
      "RemediationEnabled": true
    }'

Tag-based targeting (ResourceTags: RequireFirewall=true) means VPCs that are tagged inherit the policy on next sync; new VPCs created with the tag are auto-protected. Drift remediation is on by default — if someone manually removes the firewall, Firewall Manager re-creates it.

Firewall Manager also pushes:

• AWS WAF Web ACLs to ALBs, CloudFront, API Gateway.
• AWS Shield Advanced protections.
• Security-group baselines (audit and remediate).
• DNS Firewall policies.

A complete multi-account network defense from a single dashboard.

Step 6: Compose with WAF, Shield, and Verified Access

The full layered defense:

Each layer catches a different failure mode. Firewall Manager pushes the WAF and Network Firewall policies; Verified Access endpoints sit behind WAF; CloudFront sits in front of public ALBs with Shield Advanced.

Common pitfalls

1. Distributed when centralized was right. Picking distributed inspection at 30+ VPCs is the most expensive mistake. Migrate to centralized.
2. Ignoring the bypass list for TLS inspection. Inspecting AWS service endpoints, software-update channels, or banking partners with cert pinning breaks them. Build the bypass list before enabling.
3. Over-broad domain allow-lists. “Allow *.amazonaws.com” defeats the egress-control point. Allow specific service endpoints only.
4. Not using Firewall Manager. Per-account Terraform works for 5 accounts; at 50 it is unmaintainable. Bring Firewall Manager in early.
5. No log review. Alert logs accumulate without action. Build the SIEM ingest path and alert routing on day one.

Where to go next

• Read the AWS Network Firewall Developer Guide and the AWS Firewall Manager Developer Guide.
• Pair with AWS WAF in production and VPC networking best practices.
• Pair with AWS Verified Access for the workforce-access layer.
• Browse the AWS Security & Compliance hub and the Network & Application Security subtopic.

Network Firewall + Firewall Manager is the multi-account network-security backbone for regulated AWS estates. Most teams discover the cost-and-operational case after their first audit finding around egress control or east-west inspection. Designing the centralized inspection VPC + Firewall Manager policies before you scale to 50 accounts is the difference between a clean architecture and a refactor under audit pressure.