---
title: AWS Network Firewall + Firewall Manager: Multi-Account Stateful L3-L7 Defense in Production
description: AWS Network Firewall is the AWS-native stateful L3-L7 firewall for VPCs; Firewall Manager pushes a single policy across every account in your AWS Organization. This guide covers production deployment, Suricata rule design, TLS inspection, multi-account distribution, and how Network Firewall composes with WAF, Shield, and Verified Access.
url: https://www.factualminds.com/blog/aws-network-firewall-firewall-manager-multi-account/
datePublished: 2026-04-28T00:00:00.000Z
dateModified: 2026-04-29T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: network-firewall, firewall-manager, vpc-security, network-security, multi-account, control-tower, aws
---

# 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; Firewall Manager pushes a single policy across every account in your AWS Organization. This guide covers production deployment, Suricata rule design, TLS inspection, multi-account distribution, and how Network Firewall composes with WAF, Shield, and Verified Access.

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](/services/aws-cloud-security/) or [talk to our team](/contact-us/).

## 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:

```bash
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:

| Layer     | Service                          | Purpose                                               |
| --------- | -------------------------------- | ----------------------------------------------------- |
| Edge      | CloudFront + AWS Shield Advanced | DDoS protection, edge caching                         |
| App       | AWS WAF                          | OWASP-pattern blocking, rate limiting, bot mitigation |
| Workforce | AWS Verified Access              | ZTNA for internal app access                          |
| Network   | AWS Network Firewall             | Stateful L3-L7 inspection, egress control             |
| VPC       | Security groups, NACLs           | Stateful L4 per-ENI / stateless L4 per-subnet         |
| Resource  | IAM, KMS, S3 Block Public Access | Resource-level access control                         |

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](https://docs.aws.amazon.com/network-firewall/latest/developerguide/)** and the **[AWS Firewall Manager Developer Guide](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)**.
- Pair with **[AWS WAF in production](/blog/aws-waf-web-application-firewall-production-guide/)** and **[VPC networking best practices](/blog/aws-vpc-networking-best-practices-for-production/)**.
- Pair with **[AWS Verified Access](/blog/aws-verified-access-ztna-zero-trust-network/)** for the workforce-access layer.
- Browse the **[AWS Security & Compliance hub](/security-compliance/)** and the **[Network & Application Security subtopic](/security-compliance/network-application-security/)**.

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.

## FAQ

### When do we need Network Firewall in addition to security groups and NACLs?
Security groups are stateful L4 (port-based) and operate per-ENI; NACLs are stateless L4 and operate per-subnet; neither inspects packet contents or maintains a global stateful view across the VPC. Network Firewall is a stateful L3-L7 firewall service that inspects all traffic in and out of a VPC, runs Suricata-compatible IDS/IPS rules, supports TLS inspection (with the right key configuration), and enforces domain-based egress filtering. Most regulated workloads need it for: (1) egress filtering — restrict outbound traffic to allowed destinations; (2) intrusion detection / prevention — detect and block known-bad signatures; (3) east-west inspection — control traffic between VPCs and Transit Gateway attachments; (4) compliance — many compliance frameworks (PCI DSS, HIPAA, SOC 2, DORA) expect application-aware network controls beyond port-based filtering.

### Network Firewall vs AWS WAF — which protects what?
They protect different layers and traffic shapes. AWS WAF inspects HTTP / HTTPS traffic at the application layer (CloudFront, ALB, API Gateway, AppSync, Cognito, Verified Access) and is the right tool for SQL injection, XSS, bot mitigation, OWASP-pattern blocking, rate limiting, and geographic blocking. Network Firewall is a stateful network-layer (L3-L7) firewall for VPCs — it inspects all traffic in and out of a VPC (TLS-inspection optional), runs Suricata-compatible IDS/IPS rules, and enforces domain-based egress filtering. Most regulated workloads run both: WAF in front of public web/API endpoints, Network Firewall on the VPC edge for east-west and egress control.

### How does Firewall Manager work in a multi-account AWS Organization?
Firewall Manager is the multi-account policy engine. You designate a delegated administrator account (the Firewall Manager administrator), enable AWS Config and AWS Organizations, and create policies covering: WAF rule groups, Network Firewall stateful and stateless policies, Shield Advanced protections, security-group baselines, and DNS Firewall policies. Each policy targets specific accounts via AWS Organizational Unit (OU), explicit account list, or tag-based selectors. New accounts that match the targeting receive the policy automatically on creation; drift (a manually-edited security group, a missing WAF rule, a tampered Network Firewall rule) is auto-remediated or flagged based on the policy mode. Without Firewall Manager you end up writing per-account Terraform — workable for 5 accounts, painful at 50, broken at 200.

### Should we enable TLS inspection?
TLS inspection lets Network Firewall decrypt TLS traffic, inspect the cleartext, and re-encrypt before forwarding — required for full L7 inspection of HTTPS traffic. It is powerful but brings tradeoffs: (1) you must manage a TLS interception certificate distributed to client devices/services for trust; (2) some traffic is not amenable to inspection (mTLS, HTTPS connections to AWS service endpoints with cert pinning, certificate transparency-pinned applications); (3) latency adds a few milliseconds; (4) regulatory and compliance frameworks vary on whether TLS interception is acceptable for sensitive flows (HIPAA, PCI DSS generally allow it with the right key management; some EU sovereignty frameworks discourage it). Most organisations enable TLS inspection on egress-from-VPC traffic for a defined "go-via-Network-Firewall" path and skip it for intra-VPC, AWS-service-endpoint, and end-customer-facing traffic. Plan the inspection scope before enabling.

### What does Network Firewall cost at scale?
Network Firewall pricing has two components: per-firewall-endpoint per hour (charged per Availability Zone where the firewall is deployed) and per-GB processed. For a typical mid-market VPC with a multi-AZ deployment, the per-endpoint cost runs a few hundred dollars per month per AZ; the per-GB cost dominates at high-traffic scale. Cost-control patterns: (1) deploy in the minimum AZ count consistent with availability requirements (usually 2-3 AZs per Region); (2) use a centralized inspection VPC with Transit Gateway attachments instead of per-VPC firewalls — scales to hundreds of VPCs while paying for one centralized firewall fleet; (3) skip inspection on intra-VPC traffic where security groups already enforce the boundary; (4) for egress-only inspection, route only egress traffic through the firewall (asymmetric routing), avoiding double-billing on return traffic. At organisation scale with Firewall Manager, the per-firewall cost amortizes across many VPCs.

---

*Source: https://www.factualminds.com/blog/aws-network-firewall-firewall-manager-multi-account/*