AWS Network Firewall

AWS Network Firewall is a managed firewall service that provides network traffic filtering for VPCs. It sits in its own subnet and inspects traffic passing through it.

Capabilities

• Stateful Inspection: track connection state for TCP, UDP, ICMP
• Domain Filtering: allow or deny outbound traffic based on domain names (for example allow *.amazonaws.com only)
• Intrusion Prevention (IPS): Suricata-compatible rules for deep packet inspection
• TLS Inspection: decrypt and inspect HTTPS traffic (requires a certificate)
• Managed Rule Groups: AWS-curated threat intelligence rules

Architecture Patterns

• Centralized Inspection: deploy in a dedicated inspection VPC with Transit Gateway routing all traffic through it
• Per-VPC Deployment: deploy firewall endpoints in each VPC for isolated inspection
• East-West Traffic: inspect traffic between VPCs (lateral movement prevention)

Rule Groups and Capacity

Rules live in rule groups, which are either stateless (evaluate packets in isolation) or stateful (evaluate packets in the context of a traffic flow). Network Firewall uses a Suricata rules engine to process all stateful rules, so you can write stateful rules in Suricata compatible format, or use the simplified entry forms for domain lists and basic rules.

The detail that catches people out is capacity. Every rule group has a capacity setting that is fixed at creation and cannot be changed or exceeded later. The maximum capacity setting is 30,000 for a stateless rule group and 30,000 for a stateful rule group. For a stateful group, estimate capacity as the number of rules you expect it to hold over its lifetime. For a stateless group, the capacity of one rule is the product of the complexity values of all its match settings: a setting with no criteria counts as 1, and a setting with criteria counts as the number of specifications. A rule matching 30 protocols against 3 sources and 5 destinations therefore needs 30 times 3 times 5, that is 450 capacity units. When you reference a rule group from a firewall policy, the policy reserves that full capacity whether or not you are using it.

A second creation-time decision: the stateful RuleOrder setting in the policy's stateful engine options can only be configured when you first create the firewall policy and cannot be edited later. Changing other stateful engine options, such as the stream exception policy or the TCP idle timeout, may require a restart of the stateful engine, and existing connections are then handled according to your stream exception policy.

How It Goes Wrong in Practice

The most common operational failure is sizing a rule group too tightly. A team creates a stateful rule group with capacity set to the exact number of rules they have on day one, because the number looked right. Six weeks later they need to add ten rules and discover the capacity cannot be raised. The only path is to create a new rule group with more capacity, add it to the policy, and remove the old one, which is a change-controlled operation on a device carrying production traffic. Always set capacity with generous headroom at creation; you are reserving processing budget, not paying per unit of unused rule count.

The second pattern is the asymmetric routing mistake. Network Firewall inspects what is routed through it, and getting that routing right in a centralized inspection design means editing route tables in the inspection VPC, the spoke VPCs, the Transit Gateway route tables, and the internet gateway ingress route table. Miss one and traffic either bypasses the firewall entirely (so your rules are decorative) or takes an asymmetric path where the request goes through the firewall and the response does not, which breaks the stateful engine and produces intermittent connection failures that look like an application bug.

Third, domain filtering that silently inspects nothing in a centralized design. By default, domain list inspection uses a HOME_NET variable set to the CIDR range of the VPC where the firewall is deployed, and only traffic from that range goes through domain filtering. In the common central inspection VPC pattern, where spoke VPC traffic arrives through a transit gateway, the spoke CIDRs are not in HOME_NET, so the domain rules never apply to the traffic you built them for. You must set HOME_NET explicitly to include the spoke CIDRs plus the inspection VPC's own range. Related: mixing rule group actions carelessly. With default action ordering, an Allow domain list rule group adds a default drop that takes effect before Reject and Alert rules in other domain list groups, so combining them produces behavior most people do not expect.

Inventorying Firewalls From the CLI

To list the firewalls in an account or Region:

aws network-firewall list-firewalls

No parameters are required. You can narrow it with --vpc-ids to filter by VPC. The output is a paginated Firewalls list where each entry carries FirewallName, FirewallArn, and, for transit gateway attached firewalls, a TransitGatewayAttachmentId, plus a NextToken. Follow up with aws network-firewall describe-firewall --firewall-name my-firewall to see the associated policy, subnet mappings, and whether delete protection and subnet change protection are enabled. Those two protections are worth checking on every production firewall: without them, a single API call can remove the inspection path.

Frequently Asked Questions

How is Network Firewall different from a security group or a NACL?

Security groups and NACLs match on addresses, protocols, and ports. Network Firewall does deep packet inspection: it can match on domain names, inspect protocol behavior, run Suricata IPS signatures, and optionally decrypt TLS. It also gives you a central place to apply one policy across many VPCs, which security groups cannot do. It does not replace security groups; it is a different layer.

Do I need TLS inspection to filter domains?

Not for most cases. Network Firewall can filter HTTPS by domain using the SNI field in the TLS handshake, which is visible without decryption. Full TLS inspection is needed when you want to inspect the payload inside the encrypted session, and it requires certificate management and has performance and privacy implications. Start with SNI-based domain filtering.

Can I change a rule group's capacity later?

No. Capacity is fixed at creation and cannot be changed or exceeded when you modify the rule group. Plan for growth when you create it, or accept a rule group replacement later.