AWS Network Firewall

Lesson 2 of 4 in Network Security Controls.

Security groups and NACLs answer "may these addresses talk on this port". AWS Network Firewall answers the questions that need to look inside the conversation: which domains may be reached, whether this really is HTTPS on 443, whether this payload matches a known intrusion signature.

Architecturally it is an appliance you route traffic through. You create a firewall with a firewall policy, and Network Firewall places a firewall endpoint in a dedicated subnet in each Availability Zone you choose. Nothing is inspected until route tables send traffic to those endpoints — which is the single most important operational fact about the service, and the reason "we deployed Network Firewall but nothing is being filtered" is a routing bug. Keep an endpoint in every AZ you inspect; routing across AZs costs money and breaks when an AZ does.

The policy holds two kinds of rule group, and they are not interchangeable:

Stateless rule groups evaluate each packet on its own against the 5-tuple — protocol, source and destination address, source and destination port — plus TCP flags. Each rule has a priority and they are evaluated lowest first. Actions are pass, drop, or forward to stateful rules, and that third action is the one that matters: stateless rules are the cheap pre-filter that decides what deserves deep inspection.

Stateful rule groups track connections and understand protocols. They come in three flavours: 5-tuple rules with connection awareness, domain lists (allow or deny by domain, matched against the HTTP Host header and the TLS SNI), and raw Suricata-compatible rule strings — which is how you load a community ruleset or express a signature with content matching, thresholds and flow conditions. Actions are pass, drop, alert and reject.

Four operational details decide whether a deployment behaves the way the design document claimed.

Default actions. The policy declares what happens to traffic no rule decided — separately for the stateless side (pass, drop, or forward) and, under strict order, for the stateful side (drop all, drop established, alert all, alert established). An egress firewall built as an allow-list is only an allow-list if the default is drop; leave it at pass and you have built an elaborate logging system.

Rule order. Default action order applies the Suricata convention — pass rules are considered before drop, drop before alert — which surprises people who expect top-to-bottom. Strict order evaluates rule groups by priority and rules in the order you wrote them, which is what most teams actually want, and it is the mode that lets you choose those default actions. The rule group's own setting must match the policy's.

Logging. Network Firewall emits alert logs (for traffic matching a rule with an alert action), flow logs (connection records from the stateful engine), and TLS logs, to CloudWatch Logs, S3 or Amazon Data Firehose. Run new stateful rules with alert before drop — the same Count-then-Block discipline as WAF, under a different name.

TLS inspection. Without decryption, a stateful rule sees only the SNI and the 5-tuple. A TLS inspection configuration uses certificates in AWS Certificate Manager to decrypt, inspect and re-encrypt, which lets Suricata rules read HTTP payloads — at the cost of becoming a man in the middle of your own traffic, with everything that implies for privacy scoping and certificate management.

And one failure mode worth memorizing: flow asymmetry. If a connection's request passes through one firewall endpoint and its response through another, the stateful engine never sees both halves and the connection breaks. Through a Transit Gateway, the fix is appliance mode on the inspection VPC attachment, which keeps both directions of a flow pinned to the same Availability Zone.

Key terms: AWS Network Firewall, Firewall endpoint, Suricata-compatible rule, Inspection VPC

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.