AWS WAF vs Network Firewall vs Security Groups: What Blocks What

Security groups for free layer 3 and 4 filtering on every network interface, AWS WAF for layer 7 attacks against public HTTP endpoints, and AWS Network Firewall for VPC-wide inspection plus outbound domain control. These are not competing products: each sits at a different point in the traffic path and sees traffic the others never will. Most production stacks need security groups and WAF; Network Firewall earns its keep when egress filtering or compliance demands it.

What do security groups and NACLs actually block?

Security groups filter traffic by IP range, port and protocol at the network interface, statefully: return traffic for an allowed connection passes automatically. Network ACLs do the same job at the subnet boundary, statelessly, so each direction needs an explicit rule. Both are free, both operate at layers 3 and 4, and neither reads a byte of payload.

That last point is the one teams forget. A security group that allows port 443 from the internet will happily pass a SQL injection attempt, a credential-stuffing bot and a scraper: seen from layer 4, they are all valid TCP to an open port. Treat security groups as your default-deny baseline, keep them tight, and accept that they answer "who can talk to whom", never "what are they saying". The official reference is the VPC security groups documentation.

What does AWS Network Firewall add on top?

AWS Network Firewall is a managed inspection point inside your VPC covering layers 3 through 7: stateful rule groups, Suricata-compatible signatures for intrusion detection, and domain or TLS SNI based filtering. The decisive point: it is the only service in this trio that can stop a compromised instance from calling an attacker's domain over port 443.

You deploy it as firewall endpoints, one per Availability Zone you want protected, and steer traffic through them with route tables. The cost shape follows from that design: an hourly charge per endpoint plus a per-GB charge on inspected traffic, billed whether traffic flows or not. That makes it a poor fit for one small VPC and a reasonable one for a shared inspection VPC serving many workloads. Details are on the Network Firewall pricing page.

Where does AWS WAF fit?

AWS WAF inspects HTTP requests where your application meets the internet: it attaches to CloudFront distributions, Application Load Balancers, API Gateway and AppSync. It blocks what the layers below cannot see: SQL injection, cross-site scripting, abusive request rates and known bad bots. It never sees raw TCP and does nothing for non-HTTP protocols.

In practice, you start with the AWS managed rule groups (core rule set, known bad inputs, IP reputation), add rate-based rules per client or per path, and reach for Bot Control only when bot pressure justifies its extra fee. The cost shape: a fixed monthly charge per web ACL and per rule, plus a per-million-requests charge; see the WAF pricing page. Rate-based rules also pair naturally with the per-partner quotas we describe in our partner API SLA design article.

Is Shield Standard enough, or do you need Advanced?

Shield Standard is free, automatic and already active: it absorbs common layer 3 and 4 DDoS floods (SYN floods, UDP reflection) for every AWS customer. Shield Advanced is a paid subscription with a long-term commitment: it adds a dedicated response team, deeper detection, and financial protection against attack-driven scaling bills.

For most products, Standard plus WAF rate-based rules is a sound baseline. Advanced becomes worth discussing when downtime is measured in contractual penalties, when you are a visible target, or when finance wants a cap on what an attack can cost. The exact inclusions evolve over time, so verify the current terms before committing.

Who protects a serverless stack, and who controls egress?

For a serverless stack, WAF is the layer that matters: API Gateway, CloudFront and AppSync are its native attach points, and traffic to Lambda or DynamoDB never crosses a subnet you control. Deploying Network Firewall there is usually pointless: without a VPC data path, there is nothing for it to inspect.

Egress is the mirror image. Security groups can restrict outbound traffic by IP and port, but not by domain; WAF only ever sees inbound requests to your own endpoints. When an auditor asks you to prove that a workload can only call three named external APIs, Network Firewall (or an explicit proxy) is the only AWS-native answer. Sequencing these layers correctly is a standard part of our AWS architecture engagements.

Side by side: layer, attach point, threats, cost shape

One table, three services, five questions. Read the last row first: "when it wins" is the row that settles most arguments, because it makes explicit that these tools complement each other instead of competing for the same job. A mature stack usually runs at least two of the three.

Decision checklist

• Security groups tight and default-deny everywhere: free, non-negotiable, start here.
• Public HTTP endpoint (ALB, CloudFront, API Gateway)? Add WAF with managed rules and at least one rate-based rule.
• Serverless stack? WAF yes, Network Firewall almost certainly no.
• Need to control which external domains workloads may call? Network Firewall: nothing else on this list does it.
• DDoS: Shield Standard is already on; price Shield Advanced only against contractual downtime risk.
• Re-check attach points after every architecture change: a new ALB ships with no WAF by default.