Picking Between Network Firewall, WAF, Shield, and DNS Firewall

The situation

An organisation runs a mix of internet-facing and outbound-heavy workloads:

• A customer-facing web app behind CloudFront and ALB, tier-one revenue-bearing.
• A public API on API Gateway for partner integrations.
• A VPC with ~200 EC2 instances in private subnets, NATing outbound to the internet for software updates, package registries, and SaaS API calls. Traffic compliance says outbound must be restricted to approved domains.
• A transit-gateway-attached shared-services VPC that terminates Direct Connect and Site-to-Site VPN, acting as the hub for multi-account east-west traffic.
• A hybrid DNS setup with Route 53 Resolver endpoints.

The security team has a list of worries:

• L3/L4 volumetric attacks on the edge.
• L7 attacks (OWASP, credential stuffing, bot traffic) on the web app and API.
• Outbound egress control from private subnets to enforce domain allowlists and block traffic to embargoed geographies.
• East-west inspection across the TGW, looking for lateral movement.
• DNS filtering to block known-malicious domains at the resolver layer.

Five threats. The services in play are AWS Shield (Standard and Advanced), AWS WAF, AWS Network Firewall, and Route 53 Resolver DNS Firewall. Which does what?

What actually matters

The tempting mistake is to treat the three as tiers of the same thing (Shield is “basic,” WAF is “intermediate,” Network Firewall is “enterprise”) and layer them redundantly. They don’t work that way. They sit at different layers of the stack and see different protocol information.

Layer 3/4 (network and transport) is packets: IP headers, TCP/UDP ports, flags, volumes. Volumetric DDoS attacks live here: SYN floods, UDP reflection amplification, raw bandwidth consumption. The correct defence is at the edge of the AWS network, scaled across Anycast endpoints, running on infrastructure that can absorb terabits per second.

Layer 7 (application) is HTTP: methods, headers, URIs, query strings, bodies, cookies. SQL injection, XSS, credential stuffing, L7 DDoS (high-volume but formally well-formed requests) all live here. The correct defence understands HTTP and can inspect the request’s content.

Stateful network inspection is where things get interesting. A request leaving a private subnet to an embargoed-country IP is well-formed at L3/L4 (the packet is fine) and may never touch HTTP (it could be gRPC, SSH to a hostile bastion, a custom TCP protocol). Blocking it requires a stateful firewall deployed inline in the VPC that inspects traffic against rules beyond just tuples: signature-based intrusion detection, TLS SNI filtering, domain matching on the Host header.

DNS layer is the single earliest point to stop a lot of threats. Malware often resolves a domain (C2 host, exfil endpoint) before it connects. Blocking the resolution at the DNS layer means the malware never gets an IP to connect to; the inspection happens at the resolver, on queries, not on packets or HTTP.

Four layers, four kinds of inspection, and they stack. Edge traffic hits the L3/L4 absorber first, then (if it’s HTTP to a protected resource) the L7 inspector, then reaches the origin. Outbound from a VPC hits the stateful firewall (if deployed inline) and the DNS-layer filter (at the resolver). East-west traffic across a TGW can be hair-pinned through a central inspection VPC. The diagram looks like a layer cake; the rule system at each layer is completely different.

What we’ll filter on

1. Network layer. L3/L4, L7 HTTP, stateful TCP/UDP, DNS?
2. Deployment shape. Inline, attached to an origin, at the edge, at the resolver?
3. Direction. Ingress, egress, or both?
4. Rule model. HTTP pattern matching, signature-based IPS with domain matching, DNS query matching, or AWS-managed edge mitigation?
5. Scope. Per-resource, per-VPC, per-org?

The firewall landscape

1. AWS Shield Standard / Advanced. L3/L4 DDoS mitigation at the AWS edge. Always-on (Standard) or paid with SRT access and cost protection (Advanced). Protects CloudFront distributions, Route 53 hosted zones, Global Accelerator accelerators, Elastic IPs, and ALB/NLBs. Ingress only. No L7 inspection (Advanced bundles WAF on protected resources but doesn’t itself do L7).

2. AWS WAF. L7 HTTP inspection, attached to CloudFront, ALB, API Gateway, AppSync, Cognito user pools, App Runner. Rules match on method, URI, headers, query string, body, cookies, source IP, geo, rate. Ingress (there’s no “outbound” WAF; HTTP egress inspection is a Network Firewall or proxy problem). Per-Web-ACL, per-resource association.

3. AWS Network Firewall. Managed stateful firewall (Suricata-based under the hood) deployed inline in a VPC. Inspects all traffic flowing through an attached subnet in the VPC, in either direction. Rules: stateless 5-tuple match, stateful Suricata rules (signature-based IPS), domain-name lists (block or allow lists, enforced via TLS SNI and Host header for HTTP/HTTPS). Zone-redundant endpoints. Deployed per VPC; integrates with Firewall Manager for org-wide policy.

4. Route 53 Resolver DNS Firewall. DNS-layer filtering on queries going through Route 53 Resolver in a VPC. Domain lists (managed or custom); actions are ALLOW, BLOCK (returning NXDOMAIN or NODATA or an override), or ALERT (log only). Prevents resolution of known-malicious domains before any connection is attempted. Free tier includes AWS-managed domain lists; custom lists and some managed threat-intel feeds are priced.

5. AWS Firewall Manager. Not itself a firewall; the org-wide policy engine that centralises configuration of WAF, Shield Advanced, Network Firewall, DNS Firewall, and security groups across all member accounts. Ensures every account inherits the same baseline (e.g. every public ALB has this WAF ACL attached) without per-account configuration.

6. Security groups and NACLs. Layer 3/4 stateful/stateless packet filtering on ENIs and subnets. Always on, free, the default answer for basic connectivity filtering. Complement to Network Firewall rather than alternative; NACL/SG covers “who can talk to whom”, and Network Firewall covers “what are they saying.”

7. VPC endpoints + endpoint policies. Not a firewall but shapes the firewall problem: routing AWS service traffic over private endpoints means it doesn’t leave the VPC, which means it doesn’t need inspection by Network Firewall. Reduces egress attack surface.

Side by side

Service	Layer	Direction	Rule model	Deployment	Scope
Shield Standard	L3/L4	Ingress	AWS-managed	Edge (automatic)	Per-resource
Shield Advanced	L3/L4	Ingress	AWS-managed + SRT	Edge (opt in)	Per-resource
WAF	L7 (HTTP)	Ingress	Patterns, rate, managed	Attached to resource	Per-Web-ACL
Network Firewall	L3/L4/L7	Ingress + egress	5-tuple, Suricata, domain	Inline in VPC	Per-VPC
DNS Firewall	DNS	Queries (directional)	Domain lists	At Route 53 Resolver	Per-VPC
Security groups	L3/L4	Ingress + egress	5-tuple	Per-ENI	Per-resource
Firewall Manager	(policy)	N/A	N/A	Org-wide	Delegated admin

Reading the table by threat:

• Volumetric DDoS (L3/L4). Shield. Standard is the floor; Advanced if the resource is revenue-bearing enough to justify the subscription.
• OWASP Top 10 / credential stuffing (L7). WAF with managed rule groups on the resource.
• Egress to embargoed IPs / domain allowlist. Network Firewall in the VPC, with domain-name rules enforced via TLS SNI and Host header.
• East-west inspection across TGW. Network Firewall in a centralised inspection VPC, with traffic hair-pinned through it.
• DNS-based malware C2. DNS Firewall at the Route 53 Resolver, blocking known-malicious domains before resolution.

The layered stack

The picks in depth

Shield + WAF for the ingress path. Shield Standard is already on; for the revenue-bearing web app and API, upgrade to Shield Advanced and enroll the CloudFront distribution plus the ALB. Attach a WAF Web ACL to the CloudFront distribution (not to the ALB, because CloudFront is the earlier point and sees more attack traffic). WAF Web ACL stacks: AWSManagedRulesCommonRuleSet, AWSManagedRulesKnownBadInputsRuleSet, AWSManagedRulesSQLiRuleSet, plus a rate-based rule on /login and an AWSManagedRulesAmazonIpReputationList. For the API on API Gateway, a separate Web ACL (Regional scope, attached to the API) with the same managed stack and an API-specific rate limit.

Network Firewall for egress control and east-west. Deploy Network Firewall inline in each VPC that requires egress control. Architecture: dedicated firewall subnet per AZ, route table changes redirecting egress-destined traffic through the firewall endpoint, NAT Gateway downstream of the firewall. Stateful rule group with a domain allowlist (Suricata rule pass tls any any -> any any (tls.sni; content:"approved-domain.com"; sid:1;) or equivalent DomainListAction), geo-block rule, and AWS-managed threat-intel rule groups for known-bad IPs. For east-west inspection across TGW: a central inspection VPC with Network Firewall, TGW attachments in “appliance mode” on the inspection VPC so traffic between spoke VPCs hair-pins through the firewall.

DNS Firewall at the VPC resolver. Enable Route 53 Resolver DNS Firewall on every VPC. Attach two rule groups: AWSManagedDomainsMalwareDomainList (blocks resolution of known-malicious domains) and AWSManagedDomainsBotnetCommandandControl (blocks known C2 domains). Custom allowlist for approved upstream domains (package registries, SaaS APIs); everything else is blocked if the compliance requirement is strict allowlist, or alert-only if the requirement is lighter. The DNS Firewall sits before the packet gets generated. If the resolver refuses to answer, the process doesn’t know where to connect.

Firewall Manager for org-wide consistency. From the delegated admin account, define policies that enforce: every public ALB in any member account has the org’s baseline WAF ACL; every VPC has the DNS Firewall rule groups attached; Shield Advanced is enabled for every tagged-production resource. Violations trigger auto-remediation or Security Hub findings.

A worked egress investigation

11:42 UTC. A Security Hub finding: GuardDuty Trojan:EC2/DNSDataExfiltration on i-0beef. The instance made DNS queries that look like encoded data exfiltration. The DNS Firewall log shows the queries resolving through the VPC’s Route 53 Resolver for a domain that wasn’t on the allowlist; the finding fires because the behaviour is suspicious, even though the domain isn’t on the managed malware list.

11:45. Add the domain to a custom block list in DNS Firewall. Subsequent queries from the instance (or any instance in any VPC where this rule group is attached) return NXDOMAIN. The instance can’t resolve the exfil endpoint.

11:48. In parallel, check Network Firewall logs. The instance has been attempting connections to the IP addresses the DNS queries were previously resolving to. A Network Firewall egress rule blocks the connection (the IP isn’t in the approved CIDR list). Two layers of defence, each visible in logs.

11:55. VPC Flow Logs confirm no successful egress from i-0beef during the incident window. DNS Firewall blocked resolution; Network Firewall blocked the follow-up connection attempts anyway.

Containment succeeds because the egress controls are in place. The DNS layer is the earliest stop; Network Firewall is the deepest stop. Both catch something; either one alone is thinner.

A worked east-west inspection

An EC2 instance in VPC A (dev) talks to an RDS endpoint in VPC B (prod). Prod is supposed to be unreachable from dev; somebody opened a TGW route by mistake.

Traffic path: instance sends packet to TGW via VPC A’s route table, TGW routes to inspection VPC via appliance-mode attachment, inspection VPC’s Network Firewall evaluates the packet against east-west rules, rule matches (dev-VPC-CIDR → prod-VPC-CIDR is in the deny list), packet is dropped, flow logged with REJECT action. The sending process sees a connection timeout.

Without the inspection VPC in the middle, the route-table mistake would have worked: dev would have reached prod because security groups on the prod side allowed the source CIDR. Network Firewall in a centralised inspection VPC catches the case where application-layer controls or security groups are overly permissive, by enforcing the segmentation policy at the network layer regardless of what the VPCs themselves think.

What’s worth remembering

1. Shield, WAF, and Network Firewall sit at different layers. Shield = L3/L4 at the edge, WAF = L7 HTTP on origin-adjacent resources, Network Firewall = stateful inline in the VPC. They stack, they don’t substitute.
2. DNS Firewall is the fourth layer. Route 53 Resolver-integrated, inspects DNS queries before any IP connection. Cheap and effective as a first line against malware C2 and exfil.
3. WAF attaches to CloudFront, ALB, API Gateway, AppSync, Cognito, App Runner. Inside the VPC for unprotected east-west HTTP traffic, Network Firewall is the substitute (though it doesn’t understand HTTP bodies).
4. Network Firewall supports 5-tuple, Suricata, and domain-list rules. Domain-list enforcement uses TLS SNI for HTTPS and Host header for HTTP; TLS 1.3 ESNI/ECH breaks SNI visibility, so plan for that if the upstream adopts it.
5. Security groups remain the first-line L3/L4 filter inside the VPC. Network Firewall adds the stateful content inspection that SGs can’t do.
6. VPC endpoints reduce the firewall surface. AWS service traffic over PrivateLink doesn’t traverse the internet and doesn’t need Network Firewall inspection.
7. Firewall Manager is the org-wide policy layer. Defines baseline firewalls and enforces them across member accounts; the operator of “every public ALB has the correct WAF ACL.”
8. East-west inspection across TGW needs a centralised inspection VPC with appliance-mode attachments. TGW route tables direct traffic through the inspection VPC’s firewall endpoints before delivery to the destination VPC.

Three firewalls, each at a different layer. Knowing which one sees which packet, and which threats live at which layer, is what turns a list of AWS products into a functioning defence-in-depth.