AWS WAF, AWS Shield, AWS Network Firewall, and AWS Firewall Manager are often grouped together as “firewall services,” but they operate at different layers and have different responsibilities. AWS WAF inspects web requests. Shield protects against distributed denial-of-service attacks. Network Firewall filters traffic flowing through VPC network paths with stateless and stateful rules. Firewall Manager is the governance layer that can deploy and manage several of those protections across AWS Organizations. Placing each service at the correct layer is a core infrastructure-security skill for AWS Certified Security – Specialty SCS-C03.
The cleanest way to select a control is to identify the traffic and the enforcement point. If the requirement mentions HTTP request properties, web exploits, bot behavior, or application-layer rules at CloudFront or an Application Load Balancer, think WAF. If it mentions volumetric or protocol DDoS protection, think Shield. If it mentions filtering routed VPC traffic, inspection between network zones, or stateful intrusion-prevention rules, think Network Firewall. If the problem is consistent policy across many accounts and resources, think Firewall Manager.
AWS WAF understands web requests
AWS WAF is a web application firewall. It evaluates HTTP and HTTPS requests sent to protected application resources and can allow, block, count, challenge, or otherwise process traffic according to web ACL rules. Rules can match properties such as source IP addresses, URI paths, query strings, headers, request bodies, geographic origin, rate behavior, and known attack patterns.
That application awareness is the reason WAF is well suited to threats such as SQL injection attempts, cross-site scripting patterns, malicious scanners, credential-abuse patterns, and unwanted automated traffic. Managed rule groups can reduce the work required to maintain signatures, while custom rules handle application-specific behavior. Rate-based rules can limit clients that exceed defined request rates.
WAF is not a general VPC packet firewall. It protects supported web-facing resources such as CloudFront distributions, Application Load Balancers, API Gateway REST APIs, AppSync APIs, and other listed integrations. If a workload needs inspection of arbitrary east-west TCP traffic between subnets, WAF is operating at the wrong layer.
Shield addresses DDoS resilience, not normal application authorization
AWS Shield Standard and AWS Shield Advanced provide DDoS protections for AWS resources. Shield focuses on attacks intended to exhaust network, transport, or application capacity through distributed traffic. Shield Standard protections are built into AWS services for common network and transport-layer attacks, while Shield Advanced adds enhanced protections and operational capabilities for customers with more demanding DDoS requirements.
The important design distinction is that Shield is not a substitute for WAF rules. A request can be perfectly valid from a DDoS perspective and still be malicious at the application level. Likewise, a carefully designed WAF does not replace the need for the large-scale DDoS mitigation capabilities provided by AWS infrastructure and Shield. The two services can work together, especially for internet-facing applications where volumetric resilience and application-request filtering are both required.
Architecture reviews should therefore separate availability attacks from application exploits. “Block requests containing a malicious payload” is a WAF problem. “Protect the application from a massive flood intended to exhaust capacity” is a Shield problem. A scenario may require both controls because the threat models are complementary.
Network Firewall inspects routed traffic in and through VPCs
AWS Network Firewall is a managed, stateful network firewall and intrusion detection/prevention service for Amazon VPC. It filters traffic that is deliberately routed through firewall endpoints. The service supports stateless rules that evaluate packets independently and stateful rules that consider traffic in the context of flows. Stateful inspection is based on Suricata-compatible rule processing.
That makes Network Firewall appropriate for centralized egress inspection, ingress inspection, segmentation between network zones, filtering traffic toward internet or hybrid paths, and enforcing protocol or domain-oriented network policy. The architecture must include route-table design so the intended traffic actually crosses the firewall endpoints. A firewall policy that never sees the traffic cannot protect it.
Network Firewall is therefore closer to a conventional network security control than WAF. It works with IP traffic and flow state rather than with the full semantics of a web application request. For readers building the underlying routing model, AWS VPC networking is directly relevant because subnets, routes, gateways, and security groups determine where inspection is placed.
Firewall Manager is the policy-management plane
AWS Firewall Manager does not replace WAF, Shield Advanced, or Network Firewall. It centrally configures and manages protections across accounts and resources in an AWS Organizations environment. A security team can define a policy once and apply it to accounts, organizational units, resources, or tag-selected scopes, then have Firewall Manager maintain coverage as resources are added.
Firewall Manager can manage several protection types, including WAF policies, Shield Advanced protections, VPC security-group policies, Network Firewall policies, network ACL policies, and Route 53 Resolver DNS Firewall policies. That breadth is the clue: Firewall Manager is an organizational governance service for security controls rather than a single packet-processing engine.
For Network Firewall specifically, Firewall Manager can deploy firewalls in distributed or centralized models and apply centrally controlled policies across VPCs. For WAF, it can push required rule groups to protected resources across accounts. This is valuable when the security requirement is consistency at scale and local teams should not have to recreate the same baseline manually.
Choose the control by layer, then decide how centrally to manage it
A public API behind an Application Load Balancer may use WAF to inspect application requests and Shield for DDoS resilience. The VPC that hosts the application may route egress traffic through Network Firewall to prevent workloads from reaching prohibited destinations. Firewall Manager can then ensure that the organization applies the approved WAF and Network Firewall policies consistently across many accounts.
This layered design is better than asking which single service is “best.” Each service protects a different portion of the path. Network security generally fails when one control is expected to solve a problem outside its visibility. WAF cannot inspect private database traffic that never reaches a supported web endpoint. Network Firewall cannot understand every application-level authorization decision. Shield does not decide which authenticated user is allowed to perform a business action.
Firewall fundamentals explain state, traffic direction, and rule intent, but AWS architecture adds a second decision: which managed enforcement point owns each policy and how that policy is governed across accounts and networks. That mapping is what turns general firewall logic into an operable cloud control plane.
Security groups and NACLs still matter beside these services
Using Network Firewall does not make security groups or network ACLs obsolete. Security groups remain stateful controls associated with supported network interfaces and resources. Network ACLs remain subnet-level stateless controls. Network Firewall adds a managed inspection layer that can enforce more sophisticated stateful and stateless network policy on traffic routed through its endpoints.
A layered VPC might therefore use security groups for workload-specific least privilege, Network Firewall for centralized inspection, and WAF for HTTP application traffic. Those controls should be designed so they reinforce one another rather than create conflicting or redundant rule sets that no team fully understands.
For AWS Solutions Architect – Associate SAA-C03 scenarios, the architecture clue is often the enforcement scope. Security groups protect resource-level network reachability. WAF protects supported web applications. Network Firewall protects routed traffic. Shield protects availability against DDoS. Firewall Manager propagates governance across many accounts.
Centralization changes operations as much as security
In a multi-account organization, manually recreating firewall rules in every account creates drift. One application team forgets a managed WAF rule group, another deploys Network Firewall with different defaults, and a third launches a new account that never receives the corporate baseline. Firewall Manager addresses this consistency problem by making policy scope and remediation part of centralized administration.
Centralization still needs change control. A rule pushed to hundreds of resources can cause a much larger outage than a rule changed in one development account. Security teams should stage new policies, use count or alerting modes where available, inspect logs, test representative traffic, and define rollback procedures before broad enforcement. Organization-scale security increases both the value and the blast radius of automation.
Network protections are most useful when they are integrated with the surrounding AWS security services that generate posture and detection signals. A firewall policy is strongest when its logs, findings, exceptions, and ownership are integrated into normal security operations rather than reviewed only during an incident.
Read security scenarios by enforcement point
For SCS-C03, request-level web filtering is the WAF signal. DDoS availability protection is the Shield signal. Stateful inspection of VPC traffic is the Network Firewall signal. Central policy enforcement across many AWS accounts is the Firewall Manager signal. A scenario that includes several of those requirements can legitimately use several services.
Do not choose Firewall Manager when the requirement is simply “inspect this traffic.” It manages other controls; it is not the traffic inspection engine. Do not choose WAF for arbitrary TCP flows. Do not choose Network Firewall when the decisive requirement is to block a malicious query-string pattern at the application edge. Do not describe Shield as a replacement for normal access control.
The durable architecture model is layered: WAF sees web requests, Shield addresses DDoS, Network Firewall sees routed network traffic, and Firewall Manager governs protections across the organization. Once those scopes are clear, the four services stop looking like overlapping product names and become distinct parts of one security architecture.