AWS Firewall Manager manages policies; it does not inspect traffic. No packet ever passes through it and no HTTP request is ever blocked by it: it is the control plane that creates, audits and repairs AWS WAF web ACLs, Network Firewall firewalls, security groups and Shield Advanced subscriptions across every account in an AWS Organization. The three services below it do the actual blocking, each at a different point in the traffic path, and most of the confusion in this comparison comes from reading a management tool as a fourth firewall.
Is AWS Firewall Manager a firewall?
No, and the name is the single biggest source of that confusion. AWS Firewall Manager sits entirely outside the data path. You describe an intent once, as a policy: every internet-facing load balancer carries the AWS core rule set, every VPC in these organizational units routes through a Network Firewall endpoint, no security group allows port 22 from anywhere. Firewall Manager then finds the in-scope resources across accounts and makes reality match the policy.
The resources it produces are ordinary ones. A web ACL created by a Firewall Manager policy is a normal AWS WAF web ACL, billed and logged like any other, and it keeps filtering traffic if the policy is later deleted. That separation is the useful mental model: Firewall Manager answers "does every public endpoint in every account carry the baseline", a question no individual firewall can answer about itself, while the firewalls answer "is this specific request allowed".
Where does AWS WAF attach, and what does it block?
AWS WAF is the layer 7 filter. It attaches to CloudFront distributions, Application Load Balancers, API Gateway stages and AppSync APIs, and it reads the HTTP request: method, path, headers, query string, body. That is how it stops SQL injection, cross-site scripting, credential stuffing and abusive request rates, none of which are visible from layer 4, where a request to port 443 is just a request to port 443.
What WAF never sees matters just as much. No raw TCP, no non-HTTP protocol, and no outbound traffic at all: it only inspects requests arriving at endpoints you attached it to. The cost shape is a monthly charge per web ACL and per rule plus a per-million-requests charge, which is why a scattering of small per-account web ACLs costs more in fixed fees than one shared design. We mapped these blocking boundaries in detail in our WAF, Network Firewall and security groups article.
What does AWS Network Firewall see that WAF never will?
AWS Network Firewall lives inside the VPC. You deploy firewall endpoints, one per Availability Zone you want covered, and point route tables at them so traffic physically crosses the appliance. It filters at layers 3 and 4 with stateful rule groups, and Suricata compatible signatures let it match on domain names and TLS SNI, which is how it becomes the only service here that can stop a compromised instance from calling an attacker domain over port 443.
It is also the easiest of the four to deploy pointlessly. A serverless stack where nothing traverses a subnet you control gives it nothing to inspect, and one small VPC rarely justifies the per endpoint hourly charge plus per gigabyte inspection fee that accrue whether traffic flows or not. The design that pays is a shared inspection VPC serving many workloads, which is the same routing conversation as NAT gateways versus VPC endpoints: egress paths are where VPC bills are quietly made.
Not sure whether your accounts need a policy layer or just tighter rules? Describe your system: a one-page diagnosis within 48 hours.
Get my diagnosis →What does Firewall Manager require before it can enforce anything?
Three prerequisites, none of them optional. The accounts must belong to an AWS Organization with all features enabled. A delegated administrator account must be designated for Firewall Manager, so the management account is not the one running day-to-day security. And AWS Config must be enabled in every account and every Region the policies will cover, because Config is how Firewall Manager discovers resources and evaluates compliance.
Only then does a policy mean anything. A WAF policy is submitted through the fms API, and the rule content travels as a JSON string nested inside the JSON body, the detail that breaks most first attempts at automating it.
{
"PolicyName": "org-baseline-waf",
"ResourceType": "ResourceTypeList",
"ResourceTypeList": [
"AWS::ElasticLoadBalancingV2::LoadBalancer",
"AWS::ApiGateway::Stage"
],
"RemediationEnabled": true,
"SecurityServicePolicyData": {
"Type": "WAFV2",
"ManagedServiceData": "{\"type\":\"WAFV2\",\"defaultAction\":{\"type\":\"ALLOW\"},\"preProcessRuleGroups\":[{\"ruleGroupType\":\"ManagedRuleGroup\",\"overrideAction\":{\"type\":\"NONE\"},\"managedRuleGroupIdentifier\":{\"vendorName\":\"AWS\",\"managedRuleGroupName\":\"AWSManagedRulesCommonRuleSet\"}}],\"postProcessRuleGroups\":[]}"
}
}Two fields deserve attention. RemediationEnabled decides whether the policy acts or only reports. ManagedServiceData is a JSON document serialized as a string, so every quote inside it survives two rounds of encoding: build it with a serializer, never by hand.
What policy types exist, and what does remediation actually do?
Firewall Manager ships a closed catalogue of policy types: AWS WAF, Shield Advanced, Network Firewall, Route 53 Resolver DNS Firewall, security group policies in three flavours (a common policy that pushes a shared group, a content audit policy that flags or strips forbidden rules, a usage audit policy that removes unused ones), network ACL policies, and third-party vendor firewalls. You do not write arbitrary logic; you pick a type and configure it.
Remediation is the switch that turns the whole thing from a report into a control. With remediation off, a policy evaluates its scope and lists non-compliant resources: useful, harmless, and the only sane way to start. With remediation on, Firewall Manager creates the missing web ACL, associates it with the load balancer a product team launched an hour ago, and on security group audit policies it deletes offending rules. Run every new policy in report mode first, read what it would have changed, then turn remediation on.
Firewall Manager vs WAF vs Network Firewall vs security groups: the comparison
Four services, one table. Read the first row before anything else, because it settles the argument: three of these inspect traffic and the fourth governs the other three.
| Criterion | Firewall Manager | AWS WAF | Network Firewall | Security groups |
|---|---|---|---|---|
| What it is | Policy manager, no data path | Layer 7 HTTP filter | VPC inspection appliance | Instance level allow list |
| Layer | None; it is management | Layer 7 | Layers 3 and 4, with payload signatures | Layers 3 and 4 |
| Scope | Every account in an Organization | Per web ACL, per attached resource | Per VPC, via routed endpoints | Per network interface |
| What it blocks | Nothing; it blocks configuration drift | SQL injection, XSS, bad bots, request floods | Unwanted flows in and out, including egress by domain | Any IP, port or protocol you did not allow |
| Cost shape | Per policy, per protected resource, per month, plus AWS Config | Per web ACL and per rule, plus per million requests | Per endpoint hour, plus per gigabyte inspected | Free |
| When it wins | Many accounts, uniform baseline, an auditor asking for proof | Any public HTTP endpoint | Egress control and compliance driven inspection | Always; it is the default deny baseline |
Does a single AWS account need Firewall Manager?
Almost never. With one account and one team, the web ACL is already in your infrastructure code, the security groups are reviewed in the same pull request as the resources they protect, and your pipeline is the policy manager. Adding Firewall Manager buys you an Organization you did not need, a delegated administrator account, AWS Config running everywhere, and a second control plane that can silently modify resources your templates believe they own.
The picture inverts as soon as accounts multiply and you stop controlling all of them. When product teams create load balancers on their own, when an account vending machine hands out new accounts every month, or when an auditor wants evidence that every public endpoint carries the same managed rule group, no amount of template discipline proves coverage. That is the moment Firewall Manager pays, and the per policy per resource monthly charge on the Firewall Manager pricing page starts looking cheap next to the alternative. This trade-off, and the choices around it, is what our AWS decisions guide is for.
Decision checklist
- One account, one team: skip Firewall Manager, keep WAF and security groups in your infrastructure code.
- An Organization where you do not control every account: Firewall Manager, with a delegated administrator.
- Confirm AWS Config is on in every account and Region in scope before writing a single policy.
- Start every policy with remediation disabled, read the non-compliance report, then enable it.
- Public HTTP endpoint: AWS WAF. Outbound control by domain: Network Firewall. Neither replaces the other.
- Security groups stay tight regardless; they are free and they are the only layer present on every interface.