What Is AWS Firewall Manager? Pricing ($100 per Policy) With Examples, Every Policy Type, Setup, and Firewall Manager vs WAF vs Shield

AWS Firewall Manager is the service that applies the same firewall rules to every account in your AWS Organizations organization from one place, and keeps applying them as new accounts and resources appear. You write a policy once (an AWS WAF rule set, Shield Advanced protection, a baseline security group, a network ACL, an AWS Network Firewall, a Route 53 Resolver DNS Firewall, or a Palo Alto or Fortinet cloud firewall), choose which accounts, organizational units and resource types it covers, and Firewall Manager deploys it, reports which resources are out of compliance and, if you allow it, fixes them automatically. Pricing: $100 per policy per Region per month in most Regions, plus the AWS Config charges its compliance checks create and the normal price of whatever it deploys (web ACLs, firewalls); Firewall Manager policies are included at no policy charge for Shield Advanced subscribers. It is not free, there is no free tier, and it needs Organizations, an administrator account and AWS Config in every account and Region it manages. Below: how it works, every policy type, worked costs, Firewall Manager vs WAF vs Shield vs Network Firewall, setup step by step, CLI and Terraform, logging, and the mistakes that cause noncompliance.

Jake's repair shop now has three branches, and Ethan had given each one its own AWS account: the main shop, the booking site, and a test account that kept turning into a second production. Each account had its own web firewall rules, written at different times by different people, and one of them still allowed a test rule nobody remembered adding. Ethan wanted one set of rules, enforced everywhere, including in the next account someone would create without telling him.

New to multi-account security on AWS? The cards below explain the services Firewall Manager builds on: WAF, Organizations, Config and Security Hub.

What is AWS Firewall Manager?

Most AWS firewall features are per account. A web ACL in AWS WAF protects resources in one account; a security group belongs to one VPC in one account; an AWS Network Firewall sits in one VPC. That is fine with one account. Once a company runs ten, fifty or five hundred accounts, which is the normal way to separate teams, environments and customers on AWS, keeping those rules identical becomes a full-time job, and new accounts tend to appear with no protection at all until someone notices.

AWS Firewall Manager solves that one problem: central management of firewall rules across an organization. It is not a firewall itself. It does not inspect a single packet or request. It is a manager that creates, attaches and watches the real firewalls (WAF web ACLs, Shield Advanced protections, security groups, network ACLs, Network Firewall and DNS Firewall instances, and partner firewalls) in every account you choose, from one administrator account.

Three behaviors make it more than a deployment script:

• It keeps going. When a new account joins the organization, or a new load balancer, API or VPC appears in an account that is in scope, Firewall Manager applies the policy to it automatically.
• It checks. Every in-scope resource is marked compliant or noncompliant, so you can see at a glance which accounts are missing protection or have drifted from the baseline.
• It can fix. With automatic remediation on, noncompliant resources are brought back into line: a missing web ACL is attached, a forbidden security group rule is removed, an unused security group is cleaned up. With remediation off, it only reports, which is the safe way to start.

Do you need it? If you run several AWS accounts and want one security baseline across them, answer to auditors, or already pay for AWS Shield Advanced (which includes Firewall Manager policies without the policy charge), probably yes. If you have a single account with one website, you do not; the WAF console does the same job there for less, and your money is better spent on the rules themselves.

How it works: administrator account, policies, scope and remediation

Four pieces, in the order you meet them:

1. The organization. Firewall Manager works only with AWS Organizations, and the organization must have all features enabled (not just consolidated billing). The organization is the boundary: Firewall Manager can manage any account in it and nothing outside it.
2. The administrator account. The organization's management account names one account as the default Firewall Manager administrator, usually a dedicated security account rather than the management account itself. You can add up to nine more administrators (ten in total), each limited to certain accounts, organizational units, Regions or policy types, so a network team can own Network Firewall policies while a web team owns WAF policies.
3. Policies. Each policy has one type (WAF, security group, Network Firewall and so on), the rules or settings for that type, and a scope: which accounts or organizational units, which resource types (for WAF: CloudFront distributions, Application Load Balancers, API Gateway stages and others) and optionally which resource tags to include or exclude. Policies are Regional, except those for global resources such as CloudFront, which you create in US East (N. Virginia).
4. Compliance and remediation. Firewall Manager uses AWS Config in each member account to see the resources and their settings, compares them with the policy, and marks each one compliant or not. With automatic remediation enabled, it changes the noncompliant ones.

The quotas are generous for most companies: up to 50 Firewall Manager policies per organization per Region by default, up to 2,500 accounts in a policy's scope when you select by organizational unit (200 when you list accounts individually), and organizations of up to 10,000 accounts. Most of these can be raised through Service Quotas.

Every policy type, and what each one does

Each policy has exactly one type, but you can create as many policies of each type as you need (within the quota). A common starter set is one WAF policy for public web resources, one content-audit security group policy that forbids SSH and RDP from anywhere, and one usage-audit policy in report-only mode to see how much clean-up is waiting.

How a WAF policy shares control with account owners

The WAF policy type is the most used, and its design is worth understanding. The policy defines rule groups that run first (before anything else in the web ACL) and rule groups that run last. In between, each account's owners can add their own rules and rule groups to the web ACL that Firewall Manager manages for them. So the security team guarantees the baseline (for example, the AWS managed core rule set and an IP block list run first everywhere), while the team running a particular application can still add the rate limits or exceptions it needs.

For resources that already have a web ACL, you choose: Firewall Manager can replace existing web ACLs with its own, or retrofit them, keeping the existing web ACL and adding the policy's rule groups to it, creating new web ACLs only where none exist. Retrofitting is the gentler way to bring an existing estate under management.

AWS Firewall Manager pricing, with worked examples

"AWS Firewall Manager pricing" and "cost" are the most searched questions about it, and the bill has three parts:

1. The policy charge: $100 per protection policy per Region per month in most Regions (a few Regions charge more). Shield Advanced subscribers pay no policy charge.
2. AWS Config: Firewall Manager relies on Config rules and configuration items in each member account. Configuration item changes cost $0.003 each and rule evaluations $0.001 each, with lower rates at high volume.
3. The resources it deploys, at their normal prices: AWS WAF web ACLs ($5 per web ACL per month plus $1 per rule per month, plus request charges), Network Firewall endpoints ($0.395 per endpoint-hour plus $0.065 per GB processed), DNS Firewall ($0.60 per million queries plus a small per-domain charge), and Marketplace pricing for third-party firewalls.

The examples AWS publishes show how those parts combine:

Three lessons sit in that table for your own budget. First, you pay per policy per Region, not per account, so Firewall Manager gets cheaper per account the more accounts your policy covers. Second, for Network Firewall and DNS Firewall policies, the protected service dwarfs the Firewall Manager charge; budget for the firewall, not the manager. Third, a policy you run in three Regions costs you three times $100, which is why you should pick your Regions deliberately and use Service Control Policies to keep workloads out of the rest.

Is AWS Firewall Manager free?

No. There is no free tier and no trial. The only way to avoid the policy charge is a Shield Advanced subscription, which costs $3,000 per month per payer account on a one-year commitment and includes Firewall Manager policies, plus AWS WAF usage for protected resources (up to a large request allowance), without the per-policy charge. That only makes financial sense if you want Shield Advanced's DDoS protection anyway; at fewer than 30 policies, paying $100 per policy is cheaper than subscribing for the discount.

What Jake's three accounts would cost

Ethan's plan: one WAF policy covering the three accounts' load balancers and CloudFront distribution, in one Region plus the global (US East) policy for CloudFront, and one content-audit security group policy in the main Region. That is three policies: $300 a month in Firewall Manager charges, plus roughly $6 per web ACL in WAF and a few dollars of Config. For three accounts, that is more than the WAF rules themselves, and Ethan said so: for a business this size, a tidy WAF setup copied with infrastructure code is the cheaper answer. Firewall Manager starts paying for itself when the accounts number in the dozens, or when a new account appearing unprotected is a risk the business cannot accept.

Firewall Manager vs WAF vs Shield vs Network Firewall vs Security Hub

"AWS WAF vs Shield vs Firewall Manager" is a common confusion, because the services are related and AWS often mentions them together. Here is what each one does:

The short version: WAF and Network Firewall are the firewalls, Shield is the DDoS layer, Firewall Manager is the remote control that puts them everywhere, and Security Hub is the dashboard that tells you what is wrong. Firewall Manager sends its compliance findings to Security Hub, so the two work together rather than overlapping.

WAF vs Network Firewall

The two firewalls answer different questions. WAF understands web requests: it can see that a request to /login carries a SQL injection attempt or comes from a bot, but it only sees HTTP and HTTPS traffic reaching the resources it is attached to. Network Firewall sees every packet entering or leaving a VPC, of any protocol, and can block a server from connecting to a known command-and-control domain, but it does not understand application logic the way WAF does. Most organizations with both public web apps and sensitive VPCs use both, and Firewall Manager can manage both. Our AWS WAF guide covers the web side in depth.

Before you start: the prerequisites, in order

Firewall Manager has more setup steps than most AWS services, and they must happen in this order:

1. AWS Organizations with all features. Every account you want to manage must be in the organization. If your organization was created for consolidated billing only, enable all features first (each member account has to approve). Our AWS Organizations guide walks through the structure.
2. Set the Firewall Manager administrator account. From the organization's management account, open the Firewall Manager console and designate the administrator. A dedicated security or network account is the usual choice, so day-to-day firewall work does not happen in the management account.
3. Enable AWS Config in every member account and every Region where you will have policies, recording at least the resource types your policies cover. This is the step that breaks most first attempts: without Config in an account, Firewall Manager cannot see its resources, and they never show as compliant or noncompliant. A CloudFormation StackSet deployed to the whole organization is the usual way to switch it on everywhere at once, and AWS Control Tower turns Config on in the accounts it enrolls.
4. For third-party firewall policies, subscribe to the Palo Alto Networks Cloud NGFW or Fortinet FortiGate CNF listing in AWS Marketplace and complete the vendor's onboarding.
5. For Network Firewall and DNS Firewall policies, enable resource sharing with AWS Organizations in AWS Resource Access Manager (RAM), because Firewall Manager shares rule groups from the administrator account to members.
6. For Regions that are disabled by default (opt-in Regions), enable the Region in the accounts concerned before Firewall Manager can manage resources there.

Config deserves a note on cost. Firewall Manager needs continuous recording of the resource types it manages; daily recording, which some teams pick to save money, is not enough for it. Our Config pricing guide shows how to record only the resource types you need, which keeps the Config line small even with continuous recording.

Set up your first WAF policy, step by step

With the prerequisites done, a WAF policy for public load balancers takes about ten minutes in the console, signed in to the Firewall Manager administrator account:

1. Open AWS Firewall Manager (it lives in the AWS WAF and Shield area of the console), choose Security policies, then Create policy.
2. Choose the policy type AWS WAF and the Region. For CloudFront distributions, choose Global, which is managed in US East (N. Virginia).
3. Name the policy and add first rule groups: for a baseline, the AWS managed rule groups such as the core rule set, known bad inputs, and an IP reputation list. Add any last rule groups you want to run after account owners' rules.
4. Choose the default action for requests that match no rule (usually Allow), and turn on logging to a central destination if you want one place to search blocked requests (see the logging section).
5. Choose what happens to existing web ACLs: replace them, or retrofit them by keeping them and adding the policy's rule groups.
6. Set the policy action: start with Identify resources that don't comply (report only). Switch to Auto remediate after you have reviewed the findings.
7. Define the scope: all accounts, or chosen organizational units or accounts; the resource types (Application Load Balancer, API Gateway REST API stages, and so on); and optional tags to include or exclude resources.
8. Review and create. Within a few minutes, every in-scope account appears under the policy with its compliance status.

The report-only start matters. Auto-remediation on a WAF policy changes which requests reach production applications in every in-scope account at once. Seeing the list of noncompliant resources first, and ideally running new rule groups in Count mode for a few days (rule groups can override their actions to count), avoids blocking real customers across the whole company with one click.

Firewall Manager with the AWS CLI and Terraform

The API calls are under aws fms, run from the administrator account. Checking setup and compliance:

# which account is the Firewall Manager administrator?
aws fms get-admin-account

# every policy in this Region, then the compliance summary for one
aws fms list-policies --query "PolicyList[].{Name:PolicyName,Id:PolicyId,Type:SecurityServiceType,Remediation:RemediationEnabled}" --output table
aws fms list-compliance-status --policy-id POLICY_ID \
  --query "PolicyComplianceStatusList[].{Account:MemberAccount,Status:EvaluationResults}"

# exactly which resources in one account are out of compliance, and why
aws fms get-compliance-detail --policy-id POLICY_ID --member-account 111122223333

Policies are created with put-policy. The type-specific settings go in ManagedServiceData, a JSON document passed as a string. For a WAF policy that runs the AWS managed core rule set first and logs to a central S3 bucket, the managed service data looks like this:

{
  "type": "WAFV2",
  "preProcessRuleGroups": [{
    "ruleGroupType": "ManagedRuleGroup",
    "managedRuleGroupIdentifier": { "vendorName": "AWS", "managedRuleGroupName": "AWSManagedRulesCommonRuleSet", "version": null, "versionEnabled": null },
    "overrideAction": { "type": "NONE" },
    "excludeRules": [],
    "sampledRequestsEnabled": true
  }],
  "postProcessRuleGroups": [],
  "defaultAction": { "type": "ALLOW" },
  "overrideCustomerWebACLAssociation": false,
  "loggingConfiguration": { "logDestinationConfigs": ["arn:aws:s3:::aws-waf-logs-central-example"], "redactedFields": [] },
  "sampledRequestsEnabledForDefaultActions": true
}

In Terraform, the same policy is an aws_fms_policy resource, with the JSON produced by jsonencode so it stays readable:

resource "aws_fms_policy" "waf_baseline" {
  name                  = "waf-baseline-public-albs"
  exclude_resource_tags = false
  remediation_enabled   = false          # report only at first
  resource_type         = "AWS::ElasticLoadBalancingV2::LoadBalancer"

  include_map {
    orgunit = ["ou-ab12-cdefgh34"]
  }

  security_service_policy_data {
    type = "WAFV2"
    managed_service_data = jsonencode({
      type = "WAFV2"
      preProcessRuleGroups = [{
        ruleGroupType             = "ManagedRuleGroup"
        managedRuleGroupIdentifier = { vendorName = "AWS", managedRuleGroupName = "AWSManagedRulesCommonRuleSet" }
        overrideAction            = { type = "NONE" }
        excludeRules              = []
      }]
      postProcessRuleGroups             = []
      defaultAction                     = { type = "ALLOW" }
      overrideCustomerWebACLAssociation = false
    })
  }
}

Run Terraform from the administrator account (or with a provider that assumes a role there). In CloudFormation, the resource type is AWS::FMS::Policy. A security group usage-audit policy in report-only mode, a useful first policy for any organization, needs only this as its managed service data:

{ "type": "SECURITY_GROUPS_USAGE_AUDIT", "deleteUnusedSecurityGroups": true, "coalesceRedundantSecurityGroups": true, "optionalDelayForUnusedInMinutes": 60 }

With remediation disabled on the policy, those settings describe what would be cleaned up; the compliance report lists the unused and redundant groups without touching them.

Security group policies: the three kinds, and how to use them safely

Security groups are where Firewall Manager saves the most manual work, and where automatic remediation can do the most damage, so the three kinds are worth knowing well.

• Common security group policies take one or more primary security groups from the administrator account, replicate them into each in-scope account and VPC, and attach them to the in-scope resources (EC2 instances and network interfaces, Application and Classic Load Balancers, and more). Options control whether manual changes to the replicas are reverted and whether the policy's groups must be the only ones attached.
• Content audit policies compare every in-scope security group's rules with a reference: either rules that are allowed (anything outside them is noncompliant) or rules that are denied (anything matching them is noncompliant). The classic use is "no inbound 22 or 3389 from 0.0.0.0/0".
• Usage audit policies find security groups that nothing uses and groups that are exact duplicates, and can delete or merge them after a delay you choose.

Practices that keep these policies safe:

• Exclude the administrator account from security group policy scope (the console does this by default for usage audits).
• Start with remediation off for content and usage audits, read the findings, and only then turn remediation on.
• Avoid fights with other tools. If another service or script also manages the same security groups, and both sides auto-correct, they can undo each other's changes in a loop. Use tags to exclude groups managed elsewhere.
• Know the gaps. Changes to security groups on EC2 network interfaces can take several hours (up to six) to show up; ENIs created by Amazon RDS, Fargate and Network Load Balancers, and requester-managed ENIs, cannot be updated by these policies; and groups shared through AWS RAM are not supported.

Network Firewall and DNS Firewall policies

For VPC traffic, Firewall Manager can roll out AWS Network Firewall in two ways. In the distributed model, it creates firewall endpoints in each in-scope VPC, in Availability Zones it chooses or you specify, and can optionally monitor or manage the routes that send traffic through them. In the centralized model, it places the firewall in one inspection VPC per account, which pairs naturally with a transit gateway hub design. Either way, the policy references stateless and stateful rule groups shared from the administrator account, and can send alert and flow logs to S3, CloudWatch Logs or Firehose.

Route management is the setting to approach carefully. In monitor mode, Firewall Manager reports VPCs whose routes bypass the firewall; in the managing modes it changes route tables itself. Bad route changes break connectivity for every VPC in scope, so begin in monitor mode and read the findings. If your VPCs connect through a transit gateway, our Transit Gateway routing guide explains the route tables involved.

DNS Firewall policies are simpler: they associate up to two Route 53 Resolver DNS Firewall rule groups with in-scope VPCs, placed before or after any rule groups the account adds locally. The effect is that every VPC refuses to resolve the domains on your block lists, which stops a lot of malware from reaching its controllers. Our guide to Route 53 and Route 53 Resolver explains where DNS Firewall sits.

Logging: one place for every blocked request

"Firewall Manager logging" usually means WAF logs. A WAF policy can set one central logging destination for every web ACL it manages, so blocked and counted requests from all accounts land in one place: an Amazon Data Firehose stream or an S3 bucket in the account you choose (S3 bucket names for WAF logs must start with aws-waf-logs-). You can redact up to 20 fields, such as authorization headers, and filter logs to keep only blocked or challenged requests, which saves a lot of storage.

Network Firewall policies configure alert and flow logs the same way. And beyond the firewalls' own logs, Firewall Manager's own activity (policy changes, remediation actions) is recorded by AWS CloudTrail in the administrator account, and its compliance findings go to AWS Security Hub. Between the three, you can answer an auditor's "show me that every account had the baseline on that date" without logging in to each account.

Shield Advanced policies

If your organization subscribes to Shield Advanced, Firewall Manager is how you apply it consistently: a Shield Advanced policy enrolls in-scope resources (CloudFront distributions, load balancers, Elastic IP addresses, Route 53 hosted zones and Global Accelerator accelerators) as protected resources in every account. For CloudFront distributions and Application Load Balancers, the policy can also turn on automatic application-layer DDoS mitigation, in Count or Block mode, which creates and manages the WAF rules Shield uses to respond to an attack. Starting in Count mode, as with every other policy type here, shows what Shield would have blocked before it blocks anything.

If you are deciding whether Shield Advanced is worth it, do the arithmetic both ways. You pay $3,000 a month for the subscription, and in return you get DDoS cost protection, access to the Shield Response Team during an attack, WAF usage on protected resources and Firewall Manager policies without the policy charge. If you already spend a lot on WAF across many accounts and run more than a couple of dozen Firewall Manager policies, the bundle can cost less than paying for the pieces separately. If you mainly want consistent WAF rules, it will not.

Should you use Firewall Manager? A quick decision guide

Answer these four questions about your own setup:

1. How many AWS accounts do you run? With one to five, you can usually keep firewall settings in step with infrastructure code for less than $100 a policy. With dozens or hundreds, you will spend more time chasing drift than Firewall Manager costs.
2. Do new accounts appear without you knowing? If teams can create accounts through a vending process or Control Tower, an account that starts life unprotected is a real risk, and automatic application to new accounts is the feature you are paying for.
3. Do you have to prove compliance? If auditors ask you to show that every public web application had a WAF and that no security group allowed SSH from anywhere, the compliance view and Security Hub findings save you days of evidence gathering.
4. Do you already pay for Shield Advanced? Then you have Firewall Manager policies without the policy charge, and not using them wastes part of what you bought.

If you answered yes to two or more, Firewall Manager is likely worth it for you. If you answered no to all four, a well-written Terraform or CloudFormation module that you apply to each account will give you most of the consistency for a fraction of the cost, and you can move to Firewall Manager later without throwing that work away, because the rule groups you write can become the rule groups a policy uses.

Rolling it out without breaking production

The safest way for you to introduce Firewall Manager into an organization that already runs production traffic is in stages, over a few weeks:

1. Week 1, foundations. Set the administrator account, switch on Config recording everywhere it is missing, and confirm that each account appears in the Firewall Manager console. Nothing changes for your applications yet.
2. Week 2, report only. Create your first policies (a WAF baseline, a content audit for open SSH and RDP, a usage audit) with remediation off. Read the compliance reports with the teams that own the accounts, and agree on exceptions, which you mark with an exclusion tag.
3. Week 3, count mode. Turn on remediation for the WAF policy in a sandbox organizational unit, with new rule groups overridden to Count. Watch the central WAF logs for requests that would have been blocked, and fix false positives before they ever block anyone.
4. Week 4, enforce. Switch the counted rules to Block, extend remediation to the remaining organizational units one at a time, and turn on remediation for the content audit policy. Leave the usage audit in report-only mode until the account owners have reviewed what it would delete.

Keep a written rollback plan for each step: which policy setting you will flip back, and who can do it. The fastest rollback for a WAF policy is to switch its remediation off and its new rule groups to Count, which you can do in minutes from the administrator account.

Best practices that save money and outages

• One administrator account for security, separate from the management account, with delegated administrators for teams that own particular policy types.
• Report first, remediate second for every new policy, and change remediation on one organizational unit (such as a sandbox) before the rest.
• Count before block for new WAF rule groups, using rule action overrides, then switch rules to block once the logs look clean.
• Few, well-scoped policies. At $100 per policy per Region, ten narrowly scoped policies where three broad ones would do adds $700 a month for no extra protection.
• Tags for exceptions, not separate policies: exclude resources with a tag such as fms-exempt, and audit who uses it.
• Control Regions with Service Control Policies, so workloads cannot appear in Regions where you have no policies.
• Policies in code (Terraform or CloudFormation), reviewed like any other change, because one policy edit can change protection in hundreds of accounts.

Common problems and what causes them

• Accounts show no compliance status at all: AWS Config is not enabled or not recording the needed resource types in that account and Region, or the account is not in the policy's scope.
• "Firewall Manager administrator account is not set" or the console will not open policies: you are signed in to the wrong account; policies are managed from the administrator account, not the management account (unless they are the same).
• A WAF policy shows resources noncompliant after remediation: a web ACL already associated with the resource was not replaced, because the policy is set to keep existing associations; choose replace or retrofit.
• CloudFront distributions are not covered: CloudFront is global, so the policy must be created with the Global Region setting, managed in US East (N. Virginia).
• Network Firewall or DNS Firewall policies fail to deploy: resource sharing with Organizations is not enabled in AWS RAM, or the rule groups are not shareable.
• Security group changes are not detected for hours: changes on EC2 network interfaces can take up to six hours to appear; this is expected.
• Remediation keeps undoing someone's change: another tool manages the same security groups or web ACLs; exclude them with tags so the two stop fighting.
• The bill is higher than expected: count policies per Region, and look at the deployed resources (Network Firewall endpoints especially) rather than the Firewall Manager line.

Frequently asked questions

Ethan did not switch Jake's three accounts to Firewall Manager. He wrote the WAF rules once in Terraform and applied the same module to all three accounts, which costs a few dollars a month. But he kept the plan in a folder named "when there are ten accounts", because the shop's owner had started talking about franchises, and the first franchise account, created without telling anyone, would be exactly the problem Firewall Manager exists to solve.

Revision note. Written October 21, 2026. Prices are US list prices on that date; some Regions charge more per policy. We will update this page when policy types, quotas or prices change.