Cloud / AWS Firewall Manager Interview questions

AWS Firewall Manager is a security management service that lets you configure and enforce firewall protections centrally across every account and resource in an AWS Organization. You define a policy once, and Firewall Manager applies it wherever it is in scope.

One console covers AWS WAF, AWS Shield Advanced, VPC security groups, network ACLs, AWS Network Firewall, Route 53 Resolver DNS Firewall and supported third-party firewalls.

It also keeps auditing after deployment. When a new account joins the organization or a new resource is created, the policy is applied automatically, and anything that drifts from it is flagged as noncompliant.

Firewall Manager needs a few things in place before the first policy can be created:

1. Your accounts must belong to an AWS Organizations organization with all features enabled.
2. A Firewall Manager administrator account must be designated by the organization's management account.
3. AWS Config must be enabled in every member account and Region you want to protect.
4. Network Firewall and DNS Firewall policies also need AWS Resource Access Manager (RAM) sharing, and third-party firewall policies need an AWS Marketplace subscription.

Shield Advanced policies additionally require a Shield Advanced subscription for the administrator account.

A Firewall Manager policy is tied to exactly one policy type. To enforce several kinds of protection, you create several policies.

WAF Classic policies accept only a single rule group, so new work should use the current AWS WAF policy type.

It is the account you delegate to create and manage Firewall Manager policies for the whole organization. Only the organization's management account can designate it, and a dedicated security or audit account is the usual choice so policy control stays separate from workload accounts.

Designating the account from the management account looks like this:

aws fms associate-admin-account --admin-account 111122223333
aws fms get-admin-account

Rule groups referenced by WAF, Network Firewall and DNS Firewall policies must already exist in this account, because Firewall Manager pulls them from here when it deploys to members.

AWS Organizations gives Firewall Manager the account structure it needs. It tells Firewall Manager which accounts exist, which organizational units (OUs) they sit in, and when accounts join or leave.

Policy scope is built on this data. You can include or exclude whole OUs or individual accounts, and a newly created account inside an in-scope OU picks up the policy without anyone touching Firewall Manager.

The organization must have all features enabled, not just consolidated billing, because Firewall Manager relies on trusted access and the delegated administrator model.

A Firewall Manager policy is the rule set that defines what protection to deploy and where to deploy it. It has two halves: the security service configuration (such as WAF rule groups or a security group baseline) and the scope.

The scope names the accounts and OUs, the resource type, and optional resource tags. The policy also carries settings such as whether to remediate automatically and whether to clean up when resources leave scope.

Each policy is bound to a single policy type, and it is created in a specific Region, so a multi-Region estate usually needs the same policy repeated per Region.

Policy scope decides which resources a policy governs. It is built from four filters that combine together:

• Accounts and OUs to include or exclude
• Resource type, such as an ALB, CloudFront distribution or VPC
• Resource tags, used to include or exclude individual resources
• Region, because each policy is created in one Region

Only resources that match every filter are evaluated. Narrow scope lowers blast radius while you test a new policy, and you can widen it later.

An AWS WAF policy deploys web ACLs to in-scope resources across your organization. It supports resources such as Application Load Balancers, API Gateway stages and CloudFront distributions.

You build it from rule groups, either AWS managed, Marketplace, or your own, and set the default action and logging. Firewall Manager creates a web ACL in each account (named with an FMManagedWebACLV2 prefix) and associates it with the resources.

Member account owners can still add their own rules between the policy's first and last rule groups, so central baselines and team-specific rules coexist.

In a Firewall Manager WAF policy, the rule groups are split into two positions inside the web ACL. First rule groups are evaluated before any rules the account owner adds, and last rule groups are evaluated after them.

Typical use: put non-negotiable protections like a managed baseline or an IP block list in the first group so no local rule can bypass them. Put catch-all rules, such as a rate limit or a default cleanup, in the last group.

The account's own rules sit in the middle, so the central team sets the guardrails while application teams keep flexibility.

A Shield Advanced policy turns on Shield Advanced protection for supported resources in every in-scope account. Firewall Manager also subscribes those member accounts to Shield Advanced automatically, including new accounts that fall in scope.

Protected resource types include CloudFront distributions, Application Load Balancers, Classic Load Balancers and Elastic IP addresses.

The administrator account itself must be subscribed to Shield Advanced before you can create this policy type.

In practice, scope by resource type or tag so Shield Advanced protection lands only where exposure is real. Pair it with a WAF policy on the same ALBs and CloudFront distributions if you also need application-layer filtering.

Firewall Manager offers three security group policy types, each with a different goal.

A common policy or a content audit policy supports one security group each. Use common for enforcement, and the audit types for governance and cleanup.

A typical combination: a common policy attaching a baseline group that allows only corporate management access, a content audit policy that catches teams reopening risky ports, and a usage audit policy run regularly for cleanup.

A Network Firewall policy deploys AWS Network Firewall firewalls and endpoints into VPCs across your organization. You define the firewall policy the same way you would in Network Firewall itself, with stateless and stateful rule groups.

The rule groups must already exist in the administrator account, since Firewall Manager shares them with member accounts.

You choose a deployment model, distributed (a firewall per VPC) or centralized (one shared inspection VPC), and Firewall Manager builds the firewalls accordingly. It can also monitor or remediate the routes that send traffic through the firewall endpoints.

A DNS Firewall policy applies Route 53 Resolver DNS Firewall protections to VPCs across the organization. It associates rule groups, which filter outbound DNS queries by domain list, with every in-scope VPC.

The policy reserves positions at the start and end for the central team's rule groups, leaving the middle for rules that account owners add themselves.

The rule groups live in the administrator account and are shared to members through AWS RAM. Typical use is blocking known malicious domains or restricting workloads to an allow list.

Third-party firewall policies let Firewall Manager deploy partner firewalls across VPCs. Two are supported: Palo Alto Networks Cloud NGFW and Fortigate Cloud Native Firewall (CNF) as a Service.

Before creating one, you subscribe to the vendor's offering in the AWS Marketplace. For Palo Alto, the policy applies Cloud NGFW rulestacks to the in-scope VPCs.

These are still Firewall Manager policies, so they get the same scoping, auto-remediation and compliance reporting as native AWS policy types.

Because the partner runs the firewall itself, rule content is managed in the vendor's tooling, while Firewall Manager decides where the firewall is deployed and makes sure newly created VPCs in scope get it too.

Firewall Manager uses AWS Config to discover resources and detect changes. When Config records a new ALB, a modified security group or a removed web ACL association, Firewall Manager evaluates that change against the policy.

Without Config recording, Firewall Manager cannot see the resources, so policies show as not applying and compliance data is missing. Config must be enabled in each member account and in every Region where you enforce a policy.

Config also adds cost, since you pay for the configuration items it records, which is worth remembering when you plan Regions.

Automatic remediation lets Firewall Manager fix noncompliant resources itself and protect new ones as they appear. With it on, a resource missing its web ACL gets one, and a security group that drifted from the baseline is corrected.

With it off, Firewall Manager only reports which resources are noncompliant and leaves changes to you. This is a good first step on a new policy, so you can see the impact before enforcement.

The console offers both choices: auto remediate noncompliant resources, or identify them without changing anything. For WAF policies you can also opt to remove existing web ACL associations.

Compliance status shows whether each in-scope resource matches what its policy requires. A resource is compliant when the required protection is in place and noncompliant when it is missing or altered.

You can check it at three levels: the policy, the member account, and the individual resource. Noncompliant entries include a reason, such as a missing web ACL association or a security group rule that violates the audit.

The status is refreshed as Config reports changes, so it tracks drift over time rather than a one-time scan.

Resource tags let you narrow a policy to specific resources inside the accounts it covers. You set a tag key and value on the policy, then choose whether it should include resources with that tag or exclude them.

For example, include only ALBs tagged env=prod in a WAF policy, or exclude anything tagged fms-exempt=true for an approved exception.

Tags are read from the resource, so tagging discipline matters. An untagged resource behaves differently under include and exclude, which is a common cause of unexpected scope.

The IncludeMap and ExcludeMap fields in the policy API pick the accounts and OUs it applies to. Each accepts lists of ACCOUNT IDs and ORG_UNIT IDs.

The two are not combined freely. If you set an IncludeMap, Firewall Manager applies the policy only to those entries and does not evaluate the ExcludeMap. If you use only an ExcludeMap, the policy applies to everything in the organization except those entries.

So to cover an OU except one account, use ExcludeMap for that account with no include, or list the wanted accounts explicitly in the include map.

The setup is a short sequence, done partly in the management account and partly in the new admin account:

1. Confirm the organization has all features enabled.
2. Enable AWS Config in every member account and Region you plan to protect.
3. From the management account, designate the Firewall Manager administrator account.
4. Sign in to the administrator account and create the rule groups your policy needs.
5. Create a policy, set its scope, and start with remediation off to review results.
6. Switch on automatic remediation once compliance results look right.

Add RAM sharing and Marketplace subscriptions only if you use Network Firewall, DNS Firewall or third-party policies.

When automatic remediation is enabled, Firewall Manager applies the policy to new resources as well as existing ones. The path is event-driven: a resource is created, AWS Config records it, and Firewall Manager checks whether it matches the policy scope.

If it does, Firewall Manager attaches the required protection, for example associating the managed web ACL with a new ALB or adding the baseline security group to a new network interface.

There is a short delay between creation and protection, because discovery and evaluation are asynchronous. If you need zero-gap protection, pair the policy with a preventive control.

To see this in action, launch an internet-facing ALB in an in-scope account and watch the compliance view. It first appears unprotected, then flips to compliant once the managed web ACL is associated.

AWS WAF is the enforcement engine that inspects web requests. Firewall Manager is the governance layer that deploys and audits WAF, and other services, across many accounts.

In practice you use both: WAF does the filtering, and Firewall Manager makes sure every account has the right web ACL attached.

A handy way to remember it: WAF answers is this request malicious?, while Firewall Manager answers does every account have the right protection switched on? You can use WAF without Firewall Manager, but WAF policies in Firewall Manager depend on WAF.

Shield Advanced is a DDoS protection service. Firewall Manager is the management tool that can turn Shield Advanced on across accounts and keep it that way.

Note that Firewall Manager itself is not a DDoS service, so a Shield Advanced policy is simply how you roll the real protection out at scale.

Shield Advanced also brings features such as Shield Response Team support and cost protection at the account level, and Firewall Manager provides none of those. It only ensures accounts are subscribed and resources are protected.

Service control policies (SCPs) are preventive guardrails on what API actions accounts may perform. They never deploy anything and never grant permissions.

Firewall Manager deploys and audits network protections. It creates web ACLs, security groups and firewalls, and corrects drift.

They work well together. An SCP can deny calls like wafv2:DisassociateWebACL so member teams cannot remove a protection, while Firewall Manager makes sure the protection is present in the first place.

One more difference is reach: SCPs do not affect the management account, so keep workloads out of it.

Another practical split: an SCP can require a tag at resource creation through a request-tag condition, which keeps tag-based Firewall Manager scoping accurate. Firewall Manager alone cannot stop a resource being created untagged.

A content audit policy checks the rules inside security groups against a standard you define, rather than attaching a new group. The standard comes in two forms.

• Managed audit rules: allow or deny lists covering protocols, ports and CIDR ranges, for example disallowing 0.0.0.0/0 on port 22.
• Reference security group: an existing group whose rules act as the template.

Firewall Manager evaluates in-scope security groups and marks violators noncompliant. With auto remediation on, it can remove the offending rules. It supports one security group per content audit policy.

Example: the standard allows only port 443 from the corporate range. An in-scope group that also opens 3389 to the internet is flagged, and remediation can remove that offending rule.

A usage audit policy hunts for clutter in your security groups. It looks for two problems:

• Unused groups: groups not attached to any resource or network interface.
• Redundant groups: groups within the same VPC that contain identical rules.

In audit-only mode it reports them. With remediation on, Firewall Manager can consolidate redundant groups and delete unused ones, and you can set a waiting period before cleanup so short-lived groups are not removed early.

The payoff is a smaller attack surface and more headroom under the per-VPC security group quota.

Run it in audit mode first. Unused groups are sometimes created ahead of a planned deployment, so a report gives owners a chance to claim them before automatic cleanup is enabled.

By default, Firewall Manager creates a new web ACL for every in-scope resource. With the retrofit existing web ACLs option, it reuses web ACLs already attached and creates new ones only for resources that have none.

On a retrofit, the policy's first rule groups are inserted in front of the existing rules and its last rule groups go at the end. Logging is added only if the web ACL has none.

Firewall Manager does not touch other settings such as the default action, custom request headers, CAPTCHA or Challenge configuration, or token domain lists.

Two conditions apply: the web ACL must be owned by a customer account, and it must be associated only with in-scope resources.

Retrofit suits teams that already own web ACLs and would resist replacement. The trade-off is that the account owner's default action stays in force, so a permissive default can still allow traffic your central rules did not explicitly block.

The deployment model in a Firewall Manager Network Firewall policy decides where firewalls live.

Choose distributed for independent VPCs and clear isolation, and centralized when you already run a hub-and-spoke network and want fewer endpoints.

In centralized designs, the spoke route tables must send traffic to the inspection VPC. Firewall Manager can monitor or remediate those routes when route management is enabled, and asymmetric routing is the usual failure to watch for.

Remediation follows an evaluate-then-fix loop. Firewall Manager compares each in-scope resource with the policy, and if it fails the check, the next step depends on the policy's remediation setting.

flowchart TD
  A["Config reports a resource change"] --> B["Firewall Manager evaluates policy"]
  B --> C{Resource compliant?}
  C -- Yes --> D["Mark compliant"]
  C -- No --> E{Auto remediation on?}
  E -- Yes --> F["Apply or repair the protection"]
  E -- No --> G["Report noncompliant only"]
  F --> H["Re-evaluate and update status"]

What the fix looks like depends on the policy type. For WAF it attaches or repairs the web ACL, for security groups it corrects or removes rules, and for Network Firewall it can repair routes to the endpoints.

If a fix fails, for example due to capacity limits, the resource stays noncompliant and the reason appears in the compliance details.

From creation to steady state, a policy moves through a predictable sequence.

flowchart LR
  A["Admin creates policy"] --> B["Scope resolved: accounts, OUs, types, tags"]
  B --> C["Resources discovered through AWS Config"]
  C --> D["Managed resources created, such as web ACLs"]
  D --> E["Protection associated with resources"]
  E --> F["Compliance status reported"]
  F --> G["Drift or new resources trigger re-evaluation"]
  G --> C

1. The administrator saves the policy with its scope and settings.
2. Firewall Manager resolves which accounts and resources match.
3. It creates any managed resources, then associates them with in-scope resources if remediation is on.
4. Compliance is published to the console, notifications and Security Hub.
5. Changes recorded by Config restart the loop, so enforcement continues after the first deploy.

Notice that the loop never ends. Firewall Manager is a continuous control rather than a one-time deployment tool, so removing it after the first rollout lets drift creep back in.

Enforcement is asynchronous and eventually consistent. Creating a policy does not instantly protect resources, because several background steps run in sequence: resource discovery through Config, evaluation, and then any remediation.

In a large organization with many accounts and Regions, this can take minutes, and sometimes longer. During that window the policy may show as pending and some resources may appear with no status yet.

Before assuming a fault, refresh the compliance view after a few minutes and confirm Config is recording. Long delays usually point to missing Config recording or a permissions problem.

You can also gauge progress from the administrator side by comparing the accounts listed in the policy's compliance summary with the number you expect from the scope.

By default, nothing is removed. Firewall Manager leaves the protection it already applied, such as the managed web ACL, even after the resource or account stops matching the scope.

To change that, enable the policy option that removes protections when resources leave scope (DeleteUnusedFMManagedResources in the API). Firewall Manager then disassociates its managed web ACL from the resource and cleans up managed resources it created.

Think about this before changing tags or moving accounts between OUs. A tag edit that pushes a resource out of scope can silently strip protection if cleanup is on.

A good habit is to check which policies reference a tag key before anyone renames or removes it, since tag changes affect scope directly.

Deleting a policy can also remove what it deployed. The API's DeleteAllPolicyResources flag controls this and defaults to true, so Firewall Manager cleans up the resources it created for that policy, such as managed web ACLs and their associations.

To keep the protections running while you retire or replace the policy, delete it without that cleanup:

aws fms delete-policy --policy-id POLICY_ID --no-delete-all-policy-resources

Keep in mind that without the policy nothing will monitor or repair those leftovers, so treat them as unmanaged and plan their removal.

Your own rule groups in the administrator account are not deleted with the policy. Only resources Firewall Manager created on the policy's behalf are removed, so unused rule groups need separate cleanup. Before deleting, export the policy JSON with aws fms get-policy so you can recreate it if the deletion turns out to be premature.

A Firewall Manager policy is created per Region and governs resources in that Region. To protect ALBs in three Regions, you create a policy for each.

Global resources are the exception. CloudFront distributions are managed through policies created in us-east-1.

AWS Config must be recording in each Region where you enforce a policy, and the notification channel for events is also set per Region. When you script policies, loop over Regions explicitly rather than assuming one call covers the estate.

The policy list is Region-specific too, so check coverage with a per-Region call such as aws fms list-policies --region eu-west-1 instead of assuming one listing shows everything. Keep a simple matrix of policy, Region and OU in your runbook so gaps between Regions are easy to spot during reviews.

You have several views, from summary to detail:

• The Firewall Manager console in the administrator account shows policy status and compliance by account.
• The CLI or API lets you script checks.
• SNS notifications push events to your team.
• Security Hub collects findings alongside your other security data.

Two commands cover most CLI needs:

aws fms list-compliance-status --policy-id POLICY_ID
aws fms get-compliance-detail --policy-id POLICY_ID --member-account 444455556666

The first summarizes each account, and the second explains why a specific account is noncompliant.

For follow-up, put a Lambda subscriber on the SNS topic that opens a ticket automatically, so noncompliance gets an owner instead of sitting in a console. Review noncompliance trends weekly, since a sudden rise usually points to a new team, a changed tag convention or a failing Config recorder.

You register an SNS topic as the notification channel, plus an IAM role that Firewall Manager assumes to publish to it. The topic must be in the same Region as the channel.

aws fms put-notification-channel   --sns-topic-arn arn:aws:sns:us-east-1:111122223333:fms-alerts   --sns-role-name fms-sns-publish-role

The role needs permission to publish to the topic and a trust policy that lets Firewall Manager assume it. After that, events such as noncompliance findings reach your subscribers, which can be email, a chat webhook or a Lambda function.

Because channels are per Region, repeat the setup in each Region where you run policies.

A common gotcha is a role or topic policy lacking publish permission, which makes the channel look configured while no messages arrive. Test by creating a known noncompliance in a test account.

Some policy types depend on resources that live in the administrator account, such as Network Firewall and DNS Firewall rule groups. Members cannot use those rule groups unless they are shared.

AWS RAM handles that sharing. Firewall Manager uses it to give member accounts access to the administrator's rule groups so it can attach them to firewalls and VPCs there.

That is why RAM sharing with AWS Organizations must be enabled before you create Network Firewall or DNS Firewall policies. If it is off, those policies fail to deploy, and the error is easy to mistake for a rule group problem.

To verify sharing, look in the RAM console of the administrator account for the resource shares created for the policy, and confirm the shared rule groups are visible in a member account.

Firewall Manager sends findings to AWS Security Hub, so noncompliance appears next to results from GuardDuty, Inspector and other services in one place.

Two kinds are common: policy compliance findings for resources that do not match a policy, and Shield Advanced attack findings when a DDoS event is detected.

This helps because responders can triage through the workflow they already use, with ticketing and automation hooked to Security Hub, instead of watching a separate console. For alerting, combine it with SNS.

To act on findings automatically, attach EventBridge rules to Security Hub findings and trigger a ticket or a remediation runbook for high-severity items. Filter the Security Hub view by the Firewall Manager product to focus on policy violations, and use severity labels to decide what gets paged.

Firewall Manager is billed per policy, per Region, per month. Check the AWS pricing page for the current rate, since numbers change.

That is only part of the bill. You also pay for the services the policies deploy:

• AWS WAF web ACLs, rules and request volume
• Shield Advanced subscription fees
• Network Firewall endpoints and data processed
• DNS Firewall queries
• AWS Config configuration items

Because the policy fee multiplies by Regions, policy count matters more than account count. For many teams the underlying services cost more than Firewall Manager itself.

Example: one WAF policy enforced in two Regions counts as two policies on the Firewall Manager side, before any WAF charges. Splitting one policy into several, or adding Regions, multiplies that fixed fee.

CloudFormation offers AWS::FMS::Policy, and Terraform has an aws_fms_policy resource. Deploy the stack in the administrator account and in the right Region.

The security service settings go in ManagedServiceData as a JSON string, which is the fiddly part. Here is a minimal, abridged example:

Resources:
  AlbShieldPolicy:
    Type: AWS::FMS::Policy
    Properties:
      PolicyName: shield-prod-albs
      RemediationEnabled: true
      ExcludeResourceTags: false
      ResourceType: AWS::ElasticLoadBalancingV2::LoadBalancer
      ResourceTags:
        - Key: env
          Value: prod
      SecurityServicePolicyData:
        Type: SHIELD_ADVANCED
        ManagedServiceData: '{"type":"SHIELD_ADVANCED"}'

Designating the administrator account itself is done from the management account, so keep that step in a separate stack or pipeline.

Watch for drift: if someone edits a managed policy in the console, your template and the live policy diverge. Restrict console changes with IAM and let the pipeline own updates.

Work from the reason Firewall Manager gives, then check the usual blockers.

1. Open the policy's compliance details in the administrator account and find the account and resource.
2. Read the violation reason, such as a missing association or a rule that fails the audit.
3. Confirm the resource type, tags and Region match the policy scope.
4. Check that AWS Config is recording in that account and Region.
5. Look for an existing web ACL that blocks association, or a capacity limit being hit.
6. Rule out a member-side SCP or permission block on the actions Firewall Manager needs.

Fix the cause and wait for re-evaluation, or trigger a change on the resource to speed it up.

Tip: when many accounts share one failure reason, fix it once at policy level. A single bad rule group reference or a capacity problem can explain hundreds of noncompliant resources.

When a policy skips an account, the cause is almost always one of a short list.

• The account or its OU is missing from the IncludeMap, or it sits in the ExcludeMap.
• AWS Config is off or not recording the needed resource types.
• The resource's tags do not match the policy's tag filter.
• The policy was created in the wrong Region, for instance a CloudFront policy outside us-east-1.
• A prerequisite is missing, such as a Shield Advanced subscription or RAM sharing.
• An SCP blocks the actions Firewall Manager performs.

Start with scope, since it is the most common cause, then move to Config and Region.

If everything checks out, compare the account against one that works and look for differences in Config setup, tags or OU placement.

Every web ACL has a web ACL capacity unit (WCU) limit, 1,500 by default, and each rule group and rule consumes some of it. Firewall Manager adds its first and last rule groups to the same web ACL that carries the account owner's rules.

If the combined total goes over the limit, the association or update fails and the resource is reported noncompliant with a capacity error. Retrofitting an existing web ACL is where this bites most, since the account may already use most of its capacity.

To avoid it, check each rule group's WCU before adding it, keep the central baseline lean, and ask for a higher web ACL capacity quota where the need is justified.

For example, a large managed baseline plus several custom rule groups can approach the limit quickly, so record WCU per rule group in your design notes.

Choose Firewall Manager when consistency across accounts matters more than local flexibility. It pays off in a few situations:

• You run many accounts, or new accounts appear regularly.
• Security must enforce a baseline that teams cannot skip.
• Auditors need proof that protections exist everywhere.
• You want drift corrected automatically instead of found in reviews.

Managing per account is reasonable for a single account or a tiny estate, where policy fees and setup effort outweigh the benefit.

Even in a big estate, Firewall Manager complements local tooling. Teams still add their own rules between the central first and last groups.

Consider the operating model too. Firewall Manager needs a small owner team for the administrator account, rule group upkeep and exception review, so budget for that ownership.

Use CloudTrail and AWS Config together. Calls like PutPolicy and DeletePolicy are recorded in the administrator account, which tells you who changed a policy and when.

The resources Firewall Manager then creates or edits in member accounts, such as web ACLs, associations and security group rules, show up in those accounts' CloudTrail events. An organization trail collects them centrally.

Config's resource history adds the before and after state of each change. Together they let you answer whether a policy change or a manual edit caused a given drift.

To make the trail useful, send the organization trail to a central bucket with log file validation enabled, and set up a Config aggregator so investigators can search history across accounts and Regions.

Start by placing the administrator role in a security or audit account, separate from workloads, and structure the rollout around OUs.

1. Create baseline policies at the top-level OUs: a DNS Firewall policy for all VPCs and a common security group baseline.
2. Add WAF policies scoped by tag to internet-facing ALBs and CloudFront distributions.
3. Use a Network Firewall policy in the centralized model if you already have an inspection VPC behind Transit Gateway.
4. Route notifications to SNS and findings to Security Hub.
5. Define exceptions with an exclusion tag and require a review to use it.
6. Manage everything as code and pair it with SCPs that stop members disabling protections.

Roll out in stages, described in the next question on safe rollouts.

Treat it like any production change and expand in stages, with a way back at every step.

1. Report only. Create the policy with remediation off and a narrow scope, such as one test OU.
2. Review the noncompliant list and the reasons, and fix scope or rules that look wrong.
3. Turn on remediation for the test OU and watch application behavior, especially WAF block rates.
4. For WAF rule groups, begin in count mode and switch to block after reviewing sampled requests.
5. Widen scope OU by OU, keeping cleanup options off until you are sure of scope.

Rollback is easy early on: narrow the scope or turn remediation off. It gets harder after cleanup and retrofits, so save those for last.

Document a rollback for each stage, such as narrowing scope or switching a rule group back to count, and agree an observation window with application owners before widening.

Knowing the limits helps you avoid surprises in design reviews.

• It requires AWS Organizations and AWS Config, so it is not for standalone accounts.
• It does not support Amazon Route 53 or AWS Global Accelerator resources.
• Policies are Region-specific, so multi-Region coverage means multiple policies.
• Common and content audit security group policies support one security group each.
• WAF Classic policies take a single rule group.
• Enforcement is eventually consistent, so there is a delay before protection appears.
• It configures and audits protections but does not inspect traffic itself.

Most of these are design constraints rather than blockers, but the Organizations and Config requirements often surface late in enterprise reviews, so raise them at the start. When a limitation blocks a design, such as Regional scope, the usual answer is automation, for example looping policy creation across Regions in a pipeline.

AWS Network Security Manager became generally available on September 24, 2026, in US East (N. Virginia), and AWS documents it as the service replacing Firewall Manager. AWS also says that Firewall Manager users do not need to act now, and that existing policies and firewalls keep operating unless you terminate them.

Today it supports the WAF and SHIELD_ADVANCED firewall types. Security groups, network ACLs, Network Firewall, DNS Firewall and third-party firewalls stay on Firewall Manager for now.

If both services cover the same resource, Network Security Manager takes precedence during remediation. Migration is planned but was not yet available at last check, so verify current status in AWS documentation before designing around it.

The safe interview answer: Firewall Manager remains the tool for policy types Network Security Manager does not cover yet, and teams should watch AWS announcements for migration tooling and added firewall types.

The fee is per policy per Region, so the biggest lever is policy count, followed by what the policies deploy.

1. Consolidate overlapping policies when scope and settings allow it.
2. Enforce only in Regions where you actually run workloads.
3. Scope by OU and tags so you do not deploy protection where it is not needed.
4. Prefer the centralized Network Firewall model when it fits, to reduce endpoint count.
5. Use usage audit policies to remove unused and redundant security groups.
6. Review WAF rule groups and their request costs, since underlying services often exceed the policy fee.

Do not cut protection just to save money. Trim duplication and unneeded scope first.

Track savings in Cost Explorer by filtering on the AWS Firewall Manager service, so you can show the effect of each consolidation step.