Two Major Security Policies of AWS Firewall Manager: Practical & Operational Points for Beginners

Hello. I’m Niwa from Mamezou’s R&D Group. This time, I’d like to introduce the policy settings of AWS Firewall Manager (hereinafter, FMS), one of AWS’s security services.

Recently, in a project I’ve been involved with, we needed to implement AWS Shield Advanced. When managing accounts via AWS Organizations, it is recommended to use Firewall Manager policy settings to bulk-apply Shield Advanced protection to any OU or any accounts. Since the behavior of these policy settings was somewhat confusing, I conducted actual tests and would like to share the results here.

If you’re using Organizations and you want unified DDoS protection and Web ACL application across your organization, are considering introducing AWS Shield Advanced, or want to understand FMS policy behavior in advance—especially if you’re about to start full-scale AWS security operations—this article should be helpful.

In this article, we’ll explain the behavior of the two main security policies provided by FMS, based on actual test results:

• FMS Shield Advanced policy: A policy to centrally apply DDoS protection across the entire organization
• FMS WAF policy: A policy to centrally distribute and apply Web ACL rules across the entire organization

For each policy, we’ll organize the content around three perspectives: “Purpose,” “Mechanism,” and “Key Findings from Testing.” We’ll focus especially on real-world behavior that is hard to grasp from official documentation alone, such as the Auto Remediation feature’s behavior and co-existence patterns with existing Web ACLs (custom-defined Web ACLs).

This article focuses on “testing the behavior of FMS policy settings,” so let’s briefly organize the basics of FMS and the related services that appear during testing, such as WAF, Shield, and others. Further explanations of services appearing later will be provided as needed.

• Those who centrally manage accounts using AWS Organizations
• Those considering the adoption of Shield Advanced
• Those interested in AWS security services and organizational governance
• Those who want to apply common security rules to all accounts using FMS

As mentioned earlier, using Shield Advanced requires creating a Protection for each resource you want to protect. However, manually configuring protection for every resource across multiple accounts managed in AWS Organizations is not realistic.

The FMS Shield Advanced policy solves this problem. From the administrator account (or the delegated administrator account), you simply define a policy saying, “Apply Shield Advanced protection to all ALBs and EIPs in these accounts,” and FMS will detect the target resources and centrally apply protection.

The basic operation flow of an FMS Shield Advanced policy is as follows. Here, the “administrator account” refers to the account that has subscribed to Shield Advanced (usually the same as the Organizations management account).

flowchart TD
    A["Administrator account<br>or FMS delegated account"]
    B["AWS Firewall Manager"]
    C["Member accounts"]
    D_OFF["Detect & report only<br>Recorded as Non-Compliant"]
    D_ON["Automatically create Shield protection"]
    E{"L7 automatic mitigation<br>enabled?"}
    F["Automatically create & attach<br>a Web ACL on ALBs"]
    G["Compliant status"]

    A -->|"① Create policy<br>Define target resources, scope, auto remediation"| B
    B -->|"② Distribute Config Rules<br>Monitor resources without Shield protection"| C
    C -->|"③-a Auto Remediation OFF"| D_OFF
    C -->|"③-b Auto Remediation ON"| D_ON
    D_ON --> E
    E -->|"Yes (for ALB etc.)"| F --> G
    E -->|"No"| G

“Compliant” means that FMS has detected the target resources and applied protection centrally. If Auto Remediation is OFF, FMS only detects and does not add protection, resulting in Non-Compliant.

AWS Config is involved here, so let’s add a brief note:

The most important setting is L7 automatic mitigation (Automatic application layer DDoS mitigation). When enabled, FMS automatically creates a Web ACL rule named ShieldMitigationRuleGroup... in the Web ACL attached to target resources such as ALBs.

The test was conducted by preparing an ALB and an EIP (attached to an EC2 instance) in a member account and applying an FMS Shield Advanced policy from the administrator account.

Test Pattern S-1: Auto Remediation OFF

Result: Expected behavior.

FMS automatically distributed an AWS Config rule to the member account, and this rule detected the absence of Shield protection on the ALB and EIP. In the FMS console, the account status shows Non-Compliant, and each resource also shows Non-Compliant.

Administrator account FMS console:

• Account status is Non-Compliant
  

• Reason for Non-Compliant status on target resources (ALB, EIP)
  

Member account AWS Config console:

• Config rule created by FMS
  

• Detection of non-compliant resources by the Config rule
  

• Viewing the ALB resource’s Config details “Resource Timeline” confirms that the Config rule was applied by FMS
  

Test Pattern S-2: Auto Remediation ON

Result: Expected behavior. (There is a time lag for changes to reflect.)

A few minutes after enabling Auto Remediation, the EIP status became Compliant first. The ALB took a bit longer, requiring a few more minutes to become Compliant.

For the ALB, we also confirmed that the L7 automatic mitigation Web ACL rule (ShieldMitigationRuleGroup...) was automatically created. This behavior is expected as part of the Shield Advanced feature.

Administrator account FMS console:

• Auto Remediation enabled
  

Member account console:

• WAF & Shield console
  FMS-created Web ACLs appear.
  

  The FMS-created Web ACL is not directly associated with the ALB or other resources,
  

  Instead, rules are added to the existing Web ACL. A rule named “ShieldMitigationRuleGroup_...” is appended at the end of the existing Web ACL’s rule list. This is the DDoS mitigation rule.
  

  Because Web ACL rules are evaluated in order, adding it last ensures it does not affect the evaluation of existing rules.

• Config console
  After enabling Auto Remediation, resources became protected and status changed to Compliant.
  
  

The resource timeline also shows that the target resources became part of the Shield Advanced policy protection. (Image omitted.)

Behavior When Deleting the Policy

After testing, deleting the policy resulted in FMS-created Config rules and Web ACLs being properly removed from the member account. Resources that remained immediately after deletion were cleaned up automatically after a short wait.

Administrator account FMS console:

• Deleting the policy
  
  

Member account console:

• WAF & Shield console
  
  

• Config console
  Config rules become “Unavailable” once deleted.
  

AWS WAF is a very powerful service, but ensuring that every account in an organization adheres to common “minimum baseline rules” can be surprisingly difficult. Asking each account administrator to “please apply this configuration” is burdensome for both parties.

The FMS WAF policy allows administrators to define Web ACL settings (rule groups to apply, default action, etc.) as a policy and distribute and apply them organization-wide.

FMS WAF policies have more configuration options than Shield Advanced policies, especially regarding how to handle existing Web ACLs.

Replace vs. Combine

When creating and applying an FMS WAF policy, you can choose between:

• Replacing existing Web ACLs with FMS-managed Web ACLs
• Integrating by sandwiching member account custom rules between FMS-managed rule groups

“Sandwiching” looks like this:

flowchart TD
    subgraph ACL["FMS-managed Web ACL"]
        direction TB
        FRG["🔒 First Rule Groups (evaluated first)<br>Configured by administrators · Members cannot modify"]
        CUS["✏️ Member account custom rules<br>Each account can freely add/edit"]
        LRG["🔒 Last Rule Groups (evaluated last)<br>Configured by administrators · Members cannot modify"]
        DEF["Default Action<br>Allow or Block"]

        FRG --> CUS --> LRG --> DEF
    end

Testing Four Web ACL Management Patterns

In FMS WAF policies, there are several patterns for how to apply Web ACLs to resources. We tested the following four:

We prepared an ALB and a custom Web ACL (test-fms-waf-log) in a member account, then applied settings according to the four patterns to observe behavior.

Test Pattern W-1: Auto Remediation OFF

Result: As expected. The FMS console detected Non-Compliant status, and no changes were made to the ALB.

Administrator account console:

• Relevant settings:
  

Member account console:

• WAF & Config consoles after policy application. A custom Web ACL exists (created beforehand) but is not associated with the ALB.
  

• In the Config console, the FMS-created rule marks the ALB as Non-Compliant because Auto Remediation is OFF and no Web ACL is associated.
  

Administrator account console:

• FMS console after policy application:
  

Test Pattern W-2: Auto Remediation ON, Replace OFF

Result: As expected. The FMS-created Web ACL was automatically associated with the ALB and status changed to Compliant.

Administrator account console:

• Updated settings:
  

Member account console:

• The FMS-created Web ACL is associated with the ALB.
  

• Config rule status changes to Compliant.
  

Administrator account console:

• After a short wait, FMS console shows Compliant for pattern W-2.
  

Test Pattern W-3: Replace ON with Existing Custom Web ACL

This is where it gets interesting. Starting from W-2, where the FMS-managed Web ACL is applied, we manually replaced it in the member account with the custom Web ACL (test-fms-waf-log).

Result: As expected.

Member account console:

• Immediately after assigning the custom Web ACL:
  →
  →
  

Administrator account console:

• Change Replace option to ON:
  

Member account console:

• FMS-managed Web ACL is forcibly re-associated with the ALB.
  

• The custom Web ACL is removed from the ALB.
  

With Replace ON and Auto Remediation enabled, if a custom Web ACL is manually associated, FMS will first remove its managed Web ACL but then forcibly re-associate it, returning to Compliant. This ensures that if operations staff accidentally remove the FMS-managed Web ACL, FMS will restore it. However, it can be disruptive if done intentionally.

Test Pattern W-4: Retrofit (Existing Web ACL Modification) Mode

This is what the “Retrofit existing web ACLs” mode is for.

Starting from W-3 (FMS-managed Web ACL associated), we first changed the FMS WAF policy’s “Replace existing associated web ACLs” option to OFF in the admin account, then manually associated a custom Web ACL. Finally, we updated the policy to Auto Remediation: ON and Retrofit: ON in one update:

flowchart TD
    S["State of W-3<br>FMS-managed Web ACL → Associated with ALB"]
    A["① Update WAF policy in admin account<br>Change Replace option to OFF"]
    B["② Manual operation in member account<br>Associate custom Web ACL with ALB<br>(FMS-managed Web ACL removed)"]
    C["③ Update WAF policy in admin account<br>Auto Remediation: ON<br>Retrofit: ON"]
    D["④ FMS injects<br>First / Last Rule Groups into the custom Web ACL"]
    E["Compliant state<br>Custom rules + FMS rules coexist"]

    S --> A --> B --> C --> D --> E

Result: As expected.

In Retrofit mode, FMS does not create a new Web ACL but injects the FMS WAF policy rule groups (First/Last Rule Groups) into the existing custom Web ACL.

Specifically, the rules defined in the custom Web ACL remain intact, and FMS rule groups defined in the policy (in this case, only First Rule Groups) are inserted in a sandwich formation.

AWS Config status also changes to Compliant, confirming the coexistence of custom rules and FMS rules.

Member account console:

• Pre-test view of custom Web ACL associated with ALB:
  
  

Administrator account console:

• Enable Retrofit with Replace OFF:
  
  

Member account console:

• FMS-managed Web ACL has no resource association:
  

• Custom Web ACL now has FMS rule groups injected:
  
  

Through these tests, we verified the behavior of FMS’s two security policies. The key takeaways are summarized below.

Based on the test results, here are some points to consider when operating FMS security policies:

1. Start with Auto Remediation OFF: Begin in “Detection Only” mode to understand targets before enabling automatic changes.
2. Use the Replace option cautiously: If you already have WAF in operation, Replace ON can remove existing protections. Consider Retrofit mode.
3. Consider the time lag: Policy changes can take several minutes to propagate. Don’t panic if changes don’t appear immediately.
4. Trust cleanup on policy deletion: FMS-created resources are removed upon policy deletion, though it may take a while.

FMS is a convenient service that “protects your entire organization once configured,” but it automatically creates and manages many resources behind the scenes. Focusing on the behavior and automatic settings behind both policy types helps you implement security measures with confidence.

I hope the tests introduced here help you understand Shield Advanced and FMS and assist with your security measures.