How to Tune AWS WAF with Count, Labels and Rule Priority

2026-07-29T09:15:00+10:00

An AWS managed rule blocks a real customer. You find the request, change the entire rule group to Count and promise to revisit it next week.

Six months later, it is still counting.

AWS WAF lets you change one rule inside a managed rule group to Count, keep the label it adds to matching requests and add a blocking rule immediately after the group. The other managed rules keep their configured actions throughout the investigation.

The general WAF tuning guide explains how to classify the request and document the exception. The AWS configuration begins with the managed rule that matched.

Put the rule in Count

Start with the named rule that caused the false positive.

AWS WAF lets you apply a rule action override to an individual rule inside a managed rule group. Set that rule to Count. The override changes how that rule handles matches in your web ACL; it leaves the managed rule group itself unchanged. AWS describes Count as a non-terminating action, so evaluation continues through the rules that follow. AWS documents individual rule action overrides and the behaviour of Count.

Use the individual override for this job. The older rule-group return override changes the result returned by the group after its internal evaluation. AWS recommends rule action overrides when you want the rules inside the group to count their matches.

Keep the change small:

Record the managed rule group, version and rule name.
Change that rule to Count.
Leave the remaining rules at their current actions.
Reproduce the legitimate request.
Check the Count match and the label added by the managed rule.

AWS Managed Rules add labels to matching requests, and later rules in the same web ACL can inspect those labels. AWS lists labels as the supported way to create exceptions for managed rule groups.

Read the request that matched

The sampled-requests view supports a quick investigation. Full WAF logs provide the history needed to compare matches across users, hosts or endpoints.

With the rule set to Count, look for:

the managed rule name;
its fully qualified label;
host, URI and method;
the matching request component, when AWS supplies it;
the final action taken on the request;
the number of clients and routes producing the same match.

AWS records Count matches from managed rule groups under ruleGroupList[].nonTerminatingMatchingRules. Labels added during evaluation appear in the top-level labels field. AWS populates ruleMatchDetails for SQL injection and cross-site scripting match statements. Other managed detections may provide less detail. The AWS WAF log-field reference describes these fields and their limits.

Treat request data as customer data. Query strings, headers and bodies may contain credentials or personal information. Logging redaction applies to the configured log destination. Web ACL data protection masks matching data before it reaches either logs or sampled requests. Disable sampled requests when they could expose a field that data protection does not cover. AWS explains the distinction in its logging and data-protection guidance.

Group repeated matches by rule name, label, host, path and method. Ask the developer who owns the route what the field means and how the application uses it. Investigate a JSON field containing source code separately from a malformed body that the application accepts.

Block the managed-rule label in the next rule

Suppose a managed SQL injection rule repeatedly matches legitimate messages sent to:

POST api.example.com/v1/messages

The managed rule now runs in Count and adds its documented label. Add a custom rule after the managed rule group. That custom rule should match:

the managed-rule label
AND NOT (
    host = api.example.com
    AND path = /v1/messages
    AND method = POST
)

Give the custom rule a Block action.

Requests that match the managed rule continue to be blocked everywhere except the route you reviewed. On that route, this particular managed-rule match can pass to the rules that follow and eventually to the web ACL's default action.

The order creates the behaviour. AWS WAF evaluates rules from the lowest numeric priority upwards. A later rule can see a label only after the managed rule has added it. Put the managed rule group first and the label-matching rule directly after it. AWS documents both priority order and when labels become available to later rules.

Check the rules that come before the group as well. An earlier Allow or Block action ends evaluation before the managed rule runs. AWS documents Allow and Block as terminating actions, while Count continues to later rules. The rule-action guide explains how actions and priority interact.

The exception covers every field on the exempt route

The label tells you that the managed rule matched. AWS applies the later rule action to that match for the whole request.

On the exempt route, the later Block rule ignores that label regardless of which request field caused the managed-rule match. A different field can trigger the same rule and receive the same exception.

Keep the condition tied to the smallest stable part of the application:

exact host;
exact path or a reviewed path family;
HTTP method;
another server-controlled distinction, when one exists.

A query parameter, header or cookie supplied by the client can narrow which requests match the exception. Confirm the matched request component from the event investigation.

AWS also supports a scope-down statement on a managed rule group. The statement selects which requests enter the group for inspection; every other request bypasses the whole group. Reserve that option for traffic the whole rule group should exclude. AWS describes this evaluation behaviour in its scope-down statement documentation.

Test the complete rule path

Replay this test set:

the original legitimate request on the exempt route;
the same harmless input on another route;
a safe security test that triggers the managed rule on the exempt route;
the same test on another route;
requests that match earlier terminating rules;
normal requests that should pass unchanged.

Then check the WAF logs. Confirm that the managed rule still counts and labels the request, the later rule blocks the label outside the exception, and the final action is the one you intended.

Run the configuration against production traffic in Count while you establish its normal match rate. AWS recommends monitoring metrics, sampled requests and logs, then repeating the tuning cycle until the web ACL behaves as intended. AWS also recommends completing the final stage with production traffic. Its testing guidance lays out that process.

Restore enforcement

The label rule can remain as the enforcement point when the application genuinely needs a route-specific exception. Document:

the managed rule group and version;
the original rule action;
the overridden rule name and label;
the hosts, paths and methods allowed through;
the application owner who confirmed the behaviour;
the requests used to test the change;
the logs and metrics that will reveal a regression;
the next review date.

If the development team removes the input that caused the false positive, remove the custom exception and return the managed rule to its original action. Test that change in Count first, then restore enforcement.

Review the exception after managed rule group updates and application releases. AWS managed groups can use versioned releases, and the label, traffic shape or rule behaviour you investigated may change with the deployed version. AWS publishes the available managed groups, their rules and their labels.