What’s the safest way to move AWS WAF rules from Count to Block?

A conservative alternative is to start with a tightly restricted test deployment and expand access only as legitimate use cases are verified. Keep monitoring after enabling blocks because traffic changes over time, and make sure your test coverage includes workflows that weren’t present in the historical logs. Be especially careful with IP reputation or malicious-IP rules, since shared ISP or corporate addresses can occasionally be listed even when the user is legitimate.

The right action depends on the rule. For a payload-size rule, a small number of endpoints may need a higher limit, while applying an exception globally would weaken protection. For rate-based rules, normal bursts or testing tools may trigger false positives, so review the time window and expected request patterns. For missing User-Agent headers, fixing the client may be safer than allowing the traffic. In some cases, leaving a rule in Count mode and hardening the application is the better choice.

Don’t automatically exempt /my/path just because it was matched. First determine why the rule fired and whether the behavior is expected. If only a specific path and method legitimately need that behavior, use a narrowly scoped exception or scope-down condition for that rule. Avoid broad top-level allow rules, since they can bypass other protections and become difficult to maintain.

Move gradually rather than switching everything to Block at once. Enable one managed rule group at a time, review its per-rule CloudWatch metrics and sampled requests for several days, then change only that group or rule after you understand the impact. A short observation window can miss rarely used but legitimate workflows, so include QA, integration tests, scheduled jobs, administrative paths, and other low-frequency traffic before tightening enforcement.