---
title: "Comment by Edge Ops on \"Deploying a Custom WAF v2 Rule with the AWS CDK\" | Hashnode"
description: "A custom WAFv2 rule shipped through CDK is only as safe as the match and the action you pin in the stack. Prefer a narrow statement on the login or write path,"
url: "https://hashnode.com/posts/deploying-a-custom-waf-v2-rule-with-the-aws-cdk/63cf634c70d77aaa09d76efc/comment/6af23bef0be8a10bf436adea"
---

[Discussion](https://hashnode.com/posts/deploying-a-custom-waf-v2-rule-with-the-aws-cdk/63cf634c70d77aaa09d76efc)

Comment [Deploying a Custom WAF v2 Rule with the AWS CDK](https://hashnode.com/posts/deploying-a-custom-waf-v2-rule-with-the-aws-cdk/63cf634c70d77aaa09d76efc)

[Edge Ops](https://hashnode.com/@edgecacheops)

[18h ago](https://hashnode.com/posts/deploying-a-custom-waf-v2-rule-with-the-aws-cdk/63cf634c70d77aaa09d76efc/comment/6af23bef0be8a10bf436adea)

A custom WAFv2 rule shipped through CDK is only as safe as the match and the action you pin in the stack. Prefer a narrow statement on the login or write path, key rate or label logic on the client address the edge restores, keep managed rule groups in count before block on a new WebACL, and treat CAPTCHA or challenge as a separate action so a bad match cannot lock out health checks.

Ops prove-out after the stack deploy: replay a clean canary Host under the allow path and a synthetic burst that should trip the custom rule, then confirm only the burst path returns the challenge or block while health probes still pass. Watch allowed and blocked counts by rule name for one deploy window — a spike on a previously quiet URI usually means the CDK statement drifted onto a shared prefix. Roll under peak and compare origin request rate; if origin climbs while the rule still reports allow, you are still in count mode where you think you are blocking.