Nimbostratus
NimbostratusNot an answer, but a follow on. This problem means that I can't use more than 1 of your managed rules groups without going over the default capacity of the AWS WAF ACL. Since AWS sets that capacity quota per ACL I can't automate the creation of WAFs with multiple managed groups. For that reason we are no longer going to use the F5 managed rules until this is rectified.
MVPI tested the AWS WAF default managed rules with burp suite professional web scanner and they are good enough for basic OPSWAT top 10 protection. AWS WAF as a whole is for not so critical sites as its flexibility with false positives is really bad (you to set the action to 'count'' for the subrule group that makes a security hole or create a custom allow rule with higher priority but as you don't know from the logs exactly what part of the request causes the false positive and you can't directly view the F5 AWS WAF rules or the Native AWS WAF rules you are making the custom allow rule hoping you are not making again a security hole) and the Bot protection can be hacked by just using User-Agent header value like the one for Chrome etc. If you want to protect something really important the AWS WAF is not the solution in my view.
Edit:
You can for example attach bot protection rules under AWS Cloudfront and after that attach the OPSWAT rules under an AWS Application load balancer or even make two application load balancers one after another but yes this is a bad workaround.