This page explains what a web access control list (web ACL) and how it works.
A web ACL gives you fine-grained control over all of the HTTP(S) web requests that your protected resource responds to. You can protect Amazon CloudFront, Amazon API Gateway, Application Load Balancer, AWS AppSync, Amazon Cognito, AWS App Runner, and AWS Verified Access resources.
You can use criteria like the following to allow or block requests:
-
IP address origin of the request
Country of origin of the request
String match or regular expression (regex) match in a part of the request
-
Size of a particular part of the request
-
Detection of malicious SQL code or scripting
You can also test for any combination of these conditions. You can block or count web requests that not only meet the specified conditions, but also exceed a specified number of requests in a single minute. You can combine conditions using logical operators. You can also run CAPTCHA puzzles and silent client session challenges against requests.
You provide your matching criteria and the action to take on matches in AWS WAF rule statements. You can define rule statements directly inside your web ACL and in reusable rule groups that you use in your web ACL. For a full list of the options, see Using rule statements in AWS WAF and Using rule actions in AWS WAF.
When you create a web ACL, you specify the types of resources that you want to use it with. For information, see Creating a web ACL in AWS WAF. After you define a web ACL, you can associate it with your resources to begin providing protection for them. For more information, see Associating or disassociating a web ACL with an AWS resource.
Note
On some occasions, AWS WAF might encounter an internal error that delays the response to associated AWS resources about whether to allow or block a request. On those occasions, CloudFront typically allows the request or serves the content, while the Regional services typically deny the request and don't serve the content.
Production traffic risk
Before you deploy changes in your web ACL for production traffic, test and tune them in a staging or testing environment until you are comfortable with the potential impact to your traffic. Then test and tune your updated rules in count mode with your production traffic before enabling them. For guidance, see Testing and tuning your AWS WAF protections.
Note
Using more than 1,500 WCUs in a web ACL incurs costs beyond the basic web ACL price. For more information, see Web ACL capacity units (WCUs) in AWS WAF and AWS WAF Pricing
Temporary inconsistencies during updates
When you create or change a web ACL or other AWS WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
The following are examples of the temporary inconsistencies that you might notice during change propagation:
After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
After you change a rule action setting, you might see the old action in some places and the new action in others.
After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
