This page explains what protection packs and web access control lists (web ACLs) are and how they work.
A protection pack or web ACL performs essentially the same function. Both give 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, AWS Amplify, and AWS Verified Access resources. You use protection packs in the new console experience, and web ACLs in the standard console. For more information about the new console experience, see Working with the updated console experience.
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 protection pack or web ACL and in reusable rule groups that you use in your protection pack or 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 protection pack or web ACL, you specify the types of resources that you want to use it with. For information, see Creating a protection pack or web ACL in AWS WAF. After you define a protection pack or web ACL, you can associate it with your resources to begin providing protection for them. For more information, see Associating or disassociating protection with an AWS resource.
NoteOn 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 riskBefore you deploy changes in your protection pack or 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.
Temporary inconsistencies during updatesWhen you create or change a protection pack or 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 protection pack or web ACL, if you try to associate it with a resource, you might get an exception indicating that the protection pack or web ACL is unavailable.
After you add a rule group to a protection pack or web ACL, the new rule group rules might be in effect in one area where the protection pack or 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4