Deployment Considerations - AWS WAF Security Automations

Deployment Considerations

The AWS WAF Security Automations solution is designed to protect web applications and APIs deployed with Amazon CloudFront, an Application Load Balancer, or an Amazon API Gateway. The following sections provide other constraints and considerations for implementing this solution.


The included AWS CloudFormation template should be used as a starting point for implementing AWS WAF rules. We recommend adding custom rules, applying log analysis, and leveraging AWS WAF managed rules, based on your company’s needs.


Web ACL Rules

The web ACL that this solution generates is designed to offer comprehensive protection for web applications. The default configuration adds eight AWS WAF rules to this solution’s web ACL. You can manually modify the web ACL to add further rules, but note that there is a 10-rule limit for individual web ACLs.

IP Match Conditions

AWS WAF can block a maximum of 10,000 IP address ranges in Classless Inter-Domain Routing (CIDR) notation per IP match condition. Each list that this solution creates is subject to this limit. The whitelist, blacklist (manual IP lists component) and third-party IP block list (IP list parsing component) are separate lists, each with a 10,000 IP address limit. See AWS WAF quotas (formerly called limits) in the AWS WAF Developer Guide for more information.

Web ACL Traffic Logging

If you create the stack outside US East (N. Virginia) and set the Endpoint Type as CloudFront, you must set Activate HTTP Flood Protection to no or yes - AWS WAF rate based rule.

The other two options (yes - AWS Lambda log parser and yes - Amazon Athena log parser) require activating AWS WAF Logs on a Web ACL that runs in all AWS Edge Locations and this is not supported outside US East (N. Virginia). For more information about logging Web ACL traffic, see the AWS WAF developer guide.

Endpoint Type Update

You must use blue-green deployment to update the Endpoint Type after creating the stack. Do not manually change the Endpoint Type. Manual change will not grant the stack permissions to switch waf resources to/from waf-regional.

Solution Updates

Version 2.3.0 uses the Node.js 8.10 runtime, which reached end-of-life on December 31, 2019. To continue using this solution with the latest features and improvements, deploy version 2.3.3 as a new stack. For best practice, we recommend that you deploy the highest version that is available.

AWS Regions and Multiple Deployments

This solution includes an AWS CloudFormation template for web applications. The template contains three nested templates: one that deploys AWS WAF for Amazon CloudFront, one that deploys AWS WAF for an Application Load Balancer, and a separate template that includes resources related to AWS Glue, Amazon Athena, and Amazon Kinesis Data Firehose. This solution chooses which nested template to deploy based on the user selected input template parameters. See Step 1, for details about services dependencies.

AWS WAF Global AWS WAF Regional AWS Glue Amazon Athena Amazon Kinesis Data Firehose
Endpoint Type
Application Load Balancer (ALB)
Activate HTTP flood Protection
yes - AWS Lambda log parser
yes- Amazon Athena log parser
Activate Scanners and Probes Protection
yes- Amazon Athena log parser

Customers can deploy the AWS WAF Security Automations solution in different AWS Regions, or deploy it multiple times in the same AWS Region. Note that each unique deployment will incur additional charges.


If you plan to configure multiple instances of this solution in the same Region, you must use a unique AWS CloudFormation stack name and Amazon S3 bucket name for each deployment.

Depending on the input parameters values you define, this solution requires different resources. These resources are listed in the table below, and are currently available in specific AWS Regions only.

Cross-Site Scripting False Positives

This solution configures a native AWS WAF rule that inspects commonly explored elements of incoming requests to identify and block cross-site scripting (XSS) attacks. This detection pattern is less effective if your workload legitimately allows users to compose and submit HTML, for example a rich text editor in a content management system. In this scenario, consider creating an exception rule that bypasses the default XSS rule for specific URL patterns that accept rich text input, and implement alternate mechanisms to protect those excluded URLs.

Additionally, some image or custom data formats can trigger false positives because they contain patterns indicating a potential XSS attack in HTML content. For example, an SVG file might contain a <script> tag. If you expect this type of content from legitimate users, narrowly tailor your XSS rules to allow HTML requests that include these other data formats.

Complete the following steps to update XSS rule in order to exclude URLs that accept HTML as input. See the Amazon WAF Developer Guide for detailed instructions.

  1. Sign in to the AWS Management Console and open the AWS WAF console.

  2. Create a string match or regex condition.

  3. Configure the filter settings to inspect URI and list values that you want to accept against the XSS rule.

  4. Edit this solution’s XSS Rule and add the new condition you created.

    To exclude all URLs in the list, match the highlighted section in green below:

            XSS False Positive

    Figure 3:XSS extra condition to accept services with high false positive rate