AWS WAF Security Automations: a full web ACL template that retires in December 2026

Nine components assembled into one web ACL

The solution deploys a single AWS WAF web access control list containing a set of rules that filter common web based attacks, and the rules are grouped into labelled protection areas. The README notes that the group labels do not reflect the priority level of the rules, so the lettered groups are documentation, not an ordering. AWS Managed Rules cover IP reputation rule groups, baseline rule groups and use-case specific rule groups, which protect against exploitation of common application vulnerabilities and other unwanted traffic, including patterns described in OWASP publications, without writing your own rules. Manual IP lists create two rules where you insert addresses to allow or deny, with support for IP retention and expiry. Two dedicated rules cover SQL injection and cross-site scripting patterns in the URI, query string or body. HTTP Flood protection handles attacks made of a large number of requests from one address, such as a web-layer denial of service or a brute-force login attempt. The result is a web ACL attached to your Amazon CloudFront distributions or Application Load Balancers, inspecting requests before they reach your origin.

Scanner and Probe blocks IPs it infers from your access logs

The Scanner and Probe component works differently from the rest, because it does not rely on a rule pattern matching a request. It parses application access logs looking for suspicious behaviour, such as an abnormal number of errors generated by an origin, and then blocks those suspicious source IP addresses for a customer-defined period. The README describes this as a component that watches the application rather than the request, which is what makes it useful against reconnaissance traffic that never triggers a signature. Two Lambda log parsers feed the bad bot pipeline from this component, one collecting bad bot IPs from log entries during flood analysis and another identifying bad bot IPs from scanner-related log entries. The trade-off is operational rather than technical: the blocking decision depends on logs reaching the parser in a timely fashion, and the retention period is a parameter you own, so a period set too long will eventually block an address that has become legitimate.

Bad bot detection runs four parsers plus a fallback

The Bad Bot component enhances bot detection by monitoring direct connections to an Application Load Balancer or Amazon CloudFront, on top of a honeypot mechanism. If a bot bypasses the honeypot and tries to interact with the load balancer or the distribution, the system analyses request patterns and logs to identify malicious activity, extracts the IP address and adds it to a WAF block list. The README describes this as a structured logic chain, and the chain has five links. The HTTP Flood Protection Lambda Log Parser collects bad bot IPs from log entries during flood analysis. The Scanner and Probe Protection Lambda Log Parser picks up IPs from scanner-related entries. Two Athena log parsers do the same job over the query history, the HTTP Flood one extracting from Athena logs using partitions across the query run and the Scanner and Probe one retrieving from scanner-related Athena logs with the same partitioning strategy. The fifth link is the fallback: if both the HTTP Flood and Scanner and Probe protections are disabled, the system falls back to the Log Lambda parser, which logs bot activity based on AWS WAF label filters. The practical consequence is that turning off the two protections does not turn off bot detection, it changes which mechanism does the work.

IP reputation lists are refreshed hourly

The IP Reputation Lists component is the IP Lists Parser Lambda function that checks third-party IP reputation lists hourly for new ranges to block. The named sources are the Spamhaus Don't Route Or Peer list, the Extended DROP list, the Proofpoint Emerging Threats IP list and the Tor exit node list. The hourly cadence is the design decision worth noting. Block lists sourced from public feeds go stale quickly if they are only refreshed on deployment, and the exit node list in particular changes as Tor relays come and go. The cost of this component is a scheduled Lambda invocation and the resulting WAF rule updates, and the benefit is that a known-bad address range is blocked without a human reading a feed. One thing the README does not describe is how the component reacts when one of the upstream lists is unreachable or changes shape, so the operational behaviour under a failing feed is something to confirm against your own runbook.

Customizing means building from source with four tools

If you want to modify the solution, add custom actions or move to a newer release, you build from the GitHub source rather than launching the template. The documented process is: download the source from GitHub, create Amazon S3 buckets to store the deployment artifacts, build the solution, and upload the artifacts to those buckets in your account. The prerequisites for customization are four tools, and the README lists them precisely: the AWS Command Line Interface, Python 3.12, Poetry v2 and Node 22. The repository layout mirrors the two-phase structure, with a deployment directory for the CloudFormation side and a source directory for the solution code, plus the usual files such as CHANGELOG.md, SECURITY.md, CODE_OF_CONDUCT.md, NOTICE.txt and LICENSE.txt. If you do not intend to modify the solution, the README points you to the solution landing page instead, and installing it means launching the provided AWS CloudFormation template in your account.

The retirement in December 2026 is the headline

The first thing in the README is a notice that Security Automations for AWS WAF will retire in December 2026. After that date, deployments made through CloudFormation or GitHub remain operational, but customers assume responsibility for maintenance and API-related updates. That is the entire adoption question for this repository in 2026, and it comes with a specific piece of advice from AWS about what to use instead: native AWS WAF capabilities, including AWS Managed Rules, native rate-based rules and the AWS WAF Console for configuration and management. The README states that these native capabilities provide superior functionality, better performance, real-time updates and enhanced security features compared to the solution. For the teams still on AWS WAF Classic, there is a migration step first. Deployments of solution versions prior to v3.0.0 used AWS WAF Classic and have to migrate to AWS WAF v2 using the AWS WAF migration documentation, while customers on v3.0.0 or later are already on v2 and can adopt native managed rules and console based management directly. So the sensible use of this code today is as a reference implementation of what a full web ACL looks like, and as a base to fork if you want to keep the log-driven components.

Editorial conclusion

aws-waf-security-automations fits an engineer who needs a complete, opinionated AWS WAF web ACL quickly, who wants the log-driven parts such as scanner blocking and bad bot detection without writing the Lambda functions, and who is on version 3.0.0 or later and therefore already on AWS WAF v2. It does not fit a team that wants a maintained component to depend on, since the solution retires in December 2026 and maintenance passes to the customer, and it does not fit anyone still on a pre-3.0.0 deployment that used AWS WAF Classic. Verify first whether you are on AWS WAF v2, because the README says customers before v3.0.0 have to migrate first, then decide whether the native AWS WAF managed rules, rate-based rules and console cover what this template does. The licence field on the repository says Apache-2.0, and the last push was on 2026-10-13 with release v4.1.7 on the same day.

Frequently asked questions

Official sources

1. aws-solutions/aws-waf-security-automations on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases