Bot protection on AWS: AWS WAF Bot Control, CloudFront and Lambda@Edge compared

If your site or API runs on AWS, there are three places you can stop bots before they reach your servers: AWS WAF rules you write yourself, AWS WAF Bot Control, which is a managed rule group AWS sells on top of AWS WAF, and your own code running at the edge in CloudFront Functions or Lambda@Edge. This article covers what each one catches, what it costs on AWS's published prices, and where a specialist bot management product fits on top.

All prices below are from AWS's own pricing pages, checked on 4 November 2026, in US dollars. AWS changes its prices and free allowances from time to time, so check the linked page before you budget.

AWS WAF basics: rate-based rules, IP sets and managed rule groups

AWS WAF is a web application firewall you attach to a CloudFront distribution, an Application Load Balancer, an API Gateway stage and some other AWS resources. You create a web ACL, which is an ordered list of rules, and each rule allows, blocks, counts or challenges the requests that match it.

On the AWS WAF pricing page a web ACL costs $5 a month, each rule or rule group you add costs $1 a month, and every request the web ACL inspects costs $0.60 per million. A site serving 50 million requests a month through one web ACL with ten rules pays $5 + $10 + $30, which is $45 a month before any of the bot features below.

Three kinds of rule do most of the work against simple bots.

Rate-based rules count requests and act once a client passes a limit. AWS's rate-based rule settings allow an evaluation window of 60, 120, 300 or 600 seconds and a limit as low as 10 requests. By default the count is kept per source IP address, but the aggregation options also let you count per ASN, header, cookie, query argument, URI path, HTTP method, label, JA3 fingerprint or JA4 fingerprint, or a combination of them. Counting per JA4 fingerprint, for example, catches one bot client spread across many IP addresses, as long as it keeps the same TLS setup. AWS notes that the limit is applied "near the limit that you set" rather than exactly.

IP sets are lists of addresses and ranges you block or allow. They are useful for an attack you have already seen in your logs, and they go out of date as soon as the attacker moves.

Managed rule groups are rule sets someone else maintains. Two of AWS's own are aimed at bots, and both are charged only at the standard $1 a month per rule group. The Amazon IP reputation list blocks addresses Amazon's threat intelligence has seen doing malicious work or reconnaissance. The anonymous IP list blocks VPNs, proxies, Tor and hosting providers, with one exception worth knowing: AWS says its hosting provider list "does not include AWS IP addresses", so a bot running on EC2 is not caught by it.

The CAPTCHA and Challenge actions

Instead of blocking a request, an AWS WAF rule can answer it with a CAPTCHA puzzle or a silent Challenge, which is a JavaScript check the browser runs in the background. A visitor who passes gets a token in an aws-waf-token cookie and is not asked again until the token expires.

AWS charges $0.40 per 1,000 CAPTCHA attempts and $0.40 per million Challenge responses served. An attempt is counted whenever a solution is submitted, whatever the result, and the pricing page notes that "a single CAPTCHA response can result in multiple attempts".

Both actions have a limit that matters a lot for APIs and single-page apps. AWS's best practices for CAPTCHA and Challenge say to send them only in response to GET requests that accept text/html, and that "you can't run either the puzzle or the challenge in response to POST requests" or CORS preflight requests. A login form posts its data, so a CAPTCHA rule on the login endpoint itself cannot show a puzzle to the person submitting it. AWS's workaround is to challenge the HTML page that comes before the sensitive request, and then require a valid token on the sensitive request.

AWS WAF Bot Control: Common and Targeted protection levels

AWS WAF Bot Control is a managed rule group called AWSManagedRulesBotControlRuleSet. You add it to a web ACL and pick one of two levels.

Common level: bots that say what they are

AWS describes the Common level as detecting "a variety of self-identifying bots, such as web scraping frameworks, search engines, and automated browsers" using "static request data analysis". Its rules sort bots into categories, including advertising, archivers, content fetchers, HTTP libraries, link checkers, monitoring, scraping frameworks, search engines, SEO tools, social media and AI. Bots it can verify, such as Googlebot, are labelled and let through. Bots that claim a category but cannot be verified are blocked.

Three Common rules look past the bot's own claim: one for signs of an automated browser, one for data centres that bots typically use, and one for user agents that do not look like a browser. The AI category is handled differently from the rest: the CategoryAI rule blocks AI bots "regardless of whether the bots are verified or unverified". If you want AI search assistants to read your pages, override that rule. Our guide to detecting AI agents covers which AI crawlers and agents publish a way to verify them.

The limit of the Common level is in its description: it finds bots that identify themselves or show obvious signs of automation. A script sending a current Chrome user agent from a residential IP address does not trip a category rule.

Targeted level: bots that hide

The Targeted level includes everything in Common and adds rules whose names start with TGT_, which AWS says use "browser interrogation, fingerprinting, and behavior heuristics to identify bad bot traffic". They include:

• TGT_VolumetricIpTokenAbsent, which challenges an IP address that sends 5 or more requests in 5 minutes without a valid token
• TGT_VolumetricSession, which sends a CAPTCHA to a session making an abnormally high number of requests compared with AWS's baselines
• TGT_SignalAutomatedBrowser and TGT_SignalBrowserInconsistency, which look inside the token for signs that the browser is automated or is lying about what it is
• TGT_TokenReuseIp, TGT_TokenReuseCountry and TGT_TokenReuseAsn, which catch one token shared across several IP addresses, countries or networks in 5 minutes
• TGT_ML_CoordinatedActivity, three machine learning rules that look for "low intensity, long-duration bots that are distributed across many IP addresses"

Almost all of these depend on the AWS WAF token. AWS's rule descriptions repeat that "this inspection only applies when the web request has a token", and tokens come either from the CAPTCHA and Challenge actions or from AWS's client application integration SDKs, which exist for JavaScript, Android and iOS. On CloudFront, AWS can now insert the JavaScript SDK into your HTML pages for you, but its own documentation lists cases where the tag is not inserted, including uncached POST responses at high request rates, origins using Origin Shield and cache behaviours with a Lambda@Edge function on origin events. AWS also says that a single-page app which needs tokens on its own API calls should add the SDK itself rather than rely on automatic insertion.

The machine learning rules take time to start working. AWS says they "can take up to 24 hours to go into effect" while AWS builds a baseline of your traffic, and that a match or two "might be false positives".

What AWS WAF Bot Control costs

From the AWS WAF pricing page, checked on 4 November 2026:

These fees are added to the standard AWS WAF charges above. For 50 million requests a month, with Bot Control inspecting all of them, the Bot Control part comes to $10 + 40 × $1 = $50 a month at the Common level, and $10 + 49 × $10 = $500 a month at the Targeted level. AWS recommends a scope-down statement "to contain the costs", for example running Bot Control only on the login page or only on dynamic content, so that images and scripts are not inspected.

AWS also sells Fraud Control rule groups for login and signup pages. They cost $10 a month per web ACL plus a fee per request analysed: the first 10,000 a month are included, then $1 per 1,000 up to 2 million, falling in steps to $0.05 per 1,000 above 30 million. Our credential stuffing page explains why the login endpoint needs its own protection.

Gaps in AWS WAF Bot Control

Bot Control is a reasonable default, and it is cheap at the Common level. The gaps are mostly consequences of how it works rather than missing features:

• Direct API calls and mobile apps. Targeted rules need a token. A bot calling your API without first loading your pages has no token to inspect, and a CAPTCHA or Challenge cannot be shown in reply to a POST or a JSON request. AWS's answer is to integrate its SDK into your web and mobile apps and require a token on API calls.
• Bots that look like browsers. Common level does not see them. Targeted level sees them only through the token, so a bot that runs a real browser and solves the challenge carries a valid token like anyone else, and is then judged on volume, token reuse and the machine learning rules.
• Verified bot checks use the connecting IP address. AWS notes that Bot Control uses the IP address of the web request's origin to verify bots and cannot be set to use a forwarded IP address instead.
• Per-request pricing. At the Targeted level each extra million requests costs $10, so a large scraping attack also raises your Bot Control bill unless a cheaper rule earlier in the web ACL blocks it first.

Running your own bot checks at the edge with CloudFront Functions and Lambda@Edge

CloudFront also lets you run your own code on each request, either to build your own bot checks or to run a bot product's code. AWS's comparison of the two options sets out the differences:

Prices are from the CloudFront pay-as-you-go pricing page and the AWS Lambda pricing page, checked on 4 November 2026.

CloudFront Functions are cheap and fast but cannot make network calls, so they can only judge a request on what is in it, plus up to 5 MB of data held in CloudFront KeyValueStore. They are good for checking a signed cookie or JWT that something else issued, blocking a user agent, or redirecting a path. They cannot ask a scoring service for a verdict.

Lambda@Edge can call out to a service, read the request body and return its own response, so it can run a real bot check. On a viewer-request trigger it runs, in AWS's words, "before it checks to see whether the requested object is in the CloudFront cache", so it sees page and API requests that CloudFront would otherwise have served from cache. Lambda@Edge is billed on run time "from the time your code begins executing until it returns or otherwise terminates", which includes time spent waiting on a network call. A function with 128 MB of memory that averages 20 ms across 50 million requests a month uses 125,000 GB-seconds, about $6.25, plus $30 in request fees.

Building your own check this way puts the detection work on you. You choose the signals, keep block lists current and handle the edge cases. Our engineers found one of those edge cases the hard way: edge functions cannot see the Upgrade and Connection headers, and in our case HTTP/1.1 WebSocket upgrade requests reached the origin without the viewer-request function stopping them. The write-up, A WebSocket upgrade walked straight past our Lambda@Edge, includes the AWS WAF rule that closes the gap. Whichever edge option you choose, keep AWS WAF in front of it for the requests your function cannot see.

Where a specialist bot management product fits

AWS WAF is built around request rules, and Bot Control adds a managed set of them. A specialist bot management product adds a scoring service that looks at the whole session as well as the single request: signals collected in the browser, the TLS fingerprint, how the visitor behaves across pages, and what normal traffic looks like on your site in particular. A product of this kind can connect to CloudFront through a Lambda@Edge function, so a bad request still never reaches your origin.

That is worth paying for when your bot problem is on a route AWS WAF finds hard to protect: an API called directly by scripts, a login or checkout that bots attack from residential proxies, or a scraper that loads your pages in a real browser. Specialist products also cost a good deal more than Bot Control, and few publish a price on their own websites. Our enterprise bot protection pricing comparison lists the figures vendors publish on AWS Marketplace.

How Prosopo Protect runs on AWS

Prosopo Protect runs on CloudFront as a Lambda@Edge function on the viewer-request event, or as a Cloudflare Worker if you use Cloudflare instead. The Protect edge documentation describes how it works:

• Every request is checked at the edge. The function asks the Prosopo Protect API for a verdict and either forwards the request to your origin, serves a captcha challenge, or blocks it with a branded page. Requests that are blocked or challenged never reach your origin.
• Access rules apply before any session exists. Rules on IP range, ASN, IP category, country, user agent and JA4 TLS fingerprint decide what happens to a visitor's first request. The IP categories are Tor, data centre, proxy, VPN, abuser, mobile and crawler, and each can be set to allow, challenge or block. Policy changes apply on the next request, without redeploying the function.
• Pages and APIs are handled differently. You declare which paths serve HTML and which serve JSON. On a JSON path a request without a session gets a 401 rather than being let through, so a bot cannot reach your API by sending an Accept: text/html header.
• It comes in two parts. The Lambda@Edge function scores requests, and a script tag on your HTML pages creates the session and collects the browser signals. Both are needed.
• Deployment. The function is created in us-east-1, as Lambda@Edge requires, and attached to each CloudFront behaviour you want to protect. Protect's API is reached through a protect. subdomain on your own domain, set as a DNS-only CNAME so that the TLS fingerprint comes from the visitor's browser rather than from a proxy. The documentation gives typical API response times of under 40 ms, under 2 ms for cached lookups, with a 500 ms hard timeout, and the function lets requests through on transient errors rather than blocking your visitors.

Every deployment starts with 14 days in preview mode, in which every request is checked and nothing is blocked, so you can see what Protect would have stopped before you switch it on. Pricing is flat: Enterprise starts at $1,990 a month, priced by the number of sites you protect, and traffic is not metered, so a scraping attack does not raise the bill.

Choosing between AWS WAF rules, Bot Control and a specialist

AWS WAF rules alone are enough when the bots are crude: a handful of IP addresses or data centre ranges, an obvious user agent, or one client hammering one path. Rate-based rules keyed on IP address or JA4 fingerprint, the two AWS IP reputation rule groups and a few IP sets will handle that for the price of the web ACL.

Bot Control at the Common level is enough when the traffic you want to manage is mostly bots that announce themselves, such as SEO tools, scraping frameworks, HTTP libraries and AI crawlers, and you want them labelled and handled by category. With 10 million requests a month included, it costs little to try in count mode first.

Bot Control at the Targeted level is enough when your users reach the protected routes through a browser that can run AWS's challenge, or through apps where you can add AWS's SDK, and the bots behind the problem are using automated browsers or high request volumes. Scope it down to the routes that matter, because its request fee is ten times the Common level.

Add a specialist when the bots are getting past Targeted rules, when the routes under attack are APIs called without a browser session, or when a per-request bill makes a large attack expensive twice over. You can keep AWS WAF in front for rate limits, IP reputation and the headers your edge function cannot see, and run the specialist's Lambda@Edge function behind it.