Web application firewall with bot control

AWS WAF

AWS WAF is Amazon Web Services' managed web application firewall. Site operators attach it to AWS edge and origin services such as CloudFront distributions, Application Load Balancers, and API Gateway, where it evaluates every HTTP request against a configurable web ACL before the request reaches the application. Its optional Bot Control managed rule group extends the base firewall from generic request filtering into dedicated bot detection and mitigation.

How it decides what to block

At the base layer, AWS WAF matches request-level attributes - source IP, headers, geography, URI patterns - and applies rate-based rules that track request volume per IP. AWS-managed rule groups add IP reputation gating: the Amazon IP reputation list and Anonymous IP list classify traffic from ranges associated with hosting providers, VPNs, proxies, and known bot infrastructure, and can block or challenge on IP class alone, before any page content renders. The Bot Control rule group adds signature-based detection of self-identifying and common bots at its basic level, and at its targeted level adds client-side interrogation: a silent browser challenge or visible CAPTCHA issues a token that must accompany subsequent requests, while device and browser signals plus behavioral patterns are used to separate automated sessions from human ones. Each rule can allow, count, block, serve a CAPTCHA, or run a silent challenge, so operators tune how aggressively suspicious traffic is gated.

What IP class it takes

Because AWS WAF's managed reputation lists categorize datacenter, VPN, and anonymizer ranges wholesale, and rate-based rules count per source IP, legitimate large-scale collection against this class of protection generally requires IP space that is not pre-flagged as hosting infrastructure - in practice, real carrier-grade mobile IPs, which sit behind CGNAT shared with millions of legitimate phone users and are therefore the hardest class to blocklist wholesale, or clean residential addresses with auditable provenance such as physically-owned carrier modems and opt-in paid peers. Whatever IP class is used, respect robots.txt, the target site's Terms of Service, and applicable law, and collect only data you are permitted to collect.

Sites observed using AWS WAF

Observed via public response signatures, reviewed July 2026. Read-only reference.

Responsible use. This is a technical reference to how a protection technology works, not a guide to defeating it. Respect each site's robots.txt, Terms of Service and applicable law, and collect only data you are permitted to.

Frequently asked questions

Is AWS WAF the same protection that runs on Amazon.com?

Not necessarily. AWS WAF is a product any AWS customer can deploy in front of their own site, so detecting it usually indicates a customer-configured web ACL on CloudFront or a load balancer. Amazon's own retail properties use layered internal defenses, and detecting AWS infrastructure on a site tells you nothing about which specific rules or inspection levels are enabled.

Does AWS WAF fingerprint the browser, or only inspect requests?

Both, depending on configuration. The base firewall and most managed rules work at the request level - IP reputation, headers, geography, and per-IP rate tracking. The Bot Control rule group at its targeted inspection level adds client-side interrogation: silent JavaScript challenges, token issuance, and device and browser signal collection used to distinguish automated clients from real browsers.

Why can a request be blocked before any challenge or CAPTCHA appears?

AWS WAF evaluates rules in priority order, and IP reputation rules typically run before challenge actions. If the source IP falls in a range the managed lists classify as hosting, VPN, or anonymizing infrastructure, the request can be blocked outright on IP class alone - no challenge is ever served. This decide-on-IP-first pattern is common across enterprise anti-bot systems, which is why IP provenance matters more than any client-side factor.