You can usually tell AWS WAF Bot Control apart from a plain firewall by what shows up after the block. A request that pulled a clean 200 yesterday now returns a 403, or a full-page CAPTCHA interstitial, and an aws-waf-token cookie you never set appears in the response. Swap in a fresh proxy and nothing moves. That last part is the tell: if a new IP does not shift the block, the IP was never the only thing AWS WAF was reading. The Targeted level of Bot Control is not counting your requests the way a plain rate limiter does. It scores who you are from several angles at once, an IP and ASN reputation, a TLS fingerprint, a JavaScript token that interrogates your browser, and your session behavior, and your IP is one input out of several.
Can residential proxies get past AWS WAF?
Partly, and only for one of the things Bot Control checks. Residential proxies fix the IP-reputation and ASN signal, which is what gets hosting ranges rate-limited or challenged on sight. They do nothing for your TLS fingerprint, nothing for the JavaScript token that fills the aws-waf-token cookie, and nothing for your behavior. A clean IP behind a raw HTTP client still gets caught by the Targeted rules. You need all of it to line up.
What AWS WAF Bot Control actually checks
Bot Control ships as a managed rule group with two inspection levels, and the gap between them is the whole story. The Common level catches self-identifying and obvious bots by signature and user-agent. The Targeted level is the one that catches a clean scraper, and in AWS's own prescriptive guidance it leans on four techniques for client identification: CAPTCHA, browser profiling, device fingerprinting, and TLS fingerprinting.
IP and ASN reputation. AWS WAF reads the network that owns your address and its history. Hosting ranges from AWS, Google Cloud, Azure, or OVH start deep in the red, and AWS reading traffic from its own EC2 ranges is the clearest case of all. Rate-based rules are also, in AWS's words, more effective when keyed to an application-specific attribute like a cookie or token than to the IP alone. This reputation gate is what a proxy actually moves.
TLS fingerprint. Before any page loads, your TLS handshake produces a JA3 fingerprint from the order of cipher suites and extensions your client offers. AWS surfaces this directly: a CloudFront-Viewer-JA3-Fingerprint header carries a 32-character hash of your TLS Client Hello, which the origin can compare against known-bad or known-good lists. A Python or Go client produces a signature no browser sends, and if that contradicts the Chrome your User-Agent claims, the mismatch alone is a strong signal.
The JavaScript token. This is the part that makes the Targeted level feel like more than a firewall. AWS uses token acquisition: a JavaScript SDK collects information from the client to generate a token that is evaluated server-side, and that token carries a browser-fingerprint identifier that stays stable across acquisition attempts. The token lands in the aws-waf-token cookie. Browser profiling, in AWS's description, looks for patterns that are inconsistent with how a real browser behaves, and flags a request that shows evidence of automation. A client that cannot run the SDK never reaches a trusted state.
Session behavior and device fingerprint. With the SDK integrated, AWS WAF aggregates request behavior per session and can separate legitimate sessions from malicious ones even when both come from the same IP. Device fingerprinting lets it recognise repeated requests from the same device across proxies, so rate limiting can key on the device rather than the address.
Why a raw HTTP client never clears the Targeted level
Point a plain requests or axios script at a site running Targeted Bot Control and you fail twice before behavior is ever weighed. The client has no JavaScript engine, so it cannot execute the token SDK, and without a valid token the request stays untrusted. Separately, its TLS fingerprint and header order announce automation the moment the connection opens. This is why people rotate an entire datacenter pool against AWS WAF and stay blocked: they keep changing the one layer, the IP, that a raw client was never going to pass on by itself, while the session-keyed rate limit and the missing token do the actual blocking.
Where residential proxies fit, and where they do not
Residential proxies route your traffic through real home connections on consumer ISPs, so the reputation signal flips from a flagged hosting ASN to a neutral home line. Datacenter IPs lose at this gate first, which is why every serious attempt against Bot Control starts with residential or mobile IPs. This is real, and it is the non-negotiable foundation.
What a proxy cannot do is change how your client speaks or what the token SDK sees. The proxy forwards your bytes untouched. If those bytes carry a Python handshake and no executed token, a residential IP just means AWS WAF challenges a residential IP. The mental model is the one behind all web scraping with proxies: the proxy makes your IP believable, and your fingerprint, your token, and your pacing make the rest of you believable. Bot Control scores them together.
Sticky sessions, not blind rotation
There is a rotation trap specific to AWS WAF, and it is the same shape as the one on Akamai and DataDome, but sharper here because the Targeted rules can rate-limit on the token and device rather than the IP. Rotate to a new address on the next request and you throw away the aws-waf-token that vouches for your session, so AWS re-interrogates you from scratch, and the device fingerprint may still tie the new IP back to the same session anyway. The winning pattern is the opposite of machine-gun rotation:
- Sticky sessions per flow. Hold one residential or ISP IP for a whole browsing session so the token, the IP, and the fingerprint stay consistent. Static ISP IPs suit this because the exit does not move under you mid-session.
- Rotate between flows, not inside them. New session, new identity, new IP.
A setup that actually gets through
The honest version has no single trick in it. Getting past a real Targeted deployment means lining up every signal, and proxies are one of them:
- Route through rotating residential or mobile IPs, with sticky sessions held for the length of each flow. This clears the ASN and reputation gate that stops datacenter ranges first.
- Run a real browser, not raw HTTP. A hardened Playwright or Puppeteer, or an anti-detect browser, executes the token SDK and produces a genuine TLS and browser fingerprint as a side effect. If you must use an HTTP client, one that impersonates a real browser's TLS fingerprint is the floor, and it still will not satisfy the token on the Targeted level.
- Make the User-Agent, TLS fingerprint, and IP geography agree. A German residential IP with a US-English headless Chrome and a Python TLS signature is three contradictions in one request. Consistency is the game.
- Pace like a person, with randomized delays and modest per-session volume, since the rate limit keys on your token and device, not just your address.
- Persist the
aws-waf-tokencookie across the session on the same sticky IP, so once the token is trusted you stay trusted.
Test before you scale
Before you point a real job at a defended target, prove one identity end to end. Confirm your exit is alive and residential with the proxy checker, then hit a fingerprint test endpoint and confirm your JA3 matches the browser you claim to be. If the IP is clean but the fingerprint says Python, you have caught your block before AWS WAF does. Testing one full identity (IP, fingerprint, token, pacing) tells you which signal is failing, which is the only way to fix the right thing instead of buying more proxies you did not need.
The honest bottom line
AWS WAF Bot Control's Targeted level scores four things and folds them together: your IP and ASN, your TLS fingerprint, a JavaScript token that interrogates your browser, and your session behavior. Residential proxies fix the first completely and are the foundation, since hosting ranges (AWS's own most of all) never make it past the reputation gate. But they do nothing for the other three. A clean rotating residential pool with sticky sessions gets you to the table; a real browser that runs the token, a fingerprint that matches your User-Agent, and human pacing are what let you stay. Our residential IPs start at $0.65/GB pay-as-you-go with no KYC and a balance that does not expire, which is the right economics for a job that runs in bursts. Anyone selling residential proxies as a one-click AWS WAF bypass is skipping three quarters of the problem. Get all of it right and Bot Control stops being a wall and becomes a checklist.
Sources
- AWS Prescriptive Guidance: Client identification controls for managing bots: token acquisition via a JavaScript SDK, browser profiling, device fingerprinting that recognises repeated requests across proxies, TLS fingerprinting, and the CAPTCHA action.
- AWS WAF Bot Control rule group: the Common and Targeted inspection levels, and the silent challenge plus CAPTCHA the Targeted level uses.
- JA3 (Salesforce): the TLS ClientHello fingerprint AWS exposes as the
CloudFront-Viewer-JA3-Fingerprintheader.