Prynt vs AWS WAF Bot Control: Edge Filtering vs Device Identity

If your stack runs on AWS, the first bot defence you meet is usually AWS WAF and its Bot Control managed rule group. It sits in front of CloudFront, an Application Load Balancer or API Gateway and filters traffic before your code runs. Prynt sits somewhere else: it identifies the device in the browser or app and hands your application context about that device.

The two overlap on “is this a bot?” and diverge on almost everything else. Here is where each one fits and how they work together.

What AWS WAF Bot Control does

Bot Control is a managed rule group you add to a web ACL. AWS documents two inspection levels:

• Common detects self-identifying bots using request analysis: user agents, known crawler categories, verified bots like search engines, and similar static signals. It labels requests with the bot category and name, which your own rules can match on.
• Targeted adds protection against bots that don’t identify themselves. AWS describes it as using browser interrogation, fingerprinting and behaviour heuristics, plus machine-learning rules that look at traffic statistics for coordinated activity. It relies on a client token, obtained through AWS WAF’s challenge and its application integration SDKs.

Because it runs in the request path at the edge, Bot Control is good at shedding volume: scrapers, crawlers you don’t want, credential-stuffing bursts, inventory bots. It doesn’t need any change to your application code beyond the optional SDK for the targeted level. AWS also sells separate Fraud Control rule groups aimed at login and account creation; check AWS’s documentation for exactly what each inspects.

What a request filter can’t know

A WAF evaluates requests. It knows headers, IPs, rates, tokens and patterns across traffic. It doesn’t know your users, because it never sees your database.

That puts a class of questions out of reach:

• Accounts per device. “This browser already created three trial accounts this month” requires a persistent device id joined with your account ids.
• Device history for an account. “This account has always logged in from one laptop, and tonight it’s a new device in another country” needs per-account device history.
• Humans doing abuse. A person farming promo codes by hand, in a normal browser, from a home connection, produces perfectly clean requests. There is no bot to detect.
• Your outcomes. Which devices were behind chargebacks or bans is knowledge you hold, not the edge.

These are exactly the problems where most account-level fraud lives: multi-accounting, trial abuse, promo abuse, account takeover. They are not request-filtering problems.

What Prynt adds

Prynt gives each browser or mobile device a stable visitorId that survives cleared cookies and incognito. Your server fetches the event by requestId with a secret key:

import { PryntServer } from '@prynt/node';
const prynt = new PryntServer({ secretKey: process.env.PRYNT_SECRET_KEY });

const ev = await prynt.getEvent(req.body.requestId);
// ev.visitorId, ev.decision ('allow' | 'challenge' | 'block'), ev.riskScore (0-100)
// ev.accountsOnDevice.count -> how many of YOUR accounts this device has held
// ev.smartSignals.bot, .vpn, .residentialProxy, .tlsFingerprint, .virtualMachine, ...

After creating an account, you attach your user id with updateEvent(requestId, { linkedId }), so the next sign-up from the same device sees it. Reason codes such as MULTI_ACCOUNT, IMPOSSIBLE_TRAVEL, DATACENTER or TLS_AUTOMATION explain each decision, and you can tune rules, weights and allow/deny lists in the console. Labelling outcomes through /v1/outcomes feeds back into reputation.

Side by side

	AWS WAF Bot Control	Prynt
Where it runs	Edge, in the request path	Browser or app agent plus your server
Primary unit	Request	Device, linked to your accounts
Volumetric bots and scrapers	Strong	Partial (edge gate, bot signals)
Self-declared crawlers, verified bots	Strong	Partial
Accounts per device	Not available	Core feature (accountsOnDevice)
Manual abuse by humans	Limited	Strong when it repeats per device
Explainable verdicts	Labels per rule	Reason codes per decision
Where it can protect	AWS resources (CloudFront, ALB, API Gateway and others)	Any stack, including self-hosted

Running both on AWS

The cleanest setup lets each layer do what it is good at.

1. AWS WAF in front. Keep the managed core rule set and Bot Control on CloudFront or your ALB. Let it rate-limit and drop obvious automation before it costs you compute.
2. Prynt at the moments that matter. Load the agent on sign-up, login, checkout and promo-redemption pages. Send the requestId with the form and check it in your handler or Lambda.
3. Share context. Bot Control adds labels to requests and can forward them to your origin in a custom header if you configure a rule to insert one. Log those labels next to the Prynt visitorId and decision. When both agree on automation, you can act with more confidence; when only one fires, you have a case worth reviewing.

If you want a Prynt verdict on routes without the agent, such as an API endpoint, GET /v1/edge/gate returns 204 for allow, 403 for block and 200 for challenge. On AWS, call it from your origin middleware; it isn’t an AWS WAF integration. For agent-less scoring from the server side, POST /v1/collect scores a request from network and header signals.

Serving the Prynt agent through your own domain, via a CloudFront behaviour or your load balancer, keeps it first-party and less likely to be blocked. Your proxy passes the visitor IP with X-Prynt-Client-IP and X-Prynt-Proxy-Secret, which you get from the console.

Which should you start with?

If your bill is being driven by scrapers and request floods, start with the edge. That is what Bot Control and similar products are built for; the trade-offs are covered in server-side vs client-side bot detection and, for a comparable edge product, Prynt vs DataDome.

If your losses come from accounts, such as farmed trials, abused promos or taken-over logins, start with device identity. No amount of request filtering will tell you that the polite, human, residential-IP sign-up is someone’s eleventh account.

Most products past a certain size have both problems. Edge filtering and device identity are not competing for the same job, and running them together on AWS needs no change to your WAF configuration: the Prynt check lives in your own application code. If you’re also on Cloudflare in front of AWS, see edge bot detection on Cloudflare. The bot detection page covers which Prynt signals are on which plan.