AWS IP ranges & what they mean for fraud

Amazon Web Services is the largest public cloud. Its published IP ranges cover EC2, Lambda, and every other compute surface an attacker can rent by the minute.

How Sentinel uses these ranges

Sentinel tags traffic from these ranges with the dch (datacenter/hosting) signal in real time. The numbers above come from AWS's own published range feed — the same feed Sentinel's verdict pipeline refreshes continuously, so a new range is scored within hours of publication, not whenever a static database ships.

Range data adds a signal; it never overrides deeper network detection. VPN exits live in datacenters, so a range hit doesn't short-circuit tunnel analysis — an IP in AWS's ranges that is also a VPN exit gets both signals, and your policy sees the full picture in the reasons array.

Should you block AWS traffic?

Cheap, instantly provisioned compute makes AWS a default launchpad for scrapers, credential-stuffing runners, and headless-browser farms — while also carrying enormous volumes of legitimate server-to-server traffic.

The honest answer is: it depends on the surface. A datacenter IP on a signup, login, or checkout is a strong review signal — humans overwhelmingly arrive from residential and mobile networks. The same IP calling your API is often just a legitimate backend. Sentinel returns the raw signal so you can apply exactly that asymmetric policy instead of a blanket block.

curl -X POST https://sntlhq.com/v1/evaluate \
  -H "Authorization: Bearer sk_test_sandbox" \
  -H "Content-Type: application/json" \
  -d '{"token":"test_datacenter"}'

The sandbox key returns the documented datacenter-verdict shape (decision, risk_score, network.datacenter) — no signup required. Details in the API docs.