Hosting & cloud providers / AWS

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.

16,336published prefixes tracked (10,512 IPv4, 5,824 IPv6)
~185 millionIPv4 addresses covered (published lists may overlap)
19 July 2026feed snapshot date — refreshed daily in production

How Maskbreak uses these ranges

Maskbreak 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 Maskbreak's verdict pipeline refreshes daily, so a new range is scored within a day 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.

What these ranges actually cover

Amazon publishes one list covering every service that can hold a public address — EC2, Lambda, NAT gateways, CloudFront edges, API Gateway, and the regional service endpoints. That breadth is why an AWS match alone says very little about intent: the same list contains a scraper's spot instance and a Fortune 500's payment integration.

Because Amazon tags each prefix by service and region, a match tells you more than "hosting". CloudFront prefixes are a CDN and will front legitimate consumer traffic; EC2 prefixes are rented compute and will not. If you consume the published list directly, keeping the service tag lets you treat those two cases differently — a distinction most vendors flatten away.

Where this provider shows up in abuse

Free-tier and spot pricing make AWS the cheapest place to run a short, high-volume burst, so it shows up disproportionately in credential-stuffing and catalogue-scraping traffic that lasts hours rather than weeks.

None of this makes a range match a verdict. In Maskbreak's pipeline a datacenter hit contributes 40 points toward a 0–100 risk score — enough to reach review, never enough to block on its own — and it never short-circuits tunnel detection, because VPN and proxy exits are themselves hosted in datacenters. Which AS announces a given address is a separate question, answered in the ASN directory.

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. Maskbreak returns the raw signal so you can apply exactly that asymmetric policy instead of a blanket block.

Check any IP right now with the free IP lookup — no account needed — or exercise the full verdict from your terminal:
curl -X POST https://maskbreak.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.

Score every request against live AWS ranges.
Free tier: 1,000 requests/hour. No card, no expiry.
Get a free API key
Microsoft Azure Google Cloud Oracle Cloud DigitalOcean Linode/Akamai Vultr Cloudflare Fastly
Fraud BriefOnce a month · no spam · unsubscribe anytime
Get the new VPN, proxy & bot patterns we see each month
Short, technical breakdowns of what fraudsters changed last month — written for engineers, not marketers.