If you are trying to block datacenter IP ranges one address at a time, you are signing up for a maintenance job that never ends. The scalable way to block datacenter IP ranges is to think one level up, at the ASN: an autonomous system number groups all the prefixes of a single network operator, so one decision covers every address that operator announces, including addresses they add next month. This post walks through how to identify the network behind a request, how to build an ASN-level view of your abusive traffic, and - just as important - how to scope the resulting rules so you do not take out legitimate users along with the bots.
Why per-IP blocklists rot
A per-IP blocklist decays from the moment you write it, for structural reasons:
- Attackers rotate. Cloud instances are disposable. A scraper that gets blocked on one address spins up a new instance and arrives on a different one from the same provider's pool minutes later. You banned an address; the operator has thousands.
- Providers grow. Hosting companies acquire new address blocks constantly. A static list of "AWS ranges" copied from a forum post in 2023 misses every prefix added since.
- Addresses get reassigned. The address you banned last year may serve a different customer, or a different provider, today. Stale entries silently become false positives.
The IP address is the wrong unit of identity for infrastructure traffic. The operator is the right unit, and on the internet the operator is identified by an ASN - a number assigned by the regional internet registries to the organization that announces those prefixes in BGP. If ASNs are new to you, start with What Is ASN, Anyway?. One ASN-level decision replaces hundreds of per-prefix entries and tracks the operator's growth automatically.
How to block datacenter IP ranges by ASN
Step one is identification: for any request, find out which AS announced the source address. A single IP lookup returns the ASN details inline:
curl "https://api.theipapi.com/v1/ip/8.8.8.8?api_key=YOUR_API_KEY"
The asn object in the response tells you the number, the operator, and the specific route:
"asn": {
"asn": 15169,
"asn_description": "Google LLC",
"country": "US",
"created": "2005-11-23",
"network": "8.8.8.0/24",
"org_name": "Google LLC",
"rir": "ARIN",
"updated": "2019-10-31"
}
The same response carries an is_datacenter flag, so you can distinguish hosting ASNs from consumer ISPs without maintaining your own classification - our guide on detecting VPNs, proxies, and datacenter IPs explains how that flag is built. When you already know the ASN and want its registration details, there is a dedicated endpoint:
curl "https://api.theipapi.com/v1/asn/13335?api_key=YOUR_API_KEY"
{
"status": "OK",
"body": {
"asn": {
"asn": 13335,
"asn_description": "Cloudflare, Inc.",
"country": "US",
"org_name": "Cloudflare, Inc.",
"rir": "ARIN"
}
},
"response_time_ms": 5
}
(The live response also includes the registration created and updated dates - trimmed here.)
Both endpoints are covered in the documentation. For one-off investigation you do not even need an API key: the free ASN lookup tool resolves a number to its owner, and the IP to ASN tool maps an address to its AS and route. Every ASN also has a browsable detail page on this site - see AS15169 (Google), AS16509 (Amazon), or AS13335 (Cloudflare) for examples of what you will find when you chase down a number from your logs.
The workflow: log, aggregate, then decide
Do not start by blocking anything. Start by measuring, in three stages.
1. Log the ASN on every request. Resolve each source IP to its ASN and write the number alongside your normal request log fields. A small helper is enough:
import requests
def asn_for_ip(ip: str, api_key: str) -> int | None:
resp = requests.get(
f"https://api.theipapi.com/v1/ip/{ip}",
params={"api_key": api_key},
timeout=5,
)
data = resp.json()
if data.get("status") != "OK":
return None
return (data["body"].get("asn") or {}).get("asn")
Cache the result per IP - ASN assignments change rarely, so even a short TTL of a day cuts your lookup volume dramatically. For backfilling an existing log, POST /v1/ip/batch takes up to 100 IPs per request and deduplicates them for you.
2. Aggregate by ASN. Group your abuse signals - failed logins, scraping patterns, fake signups, card testing - by ASN over a rolling window. The distribution is usually stark: human traffic spreads across many consumer ISP ASNs with low abuse rates, while a handful of hosting ASNs account for most of the garbage. Rank ASNs by abuse rate and by absolute volume, and look at both, because a small ASN with a 95% abuse rate and a big one with 40% call for different responses.
3. Decide per ASN: rate-limit, challenge, or block. These are escalating responses, and most ASNs on your list deserve the milder ones:
- Rate-limit hosting ASNs with mixed traffic. Legitimate automation survives a sane rate limit; scrapers hammering you at high volume do not.
- Challenge (CAPTCHA or JavaScript proof-of-work) where you need a human. A challenge on signup costs a real user a few seconds and costs a bot farm its economics.
- Block only ASNs that are effectively single-purpose abuse sources for your service - and enforce it at the edge (your CDN, load balancer, or WAF), where a rule keyed on ASN or on the operator's prefixes is cheap, instead of burning application capacity on traffic you have already decided to refuse.
Before any of these go live, run them in observe mode: tag matching requests and let them through for a week, then review what you would have limited, challenged, or blocked. This is the cheapest possible way to discover that a "bad" ASN also carries a partner's integration or a paying customer's backend, and it turns your first enforcement change from a guess into a measured decision. Keep the review loop running after launch too - abuse moves between providers, and last quarter's worst ASN is often quiet today.
The caveats: a cloud ASN is not an abuse ASN
Here is the honest part. Blocking a large cloud ASN outright takes out everything hosted there, and "everything" includes traffic you want:
- Search engine and legitimate crawlers that index your site or power integrations your users rely on.
- Uptime monitors and security scanners that you or your customers configured on purpose.
- Corporate egress: plenty of companies route employee traffic through cloud-hosted proxies and security gateways, so a blanket block on a major cloud ASN can lock out entire enterprise customers.
- Your own customers' backends calling your API from cloud infrastructure, which is exactly where backends live.
The fix is scoping. Apply ASN rules per-route, not globally: a datacenter-ASN challenge on /signup and /checkout stops bot registrations and card testing while leaving your homepage, docs, and API untouched. Public content that benefits from crawling should almost never sit behind an ASN block. And maintain a small allowlist for known-good automation (verified crawlers, your monitoring vendor) that overrides the ASN rule. Narrow rules on the two or three routes where abuse actually hurts will get you most of the value with a tiny fraction of the collateral damage.
Finally, remember what ASN-level blocking cannot do: attackers using residential proxies arrive from consumer ISP ASNs and pass straight through. ASN rules raise the cost of the cheap, high-volume attacks; they are one layer, not the whole defense.
Start with your own logs
You cannot scope rules for traffic you have not measured. Sign up for a free API key - 1,000 requests per day on the free tier, no card required - resolve a day of your access log to ASNs, and see which operators are actually behind your abuse before you write a single rule.
