What Are Cloud Provider IP Ranges and Why They Get Blocked

A cloud provider IP range is a CIDR prefix, something like 52.94.76.0/22, that a Regional Internet Registry allocated to a cloud company and that the company announces over BGP from its own autonomous system. When you launch an instance, the provider leases you one address out of that pool for as long as the instance lives. Release the instance and the address goes back into circulation, often reassigned to a stranger within the hour.

Two properties matter for detection.

The address is fungible. It carries no lasting relationship to you, which is exactly why abusive traffic likes cloud IPs and exactly why defenders distrust them.

The address is enumerable. Because the provider owns the whole prefix and needs customers to be able to firewall it, the prefix list is documented. That documentation is the mechanism this whole article is about.

Compare that to a residential IP handed out by a consumer ISP. The ISP announces its prefixes too, and the ranges are recoverable from routing data, but no consumer ISP publishes a curated "here is every eyeball subnet, refreshed daily" JSON file with region and service labels attached. Cloud providers do, and they do it well.

Why they publish at all

The reason is legitimate and has nothing to do with bots. Customers need to allow-list cloud egress in their own firewalls, pin object-storage traffic to specific prefixes, route around a region, or write security-group rules that survive an IP change. AWS publishes the ranges partly so you can restrict access to AWS services. The block-list use is a side effect of a file built for allow-listing.

These are the primary sources. Every URL below is the provider's own endpoint, not a third-party mirror.

Pull the AWS file and the scale is obvious immediately:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq '{created: .createDate, v4: (.prefixes | length), v6: (.ipv6_prefixes | length)}'

On the 2026-08-18 snapshot (syncToken 1787038625) that file carried 10,648 IPv4 prefixes and 6,114 IPv6 prefixes, tagged across 43 regions and 27 service names. Filter to the ones that actually host customer compute:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq -r '.prefixes[] | select(.service=="EC2") | .ip_prefix' \
  | wc -l
# 1921

Collapse those 1,921 EC2 prefixes and they cover roughly 79.9 million IPv4 addresses. Google Cloud's cloud.json on the same date held 997 IPv4 prefixes covering about 19.1 million addresses. DigitalOcean's CSV listed 1,228 rows covering about 3.1 million.

Three files. Three HTTP requests. Around 102 million IPv4 addresses, close to 2.7% of the routable IPv4 internet, categorised and ready to drop. No machine learning, no behavioural model, no TLS fingerprint. Just a download.

The files are versioned so consumers stay current

AWS ships a syncToken and a createDate on every publish and runs an SNS topic named AmazonIpSpaceChanged that fires whenever the file changes, so subscribers can rebuild a blocklist within minutes of a new prefix appearing. Google Cloud stamps creationTime and its own syncToken. Azure publishes weekly and exposes a Service Tag Discovery API for programmatic pulls. That machinery exists so allow-lists do not go stale, and it keeps block-lists just as fresh.

There are three consumption patterns, in rising order of sophistication.

Direct, by the site itself. A team writes a cron job, downloads the JSON, and pushes the prefixes into an nginx geo block, a Cloudflare IP List, an AWS WAF IPSet, or an ipset on the host. Twenty lines of Python:

import ipaddress, json, urllib.request

def prefixes():
    aws = json.load(urllib.request.urlopen(
        "https://ip-ranges.amazonaws.com/ip-ranges.json"))
    for p in aws["prefixes"]:
        if p["service"] == "EC2":
            yield p["ip_prefix"]

    gcp = json.load(urllib.request.urlopen(
        "https://www.gstatic.com/ipranges/cloud.json"))
    for p in gcp["prefixes"]:
        if "ipv4Prefix" in p:
            yield p["ipv4Prefix"]

nets = ipaddress.collapse_addresses(
    ipaddress.ip_network(p) for p in prefixes())

with open("cloud-deny.conf", "w") as fh:
    for net in nets:
        fh.write(f"deny {net};\n")

That is the entire attack on your proxy pool. It runs in about a second and it does not care what your requests look like.

Aggregated, by feed vendors. MaxMind's GeoIP2 Anonymous IP database carries an is_hosting_provider flag. IPinfo sells an anonymous IP database with a hosting boolean. IP2Location encodes it as usage type DCH (Data Center / Web Hosting / Transit) in the IP2Location database. FireHOL's public IP lists merge cloud and hosting sets into blocklists people import wholesale. Each of these ingests the published provider files as one of its inputs, then resells the classification with a lookup API in front.

Embedded, by anti-bot platforms. Cloudflare, Akamai, DataDome and the rest fold hosting classification into a risk score alongside TLS and browser fingerprints. In Cloudflare's ruleset engine the check is a first-class field: a rule as blunt as ip.src.asnum in {16509 15169 14061} blocks AWS, Google and DigitalOcean at the edge with zero list maintenance. The field reference for ip.src.asnum documents it as an ordinary filter expression field.

The thing to internalise: pattern one is available to a solo developer with a cron job. This is not enterprise-grade defence. It is a Tuesday afternoon task.

The clearest concrete example ships from Amazon, aimed at Amazon's own customers. AWS WAF offers managed rule groups for IP reputation, and two of them matter here.

AWSManagedRulesAnonymousIpList contains a rule named HostingProviderIPList. Amazon describes it as inspecting for IP addresses of services that permit obfuscation of viewer identity, which includes hosting and cloud providers. Turning on that rule group blocks traffic from cloud compute wholesale. Sibling rules in the same group cover VPN and Tor exit ranges.

AWSManagedRulesAmazonIpReputationList is a different animal. Its rules (AWSManagedIPReputationList, AWSManagedReconnaissanceList, AWSManagedIPDDoSList) come from Amazon's internal threat intelligence, so they fire on observed behaviour rather than on category membership.

Attaching the first one is a single API call:

aws wafv2 update-web-acl \
  --name my-site --scope REGIONAL --id "$ACL_ID" --lock-token "$TOKEN" \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=acl \
  --rules '[{
    "Name":"anon-ip","Priority":10,
    "Statement":{"ManagedRuleGroupStatement":{
      "VendorName":"AWS","Name":"AWSManagedRulesAnonymousIpList"}},
    "OverrideAction":{"None":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"anon-ip"}}]'

In the console it is a checkbox in a list of recommended baseline protections, sitting next to the core rule set most teams enable without reading the descriptions. A great many WAF deployments therefore block hosting-provider traffic by accident, as a default they inherited. When your scraper gets a 403 with no CAPTCHA, no challenge and no interstitial, this is frequently what happened.

Note the asymmetry between the two rule groups. HostingProviderIPList blocks on what your IP is. The reputation list blocks on what your IP did. The first fires on request one, which is the whole point of this article and a different mechanism from the behavioural side covered in IP blacklisting and how to avoid it.

Proxy vendors advertise "clean IPs", "never-blacklisted IPs", "fresh IPs". Those claims are often true and mostly irrelevant against a categorical filter.

"Clean" describes an address-level property: this specific IP is not on a spam blocklist, has no abuse history, has not been rate-limited into oblivion, has not been burned by a previous tenant. Address-level cleanliness is real and worth paying for. It decides whether you pass reputation checks, which we cover in what IP reputation is and why it matters.

Categorical classification operates one level up. The question is not "what has this address done" but "what kind of address is this". A pristine, never-used IP inside 52.94.0.0/16 is still inside 52.94.0.0/16. The HostingProviderIPList rule does not consult its history. Neither does an nginx deny list built from ip-ranges.json an hour ago.

So when a vendor tells you the IPs are clean, the useful follow-up questions are:

1. Clean by whose measure, and against which blocklists?
2. Which ASN announces the prefix, and how do MaxMind, IPinfo and IP2Location classify that ASN?
3. Does the prefix appear in any provider's published range file?
4. What usage type does a GeoIP lookup return for it?

Question 3 is the one nobody asks and the one that decides whether the "clean" claim survives contact with a WAF. An IP can be spotless and instantly blocked at the same time.

Not all datacenter space is equal, and flattening the three tiers into one is the most common analytical error in this area.

The middle column is where most datacenter proxy space actually lives. A prefix leased from a regional hosting company or a colocation provider is not in ip-ranges.json, is not in cloud.json, and will not be caught by a cron job that only pulls the hyperscaler files. It often carries ARIN reassignment records naming the sub-allocated organisation, which reads less like anonymous ephemeral compute.

It is still hosting space. GeoIP vendors still stamp it DCH. The HostingProviderIPList rule, which is broader than any single provider's published file, still frequently catches it. The gap between those two columns is a matter of degree, not of kind, and any vendor implying otherwise is selling you something.

The right-hand column is genuinely different in kind. That is why ISP proxies exist: datacenter hardware with address space registered to a consumer ISP, so the usage-type lookup returns ISP instead of hosting.

Published prefix files are the categorical layer. ASN reputation sits underneath and makes it worse.

Every prefix is announced by an autonomous system, and detection vendors score autonomous systems in aggregate. If 4% of requests from AS-X are abusive, every IP under AS-X inherits a penalty regardless of individual behaviour. We go into the mechanics in what a datacenter ASN is. Three compounding effects matter here.

Aggregate scoring is the default. A vendor seeing ten million requests a day cannot model every IP. It models ASNs and prefixes, then adjusts for individuals. Your fresh IP starts life at its ASN's baseline, not at neutral.

Subnet correlation catches what ASN scoring misses. Even a target that ignores ASN often blocks by /24. Burn a handful of neighbours and the whole block goes, which is why pool diversity across subnets matters more than raw IP count. Subnet proxies and the reasoning behind choosing clean datacenter subnets both reduce to this.

You cannot rotate out of it. Rotating within a burned ASN moves you to a different address under the same verdict. Rotation only helps against per-IP rate limits. Against a categorical rule it changes nothing, and it burns addresses while failing.

You can check what a given IP inherits with Team Cymru's IP-to-ASN mapping service:

whois -h whois.cymru.com " -v 203.0.113.10"
# AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name

Being straight about this is more useful than a sales pitch.

SparkProxy datacenter proxies are not hosted on AWS, Google Cloud, Azure or DigitalOcean, so they do not appear in ip-ranges.json, cloud.json, the Azure service tag files or DigitalOcean's CSV. A blocklist built from those four sources will not contain them. That is a real, checkable difference, and it is why a datacenter proxy often works on a target where a raw EC2 instance collects a 403.

It is not immunity. Our datacenter ranges are hosting-registered space on hosting ASNs. Any classifier working at the usage-type level rather than the published-file level, and that includes MaxMind, IPinfo, IP2Location, AWS WAF's HostingProviderIPList, and the hosting signal inside every serious anti-bot platform, will categorise them as datacenter. On a target that blocks all hosting traffic outright, no datacenter proxy from any vendor gets through. Not ours, not anyone's. A provider claiming otherwise is either redefining "datacenter" or hoping you never test it.

What the difference actually buys you is the large middle ground. Plenty of sites block the published cloud ranges specifically, because those files are free and trivial to consume, while never enabling a full hosting-provider rule. Against that population, hosting space outside the published files works and works cheaply. Against the stricter tier you need residential or ISP address space, and pretending otherwise just spends your budget on requests that were never going to land.

Ordered by how much they help, not by how good they sound.

1. Match the address type to the target's policy. This is the whole game. If a target enforces a hosting rule, no amount of header tuning, TLS fingerprint work or rotation will fix it. Move to residential or ISP address space for that target and keep datacenter proxies for the targets that tolerate them. Splitting your target list by enforcement policy is usually the single biggest win available.

2. Test before you scale. Twenty requests tell you which category a target enforces. Guessing costs you a week. The next section shows the test.

3. Prefer address space outside the published files. Hosting space absent from every provider's self-service JSON survives the cron-job tier of blocking, which covers a large share of real deployments. Ask your provider which ASNs announce their prefixes, then check those ASNs yourself instead of accepting a "clean IP" claim.

4. Diversify across ASNs and /24s. A pool concentrated in two subnets dies as one unit. Spread across many prefixes and independent autonomous systems so one burned block does not take the pool with it.

5. Fix everything above the IP layer too. Categorical IP blocking is a floor, not a ceiling. Passing it only earns you evaluation on TLS fingerprint, HTTP/2 frame ordering, header order and behaviour. Clearing the IP check and then failing the fingerprint check produces the same 403 and a far more confusing debugging session.

6. Stop trying to out-rotate a categorical rule. If the first request from a fresh IP fails identically to the hundredth, the rule is categorical. Rotating harder makes it worse: more addresses burned, more failures logged, more fuel for the ASN reputation score already working against you.

The diagnostic takes two minutes. Send the same request through datacenter and residential exits, then compare status codes. The SparkProxy Scraping API makes this a one-parameter change: premium_proxy=false routes through datacenter exits and premium_proxy=true routes through residential. Set transparent_status_code=true so you see the target's real status instead of a wrapped error.

# Datacenter exit
curl -s -o /dev/null -w "datacenter: %{http_code}\n" \
  "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io&render_js=false&premium_proxy=false&transparent_status_code=true" \
  -H "X-API-Key: YOUR_API_KEY"

# Residential exit, same request
curl -s -o /dev/null -w "residential: %{http_code}\n" \
  "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io&render_js=false&premium_proxy=true&transparent_status_code=true" \
  -H "X-API-Key: YOUR_API_KEY"

Run it across a sample rather than once, so you can separate a categorical rule from ordinary flakiness:

import requests
from collections import Counter

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "YOUR_API_KEY"
TARGET = "https://www.sparkproxy.io/pricing"

def sample(premium, n=10):
    counts = Counter()
    for _ in range(n):
        r = requests.get(API, headers={"X-API-Key": KEY}, params={
            "url": TARGET,
            "render_js": "false",
            "premium_proxy": str(premium).lower(),
            "country_code": "us",
            "transparent_status_code": "true",
        }, timeout=90)
        counts[r.status_code] += 1
    return counts

print("datacenter ", sample(False))
print("residential", sample(True))

Read the result like this:

Row one is the case this article exists for, and it is the one teams spend weeks misdiagnosing as a fingerprint problem. If you want the exit categorised independently, point the same request at an IP echo endpoint and feed the address it returns to Team Cymru or a GeoIP usage-type lookup, so you see exactly what the target saw. Adding render_js=true and stealth=true helps when the target needs a real browser, though neither changes the IP-category verdict.