What we found in 134,000 cloud provider IP ranges

Most IP geolocation services will tell you whether an address is "hosting" — a datacenter rather than a home connection. Almost all of them work it out from the Autonomous System Number: look up who announces the address, and decide whether that organisation sounds like a hosting provider.

We wanted to know how well that actually works. So we took the IP ranges the major cloud providers publish about themselves, and checked how many of their own addresses the ASN method fails to identify.

The answer, for one provider, was worse than we expected.

The method

Seven providers publish machine-readable lists of the address ranges they use. We fetched all of them, then sampled addresses from within those ranges and asked the existing ASN-and-keyword detector a simple question: is this hosting?

Since every address came from a provider's own published list, the correct answer is always yes. Anything the detector missed is a false negative — a datacenter address that would be reported as an ordinary connection.

The results

Provider	Published prefixes	Missed by ASN alone
AWS	10,612	15.3%
Azure	79,499	2.3%
Google Cloud	997	1.9%
Vultr	440	1.1%
Oracle Cloud	1,102	1.1%
Linode / Akamai	5,409	1.0%
DigitalOcean	1,080	0.3%

Six of the seven sit at or below 2.3%, which is respectable. AWS is the outlier by an order of magnitude.

Why AWS breaks the assumption

The ASN method rests on an idea that turns out to be shaky: that a cloud provider announces its addresses under one obvious, recognisably-named ASN.

AWS does not. Its address space is announced across a large number of Autonomous Systems, many acquired along with the companies and networks they came from, and many carrying organisation names with no hosting-related word anywhere in them. A keyword matcher looking for "cloud", "hosting", "server" or "datacenter" sees nothing to match, and reports an ordinary connection.

The failure is not random. It is concentrated in exactly the address space that does not look like what you expected — which is the worst possible distribution, because it means the method fails silently and confidently.

What the ranges look like when you merge them

Taking all seven providers together:

134,409 published prefixes
  5,913 merged, non-overlapping ranges

The reduction is mostly Azure. Microsoft publishes its ranges as service tags — one entry per service per region — and those overlap heavily by design, because AzureCloud contains most of the others. The same prefix appears repeatedly under different tags. Merging collapses them.

Azure also dominates on raw count: 79,499 prefixes, nearly eight times AWS's 10,612, for a smaller share of the market. That is a difference in publishing style, not in size. Microsoft enumerates finely; Amazon aggregates.

Loading the ranges directly

Once you match against the published ranges themselves rather than inferring from the ASN, every column above goes to zero. That is not a surprise — it is close to a tautology, since the addresses were sampled from those ranges. But it does establish something useful: the ranges are complete enough to be worth loading, and the gap they close is real.

The ranges are also only ever a positive signal. A match proves the address is in a provider's published space. A non-match proves nothing, because plenty of hosting is not on this list. So the range check runs first, and the ASN and keyword signals still run behind it to catch everything else.

What is not covered

Hetzner publishes no machine-readable range file. It is a significant European host and there is simply nothing to fetch, so it rests entirely on ASN detection — AS24940 and AS213230. If you know of an official feed, we would genuinely like to hear about it.

More broadly, the seven providers here are the ones that publish. The long tail of regional hosts, colocation providers and bulletproof hosting does not, and never will. Range data raises the floor; it does not solve the problem.

Practical notes if you are building this yourself

Azure's URL rotates. The file name embeds a date and changes weekly, behind a stable landing page. Pinning the URL means it works for a few days and then quietly stops. You have to fetch the page and follow the link.

Version tokens save real work. AWS and Google publish a syncToken; Azure publishes a changeNumber. If it has not changed, neither have the ranges, and you can skip the parse, sort and merge entirely.

Partial success should be acceptable. If six providers answer and one times out, use the six. These ranges only ever produce true positives, so a missing provider costs coverage, never correctness. Failing the whole refresh because one endpoint blinked is worse than being slightly out of date.

Merge and bisect. 134,409 prefixes checked linearly is not viable per request. Sorted, merged, non-overlapping ranges searched by bisection is, and it collapses to 5,913 entries.

---

Every lookup here reports hosting using both signals — the published ranges first, then ASN and keyword matching for everything the ranges do not cover. You can see it on any address through the API, or read the companion piece on detecting VPNs, proxies and datacenter traffic for how the rest of the detection works.