The big cloud providers publish their own IP address ranges, as machine-readable files, updated continuously. Anyone can download them. So "how much of the internet does Amazon run on" ought to be a solved arithmetic problem.
It is, but not the way most people do the arithmetic. Add up Amazon's published file and you get 188 million addresses. The real figure is 101,829,252. The naive method overstates it by 85%.
Why you cannot add up the list
Two reasons, and the second catches people who already know about the first.
The same block is listed many times. Amazon's file records a prefix once per service, so a single range appears under AMAZON, and again under EC2, and again under S3. Its file lists 10,661 prefixes to describe rather fewer distinct blocks.
Prefixes nest. A /16 in the file may wholly contain a /24 listed separately. De-duplicating identical strings does not catch this, because the two entries are not identical — one is inside the other. Any method that treats prefixes as a set of labels rather than as ranges of numbers will double-count.
The correct method is to convert every prefix to a numeric interval, sort them, merge anything that overlaps or touches, and sum what remains. For Amazon that collapses 188,069,462 into 101,829,252 — a factor of 1.85.
What they actually hold
| Provider | Prefixes published | Addresses (merged) | Share of IPv4 |
|---|---|---|---|
| Amazon Web Services | 10,661 | 101,829,252 | 2.37% |
| Google (all services) | 99 | 22,179,840 | 0.52% |
| Google Cloud | 997 | 19,091,840 | 0.44% |
| DigitalOcean | 1,228 | 3,119,872 | 0.07% |
| Cloudflare | 15 | 1,524,736 | 0.04% |
Amazon alone announces the equivalent of 6.1 entire /8 blocks — six of the 256 slices the whole IPv4 address space divides into. Merged across all three of Amazon, Google and Cloudflare, the total is 125,533,828 addresses, or 2.92% of every IPv4 address that exists, and 3.39% of the space actually usable once reserved ranges are set aside.
Two details in that table say something about how these companies grew. Cloudflare describes its entire IPv4 footprint in 15 prefixes, because it was assembled recently and in large contiguous blocks. Amazon needs 10,661, because it was assembled over two decades out of whatever was available, including a great deal bought from organisations that no longer needed it. The shape of the file is company history.
The other is that the three providers' ranges do not overlap each other at all: merging across them gives exactly the sum of merging each. Their space is genuinely separate, however entangled their services are.
What this number is not
It is not ownership. These files say where a provider serves traffic from, which is not the same as what a regional registry allocated to it, and not the same as what is routed on the public internet today. A provider can announce space it leases, and can hold allocated space it does not announce.
It is also not a measure of how much of the internet's activity runs on these providers, which is far higher than three percent and cannot be computed from a prefix file. Address count measures allocated territory, not traffic, revenue or dependence. A single address in front of a load balancer can serve more requests than a million idle ones.
If you need this yourself
- Merge intervals; never sum prefixes. The gap is 85% for the largest provider and zero for the smallest, so you cannot tell whether it matters without doing it properly.
- Check your work against a provider whose file cannot overlap. Cloudflare's 15 prefixes are non-overlapping by construction, so if your method reports an overcount factor above 1 for Cloudflare, your method is wrong. That is the control we used.
- Re-download rather than cache. These files change; Amazon publishes a syncToken precisely so you can tell when.
- Do not use these lists as a security boundary. "Is this IP in AWS" is answerable; "is this IP trustworthy" is not the same question, and anyone can rent an address inside these ranges for a few cents.
Where those addresses physically answer from, and what that costs you in milliseconds, is measured in how far away the cloud is from Singapore.
What is measured here
The address counts are computed on 21 August 2026 from each provider's own published prefix file, by converting every entry to a numeric interval, merging overlaps, and summing. The naive sum is retained alongside each merged figure so the size of the correction is visible rather than asserted. The script refuses to emit results if a merge produces a total larger than the naive sum, which would mean the merge itself was broken.
Percentages are against the full 4,294,967,296 IPv4 addresses, and separately against the roughly 3.71 billion usable once reserved ranges are excluded. Both are given because the second is the more meaningful denominator and the first is the one everyone quotes.
View author profile → · Editorial policy
