Inspired by Anurag Bhatia’s global CDN mapping post, June 2026
Anurag Bhatia recently published a piece mapping the global footprint of major CDNs, including Google GGC, Netflix OCA, Facebook FNA, Akamai, and others. His method scans the BGP routing table for open port 443 and reads TLS certificate names. It is a clever, first-principles approach, and it produces a clean picture of where CDN cache nodes sit.
We thought it was worth asking whether we could replicate and expand on this using IPinfo’s own data. It turns out we can. We also get a few angles that TLS scanning does not easily give you, such as city-level breakdown and per-provider IP counts.
What is a CDN and why does any of this matter?
A Content Delivery Network (CDN) is a geographically distributed set of servers that cache and serve content such as web pages, images, video, and software downloads from a location physically close to the user. When you watch a YouTube video, the data almost certainly is not coming from a Google data centre on the other side of the world. It is coming from a Google cache node sitting inside your ISP’s network or in a nearby data centre.
CDN infrastructure is, in many ways, a proxy for where the internet’s centre of gravity sits. Understanding its distribution matters for network engineers designing peering strategies, for policymakers thinking about data sovereignty, and for anyone curious about how the web actually works at a physical level.
Our approach: tagged IP ranges instead of TLS scanning
Anurag’s method works from the outside in. He scans every routed /24 (a block of 256 IP addresses) for an open HTTPS port and reads the TLS certificate to figure out which CDN is serving from that address.
Our approach works from the inside out. IPinfo maintains a dataset of IP ranges tagged by network function, and one of those tags is cdn. This covers 246 CDN ASNs and ~3.84 million IP addresses globally, published publicly at ipinfo.io/tags/cdn.
From there, we cross-referenced each CDN-tagged /24 against IPinfo’s geolocation database to find its physical location, and against our BGP prefix data to identify which provider owns it.
In plain terms: instead of knocking on every door and asking “are you a CDN?”, we started with a list of known CDN addresses and asked “where are you?”
Key findings
The United States holds 80% of global CDN infrastructure
Of the 15,018 CDN-tagged /24s we identified worldwide, 12,017 (80%) are geolocated to the United States. That is ~3.07 million IPs in a single country. The next closest is Germany at 288 /24s, followed by the UK at 209. The US is not just ahead. It is in a different category entirely.
Three providers own 83% of US CDN IP space
The US CDN landscape is heavily concentrated:
| Provider | /24 blocks | ~IPs |
|---|---|---|
| Google (GGC) | 4,883 | ~1.25M |
| Cloudflare | 2,808 | ~719K |
| Amazon CloudFront | 2,284 | ~585K |
| Akamai | 868 | ~222K |
| Imperva / Incapsula | 614 | ~157K |
Google alone accounts for 40.6% of all CDN /24s in the US. Combined, the top three of Google, Cloudflare, and Amazon account for 83%. Fastly, Akamai, and newer players like Fly.io make up most of the remainder.
Kansas City is the largest single CDN concentration in the US
This was our most surprising finding. When we broke the data down by city, Kansas City, Missouri came out on top with 4,277 /24s (~1.09M IPs), ahead of San Francisco (3,088 /24s) and Seattle (1,606 /24s).
Kansas City’s dominance is not broadly distributed. It has just 5 unique CDN ASNs, which strongly suggests this is driven by a single provider’s large cache deployment. That is almost certainly Google GGC, which is known to operate a major hub in the Kansas City area given its well-documented data centre presence there.
But LA and NYC win on diversity
Volume and diversity tell different stories. Los Angeles has just 57 CDN /24s, but 23 different CDN providers are present. New York City has 22. Ashburn, Virginia, the unofficial “internet capital of the world” given its concentration of data centres, has 14 unique CDN ASNs despite only 119 /24s.
These are the cities where the CDN ecosystem is genuinely competitive. Kansas City has scale. Ashburn and LA have breadth.
Outside the US: Hong Kong and Netherlands punch above their weight
Among non-US countries, Hong Kong (35 unique CDN ASNs) and the Netherlands (33) have the highest CDN provider diversity despite relatively modest /24 counts (133 and 114 respectively). Both are major internet exchange hubs, with AMS-IX in Amsterdam and HKIX in Hong Kong, which makes them natural landing points for CDN providers establishing a regional presence without committing large amounts of IP space.
Methodology in detail
-
Source data: CDN-tagged IP ranges from
ipinfo.io/tags/cdn, covering 15,018 IPv4 /24s and 142 IPv6 ranges. IPv6 was excluded from this analysis due to the small sample size and the geographic representation challenges of anycast IPv6. -
Geolocation: Each /24 was geolocated using IPinfo’s geolocation database, matched by the /24’s lowest IP address. The geo join uses a Hilbert-curve-based spatial index for performance at scale.
-
ASN attribution: Each /24 was mapped to its originating ASN using IPinfo’s BGP prefix data, then matched to an operator name via WHOIS records.
-
Aggregation: Where a provider operates under multiple ASNs (Google uses AS396982, AS15169, and AS394089 among others, and Cloudflare uses AS13335 and AS209242), counts were consolidated by brand for the provider-level view. ASN-level detail is preserved in the underlying data.
Fair challenges, and our answers
“Your CDN tag list might be missing providers.”
It might. Our tags.cdn dataset covers 246 ASNs that we have identified as CDN infrastructure. Anurag’s TLS approach can discover CDN nodes we have not tagged yet, especially smaller or newer providers. Our approach, on the other hand, captures providers even if their servers do not serve TLS directly. Neither method is complete. They are complementary.
“Kansas City at #1 feels wrong.”
It felt that way to us too, at first. But it holds up. Google has a well-documented data centre in the Kansas City metro area, and the 4,277 /24s attributed there are all under Google ASNs. The low CDN ASN count (5) for such a large IP block is the tell. This is one provider with a massive deployment, not a diverse ecosystem.
“Cloudflare uses anycast. Does that not break your geolocation?”
This is the most legitimate challenge. Cloudflare, and to a lesser extent Fastly, routes the same IP addresses from many physical locations simultaneously using BGP anycast. When we geolocate a Cloudflare /24 to San Francisco, that does not necessarily mean the server is in San Francisco. It may be the location of the IP’s registered origin or the geolocation our database has resolved for it.
For non-anycast providers such as Google GGC, Netflix OCA, and Akamai, geolocation is generally accurate because each IP block is served from a single physical location. For Cloudflare specifically, our numbers reflect the registered or geo-resolved location of IP space, not necessarily where packets are actually processed. Cloudflare’s true footprint is more distributed than the raw numbers suggest.
“You are counting IPs, not active servers.”
Correct. A /24 is 256 addresses, and not all of them are necessarily in active use as CDN servers. Our counts are a measure of allocated CDN IP space, not active server count. Anurag’s port-scanning approach is closer to measuring active infrastructure. Both are useful, but they measure slightly different things.
“Why only IPv4?”
Two reasons. First, CDN providers are still predominantly IPv4 in their cache node deployments. Our tags.ip dataset has 15,018 IPv4 CDN /24s and only 142 IPv6 ranges, a ratio of 100 to 1. Second, many CDN providers use IPv6 anycast, which makes geolocation unreliable for the purposes of this analysis.
What’s next
This analysis focused on the US and global distribution. A few directions are worth exploring:
- Historical comparison: If we run the same analysis against historical snapshots of our geo and tag data, we can track CDN footprint growth over time, which is something TLS scanning cannot easily do retrospectively.
- ISP-level peering: Which ISPs in the US are hosting the most CDN nodes? That is a question about the relationship between eyeball networks and CDN cache placement that our ASN data is well suited to answer.