How Many IP Addresses Does GCP Have? (Live Data)

By Muninder Adavelli. Scraping, SEO, and proxies for over a decade.

The script I used for GCP IPs analysis and the set up is identical to AWS.

1. Like AWS, GCP also offers ips data on a json file.gstatic.com/ipranges/cloud.json

2. And they have their ASN numbers.

The script function is simple.

1. Fetch that json,

2. process the CIDRs - we get number of ips - lets call it A

3. query RIPE Stat with GCP ASN number for the BGP side, - this also gives us number of ips - lets call this B

4. the difference between A and B what I am looking for.

The Same script, different json URL and different ASN numbers for AWS or GCP or Azure.

The number On GCP IP Ranges [19.4 million IPs]

GCP's public IP file has a simpler structure than AWS's. Each entry looks like this:

"syncToken": "1794297916545",
"creationTime": "2026-11-10T00:05:16.545143",
"prefixes": [
  {
    "ipv4Prefix": "34.80.0.0/15",
    "service": "Google Cloud",
    "scope": "asia-east1"
  },
  {
    "ipv6Prefix": "2600:1900:4000::/36",
    "service": "Google Cloud",
    "scope": "us-central1"
  }

Field names are also a bit different from AWS field names - ipv4Prefix instead of ip_prefix, scope instead of region.

Only the names are different. The idea is same though: public IP json files gives us

1. a CIDR,

2. a service tag, and

3. a location.

I ran my script and got these first numbers:

$ python pipelines/gcp.py
Fetching GCP cloud.json...
  IPv4: 19,385,984 IPs across 1,058 CIDRs
  IPv6: 95 CIDRs
  Snapshot saved: 20261110000516.json

$ python pipelines/asn.py
  Fetching BGP data for GCP ASNs...
    AS15169 (Google LLC primary)...
    AS396982 (Google LLC - Google Cloud)...
    AS41264 (Google Switzerland GmbH)...
    AS16550 (Google Partner Interconnect)...
    AS32381 (Google Fiber - residential, excluded from cloud total)...
  Total BGP-announced IPv4 (cloud only): 55,941,120 IPs across 4,840 CIDRs
  Excluded (not cloud): AS32381 — 1,536 IPs

19.4 million IPs - and thats just the published count.

Let me just put that in perspective: the Netherlands, an internet dense country in EU with 18 million people, has a national IPv4 allocation of roughly 19.5 million IP addresses.

And GCP's published IP pool is as big as a countries entire national internet infrastructure.

And we should take a note these are IPs that published openly for IP intelligency. Real GCP ip infra is even bigger. I had to querry their ASN numbers in BGP databases for complete picture

In Reality, GCP is 55.9 million IPs Big

Querrying the ASN on BGP - The is where my GCP ip or infra research gets interesting.

Like everyone else, at first I queried AS15169 only - the ASN listed under "Google LLC" in most BGP databases. It returned 4.2 million IPs.

That made me think - WHAT? Google published 19 odd million Ips and routing only 4.2M? This was like the opposite of my AWS ip infra research.

I even wrote the first version of this section saying exactly that.

But it did not add up at all. The WHY kept bugging me so I looked for the complete ASN list for Google.

Bingo! found AS396982. It was registered as Google LLC.

The GCP specific tag, Google Cloud was hidden in the description. So I had to querry it via RIPE Stat. That ASN alone is 51.7 million IPs BIG.

And I found the answer to my WHY?

That single number changes the whole story.

So I went ahead and querried all Google ASN numbers.

AS15169 (Google LLC primary)...
    AS396982 (Google LLC - Google Cloud)...
    AS41264 (Google Switzerland GmbH)...
    AS16550 (Google Partner Interconnect)...
    AS32381 (Google Fiber - residential, excluded from cloud total)...
  

• AS15169 is only 7.6% of GCP's total BGP counts.

• 92.4% of the total routes through AS396982 primarily.

• I also fetched AS32381 (Google Access LLC / Google Fiber). That's Google's residential ISP service, not cloud infrastructure - 1,536 IPs, all consumer broadband. I'm including the number here for transparency but excluding it from every GCP cloud total on this page.

 Total BGP-announced IPv4 (cloud only): 55,941,120 IPs across 4,840 CIDRs

55.9-19.4 = approximately 36.6 million

The gap is now 36.6 million.

This basically is the same story as AWS.

More IPS routed than published.

So where are this unpublished 36.6 million IPs going?

The 36.6 million unpublished IPs are almost certainly the same kind of infrastructure as AWS's 55 million gap - backbone interconnects, internal services, management planes. Things that route on the internet but don't need to be in a customer-facing firewall file.

More On GCP Public Ips: One service label, 48 scopes

Difference in BGP vs Public cloud.json ip counts is interesting for sure. Give the massive size of it.

Along with it, the open cloud.json also has its own interesting details.

Lets start with service level breakdone.

That is the part that surprised me most when I first looked at the data: Unlike AWS, GCP's cloud.json has zero service-level breakdown.

Every single one of the 1,058 IPv4 CIDRs is tagged with the same service label: "Google Cloud". No EXTRA details on if the IP infra is for Compute Engine, Cloud Run, GKE, Cloud SQL, or anything else

To put that into perspective, AWS had 50+ named services - EC2, S3, CLOUDFRONT, API_GATEWAY, EFS, and so on. Each CIDR in the AWS file tells you which service is using it.

And GCP tells you nothing.

All you can see on GCP cloud.json is which region. GCP uses full region names as scope labels - us-central1, europe-west1, asia-southeast1 - which is more readable than AWS's short codes.

However, on the whole, GCP cloud.json file is significantly less useful for detection purposes than its AWS equivalent. For instance, if you want build a system to monitor or just flag traffic from GCP Compute Engine specifically, this GCP cloud.json file the published wont give us that granularity like AWS.

This probably is by choice. Google might not want to expose what infrastructure uses which address ranges particularly.

Where GCP keeps its IPs

us-central1 in Iowa holds 5.1 million IPs. That is 26% of total GCP's published pool.

Google built their first large-scale data center campuses starting around 2007. Given the fact that 26% of IP infra all at one place, the concentration is striking and in a way even surprising from a security angle.

Like we compared the Netherlands with total 19M, lets take Norway as an example here.

• Norway's national IPv4 allocation is about 5.3 million addresses.

• us-central1, the one data center in Iowa is that big - roughly the size of Norway's entire internet infrastructure.

The pattern across GCP regions is also different from AWS:

• GCP has 48 named scopes,

• AWS has well over 100 regions and availability zones.

• Also, GCP is more concentrated. The top 10 regions account for about 73% of all published IPs.

The global row covers prefixes not tied to a specific region - probably edge infrastructure and anycast ranges used for services like Cloud CDN and Cloud DNS.

Note: I want to watch how the regional distribution shifts over time, especially as GCP continues adding regions. The snapshot archive will show this after a few months of weekly fetches.

More on the ASN - AS396982

I already wrote about ASNs and BGP from missing IPs perspective. But here is a bit more about the 51.7 Million IPs big ASN - AS396982

For AWS I found that all three ASNs they have evenly split the share of IPs. GCP's split is completely uneven.

AS396982 carries 51.7 million IPs across 3,567 CIDRs.

AS15169 carries 4.2 million. Everything else is rounding noise.

These are the facts out there in public. But the interesting point I am trying to make is this: most IP intelligence tools and ASN lookup databases index AS15169 as "the Google ASN." If you look up a GCP IP in a tool that only queries AS15169, you are checking against 7.6% of Google's cloud routing. The bigger share 51.7 million IPs that routes through AS396982 and would return no match or result as an unknown attribution.

This to me is a bigger blind spot than the AWS AS14618 situation. For AWS, checking only AS16509 missed about 10% of their BGP footprint (24M out of 244M). For GCP, checking only AS15169 misses about 92%.

AS32381 is Google Fiber - consumer residential internet. 1,536 IPs, 3 CIDRs. Completely irrelevant to cloud detection. I fetched it for completeness and to confirm the number is small enough to not distort anything.

What those IPs are worth

The same secondary market logic applies here as with AWS. IPv4 addresses currently trade at $30-60 each, mid-market around $45. GCP's published pool is 19.4 million IPs.

$872 million is the rough implied asset value of what GCP publishes. That's not AWS-scale. AWS's published pool implied about $8.5 billion, but it's still nearly a billion dollars of infrastructure at current secondary market prices.

For context, Google has also been an active IP market buyer. Their overall IP holdings are significantly larger than the cloud.json file shows - Google Search, YouTube, and other consumer products all sit on infrastructure that doesn't appear in this file at all.

What this means for my scraper

I started the IP infrastructure research because I was using AWS Lambda for SERP requests and wanted to understand what I was routing through. The GCP equivalent would be Cloud Run - same idea, fresh execution environment per request, different IP each time.

The GCP picture looks different from AWS for detection purposes in a few ways.

GCP gets less scrutiny than EC2 ranges. AWS EC2 is probably the most-flagged datacenter range on the internet - it's where the highest volume of automated traffic originates. GCP compute traffic is flagged too, but I think the volume is lower and the detection rules are probably less aggressive as a result. This is my guess, not a tested claim.

AS396982 is the detection blind spot. Most IP intelligence tools index AS15169 as "Google." A system that only queries AS15169 is checking against 7.6% of GCP's actual BGP footprint. Requests from AS396982 - which carries 51.7 million IPs - return no match in an AS15169-only check and may be classified as unknown or even non-datacenter. Whether this is exploitable depends entirely on how the target's detection system is built, but it's a real gap worth knowing about.

No service-level granularity means coarser classification. With AWS, an IP lookup can tell you "this is an EC2 IP, flagged high risk" vs "this is an S3 IP, probably fine." With GCP, all you can say from cloud.json is "this is a GCP IP, region X." You can't distinguish Cloud Run from Compute Engine from GKE from the published file alone.

Where this fits in the bigger picture

This is the second article in the IP infrastructure series. The first was AWS, which found 188.7 million published IPs and a 55 million BGP gap in the direction of more-than-published. GCP ends up being the same pattern once you query all the right ASNs: 19.4 million published, 55.9 million BGP-routed, 36.6 million gap in the same direction as AWS. The difference is that Google concentrates almost all its cloud routing in one ASN (AS396982) that most tools don't query.

For the full context on how IP ownership is concentrated and why IPv4 matters for proxies, the companion piece is:

How Many IP Addresses Are There? IPv4, IPv6, and Why the Number That Matters for Proxies Is Much Smaller

Azure is next. Azure is comparable to AWS in scale - around 109 million published IPs from yesterday's pipeline run. That will make for a more direct comparison with AWS than GCP does.

After that: Cloudflare, DigitalOcean, Oracle, and Fastly. And at some point I want to put them all in a single comparison table - same methodology, same live data, all from primary sources.

P.S. The numbers on this page update weekly. If you're citing them, include the date - the IP count will be different next month. The methodology doesn't change; the data does.

If you're running scrapers on Cloud Run or GCE and have noticed different detection behaviour compared to AWS Lambda routes, I'd want to compare notes. Specifically: whether targets that check ASN are catching AS396982 traffic the same way they catch AS15169. My guess is a lot of detection systems haven't updated their Google ASN lists and AS396982 slips through. If you have data on this, I want to hear it.