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

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

109 million IPv4 Ips across 46, 992 CIDR

Azure is the third on my number of IPs analysis series. Unlike the first two, AWS and GCP it does not have one standard json file that discloses all its Ip ranges. Microsoft, instead have service tags JSON in their download center. The striking diffference is the this file changes every month. I had to edit my script quite a bit to match this new structure and do more data wrangling to get the final numbers.

$ python pipelines/azure.py
Fetching Azure service tags JSON...
  Discovered URL: https://download.microsoft.com/download/.../ServiceTags_Public_20261102.json
  IPv4: 108,967,860 IPs across 46,992 CIDRs (deduplicated)
  IPv6: 18,148 CIDRs (deduplicated)
  Snapshot saved: change_425.json

However, if we look at the final numbers, Azure is in between the two. However, there are some slight differences in the way that published 109 million IPs are packaged compared to the other two.

{
  "name": "AzureStorage.EastUS",
  "properties": {
    "changeNumber": 11,
    "region": "eastus",
    "systemService": "AzureStorage",
    "addressPrefixes": ["13.72.64.0/19", "2603:1030:504::/48"]
  }
}

The complicated part in extracting Azure IPs was that the same CIDR at times was appearing in multiple different entries. For instnace, once a CIDR that was there under a regional tag, it would again come under its global parent.

I had to add the extra step of deduplication. And then do the final counting. The raw file obviously had a lot more prefixes than the deduplicated output.

The final number as mentioned earlier is 109 million IPs.

That is around 2.93% of all routable IPv4 on the internet. Like I did with AWS and GCP, let me put compare this number to some popular country IPv4 ips count.

France, a country with 80 odd million people has a national IPv4 allocation of roughly 81 million addresses. And Azure's published pool itself is almost 35% bigger than that of France's entire national internet infrastructure.

Beside, that sheer volume that resembles the might and size of infrastructure Azure or Microsoft has, there is another number that would surprise, anyone who read my other two article in IPv4 series.

Azure has 46,992 CIDRs for 109 million IPs. To give some context here,

• AWS only uses 10,743 CIDRs for 188 million IPs.

• GCP uses 1,058 CIDRs for 19 million IPs.

• Azure has its IPs spread across four times as many blocks as AWS.

That in one line : Azure has more fragmented IP allocation.

Now that we are done with open data, lets get into the details I extracted from BGP using ASNs.

The gap

For both AWS and GCP, the total infra IPs count I extracted are higher than publically disclosed counts. For instnace, AWS, the BGP showed 55 million more routed IPs than those that are on the published JSON file.

Not at AWS 55 milllion scale, but I got the the same scenario repeated for GCP after finding missing ASNs.

I wanted to see the scenario with Azure too. I queried every public Microsoft ASN I could find:

• AS8075,

• AS12076,

• AS3598,

• AS8068,

• AS6194,

• AS8074.

• I also fetched AS23468 (Xbox Online) separately. This is I excluded on purpose as I keeping it alll limited to cloud side of the equation.

Here's what the full run returned:

Like I did on GCP, I looked for complete list of ASN for Azure and found five more ASNs on top of AS8075. But these 5 other ASN additons only moved the total from 81.8M to 82.4M.

• AS8075 carries 99.2% of Azure's publicly-routed IPv4.

• All the additional ASNs combined added 0.76% to the total. That is like 622,336 more IPs.

• And that means, the scenario is reversed here with Azure. There are more published Ips. To be precise, there are ASN-extracted Ips count is 26.5M less compared to published IP data.

I even looked for more ASNs that I might have missed but, I could not find any more new ASNs.

The most porbably reason for this might be that a significant portion of Azure's published IPs route through the Azure private infrastructure that probably never listed in public BGP.

For instnace, Azure ExpressRoute. Microsoft has these private connectivity products that allows enterprises to connect directly to Azure data centers. And traffic is routed through private links that never gets listed or announced to the global routing table.

This 26.5M short on BGP is probably a mix of such private infrastructure and backbone links that simply aren't publicly routed. And Microsoft sure has a lot of those private infra set ups.

70 services and one that breaks the math

Azure's Service Tags file has the most granular service breakdown of the three clouds. AWS tagged 50+ services. GCP tagged one. Azure has over 70 named service tags.

But there's one that breaks the math: AzureCloud.

My by-service processing counts each service's IPs before deduplication. Here's what AzureCloud reports:

AzureCloud: 117,249,140 IPs across 15,253 CIDRs

That's 117 million IPs - which is more than the deduplicated total of 108.9 million. AzureCloud is not a service. It's a catch-all label for every IP Azure owns. Every CIDR in the file also appears under AzureCloud, which is why summing AzureCloud against anything else produces a double count.

The same pattern exists in AWS - the AMAZON catch-all exceeds the total by the same logic. But Azure's AzureCloud label makes this more explicit because the number so clearly overshoots the actual total.

So the chart below excludes AzureCloud and shows the actual named services:

What I find interesting about the named services: EOPExtPublished is Exchange Online Protection. 606,373 IPs and only 147 CIDRs - which means large contiguous blocks averaging 4,125 IPs each. Email infrastructure tends to cluster in big ranges because deliverability depends on clean, recognisable IP blocks with consistent reputation. That's a different allocation pattern from AppService (2,172 CIDRs for 160k IPs - small blocks scattered everywhere) or EventGrid (849 CIDRs for 245k IPs).

Where Azure keeps its IPs

This is where Azure's structure diverges most sharply from AWS and GCP.

68,046,103 IPs - 62% of Azure's total - sit in a global bucket with no regional label. For comparison, AWS had about 5% of its IPs in a GLOBAL row, and GCP had about 7% in a global scope.

Azure's 62% global figure reflects how Service Tags actually work. Many Azure services are cross-regional by design and their IPs aren't pinned to a specific datacenter location. When you configure a firewall rule for AzureMonitor, you're often allowing traffic from infrastructure that doesn't map to a single region.

The BarChart below excludes the global bucket to show the actual named regions:

Among named regions, the US dominates as expected - eastus (Virginia), eastus2 (Virginia), centralus (Iowa), westus (California), westus2 (Washington), and southcentralus (Texas) all sit near the top. Europe is well-represented with westeurope (Netherlands) and northeurope (Ireland) in second and fourth.

eastus at 5.1 million IPs closely mirrors GCP's us-central1 at the same level, even though Azure and GCP are very different in total scale. It's probably just the ceiling of what a single major region needs at this point in time.

The 1,930 CIDRs for eastus2's 4 million IPs is a good example of the fragmentation pattern. AWS's us-east-1 uses 1,513 CIDRs for 44.9 million IPs. Azure eastus2 uses 1,930 CIDRs for 4 million IPs. Azure is allocating in much smaller blocks.

Note: I want to watch how the global vs named-region ratio shifts over time. If Azure is moving toward more region-specific routing, the global bucket should shrink relative to named regions. The snapshot archive will show this after a few months.

One ASN, many Microsoft numbers

AS8075 at 81.8M is 99.2% of the total. The contrast with GCP is stark: Google distributed 92% of its cloud routing across a secondary ASN (AS396982) that most tools don't index. Microsoft puts essentially everything in one place.

The AS12076 number is worth pausing on: 2,560 IPs via public BGP, despite being described as the ASN for "Azure services - compute, storage, peering." My read is that AS12076 is used for private peering (ExpressRoute) - traffic that routes across direct enterprise links rather than through public internet BGP. Those routes don't appear in RIPE Stat because they're never publicly announced. This is consistent with the gap explanation above.

AS6194, AS8074: both registered to Microsoft, both return zero active prefixes. Reserved but not currently routing anything publicly.

The practical takeaway for detection is different from GCP: checking only AS8075 gives you 99.2% coverage of Azure's publicly-routed IPs. It's not a material blind spot the way AS396982 was for GCP.

What those IPs are worth

$4.9 billion is the rough implied asset value of what Azure publishes. That's between GCP ($872M) and AWS ($8.5B). These are secondary-market valuations - what the blocks would fetch if sold today through a broker like IPv4.Global - not what Microsoft paid for them.

Like AWS and Google, Microsoft is not getting new IANA allocations. The free pool ran out in 2011. Any expansion has to come from secondary market purchases or more efficient use of existing space. The fragmented CIDR structure Azure uses might actually reflect acquisition history - blocks assembled from different sources tend to come in irregular sizes, which shows up as a high CIDR count relative to total IPs.

What this means for my scraper

Going back to the proxy and detection angle that started this research series.

Azure is the most useful of the three files for traffic classification - but only if you understand the AzureCloud trap. AWS gives you EC2 vs S3 vs CloudFront. GCP gives you nothing below "Google Cloud." Azure gives you 70+ named services. If you need to distinguish Azure App Service traffic from Azure CDN traffic, this file lets you do that in a way the other two clouds' files don't.

The catch is AzureCloud. If you query a prefix and get "AzureCloud" back, that tells you the IP is in Azure. But AzureCloud contains every Azure IP, so it fires on everything. You need to query the more specific service tags to get actionable granularity.

The 46,992 CIDRs make this the hardest file to load into a blocklist. AWS's 10,743 CIDRs are manageable. GCP's 1,058 barely registers. Azure's 46,992 is a file that takes noticeable time to load and iterate over at request time. If you're doing this in a hot path you need to think about data structures - a sorted list of CIDRs with binary search, or a Trie, not a linear scan.

Azure traffic is flagged but I think less precisely than AWS. EC2 is the category most fraud and bot detection systems have the most intelligence on - the highest volume of automation runs there. Azure gets flagged as datacenter but I'd guess the per-IP reputation scoring is less tuned than what detection systems have built for EC2 ranges. I haven't tested this systematically.

IPv6 at 18,148 CIDRs is the other thing to watch. This is 2.5x AWS and 191x GCP. Azure is running serious dual-stack infrastructure. For detection systems that focus on IPv4 and treat IPv6 as low-volume, that assumption probably breaks on Azure traffic more than the other clouds.

Where this fits in the bigger picture

This is article three in the IP infrastructure series. Here's where the three clouds sit now:

• AWS: 188.7M published, 244.1M BGP (BGP exceeds published - internal infrastructure)

• GCP: 19.4M published, 55.9M BGP across all cloud ASNs (BGP exceeds published - AS396982 carries 92% of routing and most tools miss it)

• Azure: 108.9M published, 82.4M BGP across all 6 Microsoft cloud ASNs (published exceeds BGP - gap explained by private/ExpressRoute routing, not missing ASNs)

Each cloud has a different gap story. AWS routes more than it publishes (internal backbone). GCP routes more than it publishes once you query all ASNs (AS396982 is the hidden one). Azure publishes more than any public ASN accounts for, even after checking all of them - the gap is likely private infrastructure.

For the broader context on how IP ownership is concentrated and what this means for the proxy ecosystem:

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

Cloudflare is next. Cloudflare is unusual - no JSON file, just two plain text lists (IPv4 and IPv6), and their IPs are more visible to detection systems than the hyperscalers because Cloudflare is a CDN and proxy layer, not a compute platform. The numbers will be much smaller but the detection angle is different.

If you're running scrapers that route through Azure or building detection that needs to handle Azure traffic - the AzureCloud trap and the ExpressRoute gap are the two things I'd want to compare notes on. Specifically: whether the 26.5M IPs that don't appear in any public Microsoft ASN are genuinely undetectable from a public BGP perspective, or whether there's a routing path I'm missing.

P.S. The numbers on this page update weekly. If you're citing them, include the date and the change number (currently #425) - Microsoft updates this file frequently and the CIDR count shifts with each update.