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

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

I am and have been scraping Google SERPs, using multiple methods.

Whatever is the method, let it be the camoufox + proxies, the playwright + proxies there is one costant: the scraping at volumes will burn the proxy IP pool. IP Pool Burn rate is a very real metric.

So at a point I was looking for alternatives and found a method on reddit. It was about using AWS Lambda instances instead of proxy ips. So basically serverless instance will create a new ip every single time, we fire up the fresh lamda function or event Make the request from a new execution environment, move on.

It worked well. A bit expensive compare to best proxyies for google scraping [meaning proxy providers with better IP Pools] but surprisingly worked well. It works even now, with out any isssues.

But that method got me thinking about how big is AWS?

How big is it on the IPs? Do they ever get blocked? How are they manging the volumes?

Like I mentioned earlier, I have already done some research on how many IP addresses exist on the internet, which made me realise just how concentrated IP ownership is only in some companies and some countries.

AWS is one such company. And, there I found out that they already have big base and are actively buying IPs on the secondary market. For instance the 8 million IPs they got from MIT.

I wanted to look deep, and see what we can understand from their public data on ips and whats not in their public data.

So, first, I built a script to find out whats in their public json

The number

The first thing I used as a source for my script was ip-ranges.amazonaws.com/ip-ranges.json AWS officially and publically is maintaining a file of every IP range they allocate to named services. Details of each ip would look like this:

"syncToken": "1794257225",
  "createDate": "2026-11-09-20-47-05",
  "prefixes": [
    {
      "ip_prefix": "3.4.12.4/32",
      "region": "eu-west-1",
      "service": "AMAZON",
      "network_border_group": "eu-west-1"
    },
    {
      "ip_prefix": "3.5.140.0/22",
      "region": "ap-northeast-2",
      "service": "AMAZON",
      "network_border_group": "ap-northeast-2"
    },

It includes the

• date it was last updated,

• every IPv4 and IPv6 CIDR,

• which AWS service each range belongs to, and

• which region.

I wrote a Python script that

1. fetches the json

2. expand every CIDR to an individual IP count using ipaddress.ip_network().num_addresses - a /24 is 256 IPs, a /16 is 65,536, and so on.

3. I also wired it to save a snapshot every time AWS's createDate timestamp changes, so I'd be tracking the count week over week without doing anything manually.

$ python run.py
IPv4: 188,682,587 IPs across 10,743 CIDRs
IPv6: 7,060 CIDRs
BGP-announced IPv4: 244,140,288 IPs across 19,408 CIDRs
# Run output from Nov 2026 fetch. Snapshots are keyed by AWS's own createDate - reruns on the same date don't overwrite.

And here are the first week numbers:

188 million is already a very big number.

Let me put in perspective: Germany, a country with almost 84 million people and 5 trillion USD GDP has an IPv4 allocation of around 120 million addresses for the whole nation.

AWS's ips at 188 million is way than that 120million. In percentage increase or just sheer terms, AWS is 57% larger than an whole GERMANY's internet infrastructure.

But here's what caught my attention.

One company controls more than 5% of all publicly routable IPv4 on Earth. And that's just what they publish.

The 55 million gap I didn't expect

The open JSON file has all the ip details. It is open for is what AWS publishes for customers - firewall rules, security group allowlists, that kind of thing.

But I wanted to know what AWS actually routes on the internet, which is a different question.

To answer that,

• I queried RIPE Stat's announced-prefixes API for all three of AWS's autonomous system numbers - AS16509, AS14618, and AS8987.

• RIPE Stat is free, run by RIPE NCC, and returns every prefix currently being announced to the global routing table from those ASNs.

• BGP routing tables show everything a network routes on the internet - not just what a company publishes in a customer-facing file, but everything they actually announce to the world.

Each run of my script also diffs against the previous snapshot and records the week-over-week delta in IPs and CIDRs. So over time I'll be able to see exactly when and by how much AWS is growing its IP footprint - something I haven't seen tracked anywhere else.

55.5 million IPs that AWS routes but doesn't publish. That's roughly 22.7% of their total routed space.

This isn't a bug in the data or a discrepancy worth investigating. It is quite deliberate.

AWS routes those blocks internally: data centre interconnects, management planes, AWS's own internal services that customers never interact with. There's no reason for them to put those in a customer-facing file.

But it matters if you're building a detection system:

• Any blocklist that only checks ip-ranges.json is working with 77% of the picture.

• The other 23% is still AWS infrastructure, routed through AWS ASNs.

I've seen this misclassify legitimate AWS traffic as unknown or even residential - which is wrong.

And here's why I think this is probably growing:

AWS has been an active buyer on the secondary IP market. IPv4 addresses currently trade at $30–60 each. AWS isn't getting new allocations from IANA. In fact no one is. The pool ran out in 2011.

So when they need more, they buy from whoever already owns them.

Note: There's a third number I haven't pulled yet - what Amazon actually owns according to ARIN's registry, which should be larger than both the JSON and the BGP figures. ARIN's RDAP API gives you everything an org has registered. I'll add that comparison on the next update, which would give a full three-way picture: registered vs published vs routed.

Which services use all those IPs

The JSON tags every CIDR with the service using it. I pulled the full list and sorted by IP count.

The AMAZON catch-all sitting at 102 million surprised me. That bucket covers subnets AWS doesn't individually name - services they don't expose individually in the file. It's the largest single bucket and also the least informative one for detection purposes.

EC2 at 80 million is the operationally interesting number. That's where compute workloads run - which is also where every scraper, every bot operator, and every proxy service on cheap cloud infrastructure runs. When I was spinning Lambda functions for SERP requests, those requests were coming from EC2 ranges. That's why Google and most major targets treat EC2 traffic with extra scrutiny by default.

One thing I noticed in the CIDR-to-IP ratio: S3 has 483 CIDRs for only 683,712 IPs (averaging ~1,400 IPs per CIDR), while EC2 has 1,906 CIDRs for 80 million IPs (averaging ~42,000 per CIDR). EC2 uses large contiguous blocks; S3 is scattered across many smaller ones. I think that's a deliberate routing architecture choice - EC2 needs big contiguous pools to hand out to instances, S3 doesn't.

Where AWS keeps its IPs

us-east-1 at 44.9 million IPs is not surprising - it's the original AWS region, launched in 2006, and it's had the most time to accumulate both customer workloads and AWS-internal infrastructure. But the magnitude is still striking.

The GLOBAL row in the table covers CIDRs not tied to a specific region - primarily CloudFront edge locations and Route 53 anycast ranges. These are the IPs that serve traffic from wherever the user is, so they don't map to a single data centre.

Note: I want to track how the regional distribution shifts over time as AWS opens new regions. My snapshot archive will make that visible after a few months of weekly fetches.

Three ASNs, not one

This is the part that surprised me most when I looked into the BGP side. AWS doesn't operate under a single autonomous system number - it uses three main ones, and they don't all behave the same way in lookup tools.

AS16509 is the operational spine. 218 million IPs, 17,734 CIDRs. If you've ever looked up an AWS IP in any BGP tool or IP intelligence database, this is the one that came back.

AS14618 is older - it was registered as "Amazon-AES" before AWS existed, back when it was just Amazon.com's e-commerce infrastructure. It still carries 24 million IPs, most of them older ARIN-registered blocks. I found that this one doesn't always appear in tooling that only queries AS16509, which creates a real blind spot for detection systems.

AS8987 is small - 1.4 million IPs, primarily Amazon Technologies EU infrastructure in Europe.

The point I am making is: if you're building a datacenter detection pipeline and you only check AS16509, you're missing 24+ million IPs that are still AWS infrastructure. That's a lot of requests that come back as "unknown" when they shouldn't.

What those IPs are worth

I mentioned that AWS is buying IPs on the secondary market. This is worth quantifying.

IPv4 addresses currently trade at $30–60 each. The mid-market rate is roughly $45. ARIN, RIPE, and APNIC all publish transfer logs - addresses move between organisations through brokers like IPv4.Global and Hilco Streambank. The MIT sell-off is probably the most cited example: in 2017, MIT sold part of its legacy 18.0.0.0/8 block to Amazon for approximately $7.9 million - covering 8 million addresses at around $1/IP. Those same addresses would fetch $360 million at today's prices.

The supply constraint is relevant for proxy operators too. When AWS or any cloud provider runs low on IPv4, they don't get more from IANA - the free pool ran out in 2011. They buy from whoever already owns blocks. That means cloud provider IP ranges are a stable, slow-moving detection target. They don't turn over fast. When a block is flagged as AWS infrastructure, it stays flagged.

What this means for my scraper

Going back to why I started this research: I was using AWS Lambda for SERP requests as an alternative to burning through proxy pools. It works well because each Lambda invocation can get a fresh execution environment with a different IP - you're not hammering the same IP repeatedly.

But understanding the full picture changes how I think about it.

EC2 is the highest-suspicion tier for anti-bot systems. The 80 million EC2 IPs are where customer compute runs - which is exactly where every scraper, every credential stuffer, every load testing tool, and every proxy service on cheap cloud infrastructure runs. When a request comes from an EC2 range, most fraud systems apply extra scrutiny regardless of any other signal. I'm probably getting away with Lambda for SERP requests partly because Lambda execution IPs rotate across the full EC2 pool, so no single IP accumulates velocity. But I think any serious anti-bot system is still applying a datacenter-range score to those requests.

The AS14618 blind spot is worth knowing. Most IP lookup tools query AS16509 by default. If you're hitting a target that uses a home-built blocklist based on a simple ASN check and they only query AS16509, requests from AS14618 may slip through with a lower suspicion score. I haven't tested this systematically, but it's probably worth exploring.

The 55 million unpublished IPs are misclassified by most detection pipelines. A request arriving from a prefix that isn't in ip-ranges.json returns no match in a JSON-only lookup, and may get classified as unknown or even residential. It isn't. I've seen this happen in proxy detection tooling I've reviewed. If you're building something that needs to identify AWS traffic reliably, you need the BGP data, not just the JSON.

Where this fits in the bigger picture

This research started with a broader question. If you want the full context - how the 3.72 billion routable IPv4 addresses are distributed, why the US holds 36% of them, what IPv4 exhaustion actually means, and how CGNAT affects proxy pool quality - that's all in the companion piece I wrote first:

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

That article flags two open research gaps that this pipeline now answers for one specific case:

1. "Exact IPv4 addresses currently in BGP routing tables" - answered here for AWS: 244,140,288, across 3 ASNs, generated from live BGP data.

2. "The gap between IANA allocation and what's actually routed" - demonstrated for AWS: 55.5 million IPs (22.7%) are routed but unpublished. The same methodology applies to any major holder.

AWS is first in this series. Next up: Google Cloud, Azure, and DigitalOcean. I want to build a comparison table across all major cloud providers - same methodology, same weekly pipeline, all from primary sources.

If you're running scrapers that route through Lambda or any AWS infrastructure - or if you're building detection systems that classify AWS traffic - I'd genuinely want to hear what you're seeing. The AS14618 blind spot especially: I've only spotted it in tooling I've reviewed, not tested it systematically myself. Hit me up if you have data on this.

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.