What AWS's IP data can and can't tell you (2026)
By Aron Bodogai · Published 2026-09-25 · Data: ip-ranges.json published 2026-09-24 06:47 UTC, syncToken 1790232426
AWS publishes every public IP range it uses, tagged with a service and a region. That makes "is this address AWS, and where?" easy to answer. "Which AWS service?" is a different matter: for about 94% of AWS's published IPv4 space, the data doesn't name one. And a large share of the addresses that do route to AWS aren't in the file at all.
This is a dated study. The figures describe AWS's data as it was on 2026-09-24 and won't be updated. For a current answer about a specific address, use the lookup.
Key findings
- The labels are vague. By address count, 77.9% of AWS's published IPv4 space is labelled only
EC2and 16.4% onlyAMAZON, which names no service. Only 5.7% carries a more specific service code. - Unnamed carve-outs hold AWS's own endpoints. Small
AMAZON-only ranges inside EC2 blocks held about 20 of the 30 AWS endpoints we resolved. That's an observation, not documented behaviour. - Half of Amazon's announced space is missing. About 50% of the IPv4 space announced by Amazon's networks isn't in the file, including customer-owned ranges and 99.4% of Amazon SES's mail-sending space.
- The file changes constantly, mostly trivially. About 11 versions a day in the month before the snapshot, most of them differing by one flapping range. Each version reached the download URL about 1.5 to 2.5 hours after its
createDate. - Reverse DNS helps in a few places only. It reveals CloudFront edge locations, specific Global Accelerators, SES senders and the real region of Route 53 health checkers, and almost nothing for the vague ranges.
The snapshot
| Item | Value on 2026-09-24 |
|---|---|
Published (createDate) | 2026-09-24 06:47:06 UTC (syncToken 1790232426) |
| File size | 2,694,143 bytes, served uncompressed |
| IPv4 | 10,527 entries; 7,801 distinct prefixes covering 101,881,686 addresses |
| IPv6 | 6,891 entries; 3,444 distinct prefixes |
| Service codes | 27 |
| Region values | 43, including GLOBAL |
| Network border groups | 124: 43 equal to a region value, 54 Local Zones, 27 Wavelength Zones |
The file ran ahead of AWS's documentation. The service code EFS and four region codes (eusc-de-east-1, me-west-1, sa-west-1, us-south-1) were missing from the documented lists of valid values when we checked on 2026-09-25, and the last three appeared nowhere in the endpoint data of botocore, the AWS SDK for Python. Code that whitelists values breaks on data like this.
Which service? Usually the data won't say
For each address, we took every service code on every published range that covers it, and grouped addresses by the most specific label they end up with:
| Label an address ends up with | IPv4 share (addresses) | IPv6 share (/64 blocks) |
|---|---|---|
Only AMAZON (no service named) | 16.42% (16,732,569) | 1.73% |
EC2 is the only specific label | 77.89% (79,352,120) | 84.96% |
A label more specific than EC2 | 5.69% (5,796,997), of which CloudFront alone is 3.79% | 13.30%, of which S3 is 10.53% |
EC2 means EC2 address space, not an EC2 instance. AWS says so itself: "some AWS services are built on EC2 and use EC2 IP address space". The EC2 pool serves Elastic IPs; Application, Network and Classic Load Balancers; NAT gateways; Lambda and Fargate outbound traffic; regional API Gateway endpoints; Lambda function URLs; Elastic Beanstalk environments; and all 1,292 Amazonbot crawler addresses we checked. The data can't tell these apart.
AMAZON is the catch-all. Every published address sits under an AMAZON range, and a range tagged only AMAZON means AWS uses it without saying for what. By prefix count, 3,682 of the 7,801 IPv4 prefixes (47.2%) were AMAZON-only: 3,096 standing alone, and 586 small carve-outs (/22 to /28, 194,256 addresses) nested inside EC2 blocks. Much of it appears to be infrastructure, China-region space or space held for later use: only 35.8% of AMAZON-only IPv4 space was announced in BGP, against 98.1% of named-service space. Some of it is very much live, though. The global sts.amazonaws.com endpoint resolved into a standalone AMAZON-only /21.
The carve-outs that hold AWS's own endpoints
We resolved 30 AWS endpoints and matched their addresses against the snapshot. About 20 landed in those 586 AMAZON-only carve-outs, among them the endpoints for STS, SQS, SNS, the EC2 API, KMS, IAM, CloudWatch, CloudWatch Logs, the Elastic Load Balancing API, ECR, Systems Manager, ECS, Step Functions, EventBridge, the RDS API and the Route 53 API. The apex domains amazon.com, imdb.com and audible.com did too. A typical case is 3.237.107.0/25, tagged only AMAZON, inside the EC2 block 3.224.0.0/12 in us-east-1.
AWS doesn't document this, the sample is small, and reverse DNS can't confirm it: carve-out addresses still return generic ec2-… names. But it changes how a hit should be read. An address in such a carve-out may well be an AWS endpoint rather than a customer's server, and collapsing it into its EC2 parent, as a "merge all tags" lookup does, hides exactly that.
Nesting, sharing and picking one answer
- No conflicts. No prefix was listed twice under the same service, and no prefix had more than one region or border group.
- Shallow nesting. 2,563 of 7,801 IPv4 prefixes and 453 of 3,444 IPv6 prefixes sat inside another listed prefix, never more than one level deep.
- Shared prefixes. 431 IPv4 and 661 IPv6 prefixes carried two or more service codes besides
AMAZON; 195 IPv4 and 469 IPv6 prefixes were tagged bothEC2andS3.
AWS documents how to read a shared prefix: a range tagged both S3 and EC2 is used exclusively by S3. It says nothing about nesting. The rule this site uses extends the documented one: the most specific prefix wins; within it, a named service beats EC2 and EC2 beats AMAZON; an AMAZON-only carve-out gets its own label; and the enclosing ranges are always shown. Without a stated rule, tools disagree. When we checked, three public lookup services gave three different answers for 44.248.100.1, an AMAZON-only /23 inside an EC2 /11. The ip-ranges.json reference works through examples.
GLOBAL doesn't always mean edge
AWS describes GLOBAL ranges as ones whose traffic can come from or go to many Regions, which fits CloudFront and Global Accelerator. The data is messier:
- 150 IPv4 and 97 IPv6 regional prefixes sat inside
GLOBALparents. For example, 56 regional EC2 /24s sat inside CloudFront'sGLOBALblock64.252.64.0/18, which is tagged bothCLOUDFRONTandCLOUDFRONT_ORIGIN_FACING. - 24 IPv4 and 51 IPv6
EC2prefixes, and 20 IPv4S3prefixes, were themselvesGLOBAL. - Route 53 health checkers in
15.177.0.0/18areGLOBALin the file, yet their reverse DNS names gave the actual region in 5 of 5 cases. - Ranges move:
108.166.224.0/21changed from us-west-2 toGLOBALduring the month before the snapshot.
Traffic direction and undocumented codes
Some service codes mark addresses a service connects from, not addresses you connect to, and a few aren't documented at all:
| Kind | Codes | Basis |
|---|---|---|
| Outbound only | API_GATEWAY, CLOUDFRONT_ORIGIN_FACING, ROUTE53_HEALTHCHECKS, EC2_INSTANCE_CONNECT | AWS documentation; for API_GATEWAY, AWS states "egress only" |
| Probably outbound | CODEBUILD, AMAZON_APPFLOW | Inferred from how the services use them |
| Internal | ROUTE53_HEALTHCHECKS_PUBLISHING | AWS: used "only internally" |
| Undocumented | ROUTE53_RESOLVER, AURORA_DSQL | Any explanation is inference; the DSQL API endpoint itself resolved into EC2 space |
The practical trap: an API_GATEWAY hit doesn't mean an API is hosted at that address. Regional API Gateway endpoints answer from EC2 and AMAZON space; the API_GATEWAY ranges are where API Gateway's own outbound requests come from. The service codes reference covers every code.
What the file leaves out
| Blind spot | Measured on 2026-09-24 |
|---|---|
| IPv4 announced by Amazon's AS numbers but not in the file | 90,981,952 of 180,468,736 addresses (50.41%), across AS16509, AS14618, AS8987, AS7224 and AS62785. Of the missing space, 844 blocks of /16 or larger (71.6 million addresses) are registered to Amazon entities. A looser time window gives about 46%. |
| Customer-owned ranges (BYOIP) | 5,083 announced /24s (1.30 million addresses) entirely outside the file. Whois on random samples returned non-Amazon holders. AWS excludes these by design. |
| Amazon SES mail servers | 13 ranges in SES's SPF record (157,696 addresses). 12 of 13 overlap nothing in the file; only 199.127.232.0/22 does, so 99.4% of the space is absent. |
| Services with no published ranges | Lambda, QuickSight and Elastic Beanstalk have no code of their own. Ground Station, S3 Express One Zone, VPC Lattice and Secrets Manager's managed external secrets exist only as AWS-managed prefix lists, which need an AWS account to read. |
| File space not announced by those AS numbers | 12.17% of the file's IPv4 space. The China Regions are announced by AS55960 and AS135629, whose registered names don't mention Amazon. |
Two AS numbers in the first row, AS7224 and AS62785, are Amazon's corporate networks rather than AWS. The conclusion holds either way: "not in AWS's published ranges" must never be presented as "not AWS". Checking the announcing network narrows it down, as long as the check knows about the China and European Sovereign Cloud (AS214101) networks.
How often the file changes
| Measure | Value |
|---|---|
| Versions since 2015-11-03 | 5,687 |
| Publications in the 30 days to the snapshot | 332 to 335 (about 11 a day); median gap 2.0 h, longest 9.3 h |
| Publications in the preceding 365 days | 1,462 (about 4 a day on average) |
| The most common change | 1.178.86.0/24 added 159 times and removed 159 times in 30 days; in 303 of 335 versions it was the only change |
| Real drift over the month (from 2026-08-23) | IPv4 +62 / −165 prefixes; IPv6 +378 / −41; one region reassignment |
| File size | 1,529,205 bytes at the end of 2023; 2,694,143 bytes at the snapshot |
| Publication lag | 93 to 151 minutes after createDate (median 113) across 292 publications |
AWS's documentation calls createDate the publication time, but a version only became downloadable one and a half to two and a half hours later. So at any moment, the newest version you can download is at least an hour and a half old by its own timestamp. Identify versions by syncToken and the file's MD5 (carried in the ETag), not by Last-Modified. AWS's change notifications on the SNS topic AmazonIpSpaceChanged can arrive out of order, so compare tokens there too.
What reverse DNS adds, and what it doesn't
| Addresses | What the PTR name gave | Observed |
|---|---|---|
Standalone AMAZON-only | Almost nothing; the rare hits were *.amazon.com | Under 1% had a name (0/190, 0/246, 1/150, 1/60); 8.5–15% failed with SERVFAIL |
AMAZON + EC2 | The default ec2-… name and its region, which always matched the file | 233 of 235; custom names rare (0/240 random, 1/69 in use) |
| IPv6 | Effectively nothing, except Route 53 name servers | — |
| CloudFront | The edge location (bud50 = Budapest), matching the X-Amz-Cf-Pop header 4 of 4 times | 47/47 in use; 8/8 random |
| Global Accelerator | The specific accelerator | 10/12 in use; 1/12 to 3/8 random |
| S3 and DynamoDB | Endpoint and region (not reliable for S3 REST versus website endpoints) | S3 18/30; DynamoDB 3/4 |
| Route 53 health checkers | The real region behind a GLOBAL range | 5/5 |
| Amazon SES (not in the file) | Mail sender and region | 22/26 and 11/13 |
Load balancers, regional API Gateway, Lambda function URLs and AWS API endpoints all returned generic ec2-… names. A generic name therefore confirms EC2 address space, nothing more.
What this means in practice
- Say "EC2 address space", never "EC2 instance", and "service not disclosed" for
AMAZON. - Show every matching range, and pick the headline from the most specific one.
- Never treat "not listed" as "not AWS"; check who announces the address.
- Record the
syncTokenwith any finding, because the data moves. - Nothing here identifies an AWS customer. For abuse, report it to AWS.
Methodology
- Snapshot.
ip-ranges.jsonwithsyncToken1790232426, downloaded on 2026-09-24. Figures derived from the file alone were recomputed from the pinned copy on 2026-09-25 and matched. - Address shares. Prefixes were deduplicated by CIDR, keeping every service code. Each address was labelled with the union of codes on all prefixes covering it. IPv6 shares count /64 blocks, so prefixes smaller than a /64 don't register.
- BGP comparison. Prefixes announced by the listed AS numbers, from RIPEstat's announced-prefixes data, compared address by address with the file.
- SES. The
ip4ranges in the SPF record ofamazonses.com(dig TXT amazonses.com). - Endpoints. 30 AWS service endpoints and Amazon domains resolved live on 2026-09-24 and matched against the snapshot.
- Reverse DNS. PTR lookups over DNS-over-HTTPS; Cloudflare and Google agreed on 35 of 35 answers. Random and in-use samples of 4 to 250 addresses per category, as shown in the table.
- History. Publication counts, flapping and drift from the public version history kept by seligman/aws-ip-ranges; lag from each version's
createDatecompared with when it became downloadable. - Verification. Each area was re-checked by a separate pass, and claims it refuted were corrected; for example, an early claim that the longest-prefix answer is worse for carve-outs did not survive. The prototype of this site's range matcher agreed with a brute-force scan on 50,000 test addresses, and the site's test suite repeats that check.
Limitations
- It is one snapshot of a file that changes several times a day.
- The endpoint and reverse DNS samples are small; treat those figures as indications, not rates.
- The BGP figures depend on the time window and on which AS numbers count as Amazon.
- The link between carve-outs and AWS API endpoints is an observation. AWS may use those ranges for other things too.
- Address shares use the union of tags, so carve-out addresses count as
EC2there, while this site's per-address answer calls them "not disclosed". - History figures come from a third-party archive; a missed version would undercount publications.
Sources
- AWS: AWS IP address ranges (EC2 address space, BYOIP, unpublished services)
- AWS: Syntax for AWS IP address range JSON (fields, valid values, range overlaps)
- AWS: AWS IP address ranges notifications
- AWS: AWS-managed prefix lists
- AWS re:Post: API Gateway IP ranges (egress only)
- AWS: IP address ranges of Amazon Route 53 servers
- AWS: Global Accelerator IP address ranges
- AWS: Bring your own IP addresses (BYOIP)
- AWS re:Post: Abuse reporting FAQs (AWS doesn't disclose customer information)
- RIPE NCC: RIPEstat announced-prefixes
- seligman/aws-ip-ranges: public history of
ip-ranges.json