How IP to AWS Service works

Every answer comes from AWS's own published list of IP ranges, which your browser downloads directly from AWS. The matching happens in your browser too. This site has no server-side code and no database: it is a set of static files.

This page explains where the data comes from, what happens to what you type, how the headline answer is chosen, and what the answers can't tell you.

The data comes straight from AWS

Download. A background worker in your browser downloads ip-ranges.json from ip-ranges.amazonaws.com. The file is a few megabytes and AWS serves it uncompressed, so on a slow mobile connection it can take a while; a status line shows the progress. The home page starts the download when you start a lookup, or otherwise once the page has finished loading (it waits for you if your browser has asked sites to save data). Other pages download it only when you press a button.
Processing. The same worker, a Web Worker running separately from the page, parses the file and builds a lookup index, so the page stays responsive while it works. It checks the file's shape first. If something else arrived instead, such as a Wi-Fi sign-in page or a proxy's error page, you get an error message, not wrong answers.
A saved copy. The index is saved in your browser's IndexedDB storage, so on your next visit answers appear immediately from the saved copy.
A freshness check. When there is a saved copy, the page asks AWS for just the first 64 bytes of the file (an HTTP Range request) and compares the version number in it, the syncToken. If AWS has published a newer version, the page downloads it and updates the answer on screen if needed.
The data date. Every result says when AWS published the data behind it. If that is more than two days ago, you'll see a warning, because AWS normally publishes much more often than that.

The addresses you look up never leave your browser. Matching happens locally against the downloaded list. AWS sees that your browser downloaded its public file, but not what you looked up. The only lookups that involve anyone else are the ones described below. The optional ones run only when you ask: when you click their button, or, for the network check, automatically once you have ticked the box that turns that on.

Downloading from AWS directly means there is no copy on this site to go stale and no data pipeline to break. The cost is a bigger download than a compressed copy would be. It also means that if AWS ever moves the file or changes its format, fresh downloads will fail until the site is updated; saved copies keep answering, with their date shown.

Matching and the headline answer

You can enter an IPv4 or IPv6 address, a CIDR range, an address with a port, a URL or a hostname. IPv4 addresses written in IPv6 form (::ffff:52.94.76.1, or NAT64's 64:ff9b::/96) are unwrapped and checked as IPv4. Private, loopback and link-local addresses get their own explanation, including AWS's special addresses such as the EC2 instance metadata service at 169.254.169.254.

AWS's ranges overlap: an address usually sits in a small range for a specific service, inside a larger EC2 range, inside an AMAZON range. The page lists every matching range, most specific first, and picks one headline:

The most specific range (the longest prefix) wins.
Within that range, a named service beats EC2, and EC2 beats AMAZON. AWS documents this for shared ranges: a range tagged both S3 and EC2 is used only by S3.
EC2 alone is reported as "EC2 address space", never as "an EC2 instance".
A range tagged only AMAZON is reported as "service not disclosed". If it sits inside a larger EC2 range, it is flagged as an undisclosed service carved out of EC2 space.
If an enclosing range is GLOBAL while the specific one is regional, both are shown.

The ip-ranges.json reference walks through worked examples, and the service codes reference explains what each code means, including the codes that only ever mark traffic from AWS. For a CIDR range, the page shows the published ranges that contain it and the ones inside it.

Hostnames: DNS over HTTPS

A web page can't make DNS queries itself, so to turn a hostname into addresses the page asks a public resolver over HTTPS:

Cloudflare's resolver (cloudflare-dns.com, the 1.1.1.1 service) is asked first.
Google Public DNS (dns.google) is asked only if Cloudflare fails, doesn't answer within five seconds, or reports a server failure. A "no such domain" answer is final and isn't retried.

The page asks for IPv4 and IPv6 addresses at the same time, shows any chain of aliases (CNAME records), and checks each address it gets back against AWS's ranges. Aliases often say more than the addresses do: a name ending in cloudfront.net, elb.amazonaws.com or lambda-url.region.on.aws names the service directly. Many AWS-hosted sites don't expose such an alias, though.

Things to keep in mind:

Answers depend on location. Large sites give different addresses to different places. You see the addresses given to the resolver, which may not be the ones your own computer gets.
Internal names don't resolve. Names that only exist inside a company or VPC can't be looked up through a public resolver. Names that can never be in public DNS, such as localhost, .onion, .local, .internal and EC2 private names like ip-10-0-0-1.ec2.internal, are explained without sending them anywhere. Single-word names and names under .lan or .corp are only sent if you ask.
If DNS over HTTPS is blocked on your network, run dig +short example.com (or nslookup example.com) yourself and paste the address.
The resolver sees the hostname. When the page asks Google, it turns off EDNS Client Subnet, so the domain's own DNS servers don't learn which network you're on; Cloudflare doesn't send that information at all. The privacy page has the details.

Reverse DNS (optional)

For an IP result, the "Look up reverse DNS" button asks the same resolvers for the address's PTR record, the name its operator gave it. A few name patterns add real information, and the page recognises them:

CloudFront edge servers, including the edge location (server-13-32-12-39.bud50.r.cloudfront.net is in Budapest);
a specific Global Accelerator accelerator;
Amazon S3 and DynamoDB endpoints;
Route 53 name servers;
Amazon SES mail servers, which are mostly missing from AWS's IP list;
Amazon Chime SDK Voice Connector;
AWS's default names for EC2 address space, which include the region.

A generic name such as ec2-3-18-1-10.us-east-2.compute.amazonaws.com doesn't prove there is an EC2 instance: load balancers, NAT gateways and AWS's own API endpoints get the same kind of name. Many AWS addresses, and nearly all IPv6 addresses, have no reverse DNS name at all. And whoever controls an address block controls its reverse DNS, so a name is a hint, never proof.

Who announces an address (optional)

When an address isn't in AWS's published ranges, the page offers a button to check which network announces it on the internet. It asks RIPEstat, a public data service run by RIPE NCC, for the announcing network (its autonomous system number, or ASN) and that network's registered name. The answer falls into one of these groups:

Announced by an AWS network: AS16509, AS14618 or AS8987; AS214101 (AWS European Sovereign Cloud); or AS55960 and AS135629 (the AWS China Regions, run by local partners). The address very likely routes to AWS but isn't in the published list. Common reasons are a customer's own range brought to AWS (BYOIP) or a service AWS doesn't publish ranges for.
Announced by another Amazon network (AS7224, AS62785, AS58588 and AS154263, Amazon's corporate networks; AS801 and AS699, Amazon Leo satellite internet): Amazon, but not AWS.
Announced by a network with "Amazon" in its name that isn't on the lists above: shown as exactly that, and never as AWS. Anyone can register a network name, and Amazon runs networks that aren't AWS, so the name alone proves nothing.
Announced by another network: its name is shown. That names the network operator, not whoever uses the address. Customers can announce ranges they bring to AWS from their own AS number (BYOASN), so this makes AWS very unlikely rather than impossible.
Not announced at the moment.

The check is opt-in because it sends the address to RIPE NCC. It runs when you click the button, or, once you tick the box to allow that, for the address on screen and automatically for later lookups. See the privacy page.

Customer-owned ranges (BYOIP). Customers can bring their own address blocks to AWS. AWS leaves them out of ip-ranges.json by design, whois shows the customer's organisation, not Amazon, and a customer can even announce them from its own AS number (BYOASN).
Amazon SES. The mail servers of Amazon's email service are almost entirely absent from the file. The reverse DNS check recognises them.
Unpublished services. AWS publishes ranges for the services customers commonly filter traffic for, not for every service. Some publish their ranges only as AWS-managed prefix lists, which need an AWS account to read. Others, such as Lambda, have no service code of their own and use EC2 address space.
ASN-only checks miss China. The AWS China Regions are announced by partner networks whose registered names don't mention Amazon, so a check that looks for "Amazon" in the network name gets them wrong. This site's list of AWS networks includes them.
Vague labels. Most of AWS's published address space is labelled only EC2 or only AMAZON, so for most addresses the data can say "AWS, in this region" but not which service. The 2026 research article measures this.
Only the current file. Ranges are added, removed and moved between regions. For an address in an old log, today's answer may differ from the answer on the day. Third-party archives such as seligman/aws-ip-ranges keep the file's history.

What it will never tell you

Who the customer is. A match identifies AWS's use of a range, never the AWS customer or account behind an address. AWS doesn't publish that. If an AWS address is attacking you, report it to AWS; if it's in your own account, these steps find the resource.
Where a person is. The region is where AWS advertises the range, not where the user of an address is.
Whether traffic is good or bad. This isn't a reputation service. Being on AWS says nothing about intent: search engines, monitoring services and attackers all use it.

Accuracy

The answers are only as current and complete as AWS's published file, read through the rules on this page. They are provided as they are, without warranty. Before a decision that matters, such as blocking a network or sending a complaint, check AWS's own documentation. This site is not affiliated with or endorsed by Amazon Web Services.

If an answer looks wrong or misleading, please open an issue with the address you looked up and what you expected.

Source code

The code is public at github.com/aronbodogai/iptoawsservice. It is plain JavaScript with no third-party libraries. The matcher is tested against a pinned copy of AWS's file and a brute-force reference, and every value that comes from DNS or RIPEstat is displayed as plain text, never as HTML. A strict Content Security Policy allows no third-party scripts at all.