How to check if an IP address belongs to AWS

AWS publishes the address ranges it uses in one file, ip-ranges.json. If an IP falls inside one of those ranges, AWS uses it. If it doesn't, you have learned less than you might think: plenty of addresses that route to AWS are left out of the file on purpose.

Below are four ways to check, from quickest to most thorough, and what each one can and can't tell you.

Method 1: look it up here

Paste an IP address, a CIDR block or a hostname into the box above. The page downloads ip-ranges.json directly from AWS, matches your query in your browser and shows:

• whether the address is in AWS's published ranges;
• the service and region of the most specific matching range, explained in plain English;
• every matching range, because ranges nest (an EC2 block often sits inside a larger AMAZON block);
• when AWS published the data you are looking at.

Some examples, with what they returned when this guide was written: 3.18.1.10 (EC2 address space, US East (Ohio)), 13.32.12.39 (CloudFront), 52.94.76.1 (AWS, service not disclosed) and 8.8.8.8 (not in AWS's ranges).

The matching happens in your browser, so the addresses you look up aren't sent anywhere unless you choose one of the optional checks, such as reverse DNS. Hostnames are the other exception: to resolve one, the page asks a public DNS-over-HTTPS resolver. The privacy page lists who sees what.

Method 2: search ip-ranges.json yourself

The file is public and authoritative. Download it and check when AWS published it:

curl -sO https://ip-ranges.amazonaws.com/ip-ranges.json
jq -r '.createDate' ip-ranges.json   # publication time, UTC

jq has no CIDR matching, so this filter turns IPv4 addresses into numbers and compares them. It prints every range that contains the address:

jq -r --arg ip 3.0.5.33 '
  def ip2n: split(".") | map(tonumber) | .[0]*16777216 + .[1]*65536 + .[2]*256 + .[3];
  ($ip | ip2n) as $n
  | .prefixes[]
  | (.ip_prefix | split("/")) as [$net, $len]
  | ($net | ip2n) as $start
  | select($n >= $start and $n < $start + pow(2; 32 - ($len | tonumber)))
  | [.ip_prefix, .service, .region, .network_border_group] | @tsv' ip-ranges.json

3.0.0.0/15    AMAZON                ap-southeast-1  ap-southeast-1
3.0.0.0/15    EC2                   ap-southeast-1  ap-southeast-1
3.0.5.32/29   EC2_INSTANCE_CONNECT  ap-southeast-1  ap-southeast-1

For IPv6 as well as IPv4, Python's standard library does the CIDR maths:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | python3 -c '
import ipaddress, json, sys
ip = ipaddress.ip_address(sys.argv[1])
d = json.load(sys.stdin)
for p in d["prefixes"] + d["ipv6_prefixes"]:
    net = ipaddress.ip_network(p.get("ip_prefix") or p["ipv6_prefix"])
    if ip in net:
        print(net, p["service"], p["region"], p["network_border_group"])
' 2600:1f18::1

2600:1f18::/33 AMAZON us-east-1 us-east-1
2600:1f18::/33 EC2 us-east-1 us-east-1

Reading the rows

• Several rows are normal. Every published address is also covered by an AMAZON row, on the same range or a larger one, and smaller ranges sit inside larger ones. The most specific range (the longest prefix) is the best answer.
• EC2 means EC2 address space, not necessarily an instance. Load balancers, NAT gateways, Lambda and many AWS services use it too.
• A range tagged AMAZON and nothing else means AWS uses it but doesn't say for what.
• A range tagged both S3 and EC2 is used only by S3, according to AWS's range overlap rules.
• AWS updates the file frequently and without a fixed schedule. For an address in an old log, the range may have been added, removed or moved since.

The ip-ranges.json reference explains every field.

Method 3: check who announces the address (ASN and whois)

Every public IP is announced to the internet by a network with an autonomous system number (ASN). Team Cymru's free whois service maps an IP to its ASN in one command:

whois -h whois.cymru.com " -v 3.18.1.10"

AS      | IP         | BGP Prefix   | CC | Registry | Allocated  | AS Name
16509   | 3.18.1.10  | 3.16.0.0/14  | US | arin     | 2017-12-20 | AMAZON-02 - Amazon.com, Inc., US

ASNs you are likely to meet:

Caveats:

• An ASN tells you who routes the traffic, not which service or region uses it.
• Customers can bring their own address blocks to AWS (BYOIP). Amazon usually announces them, but a customer can also announce them from its own AS number (BYOASN), and whois shows the customer's organisation, not Amazon.
• Whois shows who holds a block (for AWS space, Amazon entities such as Amazon Technologies Inc.), not who uses a given address today.
• Matching on the name "Amazon" misses the China Regions and wrongly includes Amazon's corporate networks and Amazon Leo, which aren't AWS.

Method 4: reverse DNS

dig +short -x 3.18.1.10
ec2-3-18-1-10.us-east-2.compute.amazonaws.com.

dig +short -x 13.32.12.39
server-13-32-12-39.bud50.r.cloudfront.net.

A name ending in compute.amazonaws.com (or compute-1.amazonaws.com for US East (N. Virginia)) is AWS's default name for EC2 address space. Names ending in r.cloudfront.net are CloudFront edge servers, and bud50 is the edge location, Budapest. The region guide decodes more patterns.

• No name proves nothing. Many AWS addresses have no reverse DNS at all, especially IPv6 addresses and ranges tagged only AMAZON.
• Confirm the name points back. Whoever controls an address block controls its reverse DNS, so check the forward lookup: dig +short ec2-3-18-1-10.us-east-2.compute.amazonaws.com should return 3.18.1.10.
• Custom names exist. AWS customers can set their own reverse DNS on Elastic IP addresses, so a name that doesn't look like AWS doesn't rule AWS out.
• An ec2-… name isn't proof of an instance. Load balancers, NAT gateways and AWS's own API endpoints get the same kind of name.

Why "not listed" doesn't mean "not AWS"

AWS publishes ranges for the services customers commonly use for egress filtering, and says it doesn't publish them for every service. Addresses that can route to AWS but won't match the file include:

• Bring your own IP (BYOIP). Customer-owned blocks brought to AWS are excluded from ip-ranges.json by design.
• Amazon SES mail servers. When we checked, almost none of SES's sending space was in the file. Reverse DNS names ending in amazonses.com are a better signal.
• Unpublished services and unused space. Some services have no published ranges, and some Amazon space isn't in the file at all.
• Stale copies. A copy of the file that is a few days old misses new ranges.

So when an address isn't listed, check the ASN (method 3). On this site, a not-listed result offers a one-click check that asks RIPEstat whether an Amazon network announces the address. It is opt-in because it sends the IP to RIPE NCC.

Which method to use

Whichever method you use, a match tells you AWS operates the range. It never tells you which AWS customer is behind an address: see who owns this AWS IP address?

Related guides

• Find the AWS region of an IP address
• Traffic from AWS IP addresses is hitting my server
• How to report abuse from an AWS IP address

Sources

• AWS: AWS IP address ranges
• AWS: Syntax for AWS IP address range JSON (including range overlaps)
• AWS: Find the IP address ranges for AWS services (official jq examples)
• AWS re:Post: How do I find the resource that owns an unknown IP address?
• Team Cymru IP to ASN mapping