How to Tell if a Website Is Hosted on AWS

To tell whether a website is hosted on AWS, look for Amazon's fingerprints across four places: headers, cookies, DNS and IP ranges. The quickest start is curl -I https://example.com — scan for x-amz-* headers, a Via header mentioning CloudFront, or the CloudFront markers x-amz-cf-id and x-amz-cf-pop. An AWSALB cookie reveals an AWS load balancer. Then resolve the domain with dig and check whether the IP sits in AWS's published ranges or reverse-resolves to amazonaws.com. The crucial caveat throughout: AWS's CloudFront CDN (or any CDN) fronts the origin, so these signals often confirm AWS is in the delivery path without pinning down exactly which service hosts the origin.

It builds on how to read a website's HTTP response headers, how to find out where a website is hosted and how to find a website's IP address.

Why AWS is harder to pin down than a single host

AWS is not one product — it is a sprawling cloud platform, and a site "on AWS" might be served by EC2 instances, an Elastic Load Balancer (ELB), S3 static hosting, CloudFront (the CDN), Lightsail, container or serverless services, or several of these together. That breadth is why AWS detection is about reading multiple signals rather than one tidy header. It is also why the origin-versus-edge distinction matters more here than almost anywhere: CloudFront commonly sits in front of an origin, so you frequently detect "AWS at the edge" cleanly while the true origin stays hidden behind it. Keeping that distinction front of mind is what makes AWS detection honest rather than overconfident.

Signal 1: x-amz-* headers

The most direct fingerprints are response headers prefixed x-amz-, which AWS services emit.

Amazon S3. Content served from or through S3 surfaces x-amz-request-id and x-amz-id-2 headers, and S3's static-website or REST endpoints can show a Server: AmazonS3 value. These are a clear sign S3 is in the delivery path — common for static sites, asset buckets and Jamstack origins.

Amazon CloudFront. CloudFront, AWS's CDN, adds x-amz-cf-id (a request ID) and x-amz-cf-pop (the edge point of presence, an airport-style code naming the city that served you), plus a Via header that mentions CloudFront. Seeing these means CloudFront is delivering the site.

Any x-amz- header strongly indicates an AWS service is involved. Just remember it identifies the service (S3, CloudFront) more than the ultimate origin.

Signal 2: CloudFront, the most common AWS tell

For a great many AWS-fronted sites, CloudFront is the signal you will hit first. Its markers are distinctive and hard to fake while genuinely using the service:

via: 1.1 <hash>.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR50-C1
x-amz-cf-id: <long-identifier>
x-cache: Hit from cloudfront

The Via value naming cloudfront.net, the x-amz-cf-pop edge location, and x-cache: Hit from cloudfront together are essentially definitive for CloudFront. But — and this is the point to keep repeating — CloudFront can front an origin hosted anywhere: another AWS service, a different cloud, or an on-premises server. So CloudFront markers confirm AWS is delivering the site at the edge; they do not prove the origin is on AWS. This is the same edge-masks-origin behaviour described in how to tell if a website uses Cloudflare or another CDN — just with AWS's own CDN.

Signal 3: ELB load-balancer cookies

If a site runs behind an AWS Elastic Load Balancer, it often sets a session-affinity cookie with a tell-tale name: AWSALB (Application Load Balancer) or AWSALBCORS, and on older Classic Load Balancers AWSELB. Spotting one of these in the Set-Cookie header (or in DevTools → Application → Cookies) is a strong indication the site sits behind AWS load balancing, which in turn implies AWS-hosted compute (EC2 or containers) behind the balancer. Unlike CloudFront, an ELB cookie points more directly at AWS hosting the application, not just delivering it at the edge — so it is a particularly useful signal when you are trying to get past the CDN layer to the origin.

Signal 4: DNS and reverse DNS

DNS corroborates the headers and sometimes reaches the origin. Resolve the domain:

dig www.example.com
nslookup www.example.com

Then take the resulting IP and do a reverse-DNS lookup:

dig -x <ip-address>

If the reverse lookup returns a hostname ending in amazonaws.com — for example an EC2 pattern like ec2-x-x-x-x.compute-1.amazonaws.com, or an ELB hostname — that is direct evidence of AWS. The catch is the familiar one: if a CDN fronts the site, the resolved IP belongs to the CDN edge, so the reverse lookup shows the CDN, not the AWS origin. DNS analysis is therefore most decisive when no CDN is masking the origin; when one is, treat the CDN's address as the edge and look elsewhere for the origin.

Signal 5: AWS IP ranges

AWS publishes its public IP ranges (the ip-ranges.json file Amazon maintains), which means you can take a resolved IP and check whether it falls within an AWS range, and even which region and service that range is associated with. A match indicates AWS hosting for whatever responded at that address. As with reverse DNS, the value depends on what the IP represents: if it is a CloudFront edge IP, you have confirmed CloudFront/AWS at the edge; if it is the origin (no CDN in front), you have confirmed the origin is on AWS, often with a region attached. IP-range checking is the most rigorous of the DNS-side methods, and pairing it with the header signals gives the most complete read.

The signal table

Signal	Where to find it	What it indicates
x-amz-request-id, x-amz-id-2	Response headers	Amazon S3 in the path
Server: AmazonS3	Response headers	S3 static hosting / endpoint
Via: ... cloudfront, x-amz-cf-id, x-amz-cf-pop	Response headers	Amazon CloudFront (edge) — strong
x-cache: Hit from cloudfront	Response headers	CloudFront cache serving the response
AWSALB / AWSALBCORS / AWSELB cookie	Set-Cookie, DevTools	AWS Elastic Load Balancer — points at AWS compute
Reverse DNS to *.amazonaws.com	dig -x <ip>	AWS-hosted (origin if no CDN)
IP in AWS published ranges	IP-range check	AWS hosting, often with region

A CloudFront cluster confirms AWS at the edge; an ELB cookie or an amazonaws.com reverse-DNS gets you closer to the origin.

Method 1: curl -I and DevTools

Start with headers. Run curl -sI https://example.com and scan for the x-amz-* headers, the CloudFront Via/x-cache, and any AWS cookie in Set-Cookie. In the browser, the DevTools Network tab shows the same response headers on the document request, and the Application → Cookies panel reveals an AWSALB cookie cleanly. If the bare domain redirects, follow it with curl -sIL so you read the final response, per the HTTP headers guide. Headers are the fastest way to confirm CloudFront or S3 in the path.

Method 2: dig / nslookup and reverse DNS

Move to DNS to corroborate and to chase the origin. Resolve the domain with dig www.example.com (and the apex), take the IP, and run a reverse lookup with dig -x <ip>. A *.amazonaws.com result is direct AWS evidence. If you have the tooling, check the IP against AWS's published ranges to attach a region. Remember the gating question: is a CDN in front? If the headers show CloudFront, the resolved IP is almost certainly an edge address, so the DNS evidence describes the edge — note that explicitly rather than calling it the origin.

Method 3: detection tools

Tools summarise much of this automatically. BuiltWith and Wappalyzer report AWS, CloudFront and S3 when their fingerprints are present, and IP-intelligence services map an address to AWS and a region. These are convenient for a quick read, but the manual header-plus-DNS approach is what lets you reason carefully about edge versus origin, which the automated label sometimes glosses over. Broader audits such as StackOptic fold AWS and CDN detection into a wider hosting and technology report, so you see the AWS signals alongside the rest of the stack and in context.

A worked example

You are assessing a media site's infrastructure. curl -sI https://www.example.com returns Via: 1.1 <hash>.cloudfront.net (CloudFront), an x-amz-cf-pop: IAD89-P2, an x-amz-cf-id and x-cache: Hit from cloudfront. That is a textbook CloudFront signature — AWS is delivering the site at the edge. But you are careful: CloudFront fronts the origin, so you do not yet know where the origin lives. You resolve the domain and the IP reverse-resolves to a cloudfront.net edge, confirming the edge rather than the origin. Digging further, the homepage's main HTML carries x-amz-request-id and x-amz-id-2 headers — S3 markers — suggesting the origin is an S3-hosted static site behind CloudFront, a very common AWS pattern. So the honest read is: CloudFront at the edge, S3 likely at the origin, all on AWS — with the origin inference clearly labelled as inference, not as something the edge headers alone proved.

What AWS hosting tells you about a site

Identifying AWS is meaningful infrastructure intelligence. The simple fact of AWS signals a cloud-hosted site rather than traditional shared hosting, which hints at scale and engineering investment. The specific services say more: S3 behind CloudFront is the classic static/Jamstack pattern; an ELB cookie implies EC2 or container-based application servers behind a load balancer, a more dynamic architecture; CloudFront alone tells you the delivery layer but leaves the origin open. For cloud and infrastructure sales, knowing a prospect runs on AWS (and roughly how) is direct qualification. For competitive and architecture research, it reveals how a rival builds and scales. And for a security or reliability view, the presence of a load balancer and a CDN says something about resilience. As always, pair the AWS read with the rest of the stack — see how to find out where a website is hosted for the wider method.

How reliable is AWS detection?

Reliable for confirming AWS in the delivery path, less so for pinning down the exact origin — and being clear about that difference is the whole game. CloudFront and S3 markers are distinctive and trustworthy, and an AWSALB cookie or an amazonaws.com reverse-DNS gets you closer to the origin with confidence. The persistent limit is the CDN: when CloudFront (or a third-party CDN) fronts the site, the edge signals are clean but the origin is deliberately hidden, so "AWS is delivering this" is answerable while "exactly which AWS service hosts the origin" sometimes is not. The right posture is to report what each signal actually proves — edge, load balancer, or origin — and to label inferences about the masked origin as inferences. Do that, and AWS detection is both accurate and honest.

The workflow

1. Run curl -sI https://example.com and scan for x-amz-*, CloudFront Via/x-cache, and AWS cookies.
2. Check cookies in DevTools for AWSALB/AWSELB — a pointer toward AWS compute.
3. Resolve and reverse-resolve the IP (dig, dig -x) and check it against AWS IP ranges.
4. Decide edge vs origin — if CloudFront is present, treat the resolved IP as the edge.
5. Report precisely — confirm AWS in the path; label any claim about the hidden origin as inference.

Go deeper

• The header reference: how to read a website's HTTP response headers.
• Where a site lives: how to find out where a website is hosted.
• The CDN question: how to tell if a website uses Cloudflare or another CDN.
• The IP side: how to find a website's IP address.

Want AWS, CloudFront, the CDN and full hosting picture identified automatically? Analyse any site with StackOptic — one report, free, no sign-up.