Detect Amazon Web Services on Any Website: Service Map

September 3, 2026 · 12 min read

"Does this site run on AWS?" is the wrong question. Amazon Web Services is not one product; it is a catalog of well over two hundred, and a website can touch one of them or thirty. The useful question is which AWS services sit on the public request path, because that answer separates a static bucket behind a CDN from a load-balanced application with an API gateway in front of it. This guide maps every AWS service that leaves an externally visible fingerprint, explains which detection layer proves each one, and shows how to pull the whole map out of the DetectZeStack API with one call.

Every JSON example below uses the fields the API actually returns, and the worked /demo response is a live scan captured while writing this article. If you want the five manual methods (dig, curl, IP ranges, openssl) spelled out step by step, How to Detect AWS Hosting on Any Website covers them. This article is about turning those signals into a per-service map.

What It Means to Detect Amazon Web Services (It Is Not One Signal)

AWS Is a Family of Services, Each With Its Own Fingerprint

There is no single "AWS header." Each service announces itself differently, and some do not announce themselves at all. CloudFront stamps X-Amz-Cf-Id and X-Amz-Cf-Pop on every response and puts (CloudFront) in the Via header. An S3 website endpoint returns Server: AmazonS3. A load balancer with no application behind it answers with Server: awselb/2.0. Elastic Beanstalk, Amplify, API Gateway, and Global Accelerator are quieter at the HTTP layer but loud in DNS, because each one hands the customer a hostname under a service-specific suffix that they then CNAME their own domain to. Route 53 is invisible in both HTTP and CNAME records and shows up only in the domain's nameservers. And AWS Certificate Manager reveals itself in the TLS handshake, where the certificate issuer organization reads Amazon.

A detector that only looks at one of those layers will confirm AWS on some sites and miss it on others. A detector that looks at all of them can name the services individually.

Why a Single Yes/No Is Not Enough for Sales, Security, or Migration Work

The people who search for "detect amazon web services" rarely want a boolean. A sales team selling cost-optimization tooling needs to know whether a prospect is running CloudFront (a CDN spend conversation) or Elastic Beanstalk (a compute-rightsizing conversation). A security reviewer mapping a vendor's attack surface needs to know that an API Gateway endpoint and a Global Accelerator are exposed, not just that "AWS" is somewhere in the picture. A migration lead tracking a move off a legacy host needs to see the individual services appear over successive scans. All three of those workflows need the service map, and the API is built to return it.

The AWS Service Map DetectZeStack Can Identify

The table lists every AWS-family technology the API can report, the layer that produces it, the exact signal, and the confidence score attached to a match from that layer. Names are the strings you will see in technologies[].name.

Reported nameLayerSignalConfidence
Amazon Web Serviceshttpx-amz-request-id, x-amz-id-2, or implied by any other AWS service match100
Amazon Web Servicestlscertificate issuer organization contains "Amazon"70
Amazon CloudFronthttpx-amz-cf-id, Via: ... (CloudFront)100
Amazon CloudFrontheaderX-Amz-Cf-Pop100
Amazon CloudFrontdns*.cloudfront.net80
Amazon S3httpServer: AmazonS3, or an s3 amazonaws.com host in Content-Security-Policy100
Amazon S3dns*.s3.amazonaws.com, *.s3-website*80
Amazon ELBhttpServer: awselb100
AWS ELBdns*.elb.amazonaws.com80
AWS Global Acceleratordns*.awsglobalaccelerator.com80
AWS Elastic Beanstalkdns*.elasticbeanstalk.com80
AWS Amplifydns*.amplifyapp.com80
AWS API Gatewaydns*.execute-api.amazonaws.com80
Amazon EC2httpServer: ... (Amazon)100
Amazon ECShttpServer: ecs...100
AWS WAF Captchahttpx-amzn-waf-action: captcha100
AWS Route 53/dns endpointNS hosts containing awsdns-dns_provider field

Amazon Web Services (TLS Issuer: Amazon-Issued Certificates)

The generic "Amazon Web Services" entry arrives by two routes. At the HTTP layer it is either matched directly from S3-style x-amz-request-id and x-amz-id-2 headers, or implied by any other AWS service fingerprint: a CloudFront, S3, ELB, EC2, or ECS match automatically adds "Amazon Web Services" alongside it. That entry carries confidence 100, source http, and the category PaaS.

At the TLS layer, the detector reads the certificate issuer during the handshake. AWS Certificate Manager issues certificates with an organization of Amazon, so any issuer string containing that word produces an "Amazon Web Services" entry with confidence 70, source tls, and the category Cloud hosting. The lower score is deliberate: an ACM certificate proves the operator has an AWS account and terminated TLS on an AWS service, but says nothing about which one.

Same name, one entry. The technologies array is deduplicated by name, and HTTP-layer matches are merged first. If the HTTP layer already produced "Amazon Web Services", the TLS entry is dropped. That means the category on the entry depends on which layer found it: PaaS when the HTTP layer did, Cloud hosting when only TLS did. Filter on the name, not the category.

Amazon CloudFront (cloudfront.net CNAME and X-Amz-Cf-Pop Header)

CloudFront is the most frequently detected AWS service because it fronts everything else. Three independent signals catch it. The HTTP fingerprint matches x-amz-cf-id or a Via header ending in (CloudFront). A custom header rule matches X-Amz-Cf-Pop, the edge location code, which is useful on the rare responses where the request ID header is stripped but the POP header survives. And at DNS, any CNAME chain that terminates in *.cloudfront.net matches even when the site returns no HTTP response at all. The CloudFront prospecting guide turns that into a lead list.

Amazon S3 (s3.amazonaws.com and s3-website CNAMEs)

A static site served straight from a bucket is identified at the HTTP layer by Server: AmazonS3, or by an s3 host under amazonaws.com inside the Content-Security-Policy header. At DNS, the two bucket-hosting patterns are bucket.s3.amazonaws.com (virtual-hosted style) and bucket.s3-website-us-east-1.amazonaws.com (website endpoint, which embeds the region). The DNS signature matches on the .s3.amazonaws.com and .s3-website suffixes, so both forms report "Amazon S3". How to Find Companies Using Amazon S3 goes deeper on the bucket-URL and asset-path signals.

AWS ELB and AWS Global Accelerator (Load Balancer Layer)

A domain that CNAMEs to name-1234567890.us-east-1.elb.amazonaws.com is pointing straight at an Application or Network Load Balancer, and the DNS layer reports it as "AWS ELB" in the Cloud and Load Balancer categories. The HTTP layer has its own ELB rule, Server: awselb, which fires only when no application behind the balancer overwrote the header. Note that the HTTP rule reports the name "Amazon ELB" while the DNS rule reports "AWS ELB". They are not deduplicated against each other, so a site can legitimately carry both. Global Accelerator, the anycast front door for multi-region deployments, is DNS-only: a CNAME ending in .awsglobalaccelerator.com.

AWS Elastic Beanstalk, AWS Amplify, and AWS API Gateway (PaaS and API Layer)

These three are DNS-only detections, because the services themselves do not add distinctive response headers on a custom domain. Each hands the customer a hostname on a service-owned suffix:

API Gateway is the interesting one for a scan of the main website, because it is usually on a subdomain such as api.example.com rather than the apex. Scanning the apex will not find it; scanning the API hostname directly will.

AWS Route 53 (awsdns- Nameservers)

Route 53 does not appear in the /analyze technologies array, because it is a DNS hosting product rather than something on the HTTP request path. It is surfaced by the /dns endpoint instead. Route 53 nameservers follow the pattern ns-NNN.awsdns-NN.com (with .net, .org, and .co.uk variants), and the endpoint's dns_provider field reports AWS Route 53 whenever an NS record contains .awsdns-. Zillow is a straightforward example; its NS set at the time of writing is four awsdns hosts:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=zillow.com" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | jq '{domain, ns, dns_provider}'
{
  "domain": "zillow.com",
  "ns": [
    "ns-1978.awsdns-55.co.uk",
    "ns-709.awsdns-24.net",
    "ns-1126.awsdns-12.org",
    "ns-258.awsdns-32.com"
  ],
  "dns_provider": "AWS Route 53"
}

Route 53 is a weak hosting signal on its own, since plenty of teams host DNS on AWS and serve the site elsewhere. It is a strong account signal: the company has an AWS bill.

Reading an AWS Footprint From the Layers

DNS Layer vs HTTP Layer vs TLS Layer: What Each One Proves

Each layer answers a different question, and treating them as interchangeable produces wrong conclusions.

When You See CloudFront but Not S3: Origin Is Hidden

The most common AWS result is CloudFront plus the implied "Amazon Web Services" entry, and nothing else. That is not a detection failure. CloudFront terminates the connection at the edge and makes its own request to the origin, so the scanner only ever talks to the edge. Whether the origin is an S3 bucket, an ALB, an EC2 box, or a server in a different cloud is invisible unless the origin leaks a header through the CDN. S3 sometimes does (its Server: AmazonS3 header survives when the distribution forwards it), which is why some CloudFront sites also report S3. When they do not, read the result as "edge confirmed, origin unknown" and do not infer that the origin is off-AWS.

Confidence Scores and the Source Field

Every entry carries a confidence integer and a source string. The scores are fixed per layer rather than computed per site: HTTP fingerprint matches are 100, custom header matches are 100, DNS suffix matches are 80, TLS issuer matches are 70. The source field is one of http, header, dns, or tls. In practice it is more useful than the score, because it tells you what kind of evidence you are holding: a dns source means a routing decision, an http source means an observed response, a tls source means a certificate.

Entries from the DNS, header, and TLS layers omit the description, website, icon, version, and cpe fields, since those come from the HTTP fingerprint database. A DNS-layer CloudFront entry is compact:

{
  "name": "Amazon CloudFront",
  "categories": ["CDN"],
  "confidence": 80,
  "source": "dns"
}

API Example: Detect Amazon Web Services With One Call

Try It Free With /demo (No API Key Required)

The public /demo endpoint runs the full detector without authentication. It is limited to 20 requests per hour per IP address, so it is for confirming the response shape rather than for scanning lists:

curl -s "https://detectzestack.com/demo?url=docs.aws.amazon.com" | python3 -m json.tool

This is the complete live response for that domain, captured on September 3, 2026:

{
  "url": "https://docs.aws.amazon.com",
  "domain": "docs.aws.amazon.com",
  "technologies": [
    {
      "name": "Amazon CloudFront",
      "categories": ["CDN"],
      "confidence": 100,
      "description": "Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds.",
      "website": "https://aws.amazon.com/cloudfront/",
      "icon": "Amazon Cloudfront.svg",
      "source": "http"
    },
    {
      "name": "Amazon Web Services",
      "categories": ["PaaS"],
      "confidence": 100,
      "description": "Amazon Web Services (AWS) is a comprehensive cloud services platform offering compute power, database storage, content delivery and other functionality.",
      "website": "https://aws.amazon.com/",
      "icon": "Amazon Web Services.svg",
      "source": "http"
    },
    {
      "name": "HSTS",
      "categories": ["Security"],
      "confidence": 100,
      "description": "HTTP Strict Transport Security (HSTS) informs browsers that the site should only be accessed using HTTPS.",
      "website": "https://www.rfc-editor.org/rfc/rfc6797#section-6.1",
      "source": "http"
    }
  ],
  "categories": {
    "CDN": ["Amazon CloudFront"],
    "PaaS": ["Amazon Web Services"],
    "Security": ["HSTS"]
  },
  "meta": { "status_code": 200, "tech_count": 3, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1750
}

Read it against the layers. CloudFront came from the HTTP layer (the response carried x-amz-cf-id), and that match implied "Amazon Web Services" at confidence 100 under PaaS. No DNS-layer entry appears because the hostname's CNAME chain ends at an Amazon-internal proxy name rather than a cloudfront.net host. No TLS-layer entry appears because the HTTP layer had already produced "Amazon Web Services" and the duplicate was dropped. The origin behind CloudFront is not visible, which is the normal case described above.

Authenticated Scan With /analyze and Filtering for AWS Services in the Technologies Array

For real usage, sign up on RapidAPI and call /analyze. The response shape is identical to /demo; the difference is that requests count against your monthly plan, and cached responses (X-Cache: HIT) are refunded. Because AWS entries come under both the "Amazon" and "AWS" prefixes, filter with a regex rather than a single name:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=docs.aws.amazon.com" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | jq '[.technologies[] | select(.name | test("^(Amazon|AWS) ")) | {name, categories, confidence, source}]'
[
  {
    "name": "Amazon CloudFront",
    "categories": ["CDN"],
    "confidence": 100,
    "source": "http"
  },
  {
    "name": "Amazon Web Services",
    "categories": ["PaaS"],
    "confidence": 100,
    "source": "http"
  }
]

The regex deliberately excludes "Amazon Pay", "Amazon Advertising", and "Amazon Associates", which the fingerprint database also knows about but which are retail and ad products rather than infrastructure. If you only need a yes/no for a single service, /check filters server-side; the tech parameter is case-insensitive:

curl -s "https://detectzestack.p.rapidapi.com/check?url=docs.aws.amazon.com&tech=Amazon%20CloudFront" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com"
{
  "domain": "docs.aws.amazon.com",
  "technology": "Amazon CloudFront",
  "detected": true,
  "confidence": 100,
  "version": "",
  "categories": ["CDN"],
  "response_ms": 1712,
  "cached": false
}

Comparing AWS Adoption Across Competitors With POST /compare

/compare accepts 2 to 10 URLs and returns each domain's full technologies array, a shared list of technologies present on every domain, and a per-domain unique list. Piping it through the same regex gives an AWS-only comparison table:

curl -s -X POST "https://detectzestack.p.rapidapi.com/compare" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["www.zillow.com", "www.coursera.org", "www.twitch.tv"]}' \
  | jq -r '
      .domains[]
      | "\(.domain)\t\([.technologies[] | select(.name | test("^(Amazon|AWS) ")) | .name] | join(", "))"
    '

Each line is a domain followed by its AWS services, or an empty column when none were found. Against those three domains at the time of writing, Zillow and Coursera both report CloudFront plus Amazon Web Services, while Twitch reports neither because its edge is a different CDN. Each URL in the request counts as one request against your plan.

Scanning a Domain List With POST /analyze/batch

/analyze/batch takes up to 10 URLs per call and scans them concurrently on the server. The response has a results array with one item per URL; each item carries either a result object in the /analyze shape or an error string, plus top-level successful, failed, and total_ms counters. This loop chunks a domain file into tens and writes one JSON line per domain with its AWS service list:

#!/usr/bin/env bash
# aws-map.sh — usage: aws-map.sh domains.txt > aws-map.jsonl
set -euo pipefail
KEY="${RAPIDAPI_KEY:?set RAPIDAPI_KEY}"
HOST="detectzestack.p.rapidapi.com"

split -l 10 "$1" chunk_
for f in chunk_*; do
  body=$(jq -R -s -c 'split("\n") | map(select(length > 0)) | {urls: .}' "$f")
  curl -s -X POST "https://${HOST}/analyze/batch" \
    -H "x-rapidapi-key: ${KEY}" \
    -H "x-rapidapi-host: ${HOST}" \
    -H "Content-Type: application/json" \
    -d "$body" \
  | jq -c '.results[] | {
      url: .url,
      error: (.error // null),
      aws: [ (.result.technologies // [])[]
             | select(.name | test("^(Amazon|AWS) "))
             | {name, source, confidence} ]
    }'
  rm -f "$f"
done

Keep the rows where error is non-null rather than discarding them. A domain that blocked the fetch may still have produced DNS-layer entries (the API returns those with scan_depth set to partial), and a domain with no result at all should be recorded as "could not scan", never as "not on AWS". Quota planning and retry patterns for larger lists are in Batch Scan 1,000 Websites for Tech Stack.

Practical Uses of AWS Service-Level Detection

Segmenting Prospects by AWS Service Rather Than Just Cloud Provider

"Uses AWS" describes a large fraction of the commercial web and is too broad to route a sales motion. The service map lets you cut it. CloudFront-only sites are CDN and media-delivery buyers. Sites reporting AWS ELB or Global Accelerator are running real application tiers and are candidates for observability, load-testing, and cost tooling. Elastic Beanstalk and Amplify sites are smaller teams on managed platforms who buy developer tooling, not infrastructure consulting. API Gateway on a subdomain flags an organization that exposes a public API and might need API security or documentation products. Each of those is a different list, and the aws array in the batch output above is enough to build all of them.

Third-Party Risk Reviews and Supply-Chain Mapping

Vendor questionnaires ask "where is our data hosted?" and get a checkbox back. A scan gives evidence. An elb.amazonaws.com CNAME with a region in the hostname confirms both the provider and the region without asking anyone. A CloudFront POP header shows which edge served your request. An Amazon-issued certificate on a vendor's API hostname confirms TLS is terminated on AWS. Running the vendor list through /analyze/batch quarterly and diffing the aws arrays catches the vendor who quietly moved.

Tracking Cloud Migrations Over Time

Migrations show up in the map as services appearing and disappearing. A site moving onto AWS typically gains Route 53 first (in /dns), then CloudFront, then the origin-side services. A site consolidating from EC2 behind ELB onto containers gains "Amazon ECS" in the HTTP layer. The /history endpoint stores each scan, and /changes returns the added and removed technologies between snapshots, so the migration timeline is a query rather than a spreadsheet. Track Technology Changes Over Time covers that workflow. The same approach works for the other direction; How to Detect if a Website Uses Google Cloud describes the GCP signals you would watch for on the way out.

DetectZeStack vs Browser Extensions for AWS Detection

Browser extensions are excellent for a single page you already have open, and for AWS they will usually spot CloudFront from the response headers. What they cannot do is see the DNS layer, which is where Elastic Beanstalk, Amplify, API Gateway, Global Accelerator, and most ELB detections live, or the TLS layer, which is where an Amazon-issued certificate identifies AWS on a site that returns nothing to the browser. They also cannot be pointed at a list of ten thousand domains. The API resolves DNS, reads the certificate, and fetches the page in one call, returns each layer's findings with a source tag, and does it for batches. For a single page, use whatever is closest to hand. For a map, use the API. The CDN and hosting provider guide makes the same point across Cloudflare, Fastly, Akamai, and Vercel.

Conclusion: Get Your API Key

Detecting Amazon Web Services well means detecting its services individually. DNS names the routing decisions (CloudFront, S3, ELB, Global Accelerator, Elastic Beanstalk, Amplify, API Gateway), HTTP names the responder (CloudFront, S3, ELB, EC2, ECS), TLS names the certificate authority (AWS Certificate Manager), and the nameservers name Route 53. One /analyze call returns the first three layers as separate entries with a source on each; /dns adds the fourth. To start:

  1. Confirm the response shape with curl "https://detectzestack.com/demo?url=docs.aws.amazon.com". No key required.
  2. Sign up at rapidapi.com/mlugoapx/api/detectzestack and copy your x-rapidapi-key. The free plan is 100 requests per month with no credit card.
  3. Run the /analyze example with the ^(Amazon|AWS) filter against a domain you care about.
  4. Move to /compare for a competitor set and /analyze/batch for a list.

Related Reading

Map Every AWS Service on a Site in One API Call

One HTTP request resolves DNS, reads the certificate, and fingerprints the response, then returns CloudFront, S3, ELB, and every other detected technology with its source layer. 100 requests per month free. No credit card.

Get your free API key

Get API updates and tech detection tips

Join the mailing list. No spam, unsubscribe anytime.