How to Find Companies Using Amazon S3 (API Guide 2026)

Amazon S3 is the default object store of the internet. Static sites live in it, single-page apps serve their bundles from it, and a large share of the images, PDFs, and downloads you encounter on the web are sitting in a bucket somewhere. That ubiquity makes “uses Amazon S3” one of the most broadly useful technographic filters you can apply to a domain list: it confirms an AWS footprint, and it does so at the storage layer, where companies rarely bother to hide it.

This guide covers what an S3 detection tells you about a company, the exact hostname, header, and DNS signals that reveal it, and how to turn a raw domain list into an S3-confirmed lead list with the DetectZeStack API—starting with a single curl command you can run right now, no API key required.

Why Find Companies Using Amazon S3?

Technographic data—what technology a company actually runs—often qualifies a prospect better than firmographics alone. An S3 detection is a specific, verifiable fact about a company’s infrastructure, and it feeds two very different workflows.

Sales Prospecting and Lead Enrichment

• It confirms an AWS commitment at the storage layer. Nobody adopts S3 in isolation. A company serving production traffic from a bucket has an AWS account, AWS billing, and almost always more AWS services behind it. If you sell cloud cost optimization, backup and archival tooling, data pipelines, security posture management, or anything that reads from or writes to S3, this filter narrows the market to companies your product actually fits.
• It maps the buyer. Object storage decisions belong to platform, data, and DevOps teams. An S3-confirmed list tells you which department owns the conversation and which pains are likely live: egress costs, bucket policy sprawl, lifecycle management, unencrypted objects.
• It stacks with other filters. S3 alone is a broad segment. S3 plus a specific application-layer detection—a CMS, a payment provider, a JavaScript framework—is a sharp one. Because a tech detection API returns the whole stack in one response, the intersection costs nothing extra to compute.

Security Research and Competitive Analysis

• Attack-surface mapping. Security teams inventory which clouds and storage services a domain depends on as part of third-party-risk reviews. Knowing that a target’s assets are served from S3 tells an auditor exactly which class of misconfiguration to check for next—bucket permissions being the classic example.
• Market research. Scanning a segment for storage choice shows how an entire market builds. A cohort serving from S3 is making different infrastructure bets than one on Google Cloud Storage or Azure Blob Storage, and shifts in that mix over time are a real competitive signal.

The same pipeline applies to any detectable technology—we have companion guides for finding companies using Amazon CloudFront and finding companies using Akamai. The filter changes; the workflow stays the same.

How Amazon S3 Usage Is Detected

S3 reveals itself in three independent layers: the URLs a page loads assets from, the HTTP response headers, and DNS. A site that hides one layer frequently gives away another.

URL and Hostname Signals

The most direct signal is the Server header. When a browser or crawler fetches an object straight from a bucket—whether through the REST endpoint or the static website endpoint—S3 answers with its own server banner. You can see it with a single curl -I:

$ curl -sI https://static.example.com/logo.png | grep -iE "^server|x-amz"
Server: AmazonS3
x-amz-request-id: 9F3A1B2C4D5E6F70
x-amz-id-2: kX8f2v...base64...==

The x-amz-request-id and x-amz-id-2 headers travel with S3 responses and independently confirm Amazon Web Services even when the Server banner is rewritten. The second URL-level signal lives in the page body: many sites keep their main domain on another host but load JavaScript bundles, images, or downloads from a bucket URL like https://s3.amazonaws.com/<bucket>/app.js or https://<bucket>.s3.amazonaws.com/app.js. Those hostnames in script sources are just as much an S3 confirmation as the header—and they survive setups where the primary domain never touches AWS at all.

DNS and CNAME Signals

When a company serves a custom domain from S3, DNS gives it away. The domain CNAMEs either to the bucket’s REST endpoint or—for static website hosting—to the region-specific website endpoint:

$ dig static.example.com CNAME +short
static.example.com.s3.amazonaws.com.

$ dig www.example.com CNAME +short
www.example.com.s3-website-us-east-1.amazonaws.com.

Both patterns are unambiguous. DetectZeStack matches both the .s3.amazonaws.com and .s3-website suffixes, and follows the full CNAME chain to find them—a domain often resolves through a vanity host first. For the mechanics of chain resolution, see DNS-Based Technology Detection.

Check Any Website for Amazon S3 with the DetectZeStack API

Checking headers, page source, and DNS by hand works for one domain. The API does all three layers in a single request.

Single Domain Check with GET /analyze

Try it right now against the public demo endpoint—no API key required. The demo is IP-rate-limited, so use it for spot checks rather than bulk scans:

$ curl -s "https://detectzestack.com/demo?url=example.com" \
  | jq '.technologies[] | select(.name == "Amazon S3")'
{
  "name": "Amazon S3",
  "categories": ["CDN"],
  "confidence": 100,
  "description": "Amazon S3 or Amazon Simple Storage Service is a service offered by Amazon Web Services (AWS) that provides object storage through a web service interface.",
  "website": "https://aws.amazon.com/s3/",
  "icon": "Amazon S3.svg",
  "source": "http",
  "version": "",
  "cpe": ""
}

The source field tells you which layer produced the evidence. A source: "http" entry at confidence 100 came from the Server: AmazonS3 header, a CSP match, or an S3 script URL in the page. When only DNS gives it away, the same technology comes back with source: "dns" at confidence 80 under the Cloud hosting category instead—reliable, but one step removed from a live header match. An S3 hit also implies Amazon Web Services, so expect an AWS entry alongside it.

For production use, call /analyze with your API key. The complete response is shaped like this:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
  "url": "https://example.com",
  "domain": "example.com",
  "technologies": [
    {
      "name": "Amazon S3",
      "categories": ["CDN"],
      "confidence": 100,
      "description": "Amazon S3 or Amazon Simple Storage Service is a service offered by Amazon Web Services (AWS) that provides object storage through a web service interface.",
      "website": "https://aws.amazon.com/s3/",
      "icon": "Amazon S3.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    },
    {
      "name": "Amazon Web Services",
      "categories": ["IaaS"],
      "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",
      "version": "",
      "cpe": ""
    }
  ],
  "categories": {
    "CDN": ["Amazon S3"],
    "IaaS": ["Amazon Web Services"]
  },
  "meta": { "status_code": 200, "tech_count": 2, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

The top-level categories map groups every detection by category so you can slice the stack without iterating the array. The meta object carries the HTTP status_code, the tech_count, and the scan_depth; response_ms and cached sit at the top level, not inside meta.

meta.scan_depth matters for list building. A value of "full" means the HTTP fetch succeeded and header plus page-source detection ran. A value of "partial" means the site blocked or timed out the HTTP request and only the DNS and TLS layers completed. Because S3 is also detectable from its CNAME suffixes, a "partial" scan can still confirm it—but an absent S3 entry on a "partial" scan is an unknown, not a no. Those domains belong in a retry queue.

Scanning a Prospect List with POST /analyze/batch

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["example.com", "aws.amazon.com", "getdropbox.com"]}'

The response wraps one result object per URL, each with the same shape as a single /analyze response, plus batch-level counters:

{
  "results": [
    { "url": "example.com",     "result": { "...full analysis..." : "" } },
    { "url": "aws.amazon.com",  "result": { "...full analysis..." : "" } },
    { "url": "getdropbox.com",  "result": { "...full analysis..." : "" } }
  ],
  "total_ms": 2341,
  "successful": 3,
  "failed": 0
}

Building an S3 Lead List Workflow Step by Step

Because each batch result matches the single-domain shape, the filtering logic is identical at any scale. Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10, and appends every S3-confirmed domain to s3_leads.csv with the detection source and tech count:

#!/usr/bin/env bash
# find-s3.sh — filter a domain list down to S3-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,source,tech_count" > s3_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
  urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
  curl -s -X POST "https://$HOST/analyze/batch" \
    -H "X-RapidAPI-Key: $KEY" \
    -H "X-RapidAPI-Host: $HOST" \
    -H "Content-Type: application/json" \
    -d "$urls" |
  jq -r '.results[]
    | select(.result != null)
    | .result as $r
    | ($r.technologies[] | select(.name == "Amazon S3")) as $s3
    | [$r.domain, $s3.source, ($r.meta.tech_count | tostring)]
    | @csv' >> s3_leads.csv
done

wc -l s3_leads.csv

A 1,000-domain list becomes 100 batch calls. Recording $s3.source per row lets you split header-confirmed hits from DNS-only ones downstream, and select(.result != null) skips domains that failed to resolve (those come back with an error field instead of a result). Three refinements worth making before outreach:

1. Split by source. An http-sourced hit means S3 is serving live traffic or page assets right now. A dns-sourced hit at confidence 80 means the domain points at a bucket endpoint. Both are real; the first is the stronger opener.
2. Cross-reference the rest of the stack. The full technologies array came back with every row you kept. S3 alongside Amazon CloudFront and Amazon Web Services is an all-in AWS shop; S3 alongside a non-AWS CDN is a mixed estate—a different conversation.
3. Score by meta.tech_count. Tech count is a rough proxy for stack maturity, useful for prioritizing which confirmed leads get personal outreach first.

Feeding these signals into a scoring model is covered in our lead enrichment pipeline guide, and the throughput, retry, and rate-limit mechanics are in how to batch scan 1,000 websites.

Amazon S3 vs Other Storage and CDN Setups

S3 detections are easy to conflate with neighboring AWS signals. Keeping them straight makes your lists cleaner:

• S3 vs CloudFront. S3 is the origin storage; CloudFront is the edge CDN. They are detected from entirely different signals (Server: AmazonS3 and bucket CNAMEs versus X-Amz-Cf-Id headers and cloudfront.net CNAMEs) and frequently—but not always—appear together. Track them as two columns: “S3-direct” companies are running without an edge in front, which is itself a signal if you sell CDN or performance tooling.
• S3 vs Akamai and other CDNs. A site can serve from S3 behind a non-AWS edge. Akamai in front of an S3 origin shows Akamai’s DNS fingerprints on the main domain while the S3 evidence hides in asset URLs—one more reason page-source signals matter. See finding companies using Akamai for that CDN’s detection surface.
• S3 vs the rest of AWS. Elastic Load Balancing, Elastic Beanstalk, and API Gateway each have their own CNAME fingerprints, and all of them—like S3—confirm the broader AWS commitment. If your qualifier is “runs on AWS at all” rather than “uses S3 specifically,” widen the jq filter to match any of them; our guide on how to detect AWS hosting catalogs the full signal set.

Get Your API Key and Start Detecting

The free Basic plan includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

1. Get a key at rapidapi.com/mlugoapx/api/detectzestack.
2. Spot-check a domain you know: curl -s "https://detectzestack.com/demo?url=yourdomain.com" | jq '.technologies[].name'
3. Run the batch script above against your first 100 domains.

Conclusion

Finding companies using Amazon S3 comes down to reading three layers well: the Server: AmazonS3 response header, the s3.amazonaws.com asset URLs in page source, and the .s3.amazonaws.com / .s3-website DNS CNAMEs. The header and page-source signals are the strongest; DNS is the reliable backup that still works when the HTTP fetch is blocked. A single /analyze call answers the one-domain question, /analyze/batch turns a raw list into an S3-confirmed lead list, and the source and meta.scan_depth fields tell you how much to trust each row. Swap the jq filter and the same pipeline segments by CloudFront, Akamai, or any other detectable technology instead.