AWS Domains List: How to Identify AWS-Hosted Domains

For competitive intelligence, lead generation, or security research, an accurate AWS domains list is valuable because hosting choice is a reliable proxy for company size, technical maturity and budget. It is also one of the harder things to determine from domain data alone, because most sites use AWS for a specific service — S3, EC2, Route 53, CloudFront — rather than as their registrar or their only provider.

The Challenge: Identifying AWS-Hosted Domains from Raw Data

There is no "AWS" flag in a WHOIS record. Identification has to be inferred, and there are three practical signals, in ascending order of cost.

The cheapest is the nameserver record. Domains using Route 53 have NS records matching the ns-XXX.awsdns-XX.com family, and that pattern is trivially greppable in a zone file. The second is IP address: AWS publishes its allocated ranges as a machine-readable file at ip-ranges.amazonaws.com, so resolving a domain and testing the result against those CIDR blocks catches EC2, S3 and CloudFront endpoints regardless of who runs the DNS. The third and most expensive is HTTP header inspection — Server: AmazonS3 or the presence of X-Amz-Cf-Id — which requires an actual request per domain.

The reason all three exist is that they catch different populations. Nameserver matching misses every domain that uses Cloudflare or a registrar's DNS while running its infrastructure on EC2. IP matching misses domains behind a third-party CDN that fronts an AWS origin. Header inspection catches CDN-fronted cases the other two miss, but it cannot be run against hundreds of millions of domains cheaply. A serious pipeline runs the cheap filters across the whole zone and reserves header checks for the shortlist.

Data Sourcing: Zone Files and Enriched Data

All three methods start from the same place: a list of domains for the zone you care about. WebTrackly's catalogue covers 716 TLD zone files and 716 matching enriched sets, totalling 279,944,703 domains across zones. The .com zone alone holds 163,422,083. The enriched packages include NS and IP fields, which means the first two identification methods above run directly against the downloaded CSV without any DNS lookups of your own.

Whichever route you take, freshness matters. For cold email outreach in particular, a domain list is only as good as its MX validation, and MX records change without notice — re-check deliverability the same week you send. WebTrackly exports each file at the moment of purchase rather than serving a pre-built snapshot, so the data reflects the current state of the zone.

The Nuance of ccTLDs

ccTLD zone files are considerably harder to obtain than gTLD zone files. Many country-code registries never publish a public zone, and others impose access restrictions, agreements or fees that make direct acquisition impractical. Germany's .de and France's .fr are the well-known examples, but the pattern repeats across much of the country-code space. Aggregated data is the only viable route to coverage for those zones, which is why per-TLD availability is uneven for every provider in this market.

Filtering Noise: Newly Registered Domains

A raw newly registered domain feed is noisy. A large share of new registrations are parked domains, PPC placeholders, or abandoned within weeks, so using a raw list for outreach wastes a substantial part of the effort. The highest-yield filter is nameserver-based: newly registered domains pointing at known parking nameservers such as ns1.sedoparking.com can be dropped as a group, with no network requests required. Registrar patterns correlate with the same clusters, so combining the two removes most of the junk in a single offline pass.

Freshness Over Volume

Marketplace dumps trade on volume, but for newly registered domain work the age of the data governs the result. A dump sold as "newly registered" may have been assembled months earlier, at which point the interesting property — that these are businesses in their setup phase — no longer applies. A smaller, recent export is the better input, which is the reasoning behind generating files on purchase rather than shipping an archive.

What Makes AWS Identification Harder Than Expected

Two complications come up repeatedly. The first is DNS and hosting decoupling: a large number of domains use a third-party DNS provider while routing traffic to AWS, so nameserver matching alone systematically undercounts. Correlating resolved IPs against the published AWS ranges is the fix, and it means keeping those ranges current — the JSON file changes regularly as capacity is added and retired.

The second is that the AWS ranges cover many services with different meanings. A domain resolving into a CloudFront range tells you it uses a CDN; a domain resolving into an EC2 range in a specific region tells you something quite different about where the workload actually runs. Treating "on AWS" as a single boolean throws away most of the signal in the data.

Practical Takeaways

1. Start from zone data, not from a crawler. Nameserver and IP matching against a full zone extract covers the majority of AWS-hosted domains at negligible cost. Reserve HTTP checks for what the cheap filters cannot resolve.
2. Keep the AWS IP ranges current. Pull ip-ranges.json on a schedule rather than hardcoding CIDRs. Stale ranges produce false negatives that look like genuine absence.
3. Segment by service, not just by provider. Distinguish Route 53, CloudFront, S3 and EC2 signals. "Uses AWS" is a much weaker qualifier than "runs EC2 in eu-west-1".
4. Filter NRDs before anything else. Drop parking nameservers and bulk-registration clusters first. Everything downstream gets cheaper.
5. Validate MX immediately before outreach. Use the MX field in the enriched CSV for the offline pass, then a verification service such as ZeroBounce or Email Hippo for the live check. WebTrackly does not sell contact records, email addresses or phone numbers — only domain-level data.

Frequently Asked Questions

Q: Does WebTrackly sell a ready-made AWS domains list?

A: Not as an "AWS" label. The catalogue includes 79 site lists organised by CMS and technology, plus enriched zone packages carrying NS and IP fields, which is what you filter against AWS nameserver patterns and published IP ranges. The identification logic stays on your side, which also means it stays under your control as AWS ranges change.

Q: Can I get a full list of domains for a specific TLD?

A: For the 716 TLDs currently in the catalogue, yes — see zones for the raw zone files and domain data for the enriched versions. Coverage for restricted ccTLDs is inherently narrower than for gTLDs, for the registry-policy reasons described above.

Q: How is the data delivered?

A: Choose a package, complete payment, and download a CSV inside a ZIP. The file is generated at purchase time. Packages start at $3.50; regular users can instead take Pro at $29/month (50 packages, 10 datasets, 30K API calls) or Enterprise at $99/month (200 packages, 50 datasets, 300K API calls).

Q: What is the best way to filter newly registered domains to avoid spam?

A: Filter on nameserver patterns first to remove parking clusters, then on registrar, then confirm the domain resolves to something other than a placeholder page. The first two steps run offline against the CSV and remove most of the noise before you spend anything on network requests.