What is amazonaws.com?

Definition

amazonaws.com is the root infrastructure domain owned and operated by Amazon Web Services (AWS), a subsidiary of Amazon.com, Inc. The domain is used to host AWS service endpoints, customer resources, and the API gateways that power the AWS cloud platform. Subdomains under amazonaws.com identify specific AWS services — for example, *.s3.amazonaws.com for Amazon S3 object storage, *.execute-api.amazonaws.com for API Gateway endpoints, and *.elb.amazonaws.com for Elastic Load Balancing — and a unique tenant or resource identifier sits to the left of the service name.

Seeing amazonaws.com in a URL typically means one of three things: a legitimate AWS-hosted application is serving content, a customer-owned static asset (image, document, JavaScript bundle) is being delivered from S3, or in a smaller but consequential share of cases, an attacker is abusing AWS infrastructure to host a phishing page or malware payload. The domain itself is neutral — what matters is the subdomain, the resource owner, and the content being served. Treating an amazonaws.com URL as automatically trustworthy because “it’s Amazon” is one of the most common security mistakes end users make.

How amazonaws.com works

amazonaws.com is structured as a multi-tenant DNS namespace. Amazon controls the root domain and delegates subdomains in a predictable pattern that encodes both the service name and the customer resource identifier. When you create an S3 bucket called acme-corp-assets, AWS automatically provisions the DNS name acme-corp-assets.s3.amazonaws.com (and a regional variant such as acme-corp-assets.s3.eu-west-1.amazonaws.com). Similar patterns apply to EC2 instances, ELB load balancers, RDS databases, and Lambda function URLs.

DNS resolution for amazonaws.com runs on Amazon’s own authoritative DNS service, Route 53, with delegation handled by Amazon Registrar. TLS certificates for *.amazonaws.com subdomains are issued by Amazon Trust Services (the Amazon Root CA hierarchy), which has been cross-signed by other major CAs and is trusted by every mainstream browser and operating system. This means an attacker who places a phishing page on an S3 bucket gets a valid, free, browser-trusted HTTPS certificate by default — a fact that is the single biggest reason amazonaws.com phishing works so well in 2026.

In practice, traffic to amazonaws.com endpoints does not necessarily go all the way to Amazon’s origin data centres — content is often served from edge locations through Amazon CloudFront (which uses a separate root domain, cloudfront.net), and many AWS services sit behind regional accelerators. The underlying TCP/IP traffic is plain AWS infrastructure: ASN 16509 (AMAZON-02) and AS14618 (AMAZON-AES) are the primary autonomous systems carrying amazonaws.com responses. From an end-user perspective, what matters is that the entire request path is controlled by AWS — Amazon decides the network plumbing, but the customer who owns the S3 bucket or EC2 instance decides the content.

Common subdomain patterns

The amazonaws.com namespace follows a consistent right-to-left hierarchy: top-level is amazonaws.com, then service name, then customer or resource identifier on the left. Recognising these patterns is the fastest way to read an unfamiliar URL:

• S3 (Simple Storage Service) — {bucket-name}.s3.amazonaws.com or regional {bucket-name}.s3.{region}.amazonaws.com (for example acme-public.s3.us-east-1.amazonaws.com). Also s3.amazonaws.com/{bucket-name}/{key} in path-style.
• EC2 (Elastic Compute Cloud) — ec2-{ip-with-dashes}.compute-1.amazonaws.com for default public DNS names of EC2 instances (for example ec2-54-23-100-50.compute-1.amazonaws.com).
• ELB (Elastic Load Balancing) — {name}-{id}.{region}.elb.amazonaws.com, typical for Application Load Balancers and Network Load Balancers fronting customer applications.
• API Gateway — {api-id}.execute-api.{region}.amazonaws.com, used for REST and HTTP API endpoints that customer applications expose.
• Lambda function URLs — {url-id}.lambda-url.{region}.on.aws (note: newer Lambda URLs use on.aws, not amazonaws.com, but legacy and many integrations still resolve through amazonaws.com).
• RDS (Relational Database Service) — {instance-name}.{random-id}.{region}.rds.amazonaws.com, used for direct database connection strings; should generally not be exposed to public internet.
• Elastic Beanstalk — {environment-name}.{region}.elasticbeanstalk.com (separate root) — included here because users often confuse it with amazonaws.com.

CloudFront, Amazon’s CDN, deserves a separate note: CloudFront distributions are served from *.cloudfront.net, not amazonaws.com. So a URL like d1a2b3c4d5.cloudfront.net/image.jpg is still AWS infrastructure but lives on a different root domain. Some customers attach custom domains (CNAME records pointing to CloudFront), in which case the URL looks like the customer’s own domain — but a DNS lookup will reveal the cloudfront.net target.

Is amazonaws.com legitimate?

The amazonaws.com domain is registered to and operated by Amazon.com, Inc. — the registration WHOIS record consistently shows Amazon as the registrant, with administrative contacts at amazon-noc.com and abuse@amazonaws.com for reporting malicious content. The domain has been continuously operated since 2006 when AWS launched S3, and it appears in every major DNS authority record as legitimate AWS infrastructure.

Verifying that a specific amazonaws.com URL really points to AWS (rather than to a spoofed or hijacked variant) is straightforward in most cases. A DNS lookup on the hostname should resolve to an IP address in one of Amazon’s documented ranges (Amazon publishes the full list of AWS IP CIDR blocks at ip-ranges.amazonaws.com/ip-ranges.json, updated multiple times per day). The TLS certificate served by the endpoint should be issued by Amazon Trust Services (O=Amazon, CN=Amazon RSA 2048 M01 or similar) — you can inspect this by clicking the padlock icon in any browser or by running openssl s_client -connect host:443. Certificate transparency logs at crt.sh provide an independent record of every certificate ever issued for *.amazonaws.com, which makes large-scale spoofing essentially impossible to hide.

Verifying that the content is legitimate is a different question. A confirmed amazonaws.com URL with a valid Amazon-issued certificate still does not tell you whether the S3 bucket behind it belongs to a legitimate organisation or to an attacker. For that, you need to check the resource owner — which is often disclosed in the AWS account ID (a 12-digit number that sometimes appears in ARNs or service responses), in bucket policy comments, in the HTML metadata of the served page, or by reverse-lookup against threat intelligence feeds. In practice, the trust chain is: “Is this really AWS?” (almost always yes) → “Whose AWS account is this?” (harder to determine) → “Is this account known-good?” (requires external reputation data).

Phishing risk and abuse

Attacker abuse of amazonaws.com is now one of the most common categories of cloud-infrastructure phishing observed by security operations centres. Three properties of the AWS platform make it attractive to attackers: high-trust parent domain (most filters allow amazonaws.com by default), automatic free TLS certificates via AWS Certificate Manager and the built-in S3 HTTPS endpoint, and low-friction account provisioning (often using stolen credit cards or short-lived trial accounts).

Common abuse patterns: (1) S3 phishing pages — attackers create a bucket with a name that mimics a target service (login-microsoft365-secure.s3.amazonaws.com, office-login-portal.s3.amazonaws.com), upload a cloned login form, send the URL via phishing email or SMS, and harvest credentials. The padlock icon and amazonaws.com parent domain reassure victims who have been trained to look for HTTPS. (2) Open S3 buckets serving malware — attackers host malware payloads (Cobalt Strike beacons, infostealers, ransomware loaders) on public S3 buckets and reference them from malicious Office macros or compromised legitimate websites. (3) API Gateway and Lambda for C2 — sophisticated actors host command-and-control infrastructure on AWS to blend in with legitimate cloud-native application traffic. (4) Subdomain takeover — when a legitimate company decommissions an S3 bucket but leaves a dangling CNAME pointing to it, attackers can register the bucket name themselves and serve content under the legitimate company’s custom domain.

AWS publishes an abuse reporting channel (abuse@amazonaws.com) and typically takes down confirmed malicious buckets within hours to a few days after a verified report. The reaction time has improved significantly since 2020 but is still long enough for a successful phishing campaign — a typical campaign harvests credentials within the first 24-48 hours, well before takedown. Security teams should not assume that AWS abuse response replaces their own filtering, monitoring, and user training.

How to verify an amazonaws.com URL safely

A practical six-step checklist for verifying an unfamiliar amazonaws.com URL before clicking, downloading, or trusting it:

1. Parse the subdomain structure. Read right-to-left. Confirm the service identifier (s3, elb, execute-api, etc.) is one you recognise. Bucket names mimicking known brands (microsoft-login, office365-secure, apple-id-verification) are an immediate red flag — Microsoft, Apple, and other major brands typically do not host login pages on public S3 buckets.

2. Run the URL through urlscan.io. This service performs a real-time scan, renders the page in a sandbox, captures screenshots, records all network requests, and flags known phishing patterns. It is free for basic use and one of the fastest ways to triage a suspicious URL.

3. Check virustotal.com. VirusTotal aggregates verdicts from 70+ antivirus engines and threat intelligence feeds. Paste the full URL and look for any “malicious” or “phishing” flags. A clean result is reassuring but not conclusive — fresh attacker infrastructure is often unflagged for the first few hours.

4. Inspect certificate transparency logs at crt.sh. Search for the exact subdomain. Legitimate AWS resources typically show a clean CT history; suspicious or short-lived buckets often show certificates issued within hours of the phishing campaign starting.

5. Look up the AWS IP range. Run a DNS lookup (dig +short) and verify the resolved IP appears in Amazon’s published CIDR ranges (ip-ranges.amazonaws.com/ip-ranges.json). This confirms the URL really points to AWS rather than a spoofed look-alike domain.

6. Read the served HTML cautiously. If you must view the page, use a sandboxed browser (Browserling, urlscan’s preview, or an isolated VM). Check for obvious phishing signals — login forms posting to non-AWS domains, missing brand consistency, urgency language (“verify your account in 24 hours or it will be deleted”), and password fields rendered over plain HTTP form actions.

The first three steps usually take under two minutes and resolve most legitimate-vs-phishing questions. Steps 4 through 6 are reserved for cases where the initial scan is ambiguous or stakes are high (incident response, executive targeting investigations).

Blocking decisions for enterprises

Most enterprises cannot fully block amazonaws.com because doing so would break a large share of legitimate SaaS, CDN, and API traffic. Slack, Zoom, Atlassian Cloud, Dropbox, Salesforce, Microsoft 365 (parts of), and the majority of B2B SaaS applications depend on AWS endpoints — a blanket block would generate immediate help-desk flooding and broken integrations across the business.

Practical blocking strategies fall on a spectrum from least to most restrictive:

• DNS filtering with threat feeds — Cisco Umbrella, Cloudflare Gateway, DNSFilter, and Quad9 maintain blocklists of known malicious S3 bucket names. Subscribe to these feeds at the DNS resolver level to block lookups for confirmed-bad buckets while allowing all other amazonaws.com traffic. This is the lowest-impact option and the recommended baseline for most organisations.

• CASB inspection — a Cloud Access Security Broker (Netskope, Zscaler Internet Access, Microsoft Defender for Cloud Apps, Skyhigh Security) sits in line with outbound traffic, decrypts TLS, inspects S3 requests, and applies policy based on bucket name, content type, and data classification. CASBs can block uploads of sensitive data to unsanctioned S3 buckets while permitting legitimate AWS traffic.

• TLS-inspecting next-generation firewall — Palo Alto, Fortinet, Check Point, and other NGFW vendors can decrypt outbound HTTPS, inspect S3 content, and block malicious file types or known phishing URLs. Higher operational cost and more user impact than CASB but useful for organisations with on-premises traffic and existing firewall investments.

• Block direct S3 uploads from user devices — allow S3 access only through application-mediated paths (corporate file-share apps, sanctioned backup tools). This prevents users from exfiltrating data to personal AWS accounts via raw S3 uploads. Implementable through SSE-managed policies or CASB shadow IT controls.

• Selective allow-listing — for very high-security environments (defence, classified networks), block all amazonaws.com by default and explicitly allow-list specific subdomains corresponding to sanctioned SaaS providers. Operationally heavy but defensible for regulated workloads.

A reasonable starting policy for a typical mid-market enterprise: DNS-level threat-feed blocking + CASB inspection on outbound S3 traffic + user awareness training that explicitly covers *.s3.amazonaws.com phishing patterns. This combination catches the bulk of attacks without breaking legitimate SaaS workflows.

Best practices

• Train users to read URLs right-to-left. The root domain (amazonaws.com) and service identifier (s3) are what matter for trust attribution — not the leftmost subdomain, which an attacker controls completely.
• Apply DNS filtering with threat intelligence feeds. Subscribe to feeds that include known-bad S3 bucket IoCs (Cisco Talos, Spamhaus, Abuse.ch URLhaus). DNS blocking is cheaper and lower-impact than full TLS inspection.
• Treat amazonaws.com URLs in inbound email as suspicious by default. Email security gateways (Proofpoint, Mimecast, Microsoft Defender for Office 365, Abnormal Security) should flag amazonaws.com links for sandboxing or URL rewriting, especially when combined with credential-harvesting page patterns.
• For developers and DevOps teams: avoid using bare amazonaws.com URLs in production user-facing applications. Use CloudFront with a custom domain (assets.acme.com) — this gives users a brand-consistent URL and prevents accidental conditioning to trust raw AWS URLs.
• Monitor for subdomain takeover. When decommissioning S3 buckets or CloudFront distributions, audit DNS records for dangling CNAMEs that could be hijacked. Tools like aquatone, subjack, and continuous attack surface management platforms (Censys, Shodan, RiskIQ) help identify exposed takeover risks.
• Report abuse to AWS promptly. Use abuse@amazonaws.com or the AWS abuse form (aws.amazon.com/forms/report-abuse) when you identify malicious content on amazonaws.com — AWS typically acts within hours for confirmed phishing reports.
• Validate AWS account ownership for B2B partners. When integrating with external AWS resources, verify the 12-digit AWS account ID against your partner’s documented account through a signed channel; do not accept account IDs over unauthenticated email.

Related terms

• AWS — overview of Amazon Web Services as a cloud platform
• Amazon Web Services — full AWS service portfolio and pricing model
• Phishing — credential-harvesting attacks including S3-hosted phishing pages
• Domain spoofing — attacker techniques to impersonate trusted domains
• Cloud security — broader cloud workload protection patterns and frameworks
• SSL certificate — TLS certificate verification fundamentals relevant to amazonaws.com endpoints