A company hosts a static website on Amazon S3 with public read access enabled. The website is accessed via a custom domain name that uses Amazon Route 53. The domain name points to the S3 bucket's website endpoint. Users report that they can access the website using the S3 bucket URL but not the custom domain name. What is the most likely cause?
The S3 bucket has two distinct endpoints: the REST API endpoint (bucket-name.s3.amazonaws.com) and the static website endpoint (bucket-name.s3-website-region.amazonaws.com). For a custom domain to serve your static website, the Route 53 alias record must target the website endpoint, because that endpoint processes requests with the Host header matching the custom domain and returns the index document. If the alias record mistakenly points to the REST endpoint, the request is handled by the S3 API, which expects path-style addressing and returns a 403 Forbidden or a connection error when it receives a Host header for a custom domain. This is the classic misconfiguration that prevents the website from appearing.
Why this answer
For an S3 static website behind a custom domain, the Route 53 alias record must point to the bucket's S3 website endpoint (for example, bucket.s3-website-us-east-1.amazonaws.com), not the regional REST endpoint (bucket.s3.us-east-1.amazonaws.com). The regional endpoint does not serve index documents or support website redirects, so requests via the custom domain fail even though the bucket URL works. This mismatch is the most likely cause of the reported behavior.
Exam trap
SOA-C02 often tests the S3 REST endpoint vs. website endpoint distinction — candidates assume any S3 endpoint works for static hosting, but only the website endpoint serves index and error documents.
How to eliminate wrong answers
Option A is wrong because public read access is already enabled and the bucket URL works, so the bucket policy is not blocking access. Option B is wrong because S3 static website endpoints only support HTTP, and browsers do not block plain HTTP by default — the symptom would be a security warning, not a failure to resolve or load the site. Option D is wrong because a long TTL would delay propagation but would not cause a persistent failure once cached records expire, and the question describes a consistent failure rather than a transient one.