To set up a static site on S3 with DNS on Route53, we have two options.
If we want the users to type www.example.com
and have that auto-replaced in the address bar by example.com
, we would do the following.
- On S3: we set two buckets, one for
example.com
and the other forwww.example.com
. We "Redirect all requests" fromwww.example.com
toexample.com
while the latter has "Enable website hosting" and of course the actual files. - On Route53: At the hosted zone for
example.com
, we get two Record Sets already made: one NS and the other SOA. We set a third, an Alias Record Set with Name:example.com
and set the Value to the one offered by the UI. We also set a fourth, a CNAME, with Name:www.example.com
and Value:example.com
.
That works!
Suppose now that we want to do the converse.
If we want the users to type example.com
and have that auto-replaced in the address bar by www.example.com
, I expected that the following would be the recipe.
- On S3: we set two buckets, one for
example.com
and the other forwww.example.com
. We "Redirect all requests" fromexample.com
towww.example.com
while the latter has "Enable website hosting" as well as the actual files. - On Route53: At the hosted zone for
example.com
, we get two Record Sets already made: one NS and the other SOA. We set a third, an Alias Record Set with Name:www.example.com
and set the Value to the one offered by the UI.
This doesn't work.
What am I missing?
CNAME
here, with two buckets, is a situation that is wrong, even though it works, for now, only because your buckets are in the same region and served by common hardware within S3. Both records should be A-record ALIASes to their respective buckets, no matter which direction you want the redirection to go. A future change to bucket DNS sharding by S3 could make that CNAME invalid if your buckets were served from different clusters within the S3 region.