Route 53 to S3 - partially working, mostly not working as required

Hi John,

The "Getting Started" topic in the Route 53 Developer Guide explains how to set up a website in an Amazon S3 bucket and how to configure Route 53 so internet traffic is routed to your bucket:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/getting-started.html

Recursive DNS resolvers typically cache the names of your name servers for 48 hours. If the recursive resolver that you're using submitted a DNS query for your domain's name servers just before you made the switch, it'll be another 12 hours or so before another query returns the names of your Route 53 name servers.

Sadly, because of the way S3 works, you need to redirect www.your-domain-name to your-domain-name. It has to do with the domain name that gets passed around in the Host header. I'll write this up someday to explain the details.

Also, what's the name of your domain? (I don't need anything secret, like your hosted zone ID. I can check using just your public domain name.) I'll take a gander at you current DNS configuration to confirm that it's set up correctly.

Scott

Hi Scott - many thanks for getting back to me.

The domain is "findtrylike.com". I'll double check the link you provided though I think I've followed all the set up correctly - certainly as far as a "visual inspection" checks out. Hence seeing if there are other ways I can debug what's going on to pinpoint what I've done wrong.

Hoping you can shed some further light.

Cheers - John

Hi John,

Everything seems to be in order from the DNS side. Take a careful look at that "Getting Started" topic. The process of routing traffic to an S3 bucket is filled with nitpicky details.

Scott

Thanks for the confirmation there Scott.

Some more diagnostics from my side to help with future articles/amendments to materials.

Testing in the Chrome browser can introduce it's own challenges. On closer inspection, part of the problem is that when requesting 'www.findtrylike.com', Chrome does a 307 internal rewrite and requests 'https://' instead. This can be turned off in the config, but runs the risk of messing up otherwise default behaviour.

I've been testing in Firefox and Insomnia and looking at the network/timeline traffic, which is more informative.

There are a couple of inconsistencies between documentation and current interface/options.

The instructions in the Getting Started link you provided don't mention turning off the 'block public' flags for the 'example.com' bucket - would be helpful to include these.

Also, for reader clarity, the second, optional 'www.example.com' bucket doesn't seem to need any access/policy settings. The redirect instructions alone are enough.

Again for reader clarity - putting 'example.com' in the bucket redirect properties does not appear to be referring to the bucket name. Such a value results in an HTTP/1.1 301 Moved Permanently response to the client, using the provided value ('example.com') which will is then treated as a domain - so the client requests 'http://example.com' - which of course then needs that to be set up as a public DNS entry in order for that redirect to work.

If the user wants specifically to refer to the bucket then the redirect on 'www.example.com' needs to point to example.com.s3-website-<zone>.amazonaws.com (NB using the bucket arn doesn't work).

I've not marked this as answered yet as I'm still trying to understand how I can diagnose whats going on w.r.t. DNS

Also, when it comes to setting up Route 53, then there seems to be some redundancy here. I'm not clear which bit of Route 53 record sets and aliases or which bits of S3 redirect are resulting in which part of the resolution from original web request from client to the final response being served from the S3 bucket.

I'll keep investigating.

Hi,

Thanks for the heads up about the "Getting Started" topic. I haven't revisited it in a while; based on your comments, it's time.

Scott

Description of process to set up is a little fragmented across the documentation for S3, Route 53, CloudFront and ACM. See the steps in the last post for a more concise, 'straight thought' recipe.

Hi,

Thanks for the feedback. I'll work with the CloudFront writer to clarify how this all works across services.

Scott

Another update. I've been using a related domain "findtrylike.eu" to do some comparative testing and experimenting with config.

Here are some observations/feedback for documentation...

There are at least two places I can redirect traffic of an S3 hosted website - in S3 itself (as per the setup instructions) and in Route 53 (and possibly in CloudFront - though I've not fully explored that).

My use case was to setup all three: S3 hosting, Route 53 for DNS/routing and CloudFront to add https. For me (being a bear of very little brain) the documentation across the three wasn't clear enough that if I was using Route 53, then some of the S3 instructions may not apply - and so on.

The S3 'redirect' as per instructions returns a client redirect (permanently moved) rather than acting
as a *nix style symbolic link - which I'd got the impression it was from the S3 documentation. If using S3 buckets as websites direct (e.g. for corporate storage directly accessed by s3-website) this wouldn't matter, but in the context of public domain name hosting it became confusing.

It does not appear to be necessary to serve content from 'example.com' - there was an earlier comment (from memory, about "www." causing problems in headers). I've set up "www.findtrylike.eu" as an S3 bucket with, no "findtrylike.eu" sibling - traffic routed by Route 53 via CloudFront (with www.findtrylike.eu as it's origin bucket) supporting both http and https and it's working find (React app so dynamic content/public content all being served fine).

With this setup, the url in my client (browser) stays as "www.findtrylike.eu" rather than getting rewritten (as a result of redirect) to "findtrylike.eu" (which was being caused by the S3 redirect).

Finally, I don't recall seeing anything about setting the Default Root Object to index.html in the CloudFront instructions for fronting an S3 website. I may have missed it, but it took me a while to realise that I was getting an Access Denied because I was trying to browse '/' rather than access a specific file. I found it and fixed it based on forums and articles rather than recalling having seen it in the main 'getting started' page - if it is there then perhaps it needs pointing out a little more clearly.

That was a bit of a dump of various learnings - hope it didn't sound too terse and hope it's of use when a documentation redraft comes around. Many thanks for the interaction and support - I'll flag this as fixed with the following summarised explanation:

If you want to set up an S3 hosted website using Route 53 to route domain traffic to it and using CloudFront to support https as well as http, then:

In S3:

• set up your S3 bucket 'www.example.com'
• set bucket permissions to unblock all four of the public access 'blocker' criteria
• set bucket permissions and policy as per AWS instructions
• for a React App (create react app) set both index and error pages to be index.html

In Route 53:

• Create an hosting zone for your domain 'example.com'
• Point your domain name servers to the AWS ones for the hosting zone and delete any current CNAME or A entries you have for your current domain

Do not create a record linking Route 53 at your S3 implementation. (The traffic route goes from client to DNS lookup (Route 53) to CloudFront to S3. So we don't need a direct Route 53 to S3 link.)

In CloudFront:

• Create a distribution for your domain 'example.com'
• Request a certificate from ACM for 'www.example.com' (also adding 'example.com') and use DNS verification
• Set the Default Root Object to 'index.html'
• Pick the http/https behaviour you want - I'm assuming you're going for http and https. Behaviour below when we test will reflect what you pick here.
• Use the ACM 'add the verification(s) to my name server' option - it will add CNAME(s) for the certificates to the Route 53 hosting zone for 'example.com'.
  - For the "Alternate Domain Names (CNAMEs)" add the web/domain name 'www.example.com' (and possibly 'example.com')

For the above, note the small print, the certificates are in Virginia zone - this confused me for a while as I tried to create ACM certificates in my zone as well and couldn't understand why CloudFront wasn't finding them.

Make a note of the CloudFront domain name, e.g 'squiggle123.cloudfront.net'

Back in Route 53:

• By the by, you should see your CNAME entries added when you created the ACM certificate(s)
• Add an A/Alias entry for the name 'www.example.com' with a target of the CloudFront domain name you created above (e.g 'squiggle123.cloudfront.net')

C'est tout

You'll need to wait for the CloudFront distribution to distribute itself. Once it has distributed, then from a browser go to 'http://www.example.com' and you should see your site, ditto 'https://www.example.com' (depending on the http/s behaviour you picked above).

Edited by: johnskelton3 on Mar 7, 2019 4:30 AM

Edited by: johnskelton3 on Mar 7, 2019 4:31 AM