Cloud Confusing

Explaining hosting, AWS, Wordpress, static sites, and all manner of cloud solutions.

This has been one of the worst parts of S3 hosting for me. In fact, it’s been one of the worst parts of all of AWS since I started my cloud hosting journey (shenanigans?). Understanding the Amazon Web Services S3 Website and REST API endpoint has been endlessly confusing and has caused me hours of frustration.

This simple in concept, but not so much in execution (at least for the novice). Amazon states it clearly:

When you configure a bucket for website hosting, the website is available via the region-specific website endpoint. Website endpoints are different from the endpoints where you send REST API requests.

We already know that Amazon S3 can host websites. In case you didn’t know S3 has an application programming interface (API) that you can use to interact with S3, for such tasks as: getting information about a bucket, creating a bucket, deleting a bucket, deleting an object in a bucket, or more advanced things, like enabling versioning for an S3 bucket. APIs are not the topic of today.

What You Need to Know About S3 Endpoints

It’s not a whole lot. Just get down the absolute basics and you’ll be in a good place to move forward. Here goes:

A website endpoint will like look this:
bucket-name.s3-website-region.amazonaws.com

In practice this might look like:

http://aws-website-mysitecom-fbuor.s3-website-us-east-1.amazonaws.com

An S3 API endpoint will look something like:
s3.website-region.amazonaws.com

One thing that makes the REST API endpoints extra confusing is that they can be used either with or without the website name in the URL. The following is the outline for the same request done in each style.

Virtual-hosted-style S3 REST endpoint:
Target file: /index.html
Host: MyBucket.s3-us-east-1.amazonaws.com

Path-style S3 REST endpoint:
Target file: /MyBucket/index.html
Host: s3-us-east-1.amazonaws.com

As you can see, the choosing of the specific bucket the files is in can happen in the path of the target file or the sub-sub-domain of the host URI, it makes no difference to S3.

How to Find the S3 Website Endpoint

  1. Go to the AWS console and then to S3
  2. Click into your chosen bucket (that is, your website)
  3. Click to Properties > Static Website Hosting
  4. The website Endpoint will be at the top of that box

When To Use the S3 Website Endpoint

The main time to use the website endpoint is when you are doing your DNS entry (such as a CNAME) to an S3 hosted site. In this scenario MySite.com, should have a DNS record that points to mysite.com.s3-website-.amazonaws.com. (You could use CloudFront as well, but a story for another day.)

Another good time to use the website endpoint is in the CloudFront > Origin Setting > Origin Domain Name field. By putting the website endpoint here, you can use all the S3 functions that make the service so powerful for static hosting, like routing rules and bucket policies. These are important since S3 can’t do otherwise simple things, like 404 a specific URL or 301 a file or path on its own. Instead you need to use S3-specific tools.

Long story short, if you S3 bucket is configured to be a website, you need to use the website endpoint! Seems obvious when stated in plain English, but it’s not immediately obvious when you have an S3-hosted site that works perfectly under almost all circumstances, but for some reason your routing rules don’t work!

As with most of the other posts on CloudConfusing.com, this is an oversimplification of the process and tools designed to get you from point A to point B so if you have any tips or feedback, please let me know.

December 24th, 2017

Posted In: AWS

Tags: , , , ,