Post #1b: Setting up this blog itself (cont'd)

Some quick notes about AWS’ S3 static hosting, which is how this blog is being served to the Internet:

• If a custom domain name is used for the website being hosted, then:
  • That domain name must be hosted by AWS using their Route 53 DNS, and
  • The S3 bucket used to host the site must be named to match the custom domain, e.g. www.example.com to host a website by the same name.
• If a custom domain name is not used, then the bucket’s name must be globally unique per AWS’ S3 bucket naming rules. The hosted website will then be presented to the public as a long URL such as http://globally-unique-bucket-name-s3-website-us-east-2.amazonaws.com/
• Public read permissions must be explicitly granted on the bucket’s contents, i.e., the web files. This can be accomplished by applying a bucket policy like the one below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::Bucket-Name/*"
            ]
        }
    ]
}

(where Bucket-Name is replaced by the actual name of the S3 bucket.)

As mentioned in the previous blog post, HTTPS is not supported by S3 website endpoints. Also mentioned there is a project requirement for this blog to support TLS, making this a problem!

The next post will cover a way of getting around this limitation of S3 static hosting by using the AWS CloudFront CDN in order to allow an S3-hosted site to support HTTPS.