Static websites on Amazon s3 and CloudFront

Are you willing to deploy your website using s3?

Follow me in this tutorial to understand the basic on how to move your static website onto S3 + by automating the deploy with gitlab CI and even use your own domain name. We will then proceed further using CloudFront to allow HTTPS for our website and gain in website speed.

Static website tooling

First of all, this tutorial is about serving static websites, thus including front end web apps that may consume backends via Ajax, for instance an Angular or React application.

If your website is a Server side rendered (SSR) website, you better go use other deployment strategies like EC2, AWS Beanstalk or any web server capable of doing such.

There’s a plethora of tools for building blazing-fast websites that can source your content and delivery it as a static bundle, these tools are not being covered in this post.

In my case, im using GatsbyJS (for this website at the time of writing).

Here you can find a list of tools for this pourpose.

Creating the target bucket’s for your website

First of all, create the S3 Bucket that will contains your website assets.

1. Enter the AWS console

2. Create a new bucket

   • The name of the bucket must correspond to your domain (apex for root) name, for instance yourwebsite.com
   • If you want to include subdomains (like www.yourwebsite.com) create a second bucket named www.yourwebsite.com
   • Stick with the default S3 bucket setting and create the bucket

For the moment the bucket will only be accessible via AWS console or CLI.

Deploying the website assets using GitLab CI

In the static website modern paradigm, we update the website using CI/CD in contrast of handling the content directly in the CMS database like for instance when using WordPress, Joomla or any other Content Management System… and for good reasons:

• No need to handle database and web servers
• Security by design
• Cheaper and faster!

For automating the delivery of the website content, we will use a private GitLab repository and update the target bucket when the pipeline has succeeded.

Setting up the repository and IAM permissions

In your GitLab repository project, under Settings -> CI/CD set the variables for accessing the Amazon API:

• AWSACCESSKEY_ID
• AWSSECRETACCESS_KEY

The values are the programmatic access key of an IAM user, that can be securely be stored in GitLab setting variables. Do not ever store the credentials in your repository files (e.g. as variables in your yaml file) even if the repository is private, always use environment variables!

I suggest creating an IAM user for this specific operation, giving programmatic access only from the CLI and allowing to only delete/put objects from S3 to conform to the least privilege principle.

Here and example IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:DeleteObjectVersion",
                "s3:ListBucketVersions",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::*/*",
                "arn:aws:s3:::yourwebsite.com"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "s3:GetAccessPoint",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAllMyBuckets",
                "s3:ListAccessPoints",
                "s3:ListJobs"
            ],
            "Resource": "*"
        }
    ]
}

Make sure to add permissions to work with objects versions if your bucket has versioning in place.

Using GitLab and the AWS cli for deploying to S3

Once you have set up the AWS credentials variables, write your gitlab-ci.yml in order to enable the pipeline. In this example we are building our Node.js application (GatsbyJS), update your build task according to your project.

The S3 deploy task is very simple: - Delete all from bucket - Publish the built assets from the build pipeline
The task, it’s rather ok, as long as your project build files name changes every build and your content is relatively small. If not, maybe will be more efficient to update only the objects using S3 cp and use filtering in order to avoid the removal of non-changing/heavy files.

stages:
  - build
  - deploy

build app:
  image: node:10.16.0
  stage: build
  script:
    - npm install
    - npm run build
  cache:
    paths:
      - public
  only:
    - master

s3 deploy:
  image: python:latest
  stage: deploy
  only:
    - master
  cache:
    paths:
      - public
  before_script:
   - pip install awscli
  script:
   - aws s3 rm s3://yourwebsite.it/ --recursive
   - aws s3 cp public s3://yourwebsite.it/ --recursive

Serving your website through S3

To serve your website from S3, we need to enable website hosting on the bucket.

1. Enter the AWS S3 console
2. Enter yourwebsite.com bucket settings -> permissions
3. Clear all Block all public access
4. Enter yourwebsite.com bucket settings -> properties
5. Tick “Use this bucket to host a web site”
6. Enter yourwebsite.com bucket settings -> bucket policy

7. Create a S3 resource policy to allow S3 public access

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

Once done your S3 bucket will be marked as “public” and if you go to settings -> properties -> Hosting static website you should be able to browse your website with the DNS name provided for you by S3:

http://yourwebsite.com.s3-website.[region].amazonaws.com

Serving the S3 bucket website from a custom domain name

To use your own domain name you might either:

• Register a new domain via Route53
• Register a new domain from a third party registrar (ex. Netsons, Godaddy)

If your domain in registered outside AWS Route53 you need to:

1. Create a public hosted zone in Route53

2. Set the aws nameservers provided by Route53 in your registrar nameserver targets (NS records)

3. create an alias record for your hosted zone that points to the bucket

   • Empty alias for your root domain (yourwebsite.com)
   • www, blog., demo. for your subdomains (these records should have an appropriate bucket with the same name!!! or the will not show up in the Route53 alias)

If you plan to access your website with www.yourwebsite.com, make sure to create the bucket for this subdomain. If the content is the same, just redirect this bucket website hosting to the apex bucket as following:

If the DNS records have been propagated, you should be now able to access your bucket content through your domain.

We have now deployed our static website with S3, but how we can use HTTPS?

You can’t use HTTPS with S3 website Hosting!

We need to use CloudFront on top of S3 in order to use HTTPS for our website.

Using CloudFront for distributing our website via HTTPS

Since we want to use TLS, let’s get first a free SSL certificate from AWS Certificate Manager (ACM).

1. Enter the console and visit Certificate Manager
2. Make sure to select us-east-1 region because we need to provide a certificate in that region for CloudFront
3. Request a certificate for the domain example : yourwebsite.com
4. Create additional domain name records for subdomains or use *.yourwebsite.com as a wildcard (all)
5. In the next page ACM will display the CNAME records your have to provide to Route53 (some can be applied directly by ACM)

It may take a while to provision the certificate but once done, enter CloudFront from the console.

6. Create a distribution for the web

7. Set these fields

   • Origin Domain Name = the domain (should be listed from Route53)

   • Restrict Bucket Access = yes

   • Origin Access Identity = Create a New Identity (CloudFront will create it for us)

   • Grant Read Permissions on Bucket = yes (we are lazy!, let CloudFront apply the policy to S3 for us)

   • Default Cache Behavior Settings -> Viewer Protocol Policy = either HTTP and HTTPS or Redirect HTTP to HTTPS

   • Alternate Domain Names (CNAMEs) = set the domains comma separated. Example: yourwebsite.com, www.yourwebsite.com.

     important! If not listed here, you won’t be able to add the appropriate DNS records in Route53

   • SSL Certificate = Custom SSL Certificate, select the certificate we requested before on ACM!

   • Review your own settings choices and create the distribution

It might take some time to provision the distribution, but with CloudFront we are done. We already allowed CloudFront to provide for us the Origin Access Identity (OAI) and also to set the bucket policy for us.

If we now visit our S3 bucket policy, we will see it has changed:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PolicyID",
            "Effect": "Allow",
            "Action": [
                "s3:DeleteObject",
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::yourwebsite.com"
            ]
        },
      {
            "Sid": "2",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::**CloudFront**:user/**CloudFront** Origin Access Identity XXXXXXXX"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::yourwebsite.it/*"
        }
    ]
} 

CloudFront has added for us the Reference to the OAI that allow CloudFront to access our bucket (and the clients from it). We can now remove the bucket policy statement for direct S3 public access safely, we don’t need it anymore and we want users to access our website only from the CloudFront distribution.

{
    "Sid": "PolicyID",
    "Effect": "Allow",
    "Action": [
        "s3:DeleteObject",
        "s3:PutObject"
    ],
    "Resource": [
        "arn:aws:s3:::yourwebsite.com"
    ]
}

Last but not least, we need to update our Route53 records in order to use CloudFront instead of S3 alias.

1. Visit Route53 from the console
2. Update alias records (yourwebsite.com, www.yourwebsite.com) to alias the CloudFront distribution instead of the S3 bucket

You should be now able to browse your S3 bucket website from CloudFront using HTTPS. If you selected Default Cache Behavior Settings to redirect HTTP to HTTPS in the CloudFront distribution, you will only be able to access the website using TLS (redirect).

Wrapping up

In this tutorial we have:

• Deployed our static web site with GitLab CI to Amazon S3 using the AWS CLI.
• Enabled S3 static hosting
• Used our own domain name for the S3 backed website using Route53 Hosted zones
• Improved our website speed and security (HTTPS) by using CloudFront in top of S3