Migrating to AWS Amplify

· ·

In a recent blog post, I wrote:

this site runs on a shared host provided by Dreamhost. I know that sounds awfully outmoded in this day and age of containerizing everything! But I’ve had antrix.net on shared hosting for more than fifteen years now and if it ain’t broke…

I guess it was time to fix it!

Being in between jobs and unable to travel, I found myself with a few days of downtime on hand. I spent some of that time evaluating a few of the newer jamstack/serverless/heroku-inspired hosting services, live tweeting along the way. In the end, I’ve settled on AWS Amplify for the moment and migrated devdriven.by and antrix.net to it.

This post documents my setup on Amplify, i.e, a prime example of Infra-as-blog-post.

Build Setup

As I’ve described previously, I use Pelican as the static site generator to build this site. Pelican provides a Makefile that encapsulates the entire site generation process. Thus, replicating it in Amplify’s app build specification was straightforward:

version: 1
frontend:
  phases:
    build:
      commands: 
      - pip3 install -r requirements.txt
      - cd site
      - make publish
  artifacts:
    baseDirectory: site/output
    files:
      - '**/*'
  cache:
      paths: []

I’ve setup Amplify to build two branches:

I used the Environment Variables facility of Amplify to setup a variable named STAGING which is active in the develop branch build.

environment variables config

The Makefile uses the STAGING variable to make some changes in the build, e.g., use a different robots.txt with a global deny rule for the staging website.

Domain Setup

Amplify uses S3 for storage and Cloudfront as the CDN for static content. But these services are not exposed to you and are managed behind the scenes within Amplify’s service accounts. The end result is that Amplify creates a <some-id>.cloudfront.net fqdn and also makes your site available on <id>.amplifyapp.com. To use a custom domain such as antrix.net, we need to setup DNS records to point to the cloudfront fqdn.

While I’ve now migrated hosting away from Dreamhost, I continue to use them for DNS management. Following Amplify’s instructions, I setup four DNS records:

@        ALIAS    <id>.cloudfront.net
www      CNAME    <id>.cloudfront.net
next     CNAME    <id>.cloudfront.net
<id2>    CNAME    <id3>.acm-validations.aws

That last one is to provide AWS proof of domain name ownership.

Rewrites & Redirects

Amplify provides flexible URL rewrite/redirect features that addressed all of my requirements. You can create these using their web console and changes appear to take effect instantaneously. Here’s my configuration:

rewrites and redirects config

Performance

The few builds I’ve observed so far trigger almost immediately after a push to Github and then complete deployment in a minute. This is quite good already and I suspect can be improved further using build caching.

On to the page load performance, this was the site’s Lighthouse score prior to migrating:

lighthouse score before migration

And this is the score post migration to Amplify:

lighthouse score after migration

As expected, the performance score improved thanks to edge caching enabled by cloudfront.

☙