Migrating to AWS Amplify
· #aws · #webdev
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.
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:
- Every commit to
developbranch is built & deployed to https://next.antrix.net/
- Every commit to
mainbranch is built & deployed to https://antrix.net/
I used the Environment Variables facility of Amplify to setup a variable named
STAGING which is active in the
develop branch build.
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.
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:
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:
And this is the score post migration to Amplify:
As expected, the performance score improved thanks to edge caching enabled by cloudfront.