Moved the site to AWS Amplify Console

Sat, Sep 5, 2020

For years I’ve hosted this site and a few others on a Linode VM running nginx, which was fine, but in the process of tidying up my monthly spending I decided to look for a cheaper alternative. I decided to go back and look at the hugo lambda project that I’d come across when I first started using Hugo to build my site. Somehow that led down a path to AWS Amplify Console for hosting static sites, and it seemed like just the sort of “serverless” web hosting I was looking for all bundled into a simple interface.

For my needs it was perfect. I just hooked it into the git repo I use for this Hugo site. It automatically detected the hugo build settings, and now every time I push to the master branch it triggers a build and deploys to Amazon’s Cloudfront CDN. Other neat features include the ability to specify alternate branches in git for test sites, etc. They can be configured to deploy to alternate URLs and the build system supports per-branch environment variables. This means for the ‘test’ branch, I can specify the HUGO_BASEURL as https://test.plain.cool and have a fully functional test site.

Another nice feature was the ability to deploy purely static (no build system) site from a git repo. The Amplify Console grumbled a little about not detecting the build requirements, but pushing past that it did the right thing - deploying the html,css,etc from a git repo to a hosted web space.

Of course it supports custom domains. If you host your DNS in Route53 and have the necessary r53 privileges, Amplify will take care of setting up your site’s DNS for you. However, if your DNS is elsewhere you just have to jump through a typical domain ownership verification hoop. The only other DNS catch is that since the site is deployed to Cloudfront, your site’s DNS needs to be a CNAME. This means if you’re deploying a domain that has MX records on it, you’ll need to set the naked domain as a CNAME-flattening record. One of my sites’ DNS was hosted at ENOM, and I discovered they didn’t support CNAME-flatteners, so I had to shift that domain’s DNS elsewhere.

The only real challenging piece of setting up Amplify was getting the AWS permissions correct for my AWS user. The trick is that all of this neat front-end automation requires the ability to deploy backend resources, and I didn’t find a pre-canned, AWS-managed policy to cover amplify functionality. I did find this document which specified a set of permissions for an IAM policy to use the Amplify CLI. However, I still had issues until I granted my user the “amplify:*” permission in addition to the permissions listed. Elsewhere in Amazon’s docs, I found mention of creating a Service Role and granting it to the Amplify Service - the document shows granting the service the AdministratorAccess policy, which is the keys to the kingdom. I haven’t done that, and seem to be functional for my basic Amplify Console usage of the service.