Looking (again) at SEO metrics, I wanted to fix two misbehaviors of the website: compression and error pages.
Let’s get through the process:

HTTP compression

This has been an easy one. The SEO tool wanted the site to accept compression, so moving from requesting this (locahost:4000 is the local hexo server where the html rendering is immediately visible):

GET / HTTP/1.1
Host: localhost:4000
Accept-Encoding: gzip, deflate, br

and getting no matching compression to asking for this:

GET / HTTP/1.1
Host: marcoaguzzi.it
Accept-Encoding: gzip, deflate, br

and be answered

Content-Encoding: br

which is the confirmation that Brotli compression is enabled.

Requirement

Using one of many online SEO checkers, I’ve found that one of the most prominent issue is a missing HTTP 301 redirect from www domain to the main one (https://www.marcoaguzzi.it to https://marcoaguzzi.it). Since the website is a static s3 bucket served by cloudfront, this can be achieved by using a Lambda@Edge function.

What’s a Lambda@Edge function?

In the AWS ecosystem, Lambda functions are small programs that can be invoked by a number of different callers. The Amazon motto is: “write the code and forget about the server”.

Requirement

This website is served by an AWS Cloudfront distribution. The distribution has a cache behavior with a lambda@edge function attached to it to complete with “/index.html” the urls ending with a slash character.
Before this post, the Cloudformation Stack with the lambda and the one with the cloudfront distribution were separated. The only link between the two was the output value exported by the former and read by the latter.
Here’s what the AWS web UI lists:

The Cloudfront distribution can’t live without the lambda, so the deployment of the lambda should be done within the distribution one. The risk of having the two stacks completely separated is that an updated version of the lambda is not immediately referenced in the Cloudfront distribution (which is exactly what happened in the previous deploys of the website)

Taken approach and what’s needed

AWS Cloudformation Nested Stacks can be useful. One child stack is referenced in a parent stack and, when the parent is deployed, the resources of the child stack are deployed first.

Requirement

Once that the pipeline has been put in place for the main url, I needed to get rid of the account that originally contained the marcoaguzzi.it domain. Instead of only closing the AWS account, I wanted to clean the account of all the resources I created in the attempts. This could also be useful when a test account is used and periodically it should be wiped out, in order not to incur in costs for the provisioned resources. This is well presented in this article: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-deletion-of-aws-resources-by-using-aws-nuke.html

Solution

One intersting tool is aws-nuke: it scans all the resources created in an AWS account and deletes them, if it’s allowed to.
The name sounds quite menacing, but there is a couple of caveats that will (should?) prevent the user from doing the irreparable damage.

How it went

Last cloudfront issue

Finally the marcoaguzzi.it domain is actually responding without pointing to dev.marcoaguzzi.cloudns.ph. The last issue preventing the production cloudfront distribution from working was:

• The lambda@edge function that was linked to development distribution was at version 5, while its cloudformation output value was pointing to version 1
• The cloudformation stack deployed with production distribution read the output value and pointed to version 1, which wasn’t quite ready yet.
• Changing the lambda@edge link in production distribution from version 1 to version 5, ending the arn for the lambda with “:5” instead of “:1”, did the trick.

Fire up staging pipeline

Now that both domains have their own distribution responding, it was time to facilitate testing.