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.

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.

Introduction

For the next steps of this blog, I wanted to migrate the domain marcoaguzzi.it from the first AWS account I’ve signed to the second one (the one that actually has the real site going on, dev.marcoaguzzi.cloudns.ph/).
These poses a few threats:

• The registered domain should be moved to the first account to the second, and should continue serving the old site (now a placeholder with redirects)