In this post I’m going to show how I triggered an automatic cache invalidation for the Cloudfront distribution that is serving this website. As in the previous posts, all the resources will be provisioned via CloudFormation.
At the end of the post the CLI commands to create and / or update the resources will be shown.

The manual procedure

Once that the markdown file for a post is written and a local compilation / rendering has been made, the markdown source can be pushed on the git repo. That triggers the AWS Codepipeline that will download the source, render the markdown into html, and push the result to the S3 bucket served by Cloudfront.
Since Cloudfront is serving the S3 bucket, caching is in place. Newly pushed content won’t be visible until the cache expires, which is not feasible. So, after a successful compilation and pushing to S3, I manually get to Cloudfront distribution invalidations and fire a new invalidation. This way I’m sure that subsequent requests to the website will get the newly updated content.
In the images below the steps for manual invalidation are shown:

Go to CloudFront / Distributions, and search for “Invalidations” tab

Then selecting the last successful invalidation (shown below on the very left) and “copy to new” (upper right)

And then confirming the copy of the invalidation with the last path (the path /* is fine since AWS charges per invalidation, regardless of how much deep it is)

The invalidation takes a few minutes to be completed, and then the website is good to go. This is a mundane and forgetful-prone task, so I’m better automating it.

Automation setup

There is not an “invalidate cache” action that can be directly call from CodePipeline. A Lambda that actually creates the invalidation is needed and must be called as an action in the CodePipeline structure.
Let’s see in details the two resources:

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.