Congrats! you’ve just opened a brand new AWS account. What now? Beside getting rid of the root account, the second most wise action to do before doing anything is setting some control for bills.
I’m writing this post because some months ago I incurred in a 20 - something dollar bill from AWS for one of the accounts I opened in order to do some exercises. The account hadn’t much going on, but I left a disconnected elastic IP on for about a week… thus the mishap.
So let’s see what I’d love to have done in that situation, of course along with the respective Cloudformation templates.

Activate cost explorer

While being with the root account, you might want to turn cost explorer on. You can do it from two places: in the main UI you should see a box with “Cost and usage”, and at its center a button stating “Turn on cost explorer”

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.