The use case

This post comes from the fact that the token used by Codepipeline to connect to Github to download the source code of the website has expired. Hence, the automation “push and update the website” is not working. Here’s the error:

Let’s view how the secret is stored into cloudformation, and how codepipeline can connect.

The secret stack

The cloudformation stack is quite easy. It does not have any hard dependency on other stacks, and it’s used both to download code for dev and prod website.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Parameters": {
        "GithubOAuthTokenParameter": {
            "Description": "Github OAuth Token",
            "NoEcho": "true",
            "Type": "String"
        }
    },
    "Resources": {
        "GithubOAuthToken": {
            "Properties": {
                "Name": "GithubOAuthToken",
                "SecretString": {
                    "Ref": "GithubOAuthTokenParameter"
                }
            },
            "Type": "AWS::SecretsManager::Secret"
        }
    }
}

The next part of the post is dedicated on how to create and use this cloudformation template

Overview

After reading a Linkedin Top Voice post, I got curious about her suggestion of using an AI tool to help revamping the resume. The website is called https://resumeworded.com/.
The website offers three main services:

• Resume check - It analyzes the CV and produces a score and recommendations about it
• LinkedIn profile check - Same as the resume, but with the LinkedIn profile
• Resume targeting - Given a job description, it tells how far the resume is from it

This post is about my experience with it.

Free vs. paid versions

For each voice, there is a free and a paid version. The former offers the most basic checks, while the latter dives a lot deeper in the analysis.
I first played aroud with the free offer, and then decided to buy a one month subscription for the full version, to give it a proper try (full details on costs in the conclusions).

Check deep dive

Let’s dive into all the available checks.
If you’re interested in the conclusions you can skip this section, but you’ll miss all the differences between paid and free version. In order to give an order of magnitude, I’ve hid the paid checks behind a clickable dropdown.

Click on Read more for the full details

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.