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.

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)

Summary

This website is build with Hexo, a static NodeJS blog framework. It allows a developer to define pages, posts, and all the elements using markdown format. Then the framework compiles them into static html, and the website is ready to be deployed on an accessible repository.