In my previous blog post, I wrote why it is important to write good commit messages. In this post I will highlight an example how this works in your advantage. Using an AWS CodeCommit repository.

We have all seen it. You see something in your source code. You do not know why it was added. And you look at the commit history. And then you see: “fix bug” or “add feature name”. How helpful is that message? In this blog post I will address how you can write commit messages that are helpful. And optimized for the reader.

Setting up and managing access to your EC2 instances can be challenging. There are a lot of things you need to consider. How do you rotate your keys? Who logged in using that key? How do you limit the risk of thread actors? And what did they do? What if you could log the complete session in a different AWS Account? And encrypt it using a customer managed KMS key? That would give you complete visibility and auditability on your shell sessions. In this blog post I will address those questions using AWS Session Manager.

If you are thinking of setting up a landing zone using ADF in AWS you will need to read this. And why? Because I will tell you why you need to set up two landing zones. And how you can use them to test your landing zones.

In my previous blog, How do you prove that your infrastructure is compliant. I explained how you can prove your infrastructure is compliant using CloudFormation Guard. But, how do you write those rules? And even more important, how do you test your rules? If you look at the repository CloudFormation Guard. You will notice that the project itself offers a testing framework. Alright! Let’s build a ruleset and write some tests for it!

When you are building your cloud infrastructure. And you have to meet certain compliance standards. You can achieve this with preventive and detective controls. In this blog post I want to focus on the preventive control. How you can stop the deployment pipeline when the infrastructure is non-compliant. And how you can visualize this using CloudWatch Reports. Let’s say that our company has the following rule:

When writing an AWS Lambda function, it’s quite possible that you get to the point where the file becomes too big. So, what do you do? You create a second file and refactor your code to do a relative import. Then, the only step left is to deploy your code and run it. And then it fails… Have you been here before? Then I might have some sound advice for you. If you look at the PEP 8 — Style Guide for Python Code.
You will read that absolute imports are recommended. But, explicit relative imports are an acceptable alternative to absolute imports.
This means that you should favor absolute imports. And only use relative imports within a package.

In this blog post I will show how you can use a Makefile to make your life easier. In this blog I will use CDK with python. But the principle of the Makefile will work on almost any project. When you start a new PoC you do not have a full CI/CD environment in place yet. So how can you deploy your CDK application? And make it easy to add the CI/CD pipeline at a later point?

It is not possible to remember all methods and properties from all classes that you write and use. That is the reason why I like to have type hinting in my IDE. In fact I will spend time to make sure it works. I even wrote a blog post about how to set it up when I started experimenting with a new language. In this post I will provide you with a couple of tips that help you develop faster. By leveraging type hinting using the AWS Lambda Powertools