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

Setup Visual Studio Code as your IDE to build and deploy an AWS SAM stack using Go. I recently started to experiment with Go and the best way to learn is to play with it and build something. So I decided to build a simple application. During this process I ran into the problem that my IDE did not like having many go modules within one project.

You can search across log groups by setting up a correlation id on your log lines. You can then use CloudWatch Logs Insights to query all related log messages. If you are dealing with different lambda functions in a project, you might not have a logging system yet. Finding and troubleshooting using Cloudwatch Logs could become cumbersome. Especially if you try to track a flow through the different log groups. In CloudWatch Logs Insights you can execute queries across log groups. In our case we want to collect related log lines across log groups. To achieve this we need to annotate the log lines with a correlation_id that ties them together.