We are all guilty of this one! We changed something, and we forgot to update the documentation. Even if you have the best intentions to do your best, it’s way too easy not to do it.

Each “Infrastructure as Code” framework has pros and cons. My go-to framework is CloudFormation, but I like CDK’s tree view, so I started thinking about borrowing this.

It’s a best practice to split your environments into separate AWS accounts. It does not cost you anything extra and you can guarantee that your development environment is completely isolated from the higher environments. With this setup, it’s also common to have a build or tooling account to be responsible for the deployment of your application.

When you deploy lambda functions using CDK and a test-driven approach, you might have noticed that the test feedback takes longer each time you add a new function. That’s because each function will be bundled with its own set of dependencies. These dependencies need to be downloaded before CDK can bundle them into a single package.

You can protect yourself from losing logs on Amazon EC2 by using CloudWatch Logs. Configure the CloudWatch Agent to stream your logs to a LogGroup. This protects you from losing logs. For example, when the instance is replaced by autoscaling. You are also protected against tampering of the logs. An attacker who has gained access to your system can remove the logs. But the logs in the LogGroup will contain the original log lines.

When you are using compute you have a lot of options. One of these options is Amazon EC2. In a world where more and more workloads become serverless. You might still have this use-case that is better off on EC2. But, how do you combine EC2 with compliance and security? In this blog post we will explore how we can build a compliant and secure EC2 stack.

How do you track your security posture in AWS? You have services like Security Hub, but it will only show you the scores of a limited set of standards. This blog post will continue on the previous 2 blog post that I wrote:

In my previous blog I showed you how you can write your own config rules. But it will only bring you value if you deploy the rule in your AWS Accounts. In this blog we will dive into the distribution of these config rules.

AWS has a lot of controls built in, but what if you need more? AWS Config allows you to create your own rules. These rules can then inspect your resources and determine if they are compliant. This is useful when you want to enforce certain configuration settings. Giving you an overview of how compliant your workloads are.