Compliant infrastructure using infrastructure as code
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.
Compliance in AWS When we talk about compliance we are actually saying AWS Config.
Tracking your security posture in AWS
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:
Use custom rules to validate your compliance Deploy config rules across your organization In this blog we will look at how you can track your security posture in your organization.
Deploy AWS Config rules across your organization
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.
What are my options? There are many ways you can deploy these rules in your member accounts. In this blog I will only focus on the 2 real options:
Use custom rules to validate your compliance
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.
Let’s use a specific example, but you can apply this concept to other scenarios.
Using design patterns in AWS Lambda
When you speak with software developers, they will probably tell you that they use design patterns. But when the world first shifted to the internet the general feeling was that these design patterns would not work for the web. This is not true, and today you see these patterns being used more and more.
I have noticed the same behavior with serverless. In this blog post I will go over some reasons why you should be using design patterns in your Lambda functions
Setting up my own landing zone on AWS
As a consultant I am used to a certain level of quality that I need to deliver to our customers. For this reason I have built a landing zone for my own website, initiatives and experiments. By using the same structure that our customers have, I can test and build my ideas and apply them in customer environments if they are successful.
At first it might feel like a massive overkill to set up a complete landing zone.
Using Golang for your Serverless projects
In one of my previous blogs I wrote why I switched to compiled languages for my lambda functions. But using Golang for your lambda functions does add some challenges. In this blog I would like to share the challenges that I have seen and how to mitigate them.
Spoiler, I use a Makefile I always use a Makefile in my projects, If you are interested in why I wrote a blog on that as well.
Avoid using the default profile
When you start working with AWS one of the easiest ways to interact with the APIs is through the IAM User. Although it’s not the advised way it’s the easiest way hence the most used one and the most abused one. In this blog I will dive a little deeper into this topic.
Easy to use Using an IAM User is the oldest way to interact with the AWS API. You only need an AccessKey and a SecretAccessKey and you are good to go!
Stubbing AWS Service calls in Golang
I recently switched to Golang for my language of choice. (In my previous blog you can read why.) But I am also a big fan of test driven development. With Python you have a stubber that helps you mock the AWS API. So how do you do this in Golang? I found 2 ways to do this. One via dependency injection and one via a stubber. In this blog I will share my experience so far.