Another day, another blog post about adding security headers to Cloudfront HTTP responses. Actually, it’s my third post about this topic, which is the same as the number of AWS services that can be used to modify Cloudfront headers. As of today we have: Lambda@Edge, Cloudfront Functions, and the newly introduced Response Headers Policies Again, ability to easily add HTTP headers to Cloudfront was very commonly requested feature: https://t.co/BGzCyi8LtU headers without needing to use lambda@edge would be great

By default AWS gives you access to all AWS regions. However, it’s a very rare case that you might need to launch resources across all AWS regions in one account. In fact, I think is usually best to have one account per AWS region when possible. As some of the services are global (like IAM roles) by using one account per AWS region you can be sure that naming of IAM roles doesn’t clash and you won’t accidentally use an IAM role written for us-west-1 for your application in us-east-1 for example.

Hi, in this post I’m going to go back to a fundamental AWS service - RDS. Specifically, I’ll focus on two ways to ensure resilience of your RDS database: RDS Multi AZ and RDS Read replica. Looking into AWS RDS console, it looks like a very simple service: you can choose which database engine you want to use, pick some additional parameters, and launch the database. However behind the single interface lies a complexity: each database engine type has slightly different concepts and functionality that you have to be aware of.

In my previous post I discussed about newly released Cloudfront functionality - Cloudfront Functions and Compared them to Lambda@Edge. In this post I will show how to migrate Cloudfront distribution that uses Lambda@Edge to set custom security headers to Cloudfront Functions using Terraform. I’ve discussed differences of these two AWS functions previously so I’m not going go into that and I’ll jump straight to the code. Replacing Lambda@Edge with Cloudfront Functions using Terraform Replacing Lambda@Edge with Cloudfront Functions using Terraform is quite straightforward.

If you follow Terraform best practices your Terraform infrastructure code should consist of multiple small modules that contain certain infrastructure code (in this case AWS). However, the problem with smaller modules is that probably most of the infrastructure doesn’t change that often. E.g.: once you create a VPC you don’t need to update it very often unless there are some changes with networking. On the other hand, other Terraform modules you use like ECS clusters, or ASG groups might require to be updated more often.