Blog category: CloudFormation

Automatically updated docker image for cfn-lint

If you’re using CloudFormation, you probably know about cfn-lint - a linting tool created by the CloudFormation team to validate templates against the schema and best practices. Validating each template before deployment is in itself actually considered a best practice by AWS. However, simply using validate-template in the Console or CLI only validates the basic syntax of the template, not the actual contents and resource specification. That’s where using a linter like cfn-lint can be helpful to make sure you’re not making any obvious mistakes or going against best practices in your resources.

You can use cfn-lint in a number of ways during development, including simply within command-line, using git pre-commit hooks or as a plugin to your IDE. All those options, while helpful in day-to-day work, do not establish code quality standards for your overall codebase. To do that, it’s ideal to include linting as part of CI/CD pipeline and/or pull/merge-requests approval process.

That is where you can come across a hurdle: cfn-lint does not have an official, up-to-date docker image

Deploying AWS GuardDuty with CloudFormation for Master and Member accounts

AWS GuardDuty analyses various events happening on your AWS account and can notify you when suspicious activity takes place. Right now, GuardDuty is specific to a region and needs to be enabled in each region you want to monitor (though AWS recommends you enable it in all regions to ensure global actions are monitored). Going through GuardDuty console in every AWS region can be a daunting task, and quite time consuming if you have multiple AWS accounts which you’d like to connect into Master-Member setup. Luckily, CloudFormation supports enabling and setting up GuardDuty detectors, so you can use it to make it a little bit less painful.

Complete code: cross-region RDS recovery

After posting the previous post on this topic (Copying RDS snapshot to another region for cross-region recovery) , I noticed a lot of people being interested in using the code I provided as an example. Many were not sure how to make use of it, and after a couple of pull requests it became obvious that a complete, fully-working code and CloudFormation template would be a good idea. So, yesterday, I pushed an update to aws-maintenance repository with a fully working code, which you can easily customize via CloudFormation parameters to match your needs.

Enabling global API Gateway stage logging using CloudFormation

Enabling logging in API Gateway for your stage is fairly easy. You go into the Console, setup a role for API Gateway to use for logging, find the stage and enable logs. It will enable logging for all methods within that stage. Doing the same configuration using CloudFormation is not completely obvious though, as the stage object’s MethodSettings property seems to allow you to only do that for a specific resource and method.

Using Magical Dictionaries to manage long CloudFormation templates with Troposphere

When deploying infrastructure with CloudFormation, at some point you will reach a moment when your CloudFormation JSON or YAML file is just too big. It will be too long to get a good overview of what’s in it, manage parameters and all dependencies between resources within the template. Nested stacks may be a solution, but if sometimes you can’t/won' t/don’t use them for whatever reason (for example, it will get to complicated to manage tested stacks or their contents are not reusable between other stacks).

Even if you’re using troposphere to generate your templates, you’ll face the same issue - a very long Python file. Luckily, if you are using troposphere, you’re inherently using Python - which means you can take advantage of it.