Posts on DevOps.
Validating an IaC template before you hand it to CloudFormation is one of the cheapest ways to avoid the
dreaded UPDATE_ROLLBACK_IN_PROGRESS. You can catch a lot without ever creating a stack - but only if you understand
what the tool you use actually checks. Here are the two we usually use, and where one stops and the other takes over.
A while back we wrote about our automatically updated docker image for cfn-lint - a public, daily-rebuilt image for cfn-lint that fills the gap left by the lack of an official one. Two changes have just landed in that build, and both are worth a few words: the images are now multiplatform, and we have fixed a problem that, from cfn-lint v1.52.0 onwards, left the image unable to recognise any resources.
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
Creating snapshots from EBS drives attached to your EC2 instances is the most basic way of backing up your data. While you have to be cautious when snapshotting running EC2 instances without restart, doing it regularly is a base of many disaster recovery plans. In the latest update to aws-maintenance repo on GitHub you’ll find a complete code and CloudFormation template that will make this as painless a process as possible.
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.
