Posts on CloudFormation.
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
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.
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.
Start with a free second opinion: 30 minutes with our founder. No account access needed, and you keep a short written read.
