| Not a great article. Most of the content is far better explained in the AWS docs. To summarize their best practices: * don't put creds in templates * reference other parameters outside of the template, e.g. in Systems Manager Parameter Store * make your code readable * add comments * check your code Except for the second, all of those are fine practices for maintaining any code. The one best practice that's actually relevant to CF is to store parameters in SSM. Yet, they mention that drift is a problem with CloudFormation. So... why do you want to store parameters to your stack in a service that allows them to change independently of the stack? Maybe there's an argument for doing this, but they don't explain it. It's just a "best practice." They don't mention a major use case for CF, namely CI/CD. The article finishes up with a pitch for their template designer. |
Basically, CloudFormation is like the shittiest programming language you've ever encountered. People will argue that it's supposed to be simple because it's just YAML, but that's bogus--we clearly need to be able to do complex things in this space or else CF wouldn't provide these hacky functions. We pretty clearly need some sort of expression language if not something more robust, since that's the direction all of these "it's just YAML!" tools are going (CloudFormation, Terraform, etc). CloudFormation might actually make a decent "assembly language" for an infrastructure-as-code backend (although extending CloudFormation for third party services was still far too difficult last I checked--basically you had to run your own lambdas) that some higher-level tools might generate, but it's a mess for anything that isn't a toy.