AWS CloudFormation Best Practices
stackery.io
AWS CloudFormation Best Practices
1–10 of 49 posts
Re: AWS CloudFormation Best Practices
#2Not 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.
Re: AWS CloudFormation Best Practices
#3CDK is strictly superior to cfn
Re: AWS CloudFormation Best Practices
#4My personal AWS CloudFormation best practice is „use Terraform“.
But I may be ignorant and would love to hear if and how CF beats TF.
Re: AWS CloudFormation Best Practices
#5CDK is strictly superior to cfn
Not at all. I don't think most people really grasp what CloudFormation is.
Re: AWS CloudFormation Best Practices
#6My personal AWS CloudFormation best practice is „use Terraform“. But I may be ignorant and would love to hear if and how CF beats TF.
Imagine CF being Terraform + Terraform Cloud (only free!) - but more reliable and having real changesets with more predictable behavior and the state being the true AWS state, not some projection of it within Terraform.
Re: AWS CloudFormation Best Practices
#7Re: AWS CloudFormation Best Practices
#8My personal AWS CloudFormation best practice is „use Terraform“. But I may be ignorant and would love to hear if and how CF beats TF.
Imagine CF being Terraform + Terraform Cloud (only free!) - but more reliable and having real changesets with more predictable behavior and the state being the true AWS state, not some projection of it within Terraform.
The only problem is Cloudformation is strictly AWS resources, so unless you're absolutely 100% sure you'll never need anything outside of AWS ecosystem, I always recommend using TF.
Re: AWS CloudFormation Best Practices
#9Earlier quoted context omitted.
Imagine CF being Terraform + Terraform Cloud (only free!) - but more reliable and having real changesets with more predictable behavior and the state being the true AWS state, not some projection of it within Terraform.
The only problem is Cloudformation is strictly AWS resources, so unless you're absolutely 100% sure you'll never need anything outside of AWS ecosystem, I always recommend using TF.
This is true, of course, but you can have a Terraform CloudFormation resource, too, and pass data from other resources back and forth. Since when we don't like using the best tool for the job?!
Re: AWS CloudFormation Best Practices
#10Earlier quoted context omitted.
Imagine CF being Terraform + Terraform Cloud (only free!) - but more reliable and having real changesets with more predictable behavior and the state being the true AWS state, not some projection of it within Terraform.
The only problem is Cloudformation is strictly AWS resources, so unless you're absolutely 100% sure you'll never need anything outside of AWS ecosystem, I always recommend using TF.
For companies the likelihood of not needing stuff outside of AWS is relatively low. Unless you're okay with managing other applications by hand, which is probably the wrong attitude.