My personal AWS CloudFormation best practice is „use Terraform“. But I may be ignorant and would love to hear if and how CF beats TF.
Use CDK.
AWS CloudFormation Best Practices
41–49 of 49 posts
Re: AWS CloudFormation Best Practices
#42Earlier quoted context omitted.
How so? CFN is terrible to write and maintain, cdk abstracts alot of the difficulty and makes reusable components possible. I work at Amazon...
Doing it by hand is certainly painful, but with libraries such as Troposphere it isn't so bad ..
Or such as CDK...
Re: AWS CloudFormation Best Practices
#43Earlier quoted context omitted.
Man, I don't miss CloudFormation. If you want to do anything interesting at all (like being able to spin up turn-key ad-hoc stacks for developers that are mostly the same as your main environments), then you have to parameterize everything, and passing data around CloudFormation templates is just awful--what you want is functions and data structures but CloudFormation gives you "nested-stacks" and you have to encode…
AWS solutions architect here! (Opinions are my own and not necessarily those of my employer.) Many of us now believe that CloudFormation is best described as the assembly language of AWS infrastructure: you can hand-code it, but it's challenging and verbose, and there's a lot of detail you have to get involved in. CDK is the high-level solution to this challenge. With CDK you describe your infrastructure in terms of…
Yeah, I haven't given CDK a good shot yet. I did write something like it (for Python) before CDK existed, and it was very nice. I'd like to play with CDK, but I'm no longer working on AWS systems but rather GCP/Terraform. Best of luck to the CDK folks!
Re: AWS CloudFormation Best Practices
#44Earlier quoted context omitted.
CDK is managed IaC, allowing compile-time checks and also to debug your infrastructure. CloudFormation is just JSON or YAML (treated as assembly by CDK, by spitting out a CFN template after synthesis)
This is not correct. CDK is not "managed IaC" - the management is done by CloudFormation. CDK is a generator for the JSON or YAML of CloudFormation, which is fully responsible for the execution and management of provisioning.
I stand corrected, thanks.
Re: AWS CloudFormation Best Practices
#45Earlier 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 stregth of TF is the community and quality of docs. I use providers to manage an infra that is a mix of AWS + Heroku + external services like Rollbar and that just comes easy with TF. The point of it being paid (although I don't use any of their paid services), is that it is their core business and they are forced to continuously improve on it. TF 5 years ago sucked, but TF in 2021 is super smooth.
As I person who uses Terraform daily, I won't agree with you - documentation on the AWS provider, for example, is terrible.
Re: AWS CloudFormation Best Practices
#46Earlier 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.
> more reliable This is... quite the assertion. Terraform has historically been _far_ more reliable than CloudFormation, and perfectly capable of getting itself into unrecoverable states. Furthermore, the behaviour has _never_ been predictable - CF only even grew the ability to preview changes relatively recently. (Disclaimer: I worked on Terraform at HashiCorp, and on other provisioning tools since).
For a person who uses Terraform daily, I won't agree with you. So many times I had to manually alter state files, and often contribute to basic providers, and wait months to get PRs merged in. It used to be that CloudFormation lagged behind Terraform for AWS, but not anymore. Now, it's quite the opposite and you see people using CloudFormation resource within Terraform as they are stuck into using plain Terraform and yet don't want to manage resource manually.
Re: AWS CloudFormation Best Practices
#47Earlier quoted context omitted.
The stregth of TF is the community and quality of docs. I use providers to manage an infra that is a mix of AWS + Heroku + external services like Rollbar and that just comes easy with TF. The point of it being paid (although I don't use any of their paid services), is that it is their core business and they are forced to continuously improve on it. TF 5 years ago sucked, but TF in 2021 is super smooth.
As I person who uses Terraform daily, I won't agree with you - documentation on the AWS provider, for example, is terrible.
I had no issues with the AWS provider. Where did you find it lacking?
Re: AWS CloudFormation Best Practices
#48Earlier quoted context omitted.
> more reliable This is... quite the assertion. Terraform has historically been _far_ more reliable than CloudFormation, and perfectly capable of getting itself into unrecoverable states. Furthermore, the behaviour has _never_ been predictable - CF only even grew the ability to preview changes relatively recently. (Disclaimer: I worked on Terraform at HashiCorp, and on other provisioning tools since).
For a person who uses Terraform daily, I won't agree with you. So many times I had to manually alter state files, and often contribute to basic providers, and wait months to get PRs merged in. It used to be that CloudFormation lagged behind Terraform for AWS, but not anymore. Now, it's quite the opposite and you see people using CloudFormation resource within Terraform as they are stuck into using plain Terraform and…
You won’t find argument from me that HashiCorp have let maintenance slide, but there is still no conceivable way that CFN is more reliable in the general case.
Re: AWS CloudFormation Best Practices
#49Earlier quoted context omitted.
For a person who uses Terraform daily, I won't agree with you. So many times I had to manually alter state files, and often contribute to basic providers, and wait months to get PRs merged in. It used to be that CloudFormation lagged behind Terraform for AWS, but not anymore. Now, it's quite the opposite and you see people using CloudFormation resource within Terraform as they are stuck into using plain Terraform and…
You won’t find argument from me that HashiCorp have let maintenance slide, but there is still no conceivable way that CFN is more reliable in the general case.
Hmmm, just searched GitHub for aws_cloudformation_stack and found 375 public repositories. I'm sure those references are orders of magnitude more in the private repos. In other words, you still need CloudFormation with Terraform on AWS... so, why use the patchwork then?