Live data from Hacker News

AWS CloudFormation Best Practices

stackery.io

11–20 of 49 posts

Re: AWS CloudFormation Best Practices

#11
post #6

Earlier 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.

Not quite true, you can technically create your own CloudFormation resources[0]. It's a pain to do though.

[0] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Re: AWS CloudFormation Best Practices

#12

CDK is strictly superior to cfn

Reading CDK's introduction page, it seems that, similar to CloudFormation, it uses pre-made components, just at a higher level. Those components are then translated into a CloudFormation template[0]. Is that correct?

Might it be more accurate to state that CDK is a higher level version of CloudFormation, that abstracts away unimportant details?

[0] https://aws.amazon.com/cdk/

Re: AWS CloudFormation Best Practices

#14
post #5

Earlier quoted context omitted.

Not at all. I don't think most people really grasp what CloudFormation is.

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 ..

Re: AWS CloudFormation Best Practices

#15
post #2

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…

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 most of your data structures as strings and "parse them out" with the YAML builtin functions that they provide (e.g., `{"Fn::Split": "foo,bar,baz"}` will evaluate to `["foo", "bar", "baz"]`, but good luck if you want a list of objects). Each stack also has a limit on the number of parameters you can pass, and since you can't really pass struct-like data (e.g., `"Foo": {"bar": "baz", "qux": "..."}`) you end up flattening that struct into N parameters (e.g., `"FooBar": "Baz", "FooQux": "..."`). You can try to plumb things through SSM or SecretsManager, but each stack also limits the number of parameters you can pass there as well.

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.

Re: AWS CloudFormation Best Practices

#17

CDK is strictly superior to cfn

Reading CDK's introduction page, it seems that, similar to CloudFormation, it uses pre-made components, just at a higher level. Those components are then translated into a CloudFormation template[0]. Is that correct? Might it be more accurate to state that CDK is a higher level version of CloudFormation, that abstracts away unimportant details? [0] https://aws.amazon.com/cdk/

Yes, exactly. CDK is the abstraction which compiles down to CloudFormation. You can see CF here as the assembly that gets generated.

Re: AWS CloudFormation Best Practices

#19
post #13

CDK is strictly superior to cfn

What would you flag as the biggest differences between the two?

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)

Post reply on HN