Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS CloudFormation Best Practices

stackery.io

Post reply on HN
Print view View original

31–40 of 49 posts

Re: AWS CloudFormation Best Practices

#31

Post by guitarbill »

Varriount wrote: post #11
SteveNuts wrote: post #8

Earlier quoted context omitted.

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

If you're invested, you can use extensions [0] which seem like they're more well-defined. It sounds like this is what APN partners like Datadog use to implement 3rd party resources.

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

Re: AWS CloudFormation Best Practices

#32

Post by twg_jack »

otterley wrote: post #23
throwaway894345 wrote: post #15

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

I'll second CDK -- love it and it's so much easier than writing raw CFN.

Re: AWS CloudFormation Best Practices

#33

Post by zokier »

Varriount wrote: post #12
logicslave wrote: post #3

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/

CDK is essentially CFN template generation tool for TypeScript

Re: AWS CloudFormation Best Practices

#34

Post by l0b0 »

Varriount wrote: post #12
logicslave wrote: post #3

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/

As someone who's used CDK for a few months and never handcoded CF, that sounds completely correct. If you're comfortable with Python, here's a simple but non-trivial architecture you can check out: https://github.com/linz/geospatial-data-lake/blob/master/app....

Re: AWS CloudFormation Best Practices

#35

Post by CyberDildonics »

guitarbill wrote: post #31
Varriount wrote: post #11

Earlier quoted context omitted.

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

If you're invested, you can use extensions [0] which seem like they're more well-defined. It sounds like this is what APN partners like Datadog use to implement 3rd party resources. [0] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Invested in what?

Re: AWS CloudFormation Best Practices

#37

Post by chriswarbo »

throwaway894345 wrote: post #15
ben509 wrote: 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…

I agree. I'm sorely tempted to introduce Dhall or CUE at work, but it might be a bit of leap for colleagues.

Re: AWS CloudFormation Best Practices

#38

Post by throwaway894345 »

dragonwriter wrote: post #30
throwaway894345 wrote: post #15

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

> Basically, CloudFormation is like the shittiest programming language you've ever encountered CF json/yaml is essentially declarative asm for AWS resources. CDK is how you use popular higher level languages to generate it, and there are some friendlier-than-raw-CF options in between (like SAM).

SAM is limited and I didn't care for it. I believe CDK is the way to go; I just haven't had much chance to play around with it yet. I suspect it doesn't solve the problem that extensions are lambdas, but it's a welcome development. I believe Terraform now has a CDK as well.

Re: AWS CloudFormation Best Practices

#39

Post by guitarbill »

CyberDildonics wrote: post #35
guitarbill wrote: post #31

Earlier quoted context omitted.

If you're invested, you can use extensions [0] which seem like they're more well-defined. It sounds like this is what APN partners like Datadog use to implement 3rd party resources. [0] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Invested in what?

Cloudformation

Re: AWS CloudFormation Best Practices

#40

Post by throwaway894345 »

chriswarbo wrote: post #37
throwaway894345 wrote: post #15

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

I agree. I'm sorely tempted to introduce Dhall or CUE at work, but it might be a bit of leap for colleagues.

I wrote a prototype thing that was like Troposphere but better (everything was generated from CloudFormation spec JSON files, no stitching together things by string IDs, etc). Also unlike CDK, there was no inheritance (I haven't used CDK that much, but inheritance-based systems seem to be universally awful, so I'm skeptical). It can be pretty nice.
Post reply on HN