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

21–30 of 49 posts

Re: AWS CloudFormation Best Practices

#21

Post by throwaway894345 »

nikolay wrote: post #6
ManuelKiessling wrote: post #4

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.

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.

I've had too many CF stacks get stuck in states that don't allow for rolling forward or backwards to buy this. You have to purchase a premium support plan to get access to the AWS personnel who can help you out.

CF does actually kind of try to behave transactionally, which is interesting--you don't often get stuck between states like you do with Terraform, but I rarely have had much of a problem getting Terraform out of one of these states either.

This isn't to speak about the abysmal expressiveness of CloudFormation. Reuse is a joke--I'm tempted to call it a programming language in which you encode the AST manually as YAML/JSON, but that would be overly generous because any programming language AST allows you to express the concept of a function that takes complex arguments (e.g., an object, list, or list of objects).

Further still, if you want to extend CloudFormation to support third party services (e.g., if you want to create a user pool in your identity management provider for your new stack, or otherwise manipulate non-AWS APIs), you have to write and run your own lambdas--which each require their own infra-as-code--which just takes a lot of effort (not to mention how hard it is to write these correctly) and so you end up compromising with a half-manual workflow, missing out on much of the promise of infra-as-code.

I don't love Terraform, mind you. I think there's a Better Way out there somewhere (maybe it's Pulumi or CDK, I'm not sure), but CloudFormation is brutal.

Re: AWS CloudFormation Best Practices

#22

Post by aledalgrande »

nikolay wrote: post #6
ManuelKiessling wrote: post #4

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.

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.

Re: AWS CloudFormation Best Practices

#23

Post by otterley »

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…

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 high-level constructs such as classes. Your stacks are described as applications instead of YAML templates. You can use many different programming languages including TypeScript and Python, and code is reusable. You can even vendor custom construct libraries to share within your org, or openly via npm.

I've become a convert since CDK came out - it's been ages since I've handwritten CloudFormation templates.

https://aws.amazon.com/cdk/

Re: AWS CloudFormation Best Practices

#24

Post by Arelius »

Honestly, I really like CFN, but raw templates are a bit of a disaster... Most of the rest of my infrastructure is powershell, so I acutally write the templates inline in Powershell something like this:

    New-AWSTemplate -Resources @{
        $OAI = @{
            Type = "AWS::CloudFront::CloudFrontOriginAccessIdentity"
            Properties = @{
                CloudFrontOriginAccessIdentityConfig = @{
                    Comment = "Access to the bucket"
                }
            }
        }
        ....
    }
If I were doing something without that context I'd likely use Javascript, and just stitch together template structures

I've tried out CDK but honestly it seems very opaque and hard to understand, I want to give it another shot but it just doesn't seem to be a direct translation from CFN templates...

Re: AWS CloudFormation Best Practices

#25

Post by jen20 »

nikolay wrote: post #6
ManuelKiessling wrote: post #4

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.

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

Re: AWS CloudFormation Best Practices

#26

Post by devonbleak »

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…

Yeah JSON/YAML is (mostly) great for data that needs to be parseable by machines and humans but trying to make a language out of it is horrible.

Raw HCL2/Terraform is marginally better IMO with being able to pass around more complex structs and function calls that don't have to be expressed as JSON dicts, but still remaining declarative to be able to create a dependency graph internally.

All of this is why CDK now exists to be able to express these things as TypeScript or Python and spit out the corresponding CFN or TF.

It's also worth noting that AWS added support for additional providers a while back so the CustomResource+Lambda you're describing isn't the only way to interact with non-AWS APIs.

I'm actually curious what you're using - you've shit all over a bunch of things without providing any real alternative.

Re: AWS CloudFormation Best Practices

#27

Post by jen20 »

zoover2020 wrote: post #19
mikeyjk wrote: post #13

Earlier quoted context omitted.

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)

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.

Re: AWS CloudFormation Best Practices

#28

Post by ipsocannibal »

Arelius wrote: post #24

Honestly, I really like CFN, but raw templates are a bit of a disaster... Most of the rest of my infrastructure is powershell, so I acutally write the templates inline in Powershell something like this: New-AWSTemplate -Resources @{ $OAI = @{ Type = "AWS::CloudFront::CloudFrontOriginAccessIdentity" Properties = @{ CloudFrontOriginAccessIdentityConfig = @{ Comment = "Access to the bucket" } } } .... } If I were doing…

Having written more CFN than I care to remember CDK is a breath of fresh air. It has a multi-level API that deals with the relationships between resources in a much cleaner way than plain CFN. However, at the lowest level you can still write basically CFN in code. But CDK has so much more. It includes multi-language support, unit testing, compile time checking for errors, etc.

Re: AWS CloudFormation Best Practices

#29

Post by dragonwriter »

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…

> Not a great article

Well, duh, it's a Stackery ad posing as an CF best practices article; if the superficial meat was any good, it would distract attention from the ad.

Re: AWS CloudFormation Best Practices

#30

Post by dragonwriter »

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…

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

Post reply on HN