Reputation: 1480
I've been using cloudformation templates for a while now and I'm keep asking myself the following question:
What are the benefits of using AWS::CloudFormation::Init
over adding those statements directly into the UserData
block?
So far I've found the AWS::CloudFormation::Init
way more verbose, especially when you need several configSets
to assure some kind of ordering on your statements.
Also, certain AMIs doesn't support running that init block out-of-the-box and need from extra scripts cfn-init
which it adds even more verbosity.
Upvotes: 3
Views: 201
Reputation: 15502
The benefits I can think of are:
If you like a simple, declarative DSL for your configuration that is similar to Puppet & Chef, then use AWS::CloudFormation::Init.
And if you are finding it cumbersome, it could be that UserData is a better fit. Too many configSets could be an indication that you're using the wrong tool (or ordering things that don't really need to be ordered!).
Also, be aware that AWS::CloudFormation::Init is old, and it predates CloudFormation's support for YAML templates.
Prior to YAML support, putting scripts in UserData was difficult, because each line of your shell script needed to be encoded in a JSON Array. This made it difficult to read, and easy to make mistakes.
The use of AWS::CloudFormation::Init, in my opinion, made more sense given only those two choices.
These days, my preference is to keep shell scripts outside CloudFormation, unit test them externally, then feed them as a base64 encoded string in as a parameter. (Beware the 4096 character limit on parameters however!).
Of course, it also depends on the complexity of your configuration. You wouldn't want to do too much in a shell script in UserData as it would quickly become unmaintainable.
Upvotes: 4