これを読むとわかること
一度作ったことがある人はわかると思いますが、 __「時間が掛かる」__ので少しでも __「技術的ではなく事前知識で」__時間を省略してHappyになりましょうねっ！っていうお話。
難しいことは書いていないので・・
タイトルだけ読むと良いと思います
1. Amazonが提供しているテンプレートの再利用は、効率上がるように見えて非効率なこともある
CloudFormationの文法やお作法は慣れていないと最初はテンプレートに頼りがちになります。確かにすごく役に立つテンプレートがいっぱいありますが、それをそのまま自分のシステムに適用する場合は、当然、どういう設定がされているか内容を把握しておく必要もあります。ファイルを開くと結構なコード量があり、多くの行を読まされてしまいます。また中にはちゃんと動作しないケースもあります。変にそこに悩んで調べてしまうよりは、ダメだったら自分で作るほうが良いこともあります。
つまり、自分が理解している正しいテンプレートに対して、新しくやりたい小さいことを追加するほうが読むべき（理解すべき）量は減ります。
2. デバッグの方法は知っておくこと
デバッグ方法を知らないでコーディングするのは無謀過ぎるでしょ？という当然な話。具体的な方法は知らなくても、「ちゃんとログを吐いてることを知っておくこと」。コンソール上のエラー内容から推測してすぐ直して動けばいいけど、それが何度かうまくいくと癖になってしまうのを恐れましょう。
具体的には、まずエラーが発生するとROLLBACKしてしまうので、AWSコンソールのCloudFormationのStack作成フロー中に、
「Select Template」＞「Specify Parameters」＞「Options」の
OptionsでAdvancedのRollback on failure設定があるのでこれを「No」にする。
エラーになったサーバーの以下のファイルなどに具体的な原因が吐かれていること
/var/log/cfn-init.log
/var/log/cloud-init.log
エラーのケースによっては調べる方法も変わってくるかと思いますが、まだエラーになったケースが少ないので知っているのはこの程度です。
3. 小さく作って大きく育てる
こちらもプログラムの基本っぽいところですが、CloudFormationのテンプレートも小さく少しずつ作って確からしいことの集合体にすべきです。TDDと同じ考え方かな、にしては１サイクルがすごく手間で時間が掛かるのをどうにかして欲しいですね。ネストしたテンプレートにしてしまうのもありだけど、よく考えて作らないと後々汎用が効かず失敗しそう。mavenからgradleへ進化していった経緯を考えると、CloudFormationもいつか進化するか、またはこれに変わる新しいものの登場が待ち遠しいところです。
4. テンプレートにする必要があるか？（その目的は何ですか？）
がんばって作ったけどImuutableな構成にする必要があるのか？目的をちゃんと考えましょう。気づいたら時間の無駄使いしているかもしれませんよ。
5. OpsWorks、その他構成管理ツール（Chef、Ansible、等々）と被るところがある
自分はOpsWorksの存在自体を知らなかったのですが、CloudFormationとOpsWorksがそれぞれ得意とするところを理解しておくべき。
まとめ
「お！これは！」感の無い記事ですが、StackTemplateを作っていて事前に知っておきたかったことをまとめさせていただきました。
これを使うとできることと、やりたいことの方法はググると出てきますが、そもそもの考え方ってなかなかちゃんと説明してくれないですよね。二の次になってしまいがちですしね。