背景
弊社ではAWSとGCP両方のご提案をさせていただく機会が多いため、 CICDとしては両方対応可能なterraformを利用する機会が多かったのですが、 今回AWS CloudFormationに関するご支援もさせていただける機会があり、 使う中で感じた違いをブログとしてまとめようと思います。
利用して感じた主な違い
実際に利用していて感じた主な違いについて以下にまとめています。 （網羅性はなく個人的に感じた点だけをまとめているので、あくまで参考程度にみていただければと思います）
参照できる値の種類
まず一番大きく感じた違いは参照できる値の種類でした。 terraformは「リソースタイプ名.リソース名.参照値名」と言った変数指定の方法で値を参照し、 CloudFormationではRefを利用してリソースIDなどの値を参照するのですが、 terrraformがほぼリソースに関するほぼ全ての値を参照できるのに対し、 CloudFormationはリソースIDなど限られた値しか参照することができませんでした。 例えばCloudFrontであれば、 IDかドメイン名しか参照することができません。
個人的にこの点は完全にCloudFrontの方が使いにくいと思っており、 例えば値を指定しなかった際にデフォルト値が割り振られる値があったとしても、 その値を参照することができなければデフォルトではなくわざわざ値を指定する必要が出てきます。
導入ハードル
次に感じたものが導入ハードルです。 terraformだと実行までに最低限ローカル環境構築などが必要になるのに対し、 CloudFormationだとコンソールから操作することができるので、 yamlさえあればコンソール上から簡単にデプロイすることができます。 また記載言語もterraformが独自言語であるHCLであるのに対して、 yamlやjsonを使うことができるので扱いやすくなっています。
柔軟性
３つ目に感じた違いが柔軟性の違いです。 例えばterraformが「loop処理を噛ませる」「shellを実行させる」「hash値をパラメーターで持たせる」 と言った様々なことができるののに対し、CloudFormationには特にそう言った機能がありません。 そのため例えばloop処理をCloudFormationでやろうとした場合は、 Jinjaなどを使って複数リソースが記述されたyamlを作る必要があります。 必要不可欠な機能ではないもののterraformで運用を行っていた際そういった機能に何度か助けられたので、 要件が複雑になった際にCloudFormationで対応できるかどうかは不安が残ります。
比較結果
今回感じた違いをまとめると以下表のような結果となりました。 これを見るとちょっとしたものはCloudFormationで作っても問題ないが、 ちゃんと管理を行う場合はterraformを利用した方が良いのではないかと感じています。
| 項目 | CloudFormation | terraform |
|---|---|---|
| 参照できる値の種類 | △ | ○ |
| 導入ハードル | ○ | × |
| 柔軟性 | × | ○ |
感想
結果として組めるのであればterraformを利用した方が良さそうという結果になったのですが、 「導入ハードル」はユースケースによってはかなり重要な項目になってくると思っており、 例えば「AWSで動くアプリケーションを配布したい」と言った場合では間違いなくCloudFormationの方がメリットが大きいと思っています。 そのため今後はterraformだけではなく各特性を考慮したご提案をしていければと思っています。 またどちらもアップデートが進んでいるので、 そちらについても逐一追っていきたいと思います。
クラウドでのデータ基盤の運用をしていくにあたってterraformやCloudFormationの知識は必要不可欠なものです。 弊社では、これらの技術を使い多くのクライアント様のデータ基盤の運用の実績があります。 お困りの際は是非こちらよりお問い合わせください。