CloudFormationをざっくり説明すると…。

はじめに

クラウドサービスはレゴブロックのようなものだ。ブロックごとに特性があって、つながるブロックとつながらないブロックがある。ブロックの１つ１つは割と単純で、似たような機能のブロックが微妙に異なったバリエーションで何種類か用意されていたりする。

CloudFormationはそんなレゴブロックの設計図をコーディングできるAWS発のIaC（Infrastructure as Code）ツールだ。作成したコードをAWSに持っていき、文法が正しいと認められると、設計図通りのものが自動で出来上がる。

普通のAPIツールとの違い

大方のクラウドエンジニアは、AWSコンソール画面でのポチポチ作業が煩わしくなってくると、AWS CLI(Shellスクリプト)やboto3(Python)などの普通のプログラミング言語を使ってAWSのサービスを作るようになる。こういう普通のAPIツールをIaCツールっぽく使うこともできなくはない。むしろカジュアルな用途ならAWS CLIやboto3でも十分対応できると思う。ただIaCツールには冪等性がどうしても必要で、冪等性の担保には普通のプログラミング言語を使った手続き型プログラミングだと限界がある。

冪等性とは

例えば、「変なPC」という名前でAWS上に（※AWSにたてるサーバーには日本語は使えないが、例えなのでご容赦いただきたい）PCを建てたいとする。その場合、設計図となるYAMLファイルは以下のようになる。

template.yml

NAME: 変なPC
CPU: ARM 1.6GHz 4-Core
MEMORY: 1000GB
Storage: 1GB, 8GB

CPUが弱いのにメモリがすごくて変なPCだ。そしてこの場合冪等性があるとは、現状がどうであるかに関わらず結果として「変なPCという名前の変なPCが出来上がる」ということだ。

どういうことか説明しよう。2つのケースを想定して欲しい。

１）名前空間上に何もPCがない
２）名前空間上にすでに「変なPC」という名前のPCがある（しかもそのPCは許せないことに超高性能のPCだ）

１）の場合は当然我々の求める結果になる（変なPCが出来上がる）。ただ２）の場合はどうだろう。「『変なPC』という名前のPCはすでに存在しています」というエラーが返ってきたとしたら、そこに冪等性はなく、IaCツールとしてはよろしくない挙動だと言える。なぜ冪等性がないかというと、先述のように「現状に関わらず結果が同じ」でなければいけないからだ。

なので２）の場合どうなれば良かったかというと、すでに存在している「変なPC」の設定が変更されて変なPCにならなくてはいけない。

CloudFormationの使いにくいところ

CloudFomrationは変数の取り扱いがだいぶ気まずいし（筆者はRosemary Wangの本に倣って、変数用のJSONファイルをPythonで生成して、それをAWS CLIで書いたShellスクリプトでCloudFormationに食わせている）、モジュールのオーケストレーションも自力でやろうとすると頭が痛くなる（Protonというツールもあるが、あまり気軽に手を出せるツールには見えない）。

スタックは「壊れる」ことがあり、ドリフト検出機能がイマイチだったりする（作成時に明示的に設定した項目以外は検出されない）。

また、CloudFormationは裸のままだと結構使いにくい。なかなか上達していかない。無駄に閾値が高くなっている感がある。初見で絶対転ぶ石みたいなものがたくさんあって、developabilityはあまり良くない。chatGPTもあまりCloudFormationの学習データが少ないらしく、堂々とhallucinationをかましてくる（文法ミスを含むコードの生成をしてくる）。

ぜひ使いたいサポートツール

rain

rainはCloudFormationユーザーなら絶対に使いたいツールだ。

rainのメイン機能である

・スケルトン生成機能
・デプロイ時のインターフェース
は、

どちらも元々のCloudFormationからごっそり抜けているところだ。そして、実際に使ってみた人しかわからないが、この２つの機能がないのは、かな〜りしんどい。前者に関してはCloudFormationのユーザーガイドと睨めっこが日課になってしまうのと、後者に関してはデプロイのたびにAWSコンソールに行かなければならず、これが小さいストレスになる。筆者はこのサービスの存在を知ったとき、松重豊ばりに「もっと早く言ってよお〜」と叫んでしまった。

AWS CDKとAWS SAM

CloudFormationユーザーならCDKとSAMも使っていきたい。どちらのツールも結局、CloudFormationのdevelopabilityの悪さからある意味必然的に生まれたツールだと言える。どちらもCFnテンプレートをより抽象化して書ける、つまりより少ないコードで簡単に書けるツールだ。CDKに至ってはTypeScriptやPythonというお馴染みの言語で書ける（一般言語でIaCをやるというのはいい意味で異次元の体験だ）。

SAMはCloudFormationと同じくYAMLでのコーディングとなるが、サーバーレスサービスのIaCに特化していて、典型的なサーバーレスの仕組みをコード化する際に、より直感的なコーディングができ、コーディング量が10分の1になるケースもあるらしい（参考：YouTubeのAWS Online TechTalk）。

どちらのツールも結局のところCloudFormationのテンプレートを仲介してインフラを作るツールなので、メインのIaCツールとして使えるだけでなく、ピンポイントのCloudFormationテンプレートジェネレーターとして使うこともできる。

Terraformとの関係

CloudFormationがマニュアルのカローラなら、PulumiやTerraformはプリウスかもしれない。CloudFormationとTerraformとの一番大きな差異は、CloudFormationが、筆者が知る限り全てのAWSサービスが対象なのに対して、Terraformは結構サポートしてないAWSサービスがあるということだ。

その代わりTerraformはGCPやAzureのサービスにも対応しているほか、DatadogやSnowflakeといったSaaSサービスもサポートしている。だからAWSオンリーの構成にはCloudFormationが採用されやすいし、AWSサービスにBigQueryやGKE、Snowflakeやdbtをピンポイントで使うようなモダンでイカした構成にはTerraformが採用される傾向にある。ユーザー数およびドキュメントは圧倒的にTerraformに軍配が上がり、CloudFormation勢は明らかに肩身の狭い思いをしている。

さいごに

今後CloudFormationが他の新生IaCツール群に押されていってしまうのか、それとも機能改善（とドキュメント改善）から華麗な変身を遂げてよりユーザーに愛されるIaCツールになるのかはわからない。また何年か後に状況をこうして記事にしてみたいと思う。