先輩から「その環境、クラウドフォーメーションで作ってあるから、コンソールで直接いじらないでね」と言われて、意味は分からないままうなずいた。そんな経験はありませんか。AWS CloudFormationは、名前が長いわりに、何をしてくれるサービスなのかが伝わりにくい代表格です。
この記事では、AWS CloudFormationを「設計図を渡すと、建物が自動で建つ」というたとえ話を軸に、何をどう書くのか、なぜ手作業を止められるのか、そして途中で失敗したときに何が起きるのかを順番に整理します。
結論から言うと、AWS CloudFormationとは作りたいAWS環境を1枚のテキストに書いておき、その通りに作らせるしくみです。
この記事でわかること
- AWS CloudFormationがどんなサービスか(設計図と建物というたとえ)
- テンプレートとスタックという2つの言葉の意味、そして失敗したときの巻き戻り
- 手で作るのと何が違うのか、料金はどこで発生するのか
AWS CloudFormationとは?一言でいうと「渡すと建物が建つ設計図」
AWS CloudFormationとは、作りたいAWSの環境を先にテキストで書いておき、それを渡すとその通りに作ってくれるサービスです。AWS公式はこれを「Infrastructure as Code でクラウドプロビジョニングを高速化する」と説明しています。
ここでいうInfrastructure as Code(IaC)とは、サーバーやネットワークといった土台の構成を、手作業の手順書ではなくプログラムのようなファイルとして残す考え方のことです。
思い浮かべてほしいのは、建築の設計図です。家を建てるとき、施主が現場に行って「ここに柱を立てて、次はこの壁」と口で指示していたら、いつまでたっても終わりません。しかも2軒目を同じように建てたくても、前回どう指示したかは誰の記憶にも残っていません。
設計図があれば話は変わります。図面を渡せば、同じ家が同じように建ちます。2軒目も3軒目も、図面をコピーするだけです。どこを直したいかも、図面の上で相談できます。
AWS CloudFormationがやっているのは、この設計図の役です。「サーバーを1台、この大きさで。ネットワークはこの範囲。データベースはこの設定で」と書いたファイルを渡すと、AWS側がその通りの環境を組み立ててくれます。
そして設計図と決定的に違うのが、いらなくなったら図面ごと捨てられる点です。この「まとめて作って、まとめて消せる」という性質が、あとで説明する事故の防止につながります。
AWS CloudFormationの仕組みと使いどころ
テンプレートとスタック、まずはこの2語だけ
AWS CloudFormationの話には専門用語がたくさん出てきますが、最初に覚えるのは2つで足ります。
- テンプレート — 設計図そのもの。公式によると「YAML または JSON 形式のテキストファイル」で、インスタンスタイプやAMI ID、キーペアの名前といったリソースの情報を書きます
- スタック — その設計図から建った建物のかたまり。公式は「関連リソースはスタックと呼ばれる単一のユニットとして管理されます」としています
ポイントは、スタックがひとかたまりとして扱われることです。10個のリソースが入ったスタックを削除すると、10個まとめて消えます。1個ずつコンソールで消して回る作業がなくなり、消し忘れも起きません。
失敗すると、CloudFormationは自動で巻き戻す
手作業でAWS環境を作っていて一番こわいのは、途中で失敗したときです。5個作って6個目でエラーになると、中途半端な5個が残ります。放っておけば課金され、消そうにも「どれを自分が作ったのか」があいまいになります。
AWS CloudFormationはここが違います。公式にはこう書かれています。「スタックの作成が失敗した場合、CloudFormation は作成したリソースを削除して、変更をロールバックします」。更新のときも同様で、失敗すれば「スタックを最新の正常な稼働状態に復元」します。
つまり、成功か、何もなかったことになるか、どちらかです。中途半端な状態が残らないので、失敗を怖がらずに何度でも試せます。学習中の身にはこれがいちばんありがたい性質かもしれません。
変更セットで「何が起きるか」を先に見る
すでに動いている環境を書き換えるときは、実行の前に変更セットを作れます。公式の説明では「変更案の概要」であり、「変更が実行中のリソース、特に重要なリソースに与える可能性のある影響を、実装前に確認できます」とされています。
これが効くのは、書き換えのつもりが作り直しになる場面です。公式は具体例として、「Amazon RDS データベースインスタンスの名前を変更すると、CloudFormation によって新しいデータベースが作成され、古いものは削除される」ケースを挙げています。名前をひとつ直しただけのつもりで、中のデータごと入れ替わってしまうわけです。変更セットを見れば、実行する前にそれが分かります。
新社会人がAWS CloudFormationに出会う場面
入社1〜3年目でよくあるのは、「テスト用の環境がほしいから、本番と同じものを1式作っておいて」と頼まれる場面です。手作業なら半日仕事ですが、テンプレートがあれば数分で終わります。
もうひとつが、冒頭の「コンソールで直接いじらないで」です。これは意地悪ではありません。設計図に書いていない変更を手で加えると、図面と現物がずれていくからです。このずれをAWS CloudFormationはドリフトと呼び、検出するしくみを持っています。公式は「リソースの実際のプロパティ値が予期されるプロパティ値と異なる場合、そのリソースはドリフトしたと見なされます」と定義しています。
ずれたまま次の更新をかけると、手で入れた変更が消えたり、更新そのものが失敗したりします。急ぎで手を入れたときは、あとで必ずテンプレート側にも反映する。この一手間を知っているだけで、先輩からの信用がだいぶ変わります。
AWS CloudFormationと関連サービスの違い・つながり
AWS CloudFormationは、これまでこのシリーズで見てきたサービスと競合しません。それらをまとめて組み立てる側にいます。
テンプレートに書けるのは、EC2のサーバー、VPCのネットワーク、RDSのデータベース、S3のバケット、IAMの権限など、ほぼひと通りです。公式もユースケースとして、VPCやECSのようなサービスを「簡単に定義できる」ことを挙げています。1枚のテンプレートに書けば、ネットワークからサーバー、データベースまでが一度に立ち上がります。
混同しやすいのが、同じIaCの道具であるTerraformです。ざっくり言えば、AWS CloudFormationはAWS専用で追加の準備がいらない代わりにAWSの外は扱えず、TerraformはAWS以外のクラウドも同じ書き方で扱える代わりに自前で状態ファイルを管理する必要があります。どちらが正解ということはなく、現場ですでに使われているほうに合わせるのが最初の一歩です。
もうひとつ名前を見かけるのがAWS CDKです。こちらはTypeScriptやPythonといったプログラミング言語でインフラを書く道具ですが、最終的にはCloudFormationのテンプレートに変換されて実行されます。つまりCDKを使う場合でも、土台にあるのはCloudFormationです。ここを知っておくと、エラーメッセージにいきなりスタックやリソースの話が出てきても驚かずにすみます。
会社の規模が大きくなると、複数のAWSアカウントに同じ構成を配りたくなります。公式が「インフラストラクチャを世界規模でスケール」できるとしているのがこの部分で、AWS CloudFormationにはスタックセットという複数アカウント・複数リージョンへまとめて展開するしくみが用意されています。新人のうちに触ることは少ないので、言葉だけ頭の隅に置いておけば十分です。
現場ではAWS CloudFormationをこう見ている
ここからは、運用監視から設計構築まで10年ほどインフラを見てきた筆者(AWS認定8冠)が、実際の案件で使っている判断の物差しを書きます。公式ページには載っていない部分です。
まず「消せるかどうか」で価値を測ります。AWS CloudFormationの本当のありがたみは、作るときより消すときに出ます。検証用にコンソールで手作りした環境は、たいてい消し残ります。セキュリティグループだけ残る、Elastic IPだけ残る、そして数か月後に請求書で気づく。スタックにしておけば削除は1回で、残りません。検証環境こそテンプレート化する価値がある、というのが実感です。
次に「全部入り」の1枚にはしません。ネットワークからアプリまで全部を1つのスタックに詰めると、アプリを少し直したいだけのときにネットワークまで巻き込むことになります。寿命の違うものは分ける、が基本です。めったに変わらないネットワーク、たまに変わるデータベース、しょっちゅう変わるアプリ。この3つでスタックを分けておくと、事故の範囲が小さくなります。
最後に「削除保護」を先に入れます。失敗しても巻き戻ってくれるとはいえ、消していいものと消してはいけないものはあります。データベースやログの保管先には、消えないようにする設定(削除ポリシー)をテンプレート側に書いておきます。CloudWatchのアラームで気づける事故と違い、消えたデータは戻りません。ここだけは最初に手当てします。
新社会人のうちは、この3つ(消しやすさ・スタックの分け方・削除保護)を意識できるだけで、テンプレートのレビューで的を射た質問ができます。
AWS CloudFormationの料金と無料枠
まず結論として、ふつうの使い方ならAWS CloudFormation自体の料金はかかりません。公式の料金ページには、AWS::* および Alexa::* という名前空間のリソースについては「追加料金は発生しません」と書かれています。EC2やS3といったAWS標準のサービスは、すべてこの範囲に入ります。
ただし当然ながら、テンプレートから作られたリソースそのものには通常どおり料金がかかります。CloudFormationはタダでも、それが建てたEC2のインスタンスは動いている時間ぶん課金されます。「無料だから」とスタックを作りっぱなしにするのが、いちばんありがちな事故です。
料金が発生するのは、AWS以外が提供するサードパーティ製のリソースや、独自に作ったフック(実行前の検査のしくみ)を使う場合です。執筆時点(2026年9月)の公式料金ページには、次のように記載されています。
- ハンドラーオペレーション1回につき 0.0009 USD
- 1回あたり30秒を超えた分は、1秒につき 0.00008 USD(最初の30秒は追加費用なし)
- 毎月1,000回のハンドラーオペレーションが無料枠(フックとサードパーティリソースの合算)
この無料枠は、新規アカウント限定ではなく毎月使えます。学習中に自分でフックを書くことはまずないので、実質は「無料で使い放題、ただし建てたものには課金される」と覚えておけば足ります。なお単価は見直されることがあるため、実際に使う前には必ず公式の料金ページで最新の内容を確認してください。
AWS CloudFormationのまとめ
ここまでの要点を整理します。
- AWS CloudFormationは、作りたいAWS環境をYAMLかJSONのテンプレートに書いて渡すと、その通りに建ててくれるしくみ。建ったかたまりをスタックと呼ぶ
- 途中で失敗すれば作ったぶんを自動で削除して巻き戻す。既存環境を変えるときは変更セットで影響を先に確認する
- CloudFormation自体はAWS標準リソースなら無料。課金されるのは建てたリソースと、サードパーティ製リソースやカスタムフックのハンドラーオペレーション(月1,000回まで無料)
まずは自分の現場で、どの環境がスタックで管理されているかを聞いてみてください。管理されている環境とされていない環境が分かると、なぜ「コンソールで直接いじらないで」と言われるのかが腹落ちします。
コメント