AWSでのインフラ構築を自動化し、手動運用のミスや手間を削減したいと考えていませんか？
「AWS CloudFormation」を活用すれば、インフラ構成をコードとして定義し、安全かつ迅速に同じ環境を再現することが可能になります。
本記事では、Infrastructure as Code (IaC) の基礎的な仕組みから、JSONやYAMLを用いたテンプレートファイルの書き方、スタックによるリソース管理の手順までを初心者向けに徹底解説します。
Terraformとの違いや料金体系といった導入前の疑問も解消し、効率的なインフラ運用の第一歩をサポートします。
この記事で分かること
- AWS CloudFormationの仕組みとIaCのメリット
- テンプレートの基本的な書き方とS3作成の記述例
- マネジメントコンソールでのスタック作成・削除手順
- Terraformとの違いや料金に関するよくある質問
AWS CloudFormationとはどのようなサービスか
AWS CloudFormationは、Amazon Web Services（AWS）のリソース設定やプロビジョニングをコードとして管理・自動化するためのサービスです。開発者やシステム管理者は、JSONまたはYAML形式のテキストファイルを作成するだけで、EC2インスタンスやRDSデータベース、S3バケットといったAWSリソースの集合体を、安全かつ繰り返し構築することが可能になります。
手動でのコンソール操作から脱却し、インフラ構築の手順書そのものをコード化してAWS側に実行させることで、人的ミスの削減や業務効率化を実現します。AWSを利用したシステム構築において、モダンな運用フローを確立するために欠かせない基盤サービスの一つと言えるでしょう。
Infrastructure as CodeであるIaCの概念と重要性
AWS CloudFormationを理解する上で前提となるのが、「Infrastructure as Code（IaC）」という概念です。これは、サーバー、ネットワーク、データベースなどのインフラ構成を、プログラムコードのように記述したファイルで管理する手法を指します。
従来の手法では、AWSマネジメントコンソール上でボタンをクリックしながら設定を行ったり、手順書を見ながらコマンドを入力したりしていました。しかし、この方法では「操作ミスが発生しやすい」「誰がいつ変更したか履歴が残りにくい」「同じ環境を複製するのに手間がかかる」といった課題がありました。
IaCを導入することで、インフラの構成情報はすべてコード（テンプレート）として保存されます。これにより、Gitなどのバージョン管理システムを用いて変更履歴を追跡したり、チームでレビューを行ったりすることが可能になるのです。アプリケーションコードと同じようなプロセスでインフラを扱えるようになることが、DevOpsを推進する上で極めて重要となります。
AWS CloudFormationで実現できるインフラ自動化の仕組み
AWS CloudFormationは、ユーザーが記述した「テンプレート」を読み込み、そこに書かれた設計図通りにAWSリソースを自動的に作成・設定します。この一連のリソース群は「スタック」という単位で管理されます。
具体的な仕組みとしては、ユーザーがテンプレートファイルをCloudFormationにアップロードすると、CloudFormationエンジンがその内容を解析します。リソース間の依存関係（例：VPCを作成してからでないとEC2は作成できない、など）を自動的に判別し、適切な順序でAWS APIを呼び出して構築を行います。
- テンプレート作成：必要なリソースや設定値をJSON/YAMLで記述する
- スタック作成指示：AWSコンソールやCLIからテンプレートを指定して実行する
- 自動プロビジョニング：CloudFormationが依存関係を解決しながらリソースを作成する
もし構築途中でエラーが発生した場合、CloudFormationは自動的に変更をロールバック（取り消し）し、実行前の状態に戻そうと試みます。これにより、中途半端にリソースが残ってしまうリスクを軽減し、安全なインフラ管理を実現しています。
AWS CloudFormationを利用するメリットとデメリット
AWS CloudFormationを導入することで得られるメリットは多岐にわたりますが、同時に学習コストなどのデメリットも存在します。導入を検討する際は、以下の特徴を把握しておくことが大切です。
主なメリットとデメリットを整理しました。
| 分類 | 内容 |
|---|---|
| メリット | インフラ構成をコードで管理できるため、バージョン管理や複製が容易になる ブラウザ操作による設定ミス（ヒューマンエラー）を防止できる 同じ構成の環境（開発・検証・本番など）を短時間で何度でも作成できる AWSサービスのため、追加料金なしで利用できる（作成されたリソース料のみ） |
| デメリット | 独自のテンプレート記述ルール（JSON/YAML）を学習する必要がある 小規模で一時的な環境構築の場合、手動操作よりも準備に時間がかかることがある 記述内容が長くなると、テンプレートファイルの管理が複雑になりやすい |
特に、インフラの「ドリフト検出」機能は大きなメリットです。これは、CloudFormationで作成した後に、誰かがコンソールから手動で設定を変更してしまった場合、コード上の定義と実際のリソース設定にズレ（ドリフト）が生じていることを検知できる機能です。
これにより、意図しない設定変更を早期に発見し、インフラの状態を健全に保つことができます。
詳細な機能や最新の情報については、AWS CloudFormation 公式製品ページもあわせて参照してください。
AWS CloudFormationの主要な構成要素
AWS CloudFormationを使いこなすためには、サービスの根幹を成すいくつかの専門用語と概念を正しく理解しておく必要があります。
このサービスは主に、インフラの構成を記述した「テンプレート」と、そこから生成されるリソースの集合体である「スタック」という2つの要素によって成り立っています。
ここでは、CloudFormationを利用する上で避けては通れない主要な構成要素について解説します。
設計図となるテンプレートファイル
テンプレートファイルは、AWSリソースの構成情報を記述したテキストファイルです。どのようなサーバー（EC2）を起動し、どのようなストレージ（S3）を作成し、それらをどうネットワーク接続するかといった「インフラの設計図」としての役割を果たします。
テンプレート内では、作成したいAWSリソースだけでなく、入力パラメータや出力値などを定義することも可能です。このファイルさえあれば、同じ構成のインフラを何度でも、異なるリージョンやアカウントに展開することができます。
テンプレートには主に以下のようなセクションが含まれます。
- Resources（必須）：作成するAWSリソース（EC2インスタンスやS3バケットなど）とそのプロパティを定義します。
- Parameters：スタック作成時に外部から値を入力できるようにするための変数を定義します。
- Outputs：スタック作成後に、生成されたリソースのIDやURLなどを出力値として表示させる定義です。
- Mappings：リージョンや環境ごとに異なる値を使い分けるための対応表を定義します。
リソースの集合体であるスタック
スタックは、テンプレートに基づいて実際にAWS上にプロビジョニング（作成）されたリソースの集合体です。テンプレートが「設計図」であるのに対し、スタックはその設計図から建てられた「実際の建物」に相当します。
CloudFormationでは、リソースを個別に操作するのではなく、このスタックという単位で一括管理します。例えば、スタックを削除すれば、そのスタックに含まれるすべてのリソース（EC2インスタンス、セキュリティグループ、RDSなど）がまとめて削除されます。これにより、リソースの消し忘れによる課金を防ぐことができるほか、依存関係のあるリソース群を安全に管理することが可能になります。
スタックの操作はAWS CloudFormation コンソールやAWS CLIを通じて行い、作成・更新・削除といったライフサイクル全体をコントロールします。
テンプレートのフォーマットであるJSONとYAML
テンプレートファイルを作成する際の記述フォーマットとして、JSON（JavaScript Object Notation）とYAML（YAML Ain't Markup Language）の2種類がサポートされています。どちらの形式を使用しても機能的な違いはなく、同じリソースを作成することができますが、記述のしやすさや可読性に違いがあります。
それぞれのフォーマットの特徴を比較すると以下のようになります。
| 比較項目 | JSON | YAML |
|---|---|---|
| 可読性 | 括弧やカンマが多く、人間にはやや読みづらい | インデントで構造を表すため、人間にとって読みやすい |
| コメント機能 | 標準ではサポートされていない | 「#」を使ってコメントを記述できる |
| ファイルサイズ | 記述量が多くなりがち | 記述量が少なくコンパクトになる |
| 主な用途 | システム間連携やプログラムによる自動生成 | 人間が手動で記述・管理する場合 |
近年では、コメントが記述でき、構造が見やすくミスが起きにくいことから、YAML形式でテンプレートを作成することが一般的になっています。特にチームで開発を行う場合、コード内に意図や説明をコメントとして残せる点は大きなメリットとなります。
- 初めて学習する場合は可読性の高いYAMLがおすすめ
- 既存のJSONテンプレートをYAMLに変換するツールも利用可能
- AWS CloudFormation Designerを使えば、GUIでテンプレートを視覚的に編集できる
AWS CloudFormationテンプレートの基本的な書き方
AWS CloudFormationを使いこなすための第一歩は、設計図となるテンプレートファイルの構造を正しく理解することです。
テンプレートは、AWSリソースのプロパティや設定値を記述したテキストファイルであり、一般的にYAML形式またはJSON形式で作成されます。ここでは、可読性が高くコメントの記述も可能なYAML形式を前提に、基本的な書き方とルールを解説します。
テンプレートの主要なセクション構成
CloudFormationのテンプレートは、いくつかの決まったセクション（項目）で構成されています。それぞれのセクションには役割があり、記述する順序に厳密な決まりはありませんが、論理的な構成を保つために一般的な並び順が存在します。
テンプレートを作成する上で最も重要な点は、Resourcesセクションのみが必須であり、それ以外は任意であるということです。つまり、リソース定義さえあればテンプレートとして機能します。主要なセクションの役割は以下の通りです。
| セクション名 | 必須 / 任意 | 役割と記述内容 |
|---|---|---|
| AWSTemplateFormatVersion | 任意 | テンプレートのフォーマットバージョンを指定します。現在は「2010-09-09」のみが有効です。 |
| Description | 任意 | テンプレートの内容を説明するテキスト文字列を記述します。 |
| Parameters | 任意 | スタック作成時にユーザーが入力できる値を定義します（例：インスタンスタイプやキーペア名など）。 |
| Mappings | 任意 | 条件（リージョンや環境など）に応じて値を切り替えるためのキーと値のマップを定義します。 |
| Resources | 必須 | EC2インスタンスやS3バケットなど、実際に作成するAWSリソースとそのプロパティを定義します。 |
| Outputs | 任意 | スタック作成後にコンソールへ表示したい値や、他のスタックから参照させたい値を定義します。 |
最小限の構成でS3バケットを作成する記述例
テンプレートの構造を理解するために、最もシンプルな構成でAWSリソースを作成してみましょう。ここでは、特別な設定を持たないS3バケットを1つ作成するYAMLテンプレートを例に挙げます。
この記述における重要なポイントは以下の通りです。
- 論理ID（MySampleBucket）：テンプレート内でこのリソースを識別するための名前です。任意の英数字を使用できます。
- リソースタイプ（Type）：作成するリソースの種類を指定します。S3バケットの場合は
AWS::S3::Bucketとなります。 - プロパティ（Properties）：この例では省略していますが、バケット名やバージョニング設定などを行う場合は、Typeの下にPropertiesセクションを追加して記述します。
このように、必須であるResourcesセクションの中に「論理ID」と「リソースタイプ」を記述するだけで、AWS CloudFormationは自動的にリソースを認識し、構築を開始することができます。
組み込み関数RefとGetAttを活用して値を参照する
実用的なテンプレートを作成する場合、リソース間で値を連携させる必要があります。例えば、EC2インスタンスを作成する際に、同じテンプレート内で作成したセキュリティグループのIDを指定する場合などです。このような動的な値の参照には「組み込み関数」を使用します。
特によく利用されるのが Ref と Fn::GetAtt の2つです。
- Ref（リファレンス）
指定したリソースやパラメータの「デフォルトの値」を返します。リソースによって返される値は異なりますが、多くの場合、リソースID（インスタンスIDやセキュリティグループIDなど）やリソース名が取得できます。 - Fn::GetAtt（ゲットアット）
リソースが持つ特定の属性値を取得します。Refでは取得できない詳細な情報（例：S3バケットのDNS名や、作成されたリソースのARNなど）を参照したい場合に使用します。
例えば、S3バケットのドメイン名を取得したい場合は、以下のように記述します。
このように組み込み関数を適切に使い分けることで、値をハードコーディングすることなく、柔軟で再利用性の高いテンプレートを作成することが可能になります。
AWS CloudFormationの使い方とスタック作成手順
前章までに作成したテンプレートファイルを使用して、実際にAWS環境へリソースを構築する手順を解説します。AWS CloudFormationでは、テンプレートをアップロードし、いくつかの設定を行うだけで、自動的にインフラ環境がプロビジョニングされます。
AWSマネジメントコンソールからスタックを作成する
最も基本的で分かりやすい方法は、Webブラウザ上のAWSマネジメントコンソールを利用する方法です。事前にYAMLまたはJSON形式で記述したテンプレートファイル（例：s3-bucket.yaml）を手元に用意した状態で、以下の手順を進めてください。
- AWSマネジメントコンソールにログインし、サービス一覧から「CloudFormation」を選択します。
- ダッシュボード画面にある「スタックの作成」ボタンをクリックし、「新しいリソースを使用（標準）」を選択します。
- 「テンプレートの準備完了」を選択し、テンプレートソースとして「テンプレートファイルのアップロード」を選びます。ここで手元のファイルを選択し、「次へ」をクリックします。
- 「スタック名」に任意の名前（例：
my-test-stack）を入力します。パラメータを設定している場合はここで値を入力し、「次へ」に進みます。 - 「スタックオプションの設定」画面では、タグの設定やIAMロールの指定が可能ですが、基本的な構成であればデフォルトのまま「次へ」をクリックします。
- 最後にレビュー画面で設定内容を確認し、問題なければ「送信」ボタンをクリックします。
この操作により、CloudFormationエンジンがテンプレートを読み込み、記載されたリソースの作成を開始します。初めて利用する場合は、意図しない課金を防ぐためにも、テスト後は必ずリソースを削除する習慣をつけることをおすすめします。
スタックのイベント確認と作成完了のステータス
「送信」ボタンをクリックすると、スタックの詳細画面に遷移し、「イベント」タブが表示されます。ここでは、AWS CloudFormationが実行している操作のログがリアルタイムで更新されます。リソースの作成開始、進行中、完了といったプロセスを時系列で確認できるため、エラーが発生した場合の原因究明にも役立ちます。
スタックの状態を示す「ステータス」は、構築の進行状況を把握する上で非常に重要です。主なステータスの意味を以下に整理しました。
| ステータス | 意味 | 詳細 |
|---|---|---|
| CREATE_IN_PROGRESS | 作成進行中 | スタックまたはリソースの作成処理が現在実行されている状態です。 |
| CREATE_COMPLETE | 作成完了 | すべてのリソースが正常に作成され、スタックの構築が成功した状態です。 |
| CREATE_FAILED | 作成失敗 | リソースの作成に失敗しました。通常、自動的にロールバック（変更の取り消し）が開始されます。 |
| ROLLBACK_IN_PROGRESS | ロールバック進行中 | 作成に失敗した後、環境を元の状態に戻すために作成したリソースを削除しています。 |
| ROLLBACK_COMPLETE | ロールバック完了 | 作成失敗後の後処理が完了した状態です。この状態のスタックは再利用できないため、削除して作り直す必要があります。 |
ステータスがCREATE_COMPLETEになれば、インフラ構築は成功です。作成されたS3バケットなどのリソースが、実際にAWSアカウント上に存在しているか確認してみましょう。
作成したスタックを削除してリソースをクリーンアップする
検証が終わった後は、不要なリソースを削除してクリーンアップを行います。AWS CloudFormationの大きなメリットの一つは、スタックを削除するだけで、そのスタックによって作成されたすべてのリソースを一括で削除できる点です。これにより、削除忘れによる不要なコスト発生や、ゴミデータの残留を防ぐことができます。
- CloudFormationコンソールのスタック一覧から、削除したいスタックを選択します。
- 画面上部の「削除」ボタンをクリックします。
- 確認ダイアログが表示されるので、再度「削除」をクリックして実行します。
削除処理が開始されると、ステータスは DELETE_IN_PROGRESS に変わり、完了すると DELETE_COMPLETE となってスタック一覧から消えます（フィルタ設定によっては表示される場合もあります）。ただし、S3バケット内にオブジェクト（ファイル）が残っている場合など、一部のリソースは安全のために削除が失敗することがあります。その場合はバケットを空にしてから再度スタックの削除を行ってください。
より詳細な操作方法やトラブルシューティングについては、AWS CloudFormation ユーザーガイドもあわせて参照してください。
AWS CloudFormationに関するよくある質問
AWS CloudFormationを導入する際や運用中に、多くのエンジニアが疑問に思うポイントをQ&A形式で解説します。IaC（Infrastructure as Code）ツールの選定や、実際のトラブルシューティングに役立つ情報を整理しました。
AWS CloudFormationとTerraformの主な違いは何ですか
AWS CloudFormationとHashiCorp社のTerraformは、どちらも人気の高いIaCツールですが、その特性には明確な違いがあります。最も大きな違いは、対応しているプラットフォームの範囲と状態管理（State）の仕組みです。
CloudFormationはAWSに特化したマネージドサービスであり、AWSの新機能への対応が早いのが特徴です。一方、TerraformはAWSだけでなく、AzureやGoogle Cloudなどのマルチクラウドに対応しており、独自の言語（HCL）を使用します。
| 比較項目 | AWS CloudFormation | Terraform |
|---|---|---|
| 対応プラットフォーム | AWS（AWS専用） | AWS, Azure, GCPなど（マルチクラウド） |
| 記述言語 | JSON, YAML | HCL (HashiCorp Configuration Language) |
| 状態管理（State） | AWS側で自動管理 | ユーザーが管理（tfstateファイル） |
| 利用料金 | 無料（リソース料のみ） | オープンソース版は無料 |
AWSのみを利用する環境であれば、状態管理の手間がないCloudFormationが手軽ですが、将来的にマルチクラウド環境を想定している場合はTerraformが有力な選択肢となります。
AWS CloudFormationの利用に料金はかかりますか
AWS CloudFormationというサービス自体の利用には、基本的に追加料金はかかりません。ただし、CloudFormationによって作成されたAWSリソース（EC2インスタンス、RDSデータベース、Elastic Load Balancingなど）に対しては、それぞれのサービス料金が発生します。
例えば、テンプレートを使ってEC2インスタンスを1台起動した場合、CloudFormationへの支払いは0円ですが、EC2の稼働時間に応じた料金は通常通り請求されます。スタックを作成する前に、テンプレート内で定義されているリソースの料金体系を確認しておくことが重要です。
テンプレート記述にはJSONとYAMLのどちらを使うべきですか
AWS CloudFormationのテンプレートはJSONとYAMLの2つの形式をサポートしていますが、人間が読み書き・保守を行う場合はYAML形式の使用が推奨されます。
YAMLはJSONに比べて記述量が少なく、コメントアウト機能（#）が使えるため、設定の意図やメモを残しやすいというメリットがあります。それぞれの特徴は以下の通りです。
- YAML：コメントが記述可能で可読性が高い。手動でのテンプレート作成に向いている。
- JSON：コメントが記述できない。システムによる自動生成や解析に向いている。
AWS公式のドキュメントやサンプルコードも、近年ではYAMLで記述されているケースが増えています。
既存のAWSリソースをCloudFormationで管理することはできますか
はい、可能です。以前は手動で作成したリソースをCloudFormationの管理下に置くことは困難でしたが、現在は「リソースのインポート」機能を利用することで、既存のリソースをスタックに取り込むことができます。
この機能を利用する手順は以下の通りです。
- 既存リソースの構成と一致するテンプレートを作成する
- CloudFormationコンソールで「スタックの作成」を選択し、「既存のリソースを使用（リソースをインポート）」を選ぶ
- テンプレートと既存リソースをマッピングしてインポートを実行する
これにより、マネジメントコンソールから手動で作った検証環境などを、後からIaCによるコード管理へ移行させることが容易になります。
スタックの削除に失敗した場合の対処法はありますか
スタックの削除が失敗する主な原因には、S3バケット内にオブジェクトが残っている、または他のリソースから依存されているセキュリティグループがある、といったケースが挙げられます。このような場合、スタックのステータスは「DELETE_FAILED」となります。
削除に失敗した際の対処法として、原因となっているリソースの削除をスキップし、スタックのみを削除する方法があります。AWSマネジメントコンソールで削除を再試行する際に、削除できないリソースを「保持するリソース」として選択することで、スタック自体を強制的に削除完了の状態にできます。その後、残ったリソースを手動で調査・削除することでクリーンアップが可能です。
まとめ
本記事では、AWSのインフラ構築を自動化する「AWS CloudFormation」について、基礎知識から実践的な使い方まで解説しました。
記事のポイントは以下の通りです。
- IaCのメリット：インフラをコード化することで、構築の迅速化と人的ミスの削減を実現できる
- 基本構造：テンプレート（JSONまたはYAML）でリソースを定義し、スタックとして一括管理する仕組み
- 実践手順：テンプレートの記述からデプロイ、リソースのクリーンアップまでの具体的な流れ
CloudFormationは、AWS環境の運用効率を劇的に向上させる強力なサービスです。まずはシンプルなS3バケットの作成から、インフラの自動化に挑戦してみましょう。
