AWS CloudFormation

解決する課題

マネジメントコンソールでリソースを手作業で作ると、環境ごとに設定がズレたり、誰が何を変えたか追えなくなったりします。CloudFormation はインフラを コード（テンプレート） として記述することで、これらを解決します。

• 同じテンプレートから 本番・ステージング・開発を再現性高く 構築できる
• 変更履歴を Git で管理し、レビューやロールバックができる
• 関連リソースを スタック という単位でまとめて作成・削除でき、消し忘れを防ぐ
• 手順書ベースの手作業を排除し、構築をプロセスとして標準化できる

主要概念と用語

• テンプレート: リソース構成を記述した宣言的な定義ファイル（YAML または JSON）
• スタック: 1つのテンプレートから作成されるリソースの集合。ライフサイクル管理の単位
• リソース: テンプレートで定義する個々のAWS要素（EC2、S3、IAMロールなど）。Resources セクションは必須
• パラメータ: 作成時に外部から渡す入力値。環境差分を吸収する
• マッピング / 条件: リージョンや環境ごとに値や作成有無を切り替える仕組み
• 組み込み関数: Ref や Fn::GetAtt などでリソース間の値を参照する仕組み
• 出力（Outputs）: スタックが生成した値を外部公開する。クロススタック参照のエクスポートにも使う
• 変更セット（Change Set）: 更新を適用する前に、何がどう変わるかを事前にプレビューする仕組み
• ドリフト検出: テンプレート定義と実環境のズレ（手動変更など）を検出する機能
• StackSets: 複数アカウント・複数リージョンへ同一スタックを一括展開する仕組み

仕様・制限・クォータ

• テンプレートは YAML / JSON で記述。リージョン単位のサービスとして動作する
• 1テンプレートに含められるリソース数やパラメータ数、テンプレートサイズには上限があり、大規模時は ネストスタック で分割する
• テンプレートが大きい場合は S3 にアップロードして参照する方式が必要になる
• アカウントあたりのスタック数などにクォータがあり、必要に応じて引き上げ申請が可能
• サービス自体の利用料は無料で、課金は作成したリソースに対して発生する

具体的な上限値は変更されることがあるため、最新のクォータは公式ドキュメントで確認してください。

内部の仕組み

CloudFormation はテンプレートを解析し、各リソースの 依存関係グラフ を構築します。Ref や Fn::GetAtt による参照から依存を推測し、依存のないものは並列に、依存があるものは順番に各サービスのAPIを呼び出して作成します。明示的に順序を強制したい場合は DependsOn を使います。

• 作成: グラフ順にリソースを生成。途中で失敗すると既定では作成済み分を削除してロールバック
• 更新: 現在の状態と新テンプレートの差分を計算し、変更が必要なリソースだけを操作する
• 更新時の挙動: プロパティ変更の種類により「中断なし更新」「中断あり更新」「置換（作り直し）」のいずれかになる。置換では物理リソースが新規作成され古いものが削除されるため、データ消失に注意が必要
• 削除: 依存の逆順でリソースを削除する

設計パターン / ベストプラクティス

• 環境差分はパラメータ / マッピングで吸収 し、テンプレート本体は使い回す
• ネストスタック や クロススタック参照 で巨大テンプレートを役割ごとに分割し、再利用性を高める
• 削除保護（Termination Protection） や、重要リソースへの DeletionPolicy で誤削除・誤置換を防ぐ
• IAM 権限は最小権限にし、CloudFormation 実行用のサービスロールを分離する
• テンプレートは Git でバージョン管理 し、CI/CD パイプラインから変更セット経由で適用する
• 既存の手動リソースは リソースインポート で取り込み、IaC 管理下に移行できる

運用・監視

• スタックの イベント で各リソースの作成・更新・失敗の進行状況を時系列で確認できる
• 失敗時は ステータス とイベントの理由メッセージから原因を特定する
• ドリフト検出 を定期的に実行し、手動変更による設定ズレを早期に発見する
• スタックの操作は CloudTrail に記録され、誰がいつ変更したか監査できる
• スタックポリシー で更新時に保護したいリソースへの変更を制限できる

コスト

CloudFormation 自体の利用に基本料金はかかりません。課金されるのは、テンプレートから作成された 実リソース（EC2、RDS など）の利用料 です。ただし、サードパーティ製リソースなどを扱う拡張機能の一部では、ハンドラ操作量に応じた課金が発生する場合があります。

コスト最適化の観点では、不要になったスタックを丸ごと削除すれば関連リソースをまとめて消せるため、検証環境の消し忘れによる無駄を抑えられます。

セキュリティ

• スタック操作には実行者の IAM 権限が必要。サービスロール を指定すれば、操作を行う権限とCloudFormationがリソースを作る権限を分離できる
• テンプレートに パスワードや鍵を直書きしない。機密値は Secrets Manager や SSM パラメータストアを参照する
• パラメータには NoEcho を指定し、入力値がログや画面に表示されないようにする
• StackSets を使う場合は、信頼関係を持つ管理者・実行ロールの権限範囲を最小限にする

Well-Architected の観点

• 運用上の優秀性: インフラをコード化し、変更をレビュー・自動化・再現可能にする。手作業を排除し、変更セットで影響を予測できる
• 信頼性: スタック単位での一括管理と失敗時の自動ロールバックにより、中途半端な状態を防ぐ。複数環境を同一テンプレートで再現でき、復旧手順をコード化できる

試験で問われるポイント

関連サービス・比較

同じくIaCを実現する Terraform とよく比較されます。CloudFormation はAWSネイティブで状態管理をマネージドに任せられる点が特徴です。

ハンズオン / CLI例

# テンプレートの文法を検証
aws cloudformation validate-template \
  --template-body file://template.yaml

# 更新前に変更セットを作成して差分を確認
aws cloudformation create-change-set \
  --stack-name my-stack \
  --change-set-name my-change-set \
  --template-body file://template.yaml \
  --capabilities CAPABILITY_NAMED_IAM

# 変更内容を確認
aws cloudformation describe-change-set \
  --stack-name my-stack \
  --change-set-name my-change-set

# 問題なければ変更セットを実行して反映
aws cloudformation execute-change-set \
  --stack-name my-stack \
  --change-set-name my-change-set