変更要約: SOA-C02 第3章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
3.1CloudFormation によるプロビジョニング
CloudFormation のテンプレートとスタック、変更セットによる事前確認、StackSets による複数アカウント/リージョンへの展開、ドリフト検出といった IaC 運用を理解します。
運用では同じ環境を再現性をもって素早く作れることが重要です。CloudFormation は宣言的テンプレートでリソース群（スタック）を一括管理します。
3.1.1テンプレート・スタック・StackSets
- テンプレート/スタック：宣言的テンプレートからリソース群（スタック）を作成・更新・削除する。
- 変更セット：更新で何がどう変わるかを事前確認し、想定外の変更を防ぐ。
- StackSets：複数アカウント/リージョンへ同じスタックを一括展開する。
- ドリフト検出：実環境がテンプレートから逸脱（ドリフト）していないか検出する。
「更新内容の事前確認＝変更セット」「複数アカウント/リージョンへ一括展開＝StackSets」「手動変更とテンプレートの差＝ドリフト検出」 は SOA で頻出です。
運用視点では、CloudFormation を「安全に変える／横展開する／逸脱を検知する」道具として使います。更新時は 変更セット で「作成/更新/置換（Replace）/削除」を事前確認します。属性によっては更新がリソース置換を招き、ID やデータが失われることがあるため、置換の有無を読むのが重要です。重要リソースは DeletionPolicy（Retain/Snapshot） や スタックポリシー で保護し、誤更新・誤削除を防ぎます。複数アカウント/リージョンへ同一構成を配るには StackSets（サービスマネージド＝Organizations 連携で自動展開、セルフマネージド＝ロールを自前で用意）を使います。手動変更による乖離は ドリフト検出 で見つけ、テンプレートへ取り込み直します。更新失敗時は既定で自動ロールバックし、DELETE_FAILED などのスタック状態や CloudTrail /イベントで原因を追います。テンプレートの再利用には ネストスタック、出力共有には クロススタック参照（Export/ImportValue） が使えます。
| やりたいこと | 使うもの |
|---|---|
| 更新前に差分（置換含む）を確認 | 変更セット |
| 複数アカウント/リージョンへ展開 | StackSets |
| 手動変更との乖離を検知 | ドリフト検出 |
| 重要リソースを誤削除から保護 | DeletionPolicy / スタックポリシー |
シナリオ：本番 DB を含むスタックを更新する。 まず 変更セットで「DB が置換（Replace）されないか」を確認（置換ならデータ損失）。DB には DeletionPolicy: Snapshot を設定して保険をかけ、スタックポリシーで当該リソースの更新を制限。全リージョンへ同設定を配るなら StackSets。手動変更があれば ドリフト検出で洗い出してテンプレートへ戻します。
Q. 更新で何が変わるか確認したい。 変更セット（置換の有無も見る）。Q. 複数アカウントへ一括展開？ StackSets。Q. 手動変更を検知？ ドリフト検出。Q. 更新失敗時は？ 既定で自動ロールバック。Q. 重要リソースを守る？ DeletionPolicy / スタックポリシー。
混同に注意：
①一部の更新はリソース置換を起こし ID/データを失う——変更セットで必ず確認。
②ドリフトを放置してテンプレート外で直すと次回更新で上書き/破壊される。
③StackSets のサービスマネージドは Organizations 前提。
④自動ロールバック中の手動操作はスタックを UPDATE_ROLLBACK_FAILED に陥れることがある。
スタックの更新が失敗するとデフォルトで自動ロールバックします。手動変更（ドリフト）を避け、変更は常にテンプレート経由で行うのが運用の鉄則です。
3.1.2この節のまとめ
- テンプレート→スタック、更新は変更セットで事前確認
- StackSets（横展開）／ドリフト検出を活用
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CloudFormation スタックの更新前に、どのリソースがどう変わるかを事前確認したい。何を使いますか？
Q2. 同じスタックを複数アカウントと複数リージョンへ一括展開したい。何を使いますか？
Q3. 誰かが手動でリソースを変更し、テンプレートと実環境がずれているか調べたい。何を使いますか？