IaC の入門は済んでいて、テンプレートを書くこと自体は分かる。けれど複数のアカウントを持つ本番では、書いた後が問題になります。壊さずに変える方法、コンソールで直された変更の見つけ方、多数のアカウントへ同じ基盤を配る方法を、どの機能が受けるのか。この記事は CloudFormation の部品を「何を守る機能か」で並べ直し、基盤をスタックで持つときの設計の論点を整理します。
この記事の結論
- CloudFormation は、テンプレートに書いた資源を「スタック」という単位でまとめて作る・変える・消すサービスです。
- 本番の更新は、変更セットで先に影響（資源の置き換えがあるか）を見てから実行します。
- コンソールでの手作業の変更は、ドリフト検出でテンプレートとの差として見つけます。
- 多数のアカウント・リージョンへは StackSets を使います。Organizations 連携のサービスマネージド型なら、新しいアカウントにも自動で展開できます。
- 削除や置き換えの事故は、終了保護・DeletionPolicy・スタックポリシーで止めます。
CloudFormation とは何か｜テンプレートとスタックで「資源のまとまり」を持つ
AWS CloudFormation は、JSON か YAML で書いたテンプレートを読み、そこに書かれた AWS の資源をまとめて作るサービスです。作られた資源のまとまりはスタックと呼ばれ、作成・更新・削除はスタックを単位に行います。スタックを消せば、そこに属する資源がまとめて片付く（DeletionPolicy で変えない限り）のが、手作業との大きな違いです。
IaC の考え方そのものは IaC とは何か に任せて、ここでは設計に効く点だけを押さえます。
| 部品 | 役割 | 守っているもの |
|---|---|---|
| テンプレート | 資源の定義書 | 再現性（同じ構成を何度でも） |
| スタック | 資源のまとまり。変更と削除の単位 | 一貫性（まとめて作り、まとめて消す） |
| 変更セット | 更新前のプレビュー | 本番の安全な更新 |
| ドリフト検出 | 実物とテンプレートの差の発見 | 定義と実態のずれの把握 |
| StackSets | 多数のアカウント・リージョンへの展開 | 組織全体の統一 |
SAFE CHANGE LOOP更新の流れ
更新は確認してから実行し、実物との差はあとで見つける
-
テンプレート
資源の定義書
-
変更セット
置き換えの有無を確認
-
実行
スタックが更新される
-
スタック
資源のまとまり
-
ドリフト検出
手作業の差を発見
本番の更新を安全にするには｜変更セットで置き換えを先に見る
テンプレートを書き換えて更新すると、プロパティによっては資源が「その場で変わる」のではなく「新しく作り直されて古いものが消える」ことがあります。これが置き換え（Replacement）です。データを持つ資源でこれが起きると、事故になります。
変更セットは、更新を実行する前に「どの資源が追加・変更・削除されるか、置き換えが起きるか」を一覧で見せる機能です。流れは、変更セットを作る、中身を人が確かめる、問題なければ実行する、の3つです。承認を挟むパイプラインなら、この確認を承認の材料にできます。
注意点は、変更セットは「CloudFormation が把握できる範囲の予告」だということです。テンプレート外で変えられた実物の差は別問題で、それは次の章のドリフト検出の守備範囲です。
CHECK 1ここまでの確認
本番のスタックを更新する前に、資源が作り直しになるかどうかを見たいとき、使う機能はどれか?
答えと解説
答え: 2. 変更セット
変更セットは更新を実行する前のプレビューで、資源ごとの変更と置き換えの有無が分かります。ドリフト検出は更新ではなく「いまの実物」を調べる機能です。第2章を読み直してください。
手作業の変更はどう見つける？｜ドリフト検出が見るものと見ないもの
障害対応では、急いでコンソールから設定を直すことがあります。その変更がテンプレートに戻らないと、次の更新で意図せず元に戻ったり、環境ごとの差になったりします。この「定義と実物のずれ」がドリフトです。
ドリフト検出は、スタックのテンプレートが期待する設定と、いまの実際の設定を比べ、差のある資源を示す機能です。差はプロパティ単位で、期待する値と実際の値が並んで見えます。
| 変更セット | ドリフト検出 | |
|---|---|---|
| いつ使う | 更新の前 | 運用中（定期的に） |
| 比べるもの | 現行スタックと新しいテンプレート | テンプレートと実際の資源 |
| 分かること | 何がどう変わるか、置き換えの有無 | テンプレート外で変えられた箇所 |
見つけるだけで、直しはしません。どちらに合わせるかは運用の判断です。また、ドリフト検出が対応する資源の種類や、検出の細かな範囲は公式ドキュメントの記述に従ってください。対応していない資源は、この機能では見えません。
CHECK 2ここまでの確認
障害対応の最中に画面から直接直された設定を、あとで見つけるにはどうするか?
答えと解説
答え: 3. ドリフト検出を実行する
ドリフト検出は、テンプレートが期待する設定と実際の設定を比べ、差のある資源を示します。見つけるだけで、元に戻す操作は含みません。第3章を読み直してください。
多数のアカウントへ配るには｜StackSets と2つの権限モデル
組織で、監査用の IAM ロールや共通の設定を全アカウントに置きたい。アカウントごとにスタックを作る代わりに、StackSets を使います。管理者アカウントで1つのテンプレートから StackSet を作ると、指定したアカウントとリージョンの組み合わせに「スタックインスタンス」が作られ、そこに実際のスタックが置かれます。
THREE LEVELSStackSets の構造
1つの StackSet がアカウント×リージョンのスタックになる
-
管理者
管理者アカウント — テンプレートから StackSet を作る
展開の指示を1か所で出す
-
StackSet
StackSet — 配る定義と対象を持つ
更新も1か所から
-
実体
スタックインスタンス — アカウントとリージョンの組ごとのスタック
ここに資源が作られる
権限の与え方が2種類あります。
TWO PERMISSION MODELS権限モデルの違い
新アカウントまで自動で届くのはサービスマネージド型
自己管理型
ロールを自分で用意する
- 管理者側とターゲット側にIAMロールを用意
- 対象はアカウントで指定
- Organizations 外のアカウントにも使える
サービスマネージド型
Organizations と連携する
- 必要なロールは CloudFormation が用意
- 対象は OU で指定
- 自動デプロイで新アカウントにも展開
- 自己管理型: 管理者アカウントと各ターゲットアカウントに、必要な IAM ロールを自分で用意する。Organizations に属さないアカウントにも使える。
- サービスマネージド型: AWS Organizations と連携し、対象を OU で指定する。必要なロールは CloudFormation が用意する。自動デプロイを有効にすると、OU に後から加わったアカウントにも展開される。
組織の基盤を配る用途では、新アカウントに自動で届くサービスマネージド型が第一候補になります。展開の失敗をどこまで許すか（失敗許容度）や同時に処理する数も StackSets の設定にあり、細かい扱いは公式ドキュメントで確認してください。
CHECK 3ここまでの確認
組織に後から加わるアカウントにも、同じスタックを自動で配りたい。StackSets ではどの組み合わせか?
答えと解説
答え: 2. サービスマネージド型の権限モデルで自動デプロイを有効にする
サービスマネージド型は AWS Organizations と連携し、対象の OU に自動デプロイを有効にすると新しいアカウントにも展開されます。第4章を読み直してください。
事故を止める仕組み｜終了保護・DeletionPolicy・スタックポリシー
似た名前の防御が3つあり、止める対象が違います。
止める対象の違い
- 終了保護: スタックの削除操作そのものを失敗させる。
- DeletionPolicy: 削除されるとき、その資源を残す（Retain）か、スナップショットを取る（Snapshot）かを決める。削除自体は止めない。
- スタックポリシー: スタック更新のとき、指定した資源の更新（置き換えや削除）を拒否する。Deny は Allow に優先する。
運用者が共通基盤のスタックを誤って消す事故には終了保護、データを持つ資源が消えても残したいなら DeletionPolicy、更新で特定の資源が作り直されるのを防ぐならスタックポリシーです。一つで全部は守れないので、事故の型ごとに組み合わせます。
CHECK 4ここまでの確認
共通の基盤スタックを運用者が間違って消す事故を、最も手軽に防ぐ設定はどれか?
答えと解説
答え: 1. 終了保護
終了保護はスタックの削除操作そのものを失敗させます。DeletionPolicy は「削除されるとき資源をどうするか」を決めるもので、削除自体は止めません。第5章を読み直してください。
スタックをどう分けるか｜Outputs/ImportValue とネストの判断軸
1つのスタックに全部を入れると、変更の影響範囲が広がり、更新も遅くなります。分け方の軸は「変更の頻度と持ち主」です。ネットワーク基盤のように変わりにくく専任のチームがいるものと、アプリのように頻繁に変わるものは、別のスタックにします。
- スタック間の参照: 基盤側が Outputs で値を Export し、アプリ側が Fn::ImportValue で参照する。IDを手でコピーしなくて済む。参照されている間は、エクスポート元のスタックの該当出力を消せないので、基盤の変更に制約が生まれる。
- ネストされたスタック: 共通の部品（同じ構成の ALB など）を別テンプレートにして、親スタックの一部として取り込む。部品の修正を1箇所で済ませられる。
前者は「別の持ち主のスタックをゆるく結ぶ」、後者は「1つのまとまりを部品に割る」ためと覚えると、使い分けられます。
CDK・Terraform とどう使い分けるか（位置づけのみ）
CDK は、プログラミング言語で定義を書き、CloudFormation のテンプレートに変換してデプロイします。だから本記事の変更セット・ドリフト・StackSets はそのまま関わります。Terraform は別の道具で、状態を自前のファイルで持つ点が異なります。選ぶ軸は、チームが書きやすい言語と、状態をどこで持つかの方針です。細部は公式ドキュメントで確認してください。
まとめ
CloudFormation は部品ごとに守るものが違います。更新の前は変更セット、運用中の実物はドリフト検出、組織への展開は StackSets、事故は終了保護・DeletionPolicy・スタックポリシーで受けます。そのうえでスタックを変更の頻度と持ち主で分けると、基盤をコードで持つ設計の見通しが立ちます。次は、複数アカウントそのものの切り方を multi-account-sekkei で確かめてください。
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
参照ソース
- AWS CloudFormation とは（ユーザーガイド） — テンプレート・スタックの概念と、資源をまとめて管理する考え方の根拠
- StackSets の概念（ユーザーガイド） — StackSet とスタックインスタンス、自己管理型とサービスマネージド型の権限モデルの根拠
