Control Tower を CloudFormation で管理する前に知っておきたいこと

2026/06/16(火) Ops-JAWS Meetup41 運用 LT 大会 & プチ交流会
https://opsjaws.connpass.com/event/393478/

#jawsug #opsjaws

Transcript

1. Control Tower を CloudFormation で 管理する前に知っておきたいこと 2026/06/16 Ops-JAWS Meetup41 運⽤ LT ⼤会 & プチ交流会
2. AWS Control Tower とは 2 • AWS 上でマルチアカウント環境を安全かつ効率的に構築‧管理するための マネージドサービス • 主な機能 ◦ ベースライン適⽤（アカウント作成時の設定⾃動化） ◦ コントロール (旧ガードレール) （SCP / Config Rules / CFn hooks 等による予防的/検出的/プロアクティブコントロール） ◦ ドリフト検知 （CT が管理する設定が意図せず変更されたことを検出） • 2025 年にランディングゾーン(LZ) 4.0 がリリース ◦ ひとつ前のバージョンは LZ 3.3 ※AWS Black Belt Online Seminar AWS Control Tower 基礎編 より引用
3. マネコンで有効化したControl Tower、あとからCFnで管理したくなりませんか? • 設定変更の履歴を Git 管理したい • ⼿動オペレーションのミスを減らしたい • 環境の複製/横展開をしたい 3
4. CFnで管理できるCTリソースは3つ • AWS::ControlTower::LandingZone ◦ Landing Zone 全体の作成/更新 • AWS::ControlTower::EnabledControl ◦ コントロールの有効化 • AWS::ControlTower::EnabledBaseline ◦ OU /アカウントレベルのベースライン展開 4
5. でもコントロール全部は管理できない 5 • Mandatoryコントロールは CFn で管理不可 ◦ CFn で扱えるのは Strongly-recommended と Elective コントロールのみ ◦ Mandatory は⾃動有効化されるので、テンプレートに書いてはいけない • Mandatory かどうかは API 識別⼦からは判別できない ◦ マネコンやドキュメントで確認が必要
6. でもコントロール全部は管理できない 6
7. 7 既存環境を import してみたら予想外の連続だった
8. import するとタグ適⽤で重い処理が⾛る CFn スタックのタグ (aws:cloudformation:stack-name 等) をリソースに 付与するため、Update API が呼ばれる • LandingZone: Landing Zone のフル更新が⾛る (約30分) • EnabledBaseline: OU 再登録が⾛る (約4分) • EnabledControl: コントロールが有効になるだけ (数秒で完了) import = 取り込むだけ、ではなかった 8
9. import するとタグ適⽤で重い処理が⾛る CFn スタックのタグ (aws:cloudformation:stack-name 等) をリソースに 付与するため、Update API が呼ばれる • LandingZone: Landing Zone のフル更新が⾛る (約30分) • EnabledBaseline: OU 再登録が⾛る (約4分) • EnabledControl: 特になし (数秒で完了) import = 取り込むだけ、ではなかった 9
10. LZ 更新中の CT ダッシュボード • 組織単位: 0 / アカウント: 0 / コントロール: 0 • 「ランディングゾーンの セットアップが完了すると、 アカウントがここに表⽰され ます」 → 元々登録済みアカウント あったはずだけど！？ • もし本番環境でこの表⽰を ⾒たらかなり焦りそう 10 ← え？🤔
11. LandingZone の import では、ドリフト検出は動かない • CFn のドリフト検出を何回か実⾏ → ドリフトステータスが UNKNOWN のまま • CLI で詳細を確認すると Internal Failure • EnabledControl / EnabledBaseline の import では正常に動作 (ドリフトステータス: IN_SYNC) • LandingZone だけドリフト検出が成功しなかった 11
12. LandingZone の import では、ドリフト検出は動かない • CFn のドリフト検出を何回か実⾏ → ドリフトステータスが UNKNOWN のまま • CLI で詳細を確認すると Internal Failure • EnabledControl / EnabledBaseline の import では正常に動作 (ドリフトステータス: IN_SYNC) • LandingZone だけドリフト検出が成功しなかった LandingZone の import では、 テンプレートの正しさは⾃分で担保する必要があるが、 以降 CFn 経由で管理すれば変更の追跡は可能 12
13. DeletionPolicy: Retain を忘れるとコントロールが消える • EnabledControl を定義しているスタック削除時の動作 • Retain なしでスタック削除 → DisableControl API が実⾏される • 本番 OU のコントロールを管理している場合、スタック誤削除で本番 OU 配下の全アカウントでコントロールが外れることに🙄 DeletionPolicy 結果 Retain あり コントロールは残る Retain なし コントロールが無効化される 13
14. DeletionPolicy: Retain を忘れるとコントロールが消える • EnabledControl を定義しているスタック削除時の動作 • Retain なしでスタック削除 → DisableControl API が実⾏される • 本番 OU のコントロールを管理している場合、スタック誤削除で本番 OU 配下の全アカウントでコントロールが外れることに🙄 DeletionPolicy 結果 Retain あり コントロールは残る Retain なし コントロールが無効化される EnabledControl には必ず DeletionPolicy: Retain を設定しておく 14
15. まとめ: CFnで管理する前に知っておきたいこと • CFnで管理できるリソースは3つ (LandingZone / EnabledControl / EnabledBaseline) • Mandatoryコントロールは管理不可 API識別⼦からは判別できない • importはタグ適⽤で重い処理が⾛る (LZ: 30分フル更新 / Baseline: OU再登録) • LandingZone の import ではドリフト検出が動かない 以降CFn経由で管理すれば追跡は可能 • DeletionPolicy: Retain は必須 忘れるとスタック削除でコントロールが消える 15