AWS Control Tower — ランディングゾーン自動構築
AWS Control Tower によるランディングゾーン自動構築、ガードレール、Account Factory、Landing Zone 更新、Control Tower vs Custom を SAA 基礎から SAP 高度設計まで解説。
AWS Control Tower は マルチアカウント環境のランディングゾーンを自動構築 するサービスです。 AWS 推奨のベストプラクティス設定を「ボタン 1 つ」で展開できます。 本記事では Control Tower の仕組みと設計を SAA / SAP 両面から整理します。
SAA レベル：基礎概念
Control Tower とは何か
Control Tower は AWS Organizations + SCP + Config + IAM Identity Center を統合 し、 ベストプラクティスに基づくランディングゾーン を自動構築します。
- ランディングゾーン: マルチアカウント環境の標準基盤
- ガードレール (Guardrails): 自動適用される SCP + Config Rules
- Account Factory: 標準設定済みアカウントの自動作成
- 統合ダッシュボード: 全アカウントのガバナンス状況を可視化
SAA レベル：基礎概念
Control Tower の核心は 「AWS 推奨のマルチアカウント基盤を自動構築」 です。 Organizations, SCP, Config, IAM Identity Center を手作業で統合する代わりに、 Control Tower が ベストプラクティス構成で一括セットアップします。 SAA では「ランディングゾーンの標準実装」として押さえます。
Control Tower が構築する基本構成
Control Tower は 以下の基本アカウントと OU 構成 を自動作成します。
Root
├── Security OU
│ ├── Audit-Account (監査アカウント)
│ └── LogArchive-Account (ログ集約アカウント)
└── Core/Workloads OU
└── Sandbox, Production 等 (ユーザーが拡張)| アカウント | 役割 | 自動作成 |
|---|---|---|
| Management | 組織のルート（既存） | 既是 |
| LogArchive | CloudTrail / Config ログ集約 | 自動 |
| Audit | GuardDuty / Security Hub 管理 | 自動 |
SAA 試験のポイント
Control Tower は LogArchive と Audit の 2 アカウントを自動作成 します。 この 2 つが AWS 推奨の「機能別分離」の最小構成。 SAA では「Control Tower が作るアカウント」として頻出します。
ガードレール (Guardrails)
Control Tower のガードレールは 3 種類 あります。
| 種類 | 説明 | 例 |
|---|---|---|
| 強制ガードレール (Mandatory) | 必須、無効化不可 | ルートユーザー MFA 強制 |
| 強く推奨ガードレール (Strongly Recommended) | デフォルト有効、無効化可 | パブリック S3 バケット検知 |
| 選択的ガードレール (Elective) | デフォルト無効、有効化可 | リージョン制限 |
SAA 頻出
強制ガードレールは無効化不可 です。これが「ガードレールの核心」。 SCP + Config Rules で実装され、組織全体のセキュリティベースラインを保証します。 SAA では「強制 vs 推奨 vs 選択」の 3 分類が頻出します。
Account Factory
Account Factory は 標準設定済みアカウントを自動作成 する機能です。
- 標準設定: SCP, CloudTrail, タグ付け, ネットワーク等が自動適用
- セルフサービス: 承認フロー経由でエンドユーザーが要求
- AWS Service Catalog 経由: 承認ベースのプロビジョニング
- 新規アカウント: Control Tower 管理下で作成
Account Factory の利点
Account Factory 経由で作成したアカウントは全ガードレールが自動適用 されます。 手動作成と違って「設定忘れ」が構造的に防止されるため、SAP では Account Factory が推奨です。
SAP レベル：高度な設計シナリオ
ランディングゾーンのカスタマイズ
Control Tower は標準構成を提供しますが、SAP では 組織固有のカスタマイズ も必要です。
SAP レベル：高度な設計シナリオ
SAP の Control Tower 活用定石は 「標準ランディングゾーン + カスタマイズレイヤ」 です。 Control Tower がベースラインを提供し、CloudFormation StackSets や Customizations for Control Tower (CfCT) で組織固有要件を上書き追加します。 これで「AWS 推奨 + 自社要件」の両立を図ります。
[Control Tower 標準ランディングゾーン]
- LogArchive, Audit アカウント
- 強制ガードレール
│ (カスタマイズレイヤ)
▼
[CloudFormation StackSets / CfCT]
- 追加 SCP (リージョン制限、タグ強制)
- 共有サービスアカウント
- ネットワーク基盤 (TGW, VPN)
- IAM Identity Center Permission SetCustomizations for Control Tower (CfCT)
CfCT は Control Tower 環境に カスタム設定を自動適用 するツールです。
- CloudFormation StackSets: 複数アカウントにテンプレートを展開
- Lambda 関数: 追加自動化処理
- Git ベース: 設定を Git で管理（IaC）
- 新規アカウント自動適用: Account Factory 経由の新規アカウントにも自動展開
CfCT の設計論点
CfCT でカスタマイズを Git 管理 すると、ランディングゾーンの設定変更を 「コード → PR → 適用」のフローで管理できます。SAP では CfCT による IaC 運用が定石です。
Control Tower と IAM Identity Center の統合
Control Tower は IAM Identity Center を統合利用 します。
- 自動有効化: Control Tower セットアップ時に Identity Center が有効化
- 事前定義 Permission Set:
AWSAdministratorAccess,AWSReadOnlyAccess等が提供 - アカウントベンダー連携: 新規アカウントが Identity Center に自動登録
[Control Tower] ──(セットアップ)── [IAM Identity Center]
│
├── AWSAdministratorAccess
├── AWSReadOnlyAccess
└── カスタム Permission Set統合の利点
Control Tower + Identity Center の統合で「ガバナンス + SSO の一貫性」を実現します。 新規アカウントが作成されると Identity Center に自動登録され、即座に SSO 対象に。 SAP ではこの統合アーキテクチャが標準です。
ガードレールの拡張設計
標準ガードレールに加え、SAP では 組織固有のガードレール を追加します。
| カスタムガードレール | 実装 | 設計論点 |
|---|---|---|
| リージョン制限 | SCP (Deny) | データ主権、コスト管理 |
| タグ強制 | SCP + Config Rules | コスト配分の前提 |
| サービス制限 | SCP (Deny) | 未承認サービスの排除 |
| 公開リソース禁止 | Config Rules + Lambda | セキュリティリスク低減 |
ガードレール追加の注意
追加ガードレールは必ず Sandbox OU でテスト してから本番適用します。 いきなり本番 OU に SCP を適用すると、既存ワークロードが予期せずブロックされるリスク。 SAP では段階導入が鉄則です。
Landing Zone の更新管理
Control Tower は Landing Zone のバージョン管理 を提供します。
- バージョン更新: AWS が新しいベストプラクティスを提供
- 更新の影響範囲: 事前にドキュメントで確認
- 段階更新: まず Sandbox OU で検証、その後本番へ
- ロールバック: 問題があれば前バージョンへ戻す
更新の設計論点
Landing Zone の更新は 「既存ガードレールの強化」「新ガードレールの追加」 を含むため、 既存ワークロードへの影響があります。SAP では「更新前に影響範囲を確認、段階適用」が定石です。
Control Tower vs カスタム構築
SAP では Control Tower とカスタム構築の選択 が論点です。
| 項目 | Control Tower | カスタム構築 |
|---|---|---|
| セットアップ工数 | 低（ボタン 1 つ） | 高（個別統合） |
| カスタマイズ性 | 中（CfCT で拡張） | 高（自由） |
| AWS 推奨準拠 | 自動 | 自力で実装 |
| 更新追従 | AWS が提供 | 自力で追従 |
| 複雑さ | 低 | 高 |
SAP レベル：高度な設計シナリオ
SAP の選択判断は 「AWS 推奨構成で十分なら Control Tower、 特殊要件が多数ならカスタム構築」 です。Control Tower は AWS 推奨のベストプラクティスに 自動追従できるため、SAP では Control Tower をベースにし、CfCT で拡張するのが定石です。
マルチリージョン展開
Control Tower は ホームリージョン を持ち、マルチリージョン展開をサポートします。
- ホームリージョン: Control Tower の管理リージョン
- リージョン制限: ガードレールで許可リージョンを制限
- ガードレール適用: 全リージョンのアカウントに自動適用
リージョン設計の論点
Control Tower の ホームリージョンは変更不可 です。 セットアップ時に慎重に選ぶ必要があります。また「ガードレールで許可リージョンを制限」すると、 未許可リージョンでのリソース作成が拒否されるため、アプリ展開リージョンと整合が必要。 SAP ではリージョン戦略の事前設計が重要です。
既存組織への Control Tower 適用
既存の Organizations 環境に Control Tower を適用する場合の注意：
- 既存 SCP との競合: Control Tower のガードレールと既存 SCP が矛盾しないか確認
- 既存アカウントの移行: 段階的に Control Tower 管理下へ
- Identity Center 移行: 既存 IAM ユーザーから Identity Center へ移行
- CloudTrail 統合: 既存トレイルと Control Tower のログ集約の統合
既存環境移行の論点
既存の Organizations に Control Tower を適用 すると、 既存 SCP と Control Tower のガードレールが AND で適用 されます。 既存 SCP が厳しすぎると Control Tower の機能が制限される可能性があるため、 事前の相互影響確認が SAP の重要論点です。
制約と考慮事項
| 項目 | 制約 / 注意 |
|---|---|
| ホームリージョン | 変更不可 |
| 自動作成アカウント | LogArchive, Audit の 2 つ |
| ガードレール | 強制 / 推奨 / 選択の 3 種 |
| カスタマイズ | CfCT または StackSets で拡張 |
| 既存組織統合 | 既存 SCP との競合確認必要 |
まとめ
- SAA: Control Tower は AWS 推奨のランディングゾーンを自動構築、 LogArchive / Audit アカウント自動作成、ガードレールは強制/推奨/選択の 3 種、 Account Factory で標準アカウント作成、を理解する。
- SAP: CfCT によるカスタマイズ、Identity Center 統合、ガードレール拡張、 Landing Zone 更新管理、Control Tower vs カスタムの選択、既存組織への適用が求められる。
次は アカウントベンディング で、アカウントの自動プロビジョニングを深掘りします。