【DOP-C02/SAP-C02】Control Tower徹底解説：概要・主要機能・試験で問われるポイント

この記事の位置づけ

AWS 認定 DevOps Engineer – Professional（DOP-C02）と Solutions Architect – Professional（SAP-C02）で頻出する 3 領域を「概要 → 主要機能 → 試験で問われるところ」の順に深掘りするシリーズの第 3 回（最終回）です。

回	テーマ
第 1 回	Code シリーズ（CodePipeline / CodeBuild / CodeDeploy / CodeArtifact ほか）
第 2 回	CloudFormation
第 3 回（本記事）	Control Tower

試験の基本情報（75 問・180 分・合格 750 点・300 USD）は第 1 回と共通です（DOP 公式ページ、SAP 公式ページ）。

SAP-C02 → SAP-C03 の切り替えに注意
SAP の公式ページには「SAP-C03 の登録受付は 2026 年 10 月 27 日に開始、SAP-C02 の最終受験日は 2026 年 11 月 16 日」と掲示されています（2026-10-20 時点）。本記事は SAP-C02 の試験ガイドに基づきます。

本文の仕様は公式ドキュメント（2026 年 10 月時点）で確認し、出典 URL を付けています。確認しきれなかった記述は末尾にまとめました。Control Tower は 2025 年 11 月のランディングゾーン 4.0 で構造が大きく変わったため、試験問題が前提とする「従来の構造」と「現在の構造」の両方 を押さえる必要があります。

0. 試験ガイドでの位置づけ

DOP-C02（試験ガイド）

タスク	内容	Control Tower の論点
2.2	マルチアカウント・マルチリージョン環境でアカウントを作成・オンボード・保護する自動化のデプロイ	Account Factory、AFT、CfCT、StackSets
6.1	大規模な ID とアクセス管理の手法の実装	Organizations、SCP、IAM Identity Center
6.2	セキュリティコントロールとデータ保護の自動化	予防・検出・プロアクティブコントロール
6.3	セキュリティのモニタリングと監査	Log Archive、Audit アカウント、Config、Security Hub

SAP-C02（試験ガイド）では分野 1「組織の複雑さに対応する設計」（26%）の タスク 1.4「マルチアカウント AWS 環境の設計」（知識項目に Organizations と Control Tower が明記。分野 1）が中心で、分野 4 のタスク 4.2 でもガバナンスツールの例として Control Tower が挙げられています（分野 4）。

両試験とも対象サービス一覧（Management and Governance）に Control Tower、Organizations、Service Catalog が含まれています。

1. 概要

Control Tower は 複数のアカウントからなる環境（ランディングゾーン）を、AWS のベストプラクティスに沿って自動でセットアップし、継続的にガバナンスを効かせる サービスです。自分で新しい仕組みを持つのではなく、AWS Organizations、AWS Service Catalog、IAM Identity Center、CloudFormation StackSets、AWS Config、CloudTrail などを オーケストレーション します（Control Tower とは）。

主要な概念は 4 つです。

概念	内容
ランディングゾーン	OU・アカウント・ユーザー・ガードレールを含む、組織全体のマルチアカウント環境そのもの
コントロール（旧称ガードレール）	平易な言葉で表現された高レベルのルール。挙動は 予防・検出・プロアクティブ の 3 種類、ガイダンスは 必須・強く推奨・選択的 の 3 段階
Account Factory	Service Catalog の製品として実装された「アカウントの自動販売機」。アカウントの作成と登録（enrollment）を自動化する
ダッシュボード	登録済みアカウント、有効なコントロール、非準拠リソースを一覧する

ランディングゾーンをセットアップすると何が起きるか

Control Tower の仕組み より、従来（ランディングゾーン 3.x まで）の既定構成です。

1. Organizations に Security OU（必須）と Sandbox OU（任意）を作る
2. Security OU に Log Archive アカウント と Audit アカウント（共有アカウント）を作る（既存アカウントを指定することも初回だけ可能。後から変更不可）
3. IAM Identity Center にディレクトリ・グループ・アクセス許可セットを作る（自前の IdP を使う選択も可）
4. 必須の予防コントロール・検出コントロール を有効化する
5. 予防コントロールは管理アカウントには適用されない

アカウント	役割	主なリソース
管理アカウント	Control Tower コンソールの操作、Account Factory（Service Catalog）、StackSets の管理者	StackSets（AWSControlTowerBP-BASELINE-* など）、Config アグリゲーター aws-controltower-ConfigAggregatorForOrganizations
Log Archive	全アカウントのログの集約先。読み取り専用に保つ	S3 バケット aws-controltower-logs-*、aws-controltower-s3-access-logs-*
Audit	セキュリティ・コンプライアンスチーム用。他アカウントへのプログラムによるアクセス（Lambda が引き受けるロール）と通知	Config アグリゲーター aws-controltower-GuardrailsComplianceAggregator、SNS トピック aws-controltower-AggregateSecurityNotifications / AllConfigNotifications / SecurityNotifications、ロール aws-controltower-AuditAdministratorRole / AuditReadOnlyRole

各メンバーアカウントには AWSControlTowerExecution ロール（管理アカウントからの操作用）、Config レコーダーと配信チャネル、Config の準拠変更を SNS へ転送する EventBridge ルールと Lambda 関数（aws-controltower-NotificationForwarder）などが StackSets で配られます（Account Factory のリソース）。CloudTrail はランディングゾーン 3.0 以降、組織の証跡（organization trail） として管理アカウントに作られ、アカウントごとの証跡（AWSControlTowerBP-BASELINE-CLOUDTRAIL）は配られません。

ランディングゾーン 4.0 での変更（2025 年 11 月 17 日）

2025 年のリリースノート と 4.0 移行ガイド より。

• サービス統合が任意に：AWS Config、CloudTrail、Security Roles、AWS Backup の統合をそれぞれ有効／無効にできる（Config を無効にするなら Security Roles、IAM Identity Center、Backup も無効にする必要がある）
• 専用リソース：Config 用と CloudTrail 用の S3 バケット、サービスごとの SNS トピックが分離される
• 組織構造の要件が撤廃：Security OU が必須でなくなり、自分の構造を定義できる。唯一の要件は ハブアカウント（サービス統合用の中央アカウント）が同じ OU にあること
• コントロール専用の体験：AWSControlTowerBaseline を有効化せずにコントロールだけを使う最小構成が可能（発表）
• Config の変更：検出コントロール専用の ConfigBaseline、Config ハブアカウントのサービスリンクアグリゲーター（SLCA）。従来の組織アグリゲーター（管理アカウント）とアカウントアグリゲーター（Audit アカウント）は 4.0 への更新時に削除される（Config 統合）
• マニフェストが任意：API でのランディングゾーン作成時に最小構成を指定できる

試験での扱い方
現行の試験問題は 4.0 より前に作られています。「Security OU に Log Archive と Audit がある」「必須コントロールが自動で適用される」「Account Factory でアカウントを作ると自動で登録される」という 従来モデルで解答 して問題ありません。4.0 の知識は「Control Tower を使うには必ずこの構造が必要」という思い込みを避けるために持っておく、という位置づけです。

既存の組織での利用

Control Tower は新規の組織だけでなく、既存の Organizations 組織にもセットアップ できます。既存の OU は「登録（register）」、既存のアカウントは「登録（enroll）」することでガバナンス対象に入ります（Control Tower とは の Extensibility）。ホームリージョンと管理対象リージョン（governed Regions）はセットアップ時に選び、後から追加できます。

2. 主要機能

2.1 コントロール

コントロールについて より。試験で最も問われる部分です。

挙動	何をするか	実装	ステータス
予防（Preventive）	違反につながる操作を 禁止 する	SCP、RCP（リソースコントロールポリシー）、宣言型ポリシー（いずれも Organizations の機能。コントロールの挙動）	enforced / not enabled
検出（Detective）	違反しているリソースを 検出 してダッシュボードに表示する	AWS Config ルール	clear / in violation / not enabled
プロアクティブ（Proactive）	リソースが プロビジョニングされる前 にスキャンし、非準拠なら作らせない	CloudFormation Hooks（CloudFormation 経由のリソースだけが対象）	PASS / FAIL / SKIP

ガイダンス	内容
必須（Mandatory）	Control Tower が配置したリソースを保護する。OU 単位では無効化できない。3.x までは最上位 OU に既定で適用されたが、ランディングゾーン 4.0 以降は既定では適用されない（コントロールの挙動）。ネスト OU の登録時は必須コントロールの適用がスキップされる（ネスト OU）
強く推奨（Strongly recommended）	マルチアカウント環境のベストプラクティス。OU 単位で有効化し、OU 配下の全アカウントに適用
選択的（Elective）	企業でよく制限される操作の追跡・禁止。OU 単位で有効化

挙動とガイダンスは独立しています（例：「必須の予防コントロール」「選択的な検出コントロール」）。

適用範囲のルール

• 予防コントロールは 全リージョン で有効。検出コントロールは Control Tower がサポートするリージョン でのみ有効
• OU にコントロールを有効化すると、予防コントロールは その OU 配下の登録済み・未登録アカウントの両方 に効く（SCP は OU 単位だから）。検出コントロールは 登録済みアカウントにだけ 効く
• ネスト OU では、上位 OU の予防コントロールは下位の未登録 OU にも適用される。OU のネストは ルートの下に最大 5 階層（ネスト OU）
• Account Factory で作ったアカウントは親 OU のコントロールを継承する。Control Tower の外で作ったアカウント（未登録アカウント）は、登録済み OU の配下にあれば予防コントロール（SCP）だけが効き、検出・プロアクティブコントロールは登録するまで適用されない（予防コントロール）
• アカウントを OU 間で移動したとき（アカウントの更新と移動）：自動登録（auto-enroll）が有効なら移動先のベースラインとコントロールが適用され、移動元のものは削除される。無効の場合、SCP 系は移動先に切り替わるが、Config ルール系（検出）は移動元のものが残り、手動で削除が必要。残ったものは「継承ドリフト」として扱われ、DisableControl API で外す（ガバナンスドリフトの種類）

コントロールの命名と探し方

• 従来のコントロールは AWS-GR_RESTRICT_ROOT_USER のような AWS-GR_ 形式、新しいコントロールは CT.S3.PR.1 や CT.MULTISERVICE.PV.1 のような CT. で始まる形式で、コントロールリファレンス に一覧がある
• コントロールカタログ（AWS Control Catalog）から、NIST 800-53 や PCI DSS などのフレームワーク、サービス、挙動で検索して有効化する。Config ルールや Security Hub のコントロールも大量に追加されている（2025 年 11 月時点で 750 以上のマネージドコントロール。発表）
• Security Hub のコントロール を Control Tower から有効化すると、Security Hub 側に「Service-Managed Standard: AWS Control Tower」という標準が作られる。有効／無効は Control Tower 側から 操作する（Security Hub 側で無効化するとコントロールドリフトになる。サービス管理型標準）
• 一部のコントロールは パラメータ を取る。代表例が OU 単位のリージョン拒否コントロール

リージョン拒否コントロール（リージョン拒否コントロールの設定）

コントロール	範囲	特徴
AWS-GR_REGION_DENY	ランディングゾーン全体（AWSControlTowerBaseline が有効な全 OU）	ランディングゾーン設定で有効化。OU 単位の設定不可。ホームリージョンは拒否できない。IAM や Organizations などのグローバルサービスは除外。選択的・予防
CT.MULTISERVICE.PV.1	指定した OU	パラメータ AllowedRegions（必須）、ExemptedPrincipalArns、ExemptedActions で例外を定義できる（OU のリージョン拒否）。ランディングゾーン側で拒否したリージョンを OU 側で許可することはできない

API：EnableControl / DisableControl / ResetEnabledControl（ドリフトしたコントロールを再適用）/ ListEnabledControls / GetControlOperation（API リファレンス）。CloudFormation の AWS::ControlTower::EnabledControl リソースでも有効化できます。

2.2 ベースライン

ベースラインの種類 より。ベースラインは「OU やアカウントに配る一連のリソースと設定」です。

ベースライン	内容	注意点
AWSControlTowerBaseline	OU 登録時に有効化される標準ベースライン。コンプライアンス監視・監査・セキュリティ監視（任意でアクセス管理）に必要なリソースとコントロールをメンバーアカウントに配る	Config 統合が前提。ランディングゾーンのリージョン拒否設定を引き継ぐ
ConfigBaseline	検出コントロールに必要な Config 関連リソースだけを配る（AWSControlTowerBaseline のサブセット）	同じ OU で AWSControlTowerBaseline と併用不可。リージョン拒否は引き継がない
IdentityCenterBaseline	IAM Identity Center のアクセス管理	AWSControlTowerBaseline 有効化時にパラメータ IdentityCenterEnabledBaselineArn で参照する

API は EnableBaseline（OU 単位、baselineVersion を指定）/ UpdateEnabledBaseline / ResetEnabledBaseline / DisableBaseline です（ベースライン API の例）。

2.3 Account Factory

Account Factory は Service Catalog の製品 として実装されたアカウント作成の仕組みです。

• 作成できるのは IAM Identity Center の AWSAccountFactory グループ（または管理グループ）のユーザー。グループと許可セットの一覧は IAM Identity Center グループ にある（作成されるのは AWSAccountFactory、AWSServiceCatalogAdmins、AWSControlTowerAdmins、AWSSecurityAuditPowerUsers、AWSSecurityAuditors、AWSLogArchiveAdmins、AWSLogArchiveViewers、AWSAuditAccountAdmins の 8 グループ）
• 作成したアカウントは 自動で OU に配置され、登録（enroll）され、OU のコントロールを継承 する。完了まで数分から数十分かかる（ユーザーガイドは「数分」、AWS ブログは「最大 35 分」としている）
• 作成したアカウントは 更新・管理対象外化（unmanage）・閉鎖（close） ができ、ユーザーパラメータを変えて再利用もできる
• VPC の設定：新規アカウントに作る VPC の CIDR、サブネット、リージョンを Account Factory の設定で決める。VPC を作らない設定も可能（VPC なしでアカウントを作成）。既存アカウントの登録では VPC を作らず、既存の VPC やデフォルト VPC も削除しない

既存アカウントの登録（enroll）（既存アカウントの登録）

• 条件：同じ Organizations 組織 の、未登録 OU にあるアカウント。別組織のアカウントは、いったん離脱して招待し直す（支払い方法の用意が必要）
• 前提：そのアカウントに AWSControlTowerExecution ロール（管理アカウントを信頼し、AdministratorAccess を持つ）を作っておく。Control Tower は CloudFormation と Organizations の信頼アクセスを使って StackSets を配る
• 登録時に起きること：ベースラインの StackSets（AWSControlTowerBP-BASELINE-CLOUDWATCH / CONFIG / ROLES / SERVICE-ROLES、VPC 用など）を配る、指定 OU に配置して SCP（必須コントロール）を適用、Config を有効化して全リソースを記録、検出コントロールの Config ルールを追加
• 既存の CloudTrail 証跡があると、組織の証跡と 二重課金 になるので事前に削除を検討する
• 既存アカウントを後から Audit / Log Archive にはできない（初回セットアップ時のみ）
• OU ごとまとめて取り込むには OU を 登録（Register OU） する。このとき Control Tower が StackSet で未登録アカウントに AWSControlTowerExecution ロールを追加してから登録する（単一アカウントの登録では事前に自分で作る）。登録できるのは 1 OU あたり 1,000 アカウントまで（既存 OU の登録）

2.4 アカウントのカスタマイズ：AFC・AFT・CfCT

「アカウント作成時に、社内標準のリソース（VPC 設計、IAM ロール、ログ設定など）を自動で入れたい」という要件に対して 3 つの選択肢があります。

方式	仕組み	向いている状況
Account Factory Customization（AFC）（AFC）	ハブアカウント に置いた Service Catalog 製品（ブループリント） を、Account Factory のコンソールからアカウント作成・登録時に適用する。ハブアカウントに AWSControlTowerBlueprintAccess ロールが必要	コンソール中心で運用したい。CloudFormation テンプレート 1 つで足りる
Account Factory for Terraform（AFT）（AFT、GitHub）	専用の AFT 管理アカウント に Terraform モジュールでパイプラインを構築。アカウントリクエスト用の Terraform ファイル を Git に push すると、アカウント作成 → グローバルカスタマイズ → アカウント別カスタマイズがパイプライン（Step Functions ほか）で流れる	Terraform で GitOps 運用したい。Terraform OSS / Cloud / Enterprise のいずれも可
Customizations for Control Tower（CfCT）（CfCT、GitHub）	マニフェストファイルに CloudFormation テンプレートと SCP を定義し、パイプラインが StackSets と Organizations に配る。ライフサイクルイベント と連動し、新規アカウント作成時に自動で適用される	CloudFormation 中心。OU 単位で SCP とスタックを一括管理したい

AFC の制約：ブループリントは 1 製品のみ、ハブアカウントかつ ホームリージョンと同じリージョン に作る、展開先は「ホームリージョンのみ」か「全管理対象リージョン」の 2 択（リージョンの個別選択は不可）、更新時にハブアカウント ID と製品は変更できない。

AFT の特徴：アカウント作成だけでなく 既存アカウントのカスタマイズ にも使える、CodeCommit が既定だが CodeConnections 経由で GitHub などの VCS も使える、機能オプション（CloudTrail データイベント、Enterprise Support への登録、デフォルト VPC の削除）がある。AFT のパイプラインはアプリケーション用のリソース（EC2 など）を配るためのものではない とドキュメントに明記されています。

2.5 ドリフトの検出と修復

ドリフトの検出と解決 より。Control Tower が管理するリソース（SCP、OU、共有アカウント、ロール）を コンソールの外で変更するとドリフト になります。

• 検出は自動。AWSControlTowerAdmin ロールが Organizations を読み取り専用で呼び出す。マネージド SCP・RCP・宣言型ポリシーは 毎日スキャン される
• 通知は Audit アカウントの SNS トピック aws-controltower-AggregateSecurityNotifications。同じドリフトは初回だけ通知される。4.0 以降は SNS ではなく管理アカウントの EventBridge に送られ、自動登録（auto-enroll）を有効にしている場合も SNS 通知は提供されない（ガバナンスドリフトの種類）
• すぐに直すべきドリフト：Security OU の削除、必須ロールの削除、共有アカウントの Security OU からの移動
• 許容されるが修復が必要なドリフト：登録済み OU や Security OU の名前変更、非基盤 OU のメンバーアカウントの名前変更、共有アカウントやメンバーアカウントのメールアドレス変更、非基盤 OU の削除、アカウントの OU 間移動
• 修復方法（ドリフトの解決）：ランディングゾーン設定ページの Reset（保存済みの構成をドリフトしたリソースへ再適用。3.1 以降で利用可。バージョンを上げるのは Update）、OU の Re-register（1,000 アカウント未満の OU で Account Factory アカウントや SCP のドリフトを修復）、個別アカウントの Update account、ResetEnabledControl / ResetEnabledBaseline API。OU 間移動による継承ドリフトは DisableControl で残ったコントロールを外すか、自動登録（auto-enrollment） を有効にしておけば移動先 OU の構成が自動で適用される

2.6 監査・ログ・通知・自動化

• ログ：全アカウントの CloudTrail（組織の証跡）と Config の履歴が Log Archive アカウントの S3 に集約される。Config アグリゲーターは Audit アカウント（検出コントロールの準拠状況）と管理アカウント（組織全体）にある（3.x まで。4.0 では Config ハブアカウントのサービスリンクアグリゲーターに置き換わる）
• 通知：Audit アカウントの SNS トピックに検出コントロールの違反やドリフトが流れる。メンバーアカウントの管理者はこのトピックを購読できる
• ライフサイクルイベント（ライフサイクルイベント）：CreateManagedAccount、UpdateManagedAccount、EnableGuardrail、DisableGuardrail、SetupLandingZone、UpdateLandingZone、RegisterOrganizationalUnit、DeregisterOrganizationalUnit などが、管理アカウントのホームリージョンで CloudTrail 経由の EventBridge イベント（source: aws.controltower、detail-type: AWS Service Event via CloudTrail）として発行される。「アカウント作成が完了したら Lambda で追加設定を入れる」自動化の起点はこれ（作成を再試行した場合は UpdateManagedAccount として記録されるので、両方を拾う）
• API：CreateLandingZone（マニフェストとバージョンを指定）、UpdateLandingZone、ResetLandingZone、GetLandingZoneOperation（API でのランディングゾーン作成）。CloudFormation の AWS::ControlTower::LandingZone でも作成できる

3. 試験で問われるところ

問題文のシナリオ	正解の方向
新しいアカウントを作るたびに、ログ・監査・ガードレールが自動で適用される環境を最小の運用負荷で	Control Tower のランディングゾーン + Account Factory
既存の Organizations 組織にガバナンスを後から入れたい	既存組織に Control Tower をセットアップし、OU を登録・アカウントを登録
既存アカウントを Control Tower の管理下に入れたい	AWSControlTowerExecution ロールを作成 → 登録済み OU に enroll（同じ組織であること）
特定リージョン以外の利用を全社で禁止したい	ランディングゾーンのリージョン拒否コントロール（AWS-GR_REGION_DENY）。OU ごとに例外が要るなら CT.MULTISERVICE.PV.1
特定の操作を禁止したい（例：CloudTrail の無効化、ルートユーザーの使用）	予防コントロール（SCP）
違反リソースを検出して可視化したい（例：パブリックな S3）	検出コントロール（Config ルール）
CloudFormation で非準拠リソースを作らせたくない（デプロイ前に止める）	プロアクティブコントロール（CloudFormation Hooks）
アカウント作成時に社内標準の VPC や IAM ロールを自動投入したい	AFC（Service Catalog ブループリント）、AFT（Terraform）、CfCT（CloudFormation + SCP）
Terraform で GitOps 的にアカウントを払い出したい	AFT
CloudFormation テンプレートと SCP を OU 単位で一括配布し、新規アカウントにも自動適用したい	CfCT
新規アカウント作成の完了をトリガーに追加処理を走らせたい	ライフサイクルイベント CreateManagedAccount を EventBridge で受けて Lambda / Step Functions
誰かが SCP を直接編集した／アカウントを OU 間で移動した	ドリフト検出 → Reset / Re-register OU / ResetEnabledControl（OU 間移動は自動登録を有効にしておけば自動修復）
アカウントを別 OU に移したら旧 OU の検出コントロールが残っている	継承ドリフト。DisableControl で手動削除
管理アカウントにも予防コントロールが効くようにしたい	効かない（SCP は管理アカウントに適用されない）。管理アカウントの操作は最小化し、CloudTrail で監査
Security Hub の標準を Control Tower の全アカウントに適用したい	Control Tower から Security Hub コントロールを有効化（Service-Managed Standard）
全アカウントのログを 1 か所に集めて改ざんを防ぎたい	Log Archive アカウント（S3）+ 予防コントロール（Log Archive のバケットポリシー変更禁止など）
監査チームに全アカウントの読み取りアクセスを与えたい	Audit アカウント（AuditReadOnlyRole、Config アグリゲーター）
開発者が Account Factory でアカウントを作れるようにしたい	IAM Identity Center の AWSAccountFactory グループに追加
OU が数百アカウントに膨らんだ	ネスト OU で分割（最大 5 階層）。OU 単位の操作（Re-register など）の影響範囲を小さくする。登録できるのは 1 OU あたり 1,000 アカウントまで
Control Tower を使わずに同等の統制を自前で組みたい	Organizations + SCP + StackSets + Config + CloudTrail を自前で構成（運用負荷が高い。Control Tower が消去法で残る）
既存の AWS Landing Zone ソリューションから移行したい	Control Tower（ALZ は長期サポートのみで新機能はなく、Control Tower への移行が公式に推奨されている。ALZ からの移行）

引っかけ

• 予防コントロールは管理アカウントに効かない。「管理アカウントを SCP で縛る」選択肢は誤り
• 検出コントロールは登録済みアカウントだけ、予防コントロールは OU 配下の未登録アカウントにも効く。この非対称を問う問題がある
• 「ガードレール」は コントロール の旧称。問題文はどちらでも出る
• プロアクティブコントロールは CloudFormation 経由のリソースにしか効かない。コンソールや CLI で作ったリソースは検出コントロールの領域
• ドリフトは 検出は自動、修復は手動（コンソールまたは API）。例外は自動登録を有効にした場合の OU 間移動（継承ドリフト）だけで、それ以外の「自動修復」をうたう選択肢は誤り
• Control Tower は Config を有効化 する（4.0 より前は既定で有効、4.0 以降は任意）。CloudTrail の組織の証跡は 3.0 以降オプトアウトできる。既存の証跡や Config レコーダーがあると二重課金や競合になる（必須コントロール、2022 年のリリースノート）
• 既存アカウントの登録には AWSControlTowerExecution ロールが必須（単一アカウントの登録では事前に作成、OU 登録では Control Tower が追加）。「Organizations に招待すれば自動で登録される」は誤り
• Account Factory で作ったアカウントの 閉鎖・管理対象外化 は Control Tower から行える。Organizations で直接いじるとドリフト
• AFT は アカウントのプロビジョニングとカスタマイズ専用。アプリケーションのデプロイに使うのは誤り
• AFC のブループリントは 1 製品のみ、ハブアカウントの ホームリージョン に作る
• 共有アカウント（Log Archive / Audit）に既存アカウントを使えるのは 初回セットアップ時だけ

4. 関連サービスとの使い分け

比較対象	違い
Organizations + SCP だけ	禁止（予防）はできるが、ログ集約・Config・アカウント作成の自動化は自前。Control Tower はこれらを束ねて標準構成を自動化する
AWS Config のコンフォーマンスパック	検出ルールの集合。Control Tower の検出コントロールも Config ルールだが、OU 単位の有効化・ダッシュボード・ドリフト管理が付く
Security Hub	検出結果の集約と標準の適用。Control Tower から有効化すると専用の標準が作られ、Control Tower 側で一元管理できる
Service Catalog	承認済みテンプレートの配布基盤。Account Factory と AFC はこの上に実装されている
CloudFormation StackSets	Control Tower がベースラインを配る手段。CfCT も StackSets を使う。「全アカウントへ任意のリソースを配る」要件は StackSets（サービスマネージド権限 + 自動デプロイ）でも満たせる
IAM Identity Center	Control Tower が既定で設定するアクセス管理。自前の IdP（外部 IdP、既存の Identity Center）を使う選択も可能
AWS Landing Zone ソリューション（旧）	以前の自前構築型ソリューション。新機能の追加はなく長期サポートのみで、Control Tower への移行が推奨されている

5. 確認しきれなかった記述

• 必須コントロールの既定適用について、コントロールの挙動は「4.0 以降は既定で適用されない」、既存 OU の登録は「OU 登録時に既定で有効化される」と記述が揺れています。4.0 環境では実際の挙動を確認してください
• CT. で始まるコントロール ID の命名規則（サービス・挙動・番号）を明文化した公式ページは見つかりませんでした（ID の実例は確認済み）
• AFT の実装に CodePipeline が使われている点は、公式ドキュメントには「パイプライン」「Step Functions」としか書かれていないため本文では製品名を省きました

おわりに

Control Tower は「サービスの中身」より 「どの層で統制するか（Organizations の SCP か、Config の検出か、CloudFormation Hooks の事前検証か）」と「アカウント払い出しをどう自動化するか（Account Factory / AFC / AFT / CfCT）」 を問われます。予防・検出・プロアクティブの実装の違い、管理アカウントの例外、登録済み／未登録アカウントの非対称、ドリフトの修復方法を押さえれば、DOP 分野 6 と SAP 分野 1 のマルチアカウント問題は安定します。

シリーズ全 3 回（Code シリーズ・CloudFormation・Control Tower）は、どれも「要件 → 機能」の逆引き表を軸にしています。問題文の制約（ダウンタイム、ロールバック、アカウント分離、運用負荷、コスト）を先に読んでから表に当てる練習をしてみてください。

---

📩 AWS認定の学習Tips・「試験に出ないが現場で必須」の知識をX（naoto@クラウドエンジニア）で毎日発信中 👉 https://x.com/naoto_tech_AI