AWSマルチアカウント基盤Vol1｜Control Tower・AFT・CfCT

1. マルチアカウント基盤の本番課題と全体設計

AWSのマルチアカウント戦略は、セキュリティ境界の明確化・コスト配賦・コンプライアンス対応・チーム自律性の確保を目的として採用されます。しかし、アカウント数が増えるにつれて手動管理は限界を迎えます。新規アカウントの払い出しに数日かかる・SCPの適用漏れによるコンプライアンス違反・OU構成の不統一によるガードレール機能不全といった課題は、多くのプラットフォームチームで見受けられます。

本記事は、AWS Control Tower Landing Zoneを中核として「マルチアカウント基盤を実装層で設計・構築・自動化する」ための実践ガイドです。Organizations/Control Towerの概要は既存記事（M&Gシリーズ）に委ね、本記事はLanding Zone構築・Account Factory自動化・OU/SCP/RCP設計パターンの実装に集中します。

本節（§1）では、本記事のゴール・想定読者像・既存記事との棲み分け・読み方ガイドを整理します。すでにマルチアカウント基盤の課題感をお持ちの方は§2から直接お読みいただけます。

なお、本記事は独立したシリーズVol1として設計しており、§2から§8まで各章が実装の一工程を担う構成です。章間のつながりは「1-4. 記事の読み方」で整理しています。

1-1. 本記事のゴール

本記事では、以下の3つの実装能力を身に付けることを目標とします。

① Control Tower Landing Zoneを中心とした全体設計の把握

AWS Control Towerが提供するLanding Zoneは、マルチアカウント基盤のベースラインを自動構築するフレームワークです。OU設計・ログ集約・監査アカウント・CloudTrail/Config集約・IAM Identity Center連携といった基盤要素が、Landing Zoneのセットアップで一括プロビジョニングされます。本記事では、このLanding Zoneをどのように設計・カスタマイズするかを扱います。

② Account Factory/AFT/CfCTによるアカウント払い出し自動化

新規AWSアカウントの払い出しをGitOpsで自動化することで、リードタイムを数日から数時間・数分に短縮できます。Control Tower標準のAccount Factory・Terraform活用のAFT（Account Factory for Terraform）・CloudFormation活用のCfCT（Customizations for AWS Control Tower）の3つの自動化手段を、使い分けの観点から扱います。

③ OU/SCP/RCPによる統制ガードレール設計

Organizations全体のセキュリティ統制は、OU設計とポリシー（SCP・RCP）の組み合わせで実現します。2024年11月にGAしたRCP（Resource Control Policy）を含め、SCPとRCPの使い分け・設計パターン・アンチパターンを実装レベルで扱います。

1-2. 読者像とユースケース

本記事は、AWSのOrganizations/Control Tower概要をすでに把握しており、「実装レベルで基盤を設計・構築・自動化したい」プラットフォームエンジニアやSREを主な読者として想定しています。以下のいずれかに当てはまる方に特に役立ちます。

• AWSマルチアカウント環境を日常的に管理しているインフラ/クラウドエンジニア
• アカウント払い出しを手動で行っており、AFT/CfCTの採用を検討しているチームリーダー
• SCP設計の経験はあるが、RCP（Resource Control Policy）との使い分けが整理できていない設計担当者
• Control Towerを導入済みだが、カスタマイズや継続運用の設計まで踏み込めていないチーム

具体的なユースケース

ユースケース1: AFT/CfCTの使い分けが分からず手動払い出しのまま

Control Towerは導入済みだが、アカウントの払い出しはAWSコンソールから手動で実施している状態です。AFTとCfCTのどちらを採用すべきか判断できず、自動化が進まないケースは多く見受けられます。本記事では、IaC方針（Terraform vs CloudFormation）・カスタマイズの範囲・チームのスキルセットを軸に、AFTとCfCTの選択基準を整理します（§4・§5）。

ユースケース2: SCPは書いているがRCPとの使い分けが整理できていない

リージョン制限やルートアカウント使用禁止などのSCPは設計・適用済みでも、2024年11月にGAしたRCP（Resource Control Policy）の使い方が分からないケースは多くあります。「S3バケットへの組織外アクセスをSCPで制御できない」といった状況がRCPの適用場面です。本記事では、SCPとRCPの概念的な違いから実践的な設計パターンまでを扱います（§2）。

ユースケース3: Landing Zone version 4.0更新後にmandatoryコントロールの挙動が変わって困っている

Landing Zone version 4.0（2024年）への更新後、mandatoryコントロールのデフォルト適用方式の変更により、既存のOU/アカウント構成に影響が出るケースも見受けられます。「更新後にコントロールの有効化状態が変わった」「アカウント登録のステップが変わった」といった問題への対応として、Landing Zoneのバージョン管理と更新手順を扱います（§3・§6）。

1-3. 既存記事との棲み分け

本記事はLanding Zoneの実装・アカウント自動化・OU/SCP/RCP設計パターンに特化します。既存記事との役割分担を以下に整理します。

本記事では、Organizations/Control Towerの概念説明や一般的なAWS IAM設計については既存記事への誘導を優先し、Landing Zone実装・アカウント自動化・OU/SCP/RCPの設計実装に集中します。

IAM Identity Centerの詳細（Permission Set・ABAC・SSOユーザー管理）は独立した記事で扱います。本記事§6でIAM Identity Centerとの連携について概要レベルで触れますが、Permission SetやABACの具体的な設計は専用記事を参照してください。また、マルチアカウント環境でのコスト配賦・Organizationsのコスト管理機能については「マルチアカウント運用入門」の範疇です。

本記事と既存記事群を組み合わせることで、AWSマルチアカウント基盤の概要から実装・運用まで一貫した知識体系を得られます。

Organizations/Control Tower概要を読む

1-4. 記事の読み方

本記事は§2から§8まで通して読むことで、マルチアカウント基盤の設計から実装・運用まで体系的に把握できます。各章の概要は以下の通りです。

目的別読み方ガイド

基盤設計者向け（OU/SCP/RCP設計から着手する場合）: §2→§3→§6の順に読むと、統制設計から基盤構築・継続運用まで効率よく通せます。アカウント自動化（§4・§5）は組織のIaC方針が固まってから読み進めることをお勧めします。

アカウント自動化担当向け（払い出し自動化を急ぐ場合）: §4→§5→§2の順に読むと、AFT/CfCTによるアカウント払い出し自動化から着手し、その後にOU/SCP/RCPの統制設計を学べます。基盤構築ステップ（§3）はAFTをデプロイする前提知識として事前確認を推奨します。

SCP/RCP設計者向け（ガードレール強化を担当する場合）: §2を中心に、継続運用での変更管理（§6）と統合設計（§7）を合わせて読むことを推奨します。RCP（2024年11月GA）を使った組織外アクセス制限の具体例は§2-3に記載しています。

既存環境への適用を検討している場合: §8のつまずきポイント・アンチパターンを先に確認することをお勧めします。既存のOrganizations環境にControl Tower Landing Zoneを後から適用するケースや、AFTを既存マルチアカウント環境に導入するケースのハマりどころを整理しています。その上で§3→§4→§6を読み進めると、適用時の注意点を踏まえた実装ができます。

2. OU設計とSCP/RCP設計パターン

マルチアカウント基盤の統制は、OU（組織単位）の設計とポリシー（SCP/RCP）の設計から始まります。OU設計はガードレールの適用境界を決め、SCPはプリンシパルの最大権限を制限し、RCPはリソースへのアクセスの上限を組織レベルで設定します。本章では推奨OU設計パターン・SCPガードレール設計・RCPとSCPの使い分けを実装観点から扱います。

2-1. 推奨OU設計

AWSは、Control Tower Landing Zoneを前提としたOU推奨構成として、FoundationalとAdditionalの2カテゴリを案内しています。

Foundational OU（Landing Zoneが自動作成）

Landing Zoneをセットアップすると、以下のFoundational OUが自動的に作成されます。

Security OUとInfrastructure OUは、Landing Zoneが強固なコントロールを自動適用するため、任意のワークロードアカウントを配置すべきではありません。特にSecurity OU配下のアカウントには、CloudTrailログや設定変更ログが集約されるため、アクセス権限の管理を厳格に行う必要があります。

Additional OU（推奨構成）

Foundational OU以外に、以下のAdditional OUの追加がAWSのベストプラクティスとして推奨されています。

Workloads OUは、Production（本番）とNon-Production（非本番）を子OUで分割することが推奨されます。この分割により、本番環境だけに適用する厳格なSCPと、開発・ステージング環境用の緩やかなSCPを別々に管理できます。

OU階層と命名規則

OU階層の深さはOrganizations全体で最大5階層まで制限されています。実運用では2〜3階層（Root→Foundational/Additional→子OU）に抑えることが管理上の推奨です。

OU命名規則の例は以下の通りです。

OU名にはスペースを使わないことを推奨します。スペースを含むOU名はCLI・Terraformでのエスケープが必要となり、自動化の妨げになる場合があります。

OU設計のアンチパターン

• アカウントをRootに直接配置する（OUを経由しないとSCPが適用できない）
• WorkloadsとSandboxを同じOUに混在させる（本番統制とPoC環境で異なるガードレールが必要）
• OU階層を4〜5階層まで深くする（管理コストが増加し、SCPの適用ルールが複雑化する）

2-2. SCPガードレール設計

SCPの仕組み

SCP（Service Control Policy）は、Organizations内のOU・アカウントに適用できる権限ガードレールです。IAMポリシーよりも上位レイヤーで機能し、メンバーアカウント内のIAMプリンシパル（ユーザー・ロール）が持てる最大権限を制限します。

SCPの重要な特性は以下の通りです。

• SCPは「許可の上限を設定する」ポリシーであり、それ自体はアクセスを許可しません
• IAMポリシーで許可されていても、SCPでDenyされていればアクセスは拒否されます
• Organizations管理アカウント自身にはSCPが適用されません（別途Config等で統制が必要）
• Control TowerのLanding Zoneが適用するコントロールの多くがSCPを利用しています

Deny List方式とAllow List方式の使い分け

エンタープライズの実装ではDeny List方式を基本とし、環境OU（Prod/NonProd）ごとに制限を調整するアプローチが一般的です。Allow List方式はサービス追加のたびにSCP更新の必要があり、管理コスト増加をまねく点を押さえておきましょう。

SCPパターン例①：リージョン制限

東京リージョン（ap-northeast-1）以外へのアクションをDenyするSCPです。グローバルサービス（IAM・STS等）はNotActionで除外します。

{
  "Version": "2012-10-17",
  "Statement": [{
 "Sid": "DenyNonTokyoRegion",
 "Effect": "Deny",
 "NotAction": [
"cloudfront:*", "iam:*",
"organizations:*", "sts:*", "waf:*"
 ],
 "Resource": "*",
 "Condition": {
"StringNotEquals": {
  "aws:RequestedRegion": "ap-northeast-1"
}
 }
  }]
}

NotActionにIAM・Organizations・STS・CloudFront・WAFを含めることで、グローバルエンドポイントで呼び出されるサービスを誤ってDenyしないようにします。

SCPパターン例②：ルートアカウント使用禁止

ルートアカウントは最高権限を持つため、SCPによる使用禁止が推奨されます。

{
  "Version": "2012-10-17",
  "Statement": [{
 "Sid": "DenyRootAccountActions",
 "Effect": "Deny",
 "Action": "*",
 "Resource": "*",
 "Condition": {
"StringLike": {
  "aws:PrincipalArn": "arn:aws:iam::*:root"
}
 }
  }]
}

ルートアカウントが必要な操作（S3バケットポリシー削除・IAMサポートプランの変更等）は、管理アカウントからの委任管理の手順で対応します。

SCPパターン例③：S3パブリックアクセスブロック無効化禁止

S3のパブリックアクセスブロックをアカウント・バケットレベルで無効化させないSCPです。

{
  "Version": "2012-10-17",
  "Statement": [{
 "Sid": "DenyS3PublicBlockDisable",
 "Effect": "Deny",
 "Action": [
"s3:PutBucketPublicAccessBlock",
"s3:DeletePublicAccessBlock"
 ],
 "Resource": "*"
  }]
}

このSCPと後述のRCP（組織外アクセス禁止）を組み合わせることで、S3の不意のパブリック公開を二重に防止できます。

SCP設計のアンチパターン

SCP継承ルール

SCPはOrganizationsの木構造に従って上位から下位へ継承されます。上位OUでDenyされた操作は、下位のOUやアカウントで許可しても覆すことができません。複数のSCPが適用される場合、どのSCPでも明示的にAllowされていてかつDenyされていない操作だけが実際に許可されます。

2-3. RCPとSCPの使い分け（2024年11月 GA）

RCP（Resource Control Policy）の概要

2024年11月にGAしたRCP（Resource Control Policy）は、AWS Organizationsに追加された新しいポリシータイプです。SCPがプリンシパルの最大権限を制限するのに対し、RCPはリソース側から「誰がこのリソースにアクセスできるか」の上限を組織レベルで設定します。

RCPが登場する前は、組織外のAWSアカウントや匿名ユーザーからのアクセスをOrganizationsレベルで制御する手段がなく、各アカウントのリソースポリシー（S3バケットポリシー等）に頼るしかありませんでした。RCPを使うと、組織全体のすべてのメンバーアカウントのリソースに対して、組織外からのアクセスを一括でガードレール適用できます。

RCPとSCPは独立して機能し、追加料金なしで併用できます。

SCP vs RCP 一覧比較

RCPの評価フロー

RCPとSCPは独立したポリシータイプであり、評価は並列に行われます。リクエストが許可されるには、「SCPでDenyされていない」「RCPでDenyされていない」「IAMポリシーで許可されている」の3条件すべてを満たす必要があります。どちらか一方でDenyされれば最終的にアクセス拒否となります。

RCP活用例：S3バケットへの組織外アクセス全面禁止

組織外プリンシパルからのS3全操作を拒否するRCPの例です。

{
  "Version": "2012-10-17",
  "Statement": [{
 "Sid": "DenyExternalPrincipalS3Access",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "*",
 "Condition": {
"StringNotEquals": {
  "aws:PrincipalOrgID": "o-xxxxxxxxxxxx"
}
 }
  }]
}

o-xxxxxxxxxxxxは実際のOrganizationsのOrg IDに置き換えます。このRCPをRoot OUに適用することで、すべてのメンバーアカウントのS3バケットへの組織外アクセスを一括ブロックできます。

RCPの注意点と制限

RCPを設計・適用する際に押さえておくべき点を以下に示します。

• 対象サービスの限定（2024年11月GA時点）: S3・STS・KMS・SQS・Secrets Managerの5サービスが対象です。EC2・Lambda等はRCPの対象外であり、これらのリソースへのアクセス制御はSCP・リソースポリシーで対応します
• 管理アカウントへの適用: SCPと異なりRCPは管理アカウントのリソースにも適用されます。管理アカウントでS3を使用している場合は事前確認が必要です
• リソースポリシーとのAND評価: RCPはリソースポリシー（バケットポリシー等）よりも上位のガードレールとして評価されます。リソースポリシーで許可していてもRCPでDenyされていれば拒否されます
• AWSサービス自身のアクセス: AWS Backupによるオブジェクトのバックアップなどのケースでは、aws:PrincipalIsAWSServiceを考慮に入れる必要があります

3. Control Tower Landing Zoneセットアップ

Control Tower Landing Zoneはマルチアカウント基盤のベースラインを自動構築します。本章ではLanding Zoneのセットアップ手順、コントロール（ガードレール）の管理方法、そしてLanding Zoneが自動構築するログアーカイブ・監査アカウントの設計を扱います。

3-1. Landing Zoneセットアップ

前提条件の確認

Control Tower Landing Zoneを有効化する前に、以下の前提条件を確認します。

• Control Towerが利用可能なリージョンを選択していること（2025年時点で30超のリージョンで利用可能）
• Management AccountでAWS Organizationsが有効化されていること（新規の場合はControl Towerが自動作成）
• Log ArchiveアカウントおよびAuditアカウント用のメールアドレスが用意されていること（既存アカウントを指定するか新規作成かを事前に決定）
• Management Accountに十分なサービスクォータが確保されていること
• CloudTrail・AWS Config・SNS・CloudFormationなど、Control Towerが依存するサービスについて、当該リージョンで利用可能であることを確認してください

Landing Zone version 4.0: Controls-Only体験の導入

2024年のLanding Zone version 4.0は、Controls-Only体験という重要なアップデートを含んでいます。

従来のLanding Zoneでは、有効化時にmandatoryコントロールが自動的に全OUへ適用される仕様でした。version 4.0以降はmandatoryコントロールのデフォルト適用動作が変更され、組織固有の要件に合わせた柔軟なカスタマイズが可能になりました。

Controls-Only体験によるメリットは以下のとおりです。

• 段階的な移行: 既存の大規模Organizations環境をControl Towerへ統合する場合でも、コントロール適用を段階的に計画できます
• 組織固有要件への対応: 規制業界など特定のコントロールを先行適用したい組織で、適用順序の制御が可能になりました
• テスト容易性: 本番OUに影響を与えずに、sandbox OUでコントロールの挙動を事前検証できます
• 既存環境との整合: すでに独自のポリシーを管理している環境でも、段階的にControl Towerへ移行できます

既存Landing Zoneをversion 4.0へアップグレードする場合は、Control Towerダッシュボードの「Update available」から実施します。アップグレード前に既存コントロールの適用状態を記録し、アップグレード後の差分を確認することを強く推奨します。

セットアップ手順（マネジメントコンソール）

Landing Zone作成の主要ステップは以下の流れです。

1. Management AccountのAWS Control Towerダッシュボードを開き、「Set up landing zone」を選択します
2. ホームリージョンを指定します。ホームリージョンは後から変更できないため、慎重に選択してください
3. ガバナンス対象リージョン（Landing Zoneが管理するリージョン）を選択します
4. Log ArchiveアカウントとAuditアカウントのメールアドレスを設定します（新規作成または既存アカウントの指定）
5. 初期OU構成（Security OU / Sandbox OU）を確認します
6. 適用するコントロールとLanding Zoneバージョンを確認します
7. 設定内容をレビューして「Set up landing zone」を実行します

セットアップには30〜60分程度かかります。完了後、Control Towerダッシュボードで各OUとアカウントの状態を確認し、Landing Zoneの状態が「Up to date」になっていれば正常完了です。

ベースラインの自動構築

Landing Zone有効化に伴い、以下のベースラインリソースが自動構築されます。

• AWS CloudTrail組織トレイル: 全アカウント・全リージョンの管理イベントを集約するトレイルがManagement Accountに作成されます
• AWS Config記録: 全アカウント・全リージョンで設定記録が有効化されます
• Log ArchiveアカウントへのS3集約: CloudTrailログとConfigスナップショットが一元集約されます
• Auditアカウントへのセキュリティツール集約: Security Hub・GuardDutyの委任管理者としてAuditアカウントが設定されます
• IAM Identity Center: オプションとして有効化可能で、SSOの基盤が構築されます

これらはLanding Zoneが管理するため、個別アカウントでの手動変更はドリフト（Landing Zoneとの不整合）を引き起こします。Control Tower外での手動変更は原則禁止とし、すべてControl Towerコンソール経由で管理します。

3-2. コントロールの管理

Control Towerのコントロール（旧称: ガードレール）は、マルチアカウント環境に統制ルールをOU単位で適用する仕組みです。動作種別（予防的・探偵的・事前対応）と3段階のガイダンスレベルで分類されます。

コントロールの3つのガイダンスレベル

mandatory（必須）

Landing Zoneの基本要件を満たすために必要なコントロールです。

• Landing Zoneの整合性（ドリフトなし状態）を維持するために設計されています
• 一部のmandatoryコントロールはOUのLanding Zone登録時に自動適用されます
• version 4.0以降はControls-Only体験の導入により、mandatoryコントロールの適用タイミングとデフォルト動作が変更されています。詳細はAWSドキュメントの「Landing Zone Version 4.0」を参照してください
• mandatoryコントロールの無効化は、Landing Zoneのドリフト検知を引き起こすことがあります

strongly recommended（強く推奨）

AWSのWell-Architectedフレームワークに基づくベストプラクティスコントロールです。

• デフォルトでは無効です。組織のセキュリティポリシーや規制要件に応じて有効化を検討してください
• コンプライアンス要件（SOC2、PCI-DSS等）を持つ組織では、strongly recommendedコントロールの多くを有効化することを推奨します
• 有効化例: ルートアカウントのMFA必須化、CloudTrailログの暗号化有効化など

elective（選択的）

エンタープライズ環境で一般的に採用される選択的コントロールです。

• デフォルトでは無効です
• 組織の業務要件やセキュリティポリシーに応じて個別に評価・有効化します
• 有効化例: ルートユーザーのアクセスキー作成禁止、特定リソースタイプの制限など

コントロールの追加・変更手順

1. Control Towerコンソールの左メニューから「Controls」を選択します
2. コントロール名、ガイダンスレベル、動作種別（予防的・探偵的）でフィルタリングして目的のコントロールを検索します
3. 対象コントロールの詳細ページで「Enable control on OU」を選択します
4. 適用するOUを選択して実行します。有効化には数分かかる場合があります
5. Control Towerダッシュボードで適用状態（有効・無効・ドリフト）を確認します

大量のコントロールを一括有効化する場合は、AFTまたはCfCT経由での適用が効率的です。

2024年11月: RCPベースの構成可能マネージドコントロール

Control Towerは2024年11月、Resource Control Policy（RCP）を活用した構成可能マネージドコントロールを新たに追加しました。

• 従来のSCPはプリンシパル（ユーザー・ロール）の最大権限を制限するものでしたが、RCPはリソース側からのアクセス制御を担います
• RCPベースのマネージドコントロールをControl TowerコンソールからOU単位で一元管理できます
• 組織外プリンシパルからS3バケットやKMSキーへのアクセスを制限するコントロールなど、SCPでは実現できなかった統制が可能になりました
• RCPコントロールとSCPコントロールを組み合わせることで、プリンシパルとリソース双方向からのガードレールを構成できます

コントロール選択の考え方

コントロール選択は以下の順序で検討することを推奨します。

1. 規制・コンプライアンス要件の確認: SOC2、PCI-DSS、ISMS等で要求されるコントロールを最優先で特定します
2. strongly recommendedコントロールの評価: Well-Architectedレビューと照合し、組織のリスク許容度に応じて有効化対象を決定します
3. electiveコントロールの評価: 業務要件や過去のインシデント経験から選択します
4. sandbox OUでのテスト: 本番OUへの適用前に動作を検証します

コントロールの有効化・無効化はいつでも変更可能ですが、変更前に影響範囲を必ず確認してください。

3-3. ログアーカイブ・監査アカウント

Control Tower Landing Zoneはセキュリティ境界設計の核心として、Log ArchiveアカウントとAuditアカウントの2つの専用アカウントを自動構築します。

Log Archive（ログアーカイブ）アカウント

全メンバーアカウントのCloudTrailログとAWS Configデータを一元集約する専用アカウントです。

• Landing Zoneが有効化するCloudTrail組織トレイルのS3バケットは、このアカウント内に作成されます
• CloudTrailログ: 組織全体の管理イベント（コンソール操作・API呼び出し）を全リージョンで集約します
• AWS Config記録: 全アカウント・全リージョンのリソース設定変更履歴を集約します
• S3バケットへの書き込みはCloudTrailサービスが担い、一般ユーザーは原則アクセス不可とします
• ログの改ざん防止のため、S3 Object Lock（COMPLIANCE mode）の適用を強く推奨します
• バケットへのアクセスはLog Archiveアカウントの管理者（セキュリティチーム）のみに限定します
• ログ保持期間はコンプライアンス要件に応じて設定します（最低1年以上を推奨）
• S3ライフサイクルポリシーで一定期間後にGlacierへ移行するコスト最適化も検討します

Audit（セキュリティ・監査）アカウント

セキュリティツールを集約し、全アカウントへの読み取り専用アクセスを持つアカウントです。

• AWS Security Hubの委任管理者アカウントとして設定され、全アカウントのセキュリティ検出結果を一元管理します
• Amazon GuardDutyの委任管理者アカウントとして設定され、全アカウントの脅威検出結果を集約します
• AWS Config Aggregatorのソースアカウントとして、Organization全体の構成コンプライアンスデータを集約します
• Auditアカウントの管理者は全メンバーアカウントのセキュリティアラートを一元確認できます
• 業務担当者はAuditアカウントへのアクセスを原則禁止とし、セキュリティチームのみが管理します

アカウント分離によるセキュリティ境界設計

Log ArchiveとAuditを分離する設計には、明確なセキュリティ原則があります。

• 最小権限の原則: セキュリティツールと監査ログを業務アカウントから物理的に分離することで、侵害の影響範囲を限定します
• 耐タンパー性: アプリケーションアカウントが侵害された場合でも、攻撃者はLog ArchiveアカウントのS3バケットに書き込みアクセスができません。これにより、ログ改ざんによる証拠隠滅のリスクを大幅に低減します
• 集中監視: セキュリティイベントとコンプライアンス情報を単一アカウントに集約することで、SOCチームが組織全体を網羅的に監視できます
• 運用分離: セキュリティ運用チームと開発・運用チームのアカウントを分離することで、人的ミスによるセキュリティツール設定変更を防ぎます

CloudTrail組織トレイルの設定

Landing Zoneが有効化するCloudTrail組織トレイルは、Management Accountで作成され、Organization内の全アカウント・全リージョンを対象にします。

• 管理イベント: 全リージョンで有効化します（書き込みイベントのみ、または読み書き両方を組織の要件に応じて選択）
• データイベント（S3・Lambdaなど）: 機密データを扱うアカウントでは別途有効化を検討します
• ログファイル検証: 有効化することでSHA-256ダイジェストによるログ完全性の保証が可能です
• CloudTrail Lake: 高度なクエリが必要な場合は、CloudTrail Lakeへの転送も検討します
• CloudTrail Insights: 異常なAPI呼び出しパターンを自動検知する機能で、コスト急増やセキュリティイベントの早期発見に有効です

4. Account Factory / AFT によるアカウント払い出し自動化

手動でのアカウント作成は規模が増えると破綻します。本章ではControl Tower標準のAccount FactoryによるプロビジョニングとAFT（Account Factory for Terraform）によるGitOpsベースのアカウント払い出し自動化を扱います。

4-1. Account Factory概要

Account Factoryの仕組み

Account FactoryはControl Towerの標準機能で、AWS Service Catalogを経由して新しいAWSアカウントを標準化されたベースライン付きで作成します。

• ManagementアカウントのControl TowerコンソールまたはService Catalogから新規アカウントをプロビジョニングします
• アカウント作成時に自動的にOUへ配置され、Landing Zoneのベースライン（CloudTrail/Config/コントロール）が適用されます
• Account Vending（アカウント自動販売）パターンにより、ルートアカウントの直接作成を排除してガバナンス遵守を強制できます
• アカウント作成に伴う反復作業（OU配置・タグ付け・SSO設定）を標準化・自動化できます

Account Factory設定

Account Factoryの設定で事前に決定すべき主要項目は以下のとおりです。

デフォルトVPCはセキュリティリスクになるため、特別な理由がない限り削除設定を推奨します。メールアドレスはエイリアス形式（例: aws+アカウント名@example.com）を活用すると、大量アカウントでも一つのメールボックスで管理できます。

Account Factoryで作成されたアカウントの初期設定

Account Factoryで作成されたアカウントには以下が自動適用されます。

• 対象OUに紐づくSCP（Service Control Policy）が即座に適用されます
• CloudTrailとAWS ConfigがLanding Zoneのベースラインとして有効化されます
• IAM Identity CenterでシングルサインオンのEntitlementが付与されます（設定済みの場合）
• Account Factory設定で指定したネットワーク初期化が実行されます

これにより、アカウント作成直後から統制されたセキュリティベースラインが適用された状態になります。

4-2. AFT（Account Factory for Terraform）

AFTはControl Towerと統合したGitOpsベースのアカウントプロビジョニングフレームワークです。Terraformでアカウント定義を管理し、Gitへのプッシュをトリガーにアカウント作成・カスタマイズを自動化します。

AFTの特徴

• Infrastructure as Code（IaC）による再現性のあるアカウントプロビジョニング
• GitOpsによる変更管理と承認ワークフローの統合が可能
• 全アカウント共通カスタマイズと個別カスタマイズを分離管理
• 2023年以降、AWSが公式サポートする推奨アカウント自動化手段

AFTの4リポジトリ構成

AFTは4つのGitリポジトリで構成されます。それぞれの役割を明確に分離することがAFT設計の核心です。

① aft-account-request

新規アカウントのプロビジョニングリクエストを定義するリポジトリです。

• 各アカウントの定義をTerraformコードで記述します
• このリポジトリへのプルリクエスト（マージ）がアカウント作成パイプラインのトリガーになります
• 必要な情報: アカウント名、メールアドレス、OU配置、タグ、SSO設定など

module "dev_account" {
  source = "aws-ia/control_tower_account_factory/aws"
  control_tower_parameters = {
 AccountEmail  = "platform+dev@example.com"
 AccountName= "dev-workload-001"
 ManagedOrganizationalUnit = "Workloads"
 SSOUserEmail  = "admin@example.com"
 SSOUserFirstName = "Platform"
 SSOUserLastName  = "Admin"
  }
  account_tags = {
 Environment = "dev"
 Team  = "platform"
  }
}

② aft-global-customizations

全アカウントに共通適用するカスタマイズを定義するリポジトリです。

• 全アカウントに適用するSSMパラメータや共通Lambdaを管理します
• セキュリティベースライン（GuardDuty有効化、Security Hub標準適用等）の全アカウント展開に活用します
• Terraform（api_helpers）またはPython Lambda（lambda/）を組み合わせて実装します

③ aft-account-customizations

特定アカウントまたはアカウントグループ向けのカスタマイズを定義するリポジトリです。

• アカウント名をキーにしたディレクトリ構成でカスタマイズを管理します（例: customizations/dev-workload-001/）
• 環境別のVPC設定、セキュリティグループ、各種設定などを個別に管理します
• global-customizationsで管理できない個別要件を担当します

④ aft-account-provisioning-customizations

Step Functionsによるプロビジョニングプロセスの拡張を定義するリポジトリです。

• アカウント作成フローにカスタムステップを追加します（例: CMDBへの登録、Slackへの通知）
• 複雑な承認ワークフローや外部システム連携が必要な場合に使用します
• 通常のアカウント自動化では使用しないケースも多く、必要に応じて活用します

AFTパイプラインの動作フロー

1. aft-account-requestリポジトリにTerraformでアカウント定義を追加し、プルリクエストを作成します
2. レビュー・承認後にメインブランチへマージします
3. AWS CodePipelineがトリガーされ、Terraformでアカウントを作成します
4. Control Towerのアカウント登録処理（CloudFormation StackSet）が実行されます
5. Step FunctionsがAFTのカスタマイズパイプラインを起動します
6. global-customizations → account-customizations → provisioning-customizations の順で適用されます
7. アカウント作成完了の通知がSNS/Lambda経由で送信されます（任意設定）

4-3. AFTカスタマイズ実践

AFTの4リポジトリを活用した実践的なカスタマイズ例を示します。

グローバルカスタマイズ例: 全アカウントへのSSMパラメータ配布

全アカウントに共通の設定値をSSM Parameter Storeで配布する例です。aft-global-customizationsのTerraformコードとして管理します。

resource "aws_ssm_parameter" "org_id" {
  name  = "/aft/shared/org-id"
  type  = "String"
  value = var.org_id
}

resource "aws_ssm_parameter" "log_archive_account_id" {
  name  = "/aft/shared/log-archive-account-id"
  type  = "String"
  value = var.log_archive_account_id
}

全アカウントで共通の設定値をSSM経由で参照できるため、アカウント固有設定へのハードコーディングを防げます。

アカウント固有カスタマイズ例: 環境別VPC設定

aft-account-customizationsで特定アカウントのVPCを設定する例です。環境（dev/stg/prod）に応じてNATゲートウェイの冗長構成を変えるなど、アカウント固有の要件をコードで表現できます。

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name= "workload-vpc"
  cidr= "10.10.0.0/16"
  private_subnets = ["10.10.1.0/24", "10.10.2.0/24"]
  public_subnets  = ["10.10.101.0/24", "10.10.102.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = var.environment == "dev" ? true : false
}

2024年強化機能

AFTは2024年に以下の機能強化が行われました。

• VPCデプロイ選択: アカウント作成時にデフォルトVPC削除・カスタムVPC作成をAFTパイプライン内で制御できるようになりました
• AWS Backupカスタマイズ: バックアッププランを新規アカウントに自動適用できます
• CloudWatch設定: アラームやダッシュボードの初期設定をカスタマイズパイプライン内で適用できます
• S3ライフサイクルポリシー: ログアーカイブの保持期間をアカウント種別に応じてカスタマイズできます

これらにより、以前は手動後作業だったアカウント初期設定の多くをAFTパイプライン内で自動化できるようになりました。

AFT運用上の注意点

• AFT管理Terraformの状態はManagement AccountのS3バケットに保存されます。バケットのバージョニングと暗号化を確実に設定してください
• AFTで作成されたアカウントはAFT経由で管理することを原則とし、コンソールからの手動変更はドリフト原因になります
• Terraform moduleのバージョンは定期的にアップデートし、Control Towerのバージョンアップに追従してください
• アカウント数が増えるとaft-account-requestリポジトリが肥大化します。ディレクトリ構成の整理方針を事前に定めることを推奨します

5. CfCT (Customizations for Control Tower) による基盤カスタマイズ

CfCT（Customizations for Control Tower）は、CloudFormationテンプレートとSCP/RCPをCodePipelineで一元管理し、新規アカウント作成時に自動デプロイするAWSの公式ソリューションです。本章では、CfCTの仕組み・manifest.yaml設計・AFTとの使い分けを詳しく解説します。

5-1. CfCTとは

CfCTは、AWS Control Tower環境に追加カスタマイズを適用するためのAWS公式ソリューションキット（CloudFormationで展開）です。その設計思想は「Landing Zoneのガードレールをベースとしつつ、組織固有のCloudFormation/SCPカスタマイズをCIパイプラインで管理する」点にあります。

CfCTが解決する課題

Control TowerのAccount Factoryでアカウントを払い出した直後は、「ガードレールが適用されたベースライン状態」に過ぎません。そのアカウントにVPC設定・CloudTrail追加設定・セキュリティグループ・IAMロール等を手動で設定する作業が残り、設定漏れがセキュリティインシデントの原因となりがちです。

CfCTはこの問題を次のアプローチで解決します。

• 宣言的カスタマイズ: manifest.yamlにデプロイ対象のCloudFormationテンプレートとSCPを宣言的に記述します。
• 自動トリガー: Account Factoryがアカウントを作成するたびに、CfCTのCodePipelineが自動起動し、manifest.yamlの内容を新規アカウントに適用します。
• 既存アカウントへの一括適用: 既存の全アカウントへのCFNスタック展開や、OU単位でのSCP適用も可能です。
• コードレビュー統合: manifest.yamlとCFNテンプレートをGitで管理し、CodePipelineのソースとすることでPRレビュー→自動デプロイのワークフローを実現します。

CfCTのアーキテクチャ構成

CfCTを展開すると、以下のAWSリソースが管理アカウントに自動作成されます。

• S3バケット（ソース）: manifest.yamlとCFNテンプレートを格納するリポジトリ相当のバケットです。CodeCommitも代替として利用できます。
• CodePipeline: S3/CodeCommitの変更を検知し、Validate→Deploy→Notifyの3ステージを実行します。
• Step Functions: 各OU/アカウントへのCloudFormationスタック展開をオーケストレーションします。
• CloudFormation StackSets: 複数アカウントへのCFNスタックの同時展開を担います。
• SNSトピック: デプロイ結果の成功/失敗通知をメール等に配信します。

Account Factoryとの連携フロー

CfCTはControl TowerのLifecycle Eventを介してAccount Factoryと連携します。Account FactoryがCreateManagedAccountを発行するたびに、CfCTのEventBridgeルールがCodePipelineを起動します。これにより「アカウント作成→カスタマイズ適用」が自動化された連続プロセスとなります。

CfCTによる自動化の代表的なユースケースを示します。

• 本番OU向けに「デフォルトVPC削除」を全新規アカウントに自動適用
• 全アカウントに共通のAWS Config Rules（カスタムルール）をSCPとセットで展開
• セキュリティチームが管理するIAMロールを全アカウントに自動プロビジョニング
• タグポリシーと合わせてコスト配賦タグの強制をOU単位で一括適用

5-2. manifest.yaml の設計

CfCTの中核はmanifest.yamlです。このファイルが「どのOU/アカウントに、何を（CFNテンプレート/SCP）、どのリージョンに展開するか」を宣言します。

manifest.yamlの基本構造

manifest.yamlはバージョン宣言と3つの主要セクション（organizational-units / accounts / resources）で構成されます。

region: ap-northeast-1
version: 2021-03-15

organizational-units:
  - name: Production
 core-accounts:
- name: primary
 resources:
- name: production-baseline
  resource-file: templates/production-baseline.yaml
  deploy-method: stack_set
  deployment-targets:
 organizational-units:
- Production
  regions:
 - ap-northeast-1
 - us-east-1
- name: production-scp
  resource-file: policies/production-scp.json
  deploy-method: scp
  deployment-targets:
 organizational-units:
- Production

accounts:
  - name: logging-account
 account-owner-email: logging@example.com
 organizational-unit: Security
 resources:
- name: logging-config
  resource-file: templates/logging-config.yaml
  deploy-method: stack_set
  regions:
 - ap-northeast-1

deploy-methodにはstack_set（CFNスタック展開）とscp（SCPアタッチ）の2種類があります。

CFNテンプレートのデプロイ設定

CFNテンプレートの展開はdeploy-method: stack_setで行います。デプロイ先はorganizational-units（OU単位）またはaccounts（アカウント単位）で指定でき、OU配下に新規アカウントが追加されるたびに自動展開されます。

CfCTのStackSetsはCloudFormationのサービスマネージドStackSetsを利用するため、管理アカウントのCloudFormationコンソールで「Organizations信頼アクセスを有効化」する設定が前提条件となります。

SCPのデプロイ設定

SCPポリシー本体はJSONファイルとして管理し、manifest.yamlからdeploy-method: scpで参照します。以下はルートユーザー操作を拒否するSCPの例です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyRootUser",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
  "StringLike": {
 "aws:PrincipalArn": "arn:aws:iam::*:root"
  }
}
 }
  ]
}

このSCPをmanifest.yamlのresource-file: policies/deny-root.jsonとして参照することで、指定OU配下の全アカウントに自動適用されます。

タグポリシーの展開

SCPと同様に、タグポリシー（Tag Policy）もmanifest.yaml経由で展開できます。deploy-method: tag_policyを指定し、JSONファイルにタグポリシーを記述します。コスト配賦に必要なタグキー（Environment / Project / Owner等）を強制する設計が一般的です。

StackSetsとの使い分け

CfCTのコア機能は実質CloudFormation StackSetsですが、生のStackSetsと比較すると以下の差異があります。

CfCTを使うことで「アカウント作成とカスタマイズ適用の自動化」と「CFN/SCP管理のコード化」が一体で実現します。

5-3. AFTとCfCTの使い分け

AFT（Account Factory for Terraform）とCfCTは目的に重なる点がありながらも、設計思想・得意領域は異なります。以下の比較表を参照に、組織のIaC方針に応じて選択してください。

AFTを選ぶ判断基準

次の条件が当てはまる場合は、AFTの採用を優先することをおすすめします。

• 組織のIaC標準がTerraformであり、インフラ定義をTerraformで統一したい
• account-customizationsでアカウントごとの複雑なカスタマイズを差分管理したい
• GitOps（PR→CI→Apply）の細かい制御と承認フローが求められる
• アカウント作成後の段階的なリソース追加（後続カスタマイズ）が発生する

CfCTを選ぶ判断基準

次の条件が当てはまる場合は、CfCTの採用が合理的です。

• 組織のIaC標準がCloudFormationであり、Terraformを導入したくない
• SCP/タグポリシーをCFNと同じパイプラインで一元管理したい
• アカウント作成時のベースライン適用が主要ユースケースであり、後続カスタマイズの複雑さは低い
• AWSネイティブツールのみで完結させたい（Terraform Cloudや外部バックエンドを避けたい）

AFTとCfCTの併用パターン

AFTとCfCTは排他的な選択肢ではありません。「AFTでアカウントを作成し、CfCTでベースラインリソースを適用する」という組み合わせも技術的に可能です。ただし、パイプラインが二重化して運用負荷が増加するため、特定の要件がない限り一方を選択することをおすすめします。組織のIaC標準が既にどちらかに決まっている場合は、そちらに統一するのが最も合理的です。

6. 基盤の継続運用とドリフト検知

マルチアカウント基盤は構築後も継続的な統制が必要です。本章では、Control Towerのドリフト検知と修復、アカウントライフサイクル管理、IAM Identity Center連携の運用設計を解説します。

6-1. ドリフト検知と修復

Control Towerにおけるドリフトとは

ドリフトとは、Control TowerのLanding Zoneが意図した設定状態から逸脱した状態を指します。代表的なドリフトシナリオを示します。

• Mandatoryコントロールの無効化: Control Towerが必須とするコントロール（GuardDuty有効化・CloudTrail設定等）が手動で無効化された状態です。
• ログ設定の変更: ログアーカイブアカウントのS3バケットポリシーやライフサイクル設定が手動変更された状態です。
• OUの外部変更: Organizations管理コンソールから直接OU構成が変更され、Control Towerの期待状態と不一致が生じた状態です。
• アカウントのOU移動: Control Tower外でアカウントを別OUに移動した場合、そのアカウントの管理が手動状態になります。

これらのドリフトは、Control TowerコンソールのDashboardまたはAccounts/OUのステータスで「Drifted」として表示されます。

ドリフト通知の設定

Control TowerはEventBridgeを介してドリフトイベントを発行します。以下のEventBridgeルールパターンでドリフトイベントを捕捉できます。

{
  "source": ["aws.controltower"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
 "eventName": ["UpdateLandingZone", "DeregisterOrganizationalUnit"]
  }
}

捕捉したイベントをSNS経由でメール通知・Slack通知・PagerDutyエスカレーションと連携することで、ドリフト発生を即時に検知できます。

ドリフト修復: 手動修復 vs 自動修復

ドリフトの修復方法は手動修復と自動修復の2パターンがあります。

手動修復は、Control TowerコンソールのDashboardから「Re-register OU」または「Update Landing Zone」を実行します。操作前に「何が変更されたか」を確認し、意図的な変更であれば設計書を更新し、意図しない変更であれば根本原因を調査した上で修復します。

自動修復は、AWS Config Rules + Auto-Remediationを組み合わせます。

Config Rule: ct-mandatorycontrol-enabled
  → Noncompliant検知
  → SSM Automation Document: AWSConfigRemediation-EnableControlTower
  → SNS通知（修復完了）

ただし、自動修復はすべてのドリフトに適用できるわけではありません。OU構成変更のような複雑なドリフトは手動確認が必要です。自動修復の適用範囲を設計書に明記し、範囲外のドリフトはアラートと手順書で対応します。

定期ドリフトチェックの運用設計

ドリフトはリアルタイム通知だけでなく、定期的なチェックも重要です。推奨する運用サイクルを示します。

• 日次: EventBridge + SNSによる自動アラート（即時検知）
• 週次: Control Tower Dashboardの全アカウントステータス確認（手動レビュー）
• 月次: Organizations全体のOU構成とControl Tower期待値との突合（台帳との照合）
• 四半期: Mandatoryコントロールの適用状況を全アカウントでAudit（Config Aggregator活用）

6-2. アカウントライフサイクル管理

マルチアカウント基盤ではアカウントの払い出しだけでなく、休止・廃止・再利用のライフサイクル全体を設計する必要があります。

アカウントの休止（Suspend）と削除フロー

Control Towerで管理されているアカウントを廃止する場合、以下の手順を踏みます。

1. 事前確認: アカウント内のアクティブリソース・データ・IAMロールを棚卸しします。
2. データ移行/削除: S3バケットのデータを移行またはシュレッドし、必要なRDSスナップショット等は別アカウントに移します。
3. Suspend処理: Organizations管理コンソールから「Close Account」を実行します（AWSのアカウント閉鎖プロセスが開始します）。
4. Control Tower側のクリーンアップ: 閉鎖アカウントは自動的にOrganizationsから除外されますが、Control TowerのDashboardで「Suspended」ステータスを確認します。
5. 記録更新: アカウント台帳・CMDB・コスト配賦設計を更新します。

アカウント再利用 vs 削除の判断基準

廃止アカウントを再利用するか完全削除するかは、以下の観点で判断します。

AWSアカウントは一度閉鎖すると90日間の猶予期間後に完全削除されます。再利用が確定している場合は、閉鎖前に「Sandbox OUへの移動＋リソース全削除」を行い、閉鎖せずに再利用する方が運用上シンプルです。

コントロールの追加・変更時の影響範囲確認手順

新しいコントロールを有効化したり、既存コントロールを変更する場合は、必ず影響範囲を確認してから適用します。

• Strongly Recommendedコントロールの有効化: 対象OU配下の全アカウントへの影響を事前にConfig Aggregatorで確認します。
• SCPの変更: IAM Policy SimulatorまたはAccess Analyzerで既存のIAMロール・ユーザーへの影響を事前に確認します。
• ステージング環境での先行適用: 本番OUの前にSandbox OUで先行適用し、副作用がないことを確認します。

緊急時のアカウント分離手順

セキュリティインシデントやコンプライアンス違反が発生した場合、対象アカウントを迅速に分離します。

1. SCPによる即時分離: 管理アカウントから対象アカウントへの「Deny all actions」SCPを即時アタッチします。
2. IAMによるアクセス無効化: 対象アカウント内の全IAMユーザーのアクセスキーを無効化し、IAMロールのTrust Policyを削除します。
3. ネットワーク分離: Transit Gatewayのルートテーブルから対象アカウントのVPCを切り離します。
4. 証拠保全: CloudTrailログ・VPCフローログ・Config履歴をログアーカイブアカウントにエクスポートします。
5. 通知: セキュリティ担当・CISO・法務へのエスカレーションを実施します。

6-3. IAM Identity Center連携

IAM Identity Centerとは

IAM Identity Center（旧AWS SSO）は、マルチアカウント環境におけるSSOを実現するAWSのサービスです。Control Towerのセットアップ時に自動有効化されるため、追加の有効化操作は不要です。

IAM Identity Centerとの統合設定

Control TowerはセットアップフェーズでIAM Identity Centerと自動統合します。設定後は、IAM Identity Centerのコンソールから以下を管理します。

• Identity Source（IDソース）: AWSが提供するIAM Identity Center組み込みのディレクトリ、またはActive Directory（AWS Managed Microsoft AD）、外部IdP（Okta / Azure AD / Google Workspace等）を接続します。
• Users / Groups: IDソースからユーザー・グループを同期またはプロビジョニングします。
• Permission Sets: AWSアカウントへのアクセス権限セットを定義します。
• Account Assignments: Permission Setをユーザー/グループに割り当て、対象アカウントを指定します。

Permission Set の設計パターン

Permission Setは「どのアカウントに、どの権限で」アクセスするかを定義します。代表的な設計パターンを示します。

Permission Setにはインラインポリシーとマネージドポリシーの両方を付与できます。必要最小権限の原則に従い、開発者にはPowerUserAccess（IAM操作を除く）を基本とし、追加権限が必要な場合は個別のカスタムポリシーで補います。

ABAC（属性ベースアクセス制御）の活用

ABACは、ユーザー属性（タグ）とリソースタグを照合してアクセス制御を行う仕組みです。IAM Identity Centerでは「Access Control Attributes」としてユーザー属性を定義し、Permission Setのポリシー内でaws:PrincipalTagとして参照できます。

ABACを活用することで、Environment=productionタグが付いたリソースにはEnvironment=production属性を持つユーザーのみアクセス可能とする設計が実現します。これにより、アカウント数の増加に伴うPermission Set数の爆発を抑制できます。

ABACの詳細な設計・実装については、IAM Identity Center専用記事で詳しく解説していますので、そちらも合わせて参照してください。

7. 実戦統合パターン — エンプラ基盤の全体設計

本章では、Control Tower・AFT・CfCT・SCP/RCP・IAM Identity Centerを組み合わせたエンタープライズ基盤の統合設計パターンを扱います。各コンポーネントの責務を整理し、実際の構築シナリオとシリーズの全体像を示します。

7-1. エンプラ基盤全体設計

統制レイヤーと責務分界

マルチアカウント基盤は複数のコンポーネントが連携する多層構造です。各コンポーネントの責務を明確に分界することで、設計の重複を避け、参照すべき記事を明確化できます。

本記事はLanding Zone構築・アカウント払い出し自動化・OU/SCP/RCP設計の実装層を担います。概要やIAM設計は既存の関連記事が担当するため、本記事ではその実装詳細に集中します。

実戦統合パターン A — 新規エンプラ基盤構築（ゼロから始める場合）

新規でエンタープライズ基盤を構築する場合の標準的な進め方です。組織単位での統制を最初から組み込むことで、後からの設計変更コストを最小化できます。

構築フロー:

1. OU/SCP設計の確定（Security/Infrastructure/Workloads/Sandbox OU構成）
2. Control Tower有効化（Landing Zone作成・管理アカウント設定）
3. OU登録とコントロール適用（strongly recommended＋必要なelective）
4. SCP/RCPの適用（OU単位のガードレール設定）
5. AFT導入（4リポジトリ作成・Terraform設定）
6. CfCTベースライン（manifest.yaml設計・CodePipeline設定）
7. IAM Identity Center設定（Permission Set・グループ割り当て）

AFT初期構築コマンド例:

module "aft" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"

  ct_management_account_id = var.management_account_id
  log_archive_account_id= var.log_archive_account_id
  audit_account_id= var.audit_account_id
  aft_management_account_id= var.aft_management_account_id
  ct_home_region  = "ap-northeast-1"
  tf_backend_secondary_region = "ap-northeast-3"

  vcs_provider  = "github"
  account_request_repo_name = "my-org/aft-account-request"
  global_customizations_repo_name= "my-org/aft-global-customizations"
  account_customizations_repo_name  = "my-org/aft-account-customizations"
  account_provisioning_customizations_repo_name = "my-org/aft-account-provisioning-customizations"
}

AFT初期構築では管理アカウント・ログアーカイブアカウント・監査アカウントのIDが必須です。事前にControl TowerのLanding Zoneセットアップを完了させ、各アカウントIDをTerraform変数として管理します。

実戦統合パターン B — 既存Organizations環境にControl Towerを追加

既にAWS Organizationsを運用している場合に、Control Towerを後から追加登録するパターンです。既存アカウントのEnrollmentと既存OU設計との整合が鍵となります。

構築フロー:

1. 既存OU構成の棚卸し（Control Tower推奨OU設計との乖離確認）
2. 管理アカウントでControl Tower有効化（Landing Zone作成）
3. 既存アカウントのControl Tower登録（Enrollment）
4. Landing Zoneのベースラインを既存アカウントへ適用
5. 既存SCPとControl TowerコントロールのSCP競合確認
6. AFT移行（既存アカウント管理をAFTへ段階移行）

既存アカウントのEnrollmentコマンド例:

# 既存OUのControl Tower登録
aws controltower register-organizational-unit \
  --organizational-unit-id ou-xxxx-xxxxxxxx

# 既存アカウントの個別Enrollment
aws controltower enroll-account \
  --account-id 123456789012 \
  --enrolled-account-configuration accountId=123456789012

既存環境へのControl Tower導入で注意すべき点は、既存SCPとControl TowerのSCP競合です。Control TowerはSecurity OUとSandbox OUに独自のSCPを適用するため、既存SCPとのAND評価を事前に確認します。AND評価では、意図しないDenyの発生リスクがあります。Enrollment前に既存SCPの内容を精査することを推奨します。

実戦統合パターン C — Landing Zone 4.0へのアップグレード

Landing Zone 3.x系から4.0へのアップグレードです。Controls-Only体験への移行により、mandatoryコントロールの扱いが変わるため、事前の影響確認が重要です。

アップグレードフロー:

1. 現在のLanding Zoneバージョン確認
2. Controls-Only体験の影響確認（mandatory → デフォルト適用変更の影響）
3. 新規追加のRCPの評価と適用判断
4. Landing Zone更新実行（コンソールから「Update」）
5. アップグレード後のコントロール状態確認とドリフト修復

バージョン確認・更新コマンド例:

# Landing Zoneのバージョン確認
aws controltower get-landing-zone \
  --landing-zone-identifier \
  arn:aws:controltower:ap-northeast-1:123456789012:landingzone/XXXXXXXXXXXX

# Landing Zone更新
aws controltower update-landing-zone \
  --landing-zone-identifier \
  arn:aws:controltower:ap-northeast-1:123456789012:landingzone/XXXXXXXXXXXX \
  --version "4.0" \
  --manifest file://landing-zone-manifest.json

バージョン4.0ではRCP（Resource Control Policy）のサポートも追加されています。SCPとRCPを組み合わせた多層ガードレール設計を検討する良い機会となります。

CfCT初期構築コマンド例

CfCTをCodePipelineとして設定する場合のCloudFormationデプロイ例です。

# CfCT CloudFormationスタックのデプロイ
aws cloudformation create-stack \
  --stack-name customizations-for-aws-control-tower \
  --template-url https://s3.amazonaws.com/solutions-reference/customizations-for-aws-control-tower/latest/custom-control-tower-initiation.template \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters \
 ParameterKey=PipelineApprovalEmail,ParameterValue=ops@example.com \
 ParameterKey=CodePipelineSource,ParameterValue=GitHub

# CfCTのスタック状態確認
aws cloudformation describe-stacks \
  --stack-name customizations-for-aws-control-tower \
  --query 'Stacks[0].StackStatus'

CfCTはS3（またはCodeCommit/GitHub）にmanifest.yamlとCloudFormationテンプレートを配置することで、新規アカウント作成時に自動的にリソースをデプロイします。AFTとの使い分けは、組織のIaC方針（CloudFormation中心かTerraform中心か）に応じて選択します。

7-2. 関連記事との連携パターン

マルチアカウント基盤の実装は、本記事単体で完結するわけではありません。概要理解・IAM設計・SSO設定・継続運用の各フェーズで、既存の関連記事と連携しながら進めることが実践的なアプローチです。

M&G Vol1（概要）との連携

Organizations/Control Towerの概要・全体像についてはM&G Vol1記事を先に読むことを推奨します。M&G Vol1でOrganizations・Control Towerの基本概念と本番運用の全体像を把握した後、本記事でLanding Zone構築とアカウント払い出し自動化の実装に踏み込む流れが最も効率的です。

• M&G Vol1：Organizations/Control Towerの概要・本番運用の全体像
• 本記事：Landing Zone構築・AFT/CfCT実装・OU/SCP/RCP設計の詳細

IAM Identity Center記事との連携

IAM Identity CenterのPermission SetによるマルチアカウントSSOの概要は本記事でも触れていますが、ABAC（属性ベースアクセス制御）やPermission Set設計の詳細はIAM Identity Center専用記事を参照してください。本記事ではSSO設定のマルチアカウント基盤との接続点を扱い、個別の権限設計は専用記事に委ねる構成となっています。

Config/SSM記事（M&G Vol2）との連携

Landing Zone構築後のガバナンス強化では、Config RulesによるリソースコンプライアンスチェックやSystems Manager（SSM）による集中管理が重要です。これらはM&G Vol2以降で扱う予定のトピックです。Landing Zone自体が有効化するCloudTrail/Config集約ベースラインの上に、追加のガバナンスレイヤーを積み上げるパターンとして理解してください。

7-3. シリーズロードマップ

本シリーズ「AWSマルチアカウント基盤本番運用」は、エンタープライズ規模のAWSマルチアカウント運用を実装レベルで扱うシリーズです。本記事（Vol1）はLanding Zone構築・アカウント払い出し自動化・SCP/RCP設計を中心に据えています。

既存関連記事の読み順ガイド

既存のガバナンス・マルチアカウント関連記事と本シリーズの関係を整理します。

Vol2以降の想定トピック

本シリーズVol2以降では、以下のトピックを扱う予定です。

セキュリティ強化:
– Security Hubによるマルチアカウントセキュリティ集約
– GuardDutyのOrganizations管理・インシデント対応
– Detective/Macieのガバナンス統合

コスト最適化:
– CURとCost Allocation Tagsの集中管理
– Savings Plans/Reserved Instancesのマルチアカウント管理
– コスト異常検知の自動化

GitOps高度化:
– AFTパイプラインのCI/CD強化（テスト自動化・承認フロー）
– CfCT manifest.yamlのバージョン管理とレビュープロセス
– IaCドリフト検知の自動化

マルチアカウント基盤は一度構築して終わりではなく、組織の成長とともに継続的に進化させる長期投資です。本シリーズがその基盤となる実装知識の集積として機能することを目指しています。

8. つまずきポイント・アンチパターン・まとめ

マルチアカウント基盤の構築・運用で直面する課題と対策、本記事の要点を整理します。

8-1. つまずきポイント

Landing Zone構築・AFT/CfCT運用で詰まりやすい点を、症状・原因・対処の形式で整理します。

つまずき1: Landing Zone v4.0でmandatoryコントロールが自動適用されない

症状: Landing Zone v4.0へアップグレード後、既存OUへのmandatoryコントロール自動適用が停止し、ガバナンス要件（CISベンチマーク等）を満たせない状態が続いています。

原因: Landing Zone v4.0では「Controls-Only体験」に移行し、mandatoryコントロールのデフォルト適用動作が変更されました。v3.x以前の挙動と異なり、既存OUへの自動適用が行われなくなっています。

対処: アップグレード後にコントロールライブラリを確認し、mandatory判定のコントロールを手動で対象OUに有効化します。AWS CLIでaws controltower list-enabled-controlsを実行し、適用済みコントロールを棚卸しします。新規OUには必ずmandatoryコントロールを有効化してからアカウントを追加する運用ルールを設けることを推奨します。

つまずき2: AFTのCodePipelineが失敗し続ける

症状: AFTをTerraformでデプロイしたが、CodePipelineがDeployステージでエラーとなり、アカウント払い出しが進みません。

原因: AFTのCodePipelineが失敗する原因は複数あります。(1) CodeBuild/CodePipelineのIAMロールに必要な権限が不足している。(2) Terraform stateを管理するS3バケットがDeploy前に作成されていない。(3) aft-account-requestリポジトリの.tfファイルの構文エラー。(4) AFTモジュールが必要とするAWS OrganizationsのEnableAWSServiceAccessが未実行。

対処: (1) AFT展開時に生成されるIAMロールのポリシーを確認し、sts:AssumeRole・organizations:*・servicecatalog:*の権限を確認します。(2) Terraformのbackend.tfが参照するS3バケットとDynamoDB（ロックテーブル）を先行作成します。(3) terraform validateでHCL構文を事前検証します。(4) AFT管理アカウントでサービス連携を有効化してから再実行します。

つまずき3: CfCTのmanifest.yamlのエラーでデプロイが止まる

症状: CfCTをS3にアップロードしてCodePipelineをトリガーしたところ、Validateステージでエラーが発生し、パイプラインが停止します。

原因: manifest.yamlのよくあるエラーは次の通りです。(1) YAMLのインデントや区切りの誤り。(2) organizational-unit:に指定したOU名が実際のOrganizations上のOU名と一致しない（大文字小文字の相違含む）。(3) accounts:セクションでAccountIDが12桁でない。(4) CloudFormationテンプレートのS3パスが存在しない。

対処: (1) YAMLLintやpython -c "import yaml; yaml.safe_load(open('manifest.yaml'))" でローカル検証します。(2) aws organizations list-organizational-units-for-parentでOU名を確認し、manifest.yamlと完全一致させます。(3) テンプレートS3パスは実際にオブジェクトが存在することをaws s3 lsで確認します。

つまずき4: SCPを適用したらControl Towerのサービス連携が壊れた

症状: SCPをルート直下またはすべてのOUに適用したところ、Control TowerのコンソールでLanding Zoneのドリフトが検出され、自動修復が失敗するようになりました。

原因: Control Tower管理アカウント（Management Account）にSCPが適用されると、Control Towerが内部で行うサービス連携（CloudFormation StackSets・IAM Identity Centerの設定変更等）がSCPに阻まれます。特にDeny: cloudformation:*やDeny: iam:*などの広範囲Denyポリシーが原因です。

対処: SCPは必ずWorkloads/Security/SandboxなどのメンバーアカウントのOU単位で適用します。管理アカウントにはSCPを適用しない設計を徹底します。aws organizations list-policies-for-targetで管理アカウントに適用済みのSCPを確認し、Control Tower関連サービスの操作にDenyが入っていないかレビューします。

つまずき5: RCPを設定したらCloudFormationのS3アクセスが失敗した

症状: RCP（Resource Control Policy）をS3に適用した直後、CloudFormationのスタック作成・更新でテンプレートのS3アクセスがAccessDeniedとなりデプロイが止まりました。

原因: RCPはリソース（S3バケット）へのアクセスを組織外プリンシパルからも制限します。CloudFormationサービスがS3にアクセスする際、CloudFormationサービスプリンシパル（cloudformation.amazonaws.com）として行うリクエストがRCPのConditionチェックに引っかかる場合があります。

対処: RCPのCondition句にaws:PrincipalOrgIDの許可条件と合わせ、aws:PrincipalServiceName条件でCloudFormationサービスプリンシパルを例外として許可します。RCP適用前にデプロイパイプラインの影響範囲をテスト環境で確認し、例外条件を正確に設計してから本番OUに展開します。

つまずき6: AFTで作成したアカウントにBaselineが適用されない

症状: AFTで新規アカウントを払い出したが、aft-global-customizationsのベースラインコードが適用されず、VPC/CloudWatch/S3設定がデフォルトのままとなっています。

原因: AFTのaccount-tagsが正確に設定されていないと、aft-global-customizationsのフィルタリング条件に一致せず、Baseline Step Functionsがスキップされます。また、AFTモジュールのfeature_optionsでaft_feature_cloudtrail_data_events等のフラグが無効のままになっている場合もあります。

対処: aft-account-requestリポジトリの.tfファイルでaccount-tagsを正確に定義します。aws stepfunctions list-executionsで対象アカウントのStep Functions実行ログを確認し、どのステップで失敗または飛ばされたかを特定します。aft-global-customizationsのフィルタリングロジックとaccount-tagsの一致を検証します。

つまずき7: Account FactoryでアカウントをプロビジョニングしたがIAM Identity Centerに自動登録されない

症状: Control TowerのAccount FactoryでService Catalogからアカウントを作成したが、IAM Identity Center（SSO）に対象アカウントが自動登録されず、Permission Setを割り当てられません。

原因: Control TowerのLanding Zone設定時にIAM Identity Centerとの統合が正しく設定されていない場合、アカウント作成時の自動登録が機能しません。特に既存のOrganizationsにControl Towerを後から導入した場合、IAM Identity Centerのホームリージョンとの整合が取れていないことがあります。

対処: Control TowerコンソールのLanding Zone設定でIAM Identity Centerの統合状態を確認します。IAM Identity CenterコンソールのSettingsでAutomatic account provisioningが有効になっているかを確認し、有効でなければ有効化します。手動での対応が必要な場合はaws sso-admin create-account-assignmentでPermission Setを割り当てます。

つまずき8: Control Tower登録済みOUに既存アカウントをEnrollしたらCloudTrailが二重課金される

症状: 既存アカウントをControl TowerのOU配下にEnrollした後、CloudTrailコストが約2倍になりました。

原因: Control TowerはLanding Zone構築時に組織証跡（Organization Trail）を作成します。既存アカウントにも独自のCloudTrailが設定されていると、Enroll後に組織証跡と個別証跡の両方が有効になり、同一イベントが二重に記録・課金されます。

対処: Enroll対象アカウントの既存CloudTrailを事前に確認し、aws cloudtrail list-trailsで個別証跡を特定します。組織証跡でカバーされる範囲を確認し、重複する個別証跡は無効化または削除します。新規アカウントはAFTを通じて払い出し、個別証跡を後から作らない設計にすることで二重課金を防止します。

8-2. アンチパターン → 正解

OU/SCP設計やアカウント払い出しで陥りやすいアンチパターンと、推奨する正解パターンを対比形式で整理します。

アンチパターン1: 全OUに同一SCPを適用してWorkloadsのデプロイが制限される

アンチパターン: 「セキュリティを強化しよう」と、Security/Infrastructure/Workloads/Sandboxの全OUに同じ厳格なSCPを適用しました。直後にWorkloadsのCI/CD（CodePipeline/CodeBuild）からAWS APIコールが軒並み失敗し、デプロイが止まりました。

正解: OUの役割に応じてSCPを個別に設計します。Security OUには厳格なSCPを適用しますが、Workloads OUにはビジネス要件に必要なサービス操作を許可するSCPを別途設計します。FullAWSAccess（全許可）をベースに、OU別で必要なDenyルールを上乗せする設計が実装しやすく管理しやすいです。Sandboxはさらにコスト上限・リージョン制限などの追加制約を検討します。

アンチパターン2: AFTを使わず手動でアカウント作成してカスタマイズ漏れが発生

アンチパターン: 少数のアカウントだからと手動でAccount Factoryを使い、必要なVPC/CloudWatch/S3保持期間設定を手作業で行いました。アカウント数が増えるにつれて設定漏れが頻発し、本番環境で個別証跡がないアカウントを監査で発覚しました。

正解: アカウント払い出しはAFTの4リポジトリによるGitOps管理に統一します。全アカウントへの共通設定はaft-global-customizationsで一元化し、アカウント固有の設定はaft-account-customizationsで管理します。1アカウントであっても自動化の仕組みを導入することで、設定漏れをコード検証でブロックできます。

アンチパターン3: Control Tower管理アカウントにSCPを適用してサービス連携が壊れる

アンチパターン: 「Organizationsのルート」にSCPを適用することで全アカウントに統一ポリシーを適用しようとしました。直後にControl Towerのランディングゾーンドリフトが多発し、StackSet更新が失敗するようになりました。

正解: SCPはメンバーアカウントが属するOUに適用します。管理アカウント（Management Account）はSCPの適用対象外とする設計を徹底します。ルートへのSCP適用は意図せず管理アカウントも制約するため、Control Tower関連サービス（cloudformation/servicecatalog/identitystore等）の操作を例外許可するConditionを必ず含めます。

アンチパターン4: Landing Zoneのelective/strongly recommendedコントロールを理解せず全て有効化して本番影響が出る

アンチパターン: 「セキュリティは高ければ高いほどよい」と判断し、コントロールライブラリのstrongly recommended/electiveコントロールを一括で有効化しました。その結果、特定リージョンへのEC2インスタンス作成が禁止され、既存ワークロードが新規デプロイできなくなりました。

正解: まずmandatoryコントロールのみ有効化し、Landing Zoneの基本統制を確立します。strongly recommended/electiveコントロールは1件ずつ内容を確認し、ビジネス要件・規制要件と照合した上で計画的に有効化します。有効化前にStaging/Dev OUで影響確認を行い、問題がなければProduction OUに展開するフローを設けます。

アンチパターン5: RCP導入後にS3静的ホスティングが壊れる

アンチパターン: RCPを導入して「組織外プリンシパルからのS3アクセスを全てDeny」するポリシーを適用したところ、Webサイト向けのS3静的ホスティング（パブリック読み取り）が一切応答しなくなりました。

正解: RCPでS3を制限する際は、パブリックバケットポリシーで許可している操作がRCPのConditionと両立するかを事前検証します。S3静的ホスティングや外部パートナー向けのバケットにはaws:PrincipalOrgIDの例外条件を設定するか、該当バケットを持つアカウントをRCP適用OUから分離します。テスト環境でRCP適用→アクセス確認→本番展開の3ステップを必ず踏みます。

アンチパターン6: CfCTとStackSetを二重管理してドリフトが頻発する

アンチパターン: CfCT導入前からCloudFormationのStackSetを手動管理していたため、CfCT導入後もStackSetを並行運用しました。同一リソースへの変更が2経路で発生し、どちらが正とも言えないドリフトが常態化しました。

正解: CfCTを導入した後はCloudFormationのStackSetによる手動管理を廃止し、CfCTのmanifest.yamlに一本化します。移行期は新規リソースをCfCTで管理し、既存StackSetを段階的にCfCTリポジトリに取り込みます。最終的にStackSetの管理をCfCTに委譲し、手動のStackSet操作を禁止するSCPの導入も検討します。

8-3. まとめ

本記事では、AWS Control Tower Landing Zoneを中核としたマルチアカウント基盤の構築から継続運用まで、実装層で設計・運用するために必要な知識を体系的に整理しました。

本記事の総括

マルチアカウント基盤を正しく機能させるためには、5つの実装軸を連携させることが必要です。

OU/SCP/RCP設計（§2）では、Organizationsの組織階層設計と、プリンシパル中心の制御（SCP）とリソース中心の制御（RCP）の使い分けを扱いました。OUの役割に応じたSCP設計と、SCPでカバーできない組織外プリンシパルへの統制をRCPで補完する考え方が基本です。2024年11月にGAしたRCPはSCPの補完として重要性が増しており、S3/KMS/SQS等のリソース保護に積極的に活用することを推奨します。

Control Tower Landing Zoneセットアップ（§3）では、Landing Zoneが自動構築するベースライン（ログアーカイブ・監査アカウント・CloudTrail集約）と、コントロールの3レベル（mandatory/strongly recommended/elective）の管理を扱いました。v4.0でのControls-Only体験の変更点を理解し、既存OU/アカウントへの適用漏れを防ぐことが重要です。コントロールの定期棚卸しを運用プロセスに組み込み、新たに追加されたmandatoryコントロールの適用漏れを防ぎます。

AFTによるアカウント払い出し自動化（§4）では、4リポジトリ構成（aft-account-request/aft-global-customizations/aft-account-customizations/aft-account-provisioning-customizations）によるGitOpsを扱いました。手動払い出しを廃止し、全アカウントの設定をコードで一元管理することがスケーラブルな基盤の要件です。アカウント数が二桁を超えると手動運用のコストは急激に増大するため、早期のAFT導入が長期的な運用コストを下げます。

CfCTによる基盤カスタマイズ（§5）では、manifest.yamlによる宣言的なリソース/SCPデプロイと、CodePipelineによる自動展開を扱いました。CloudFormation主体の組織ではCfCT、Terraform主体ではAFTと、既存のIaCツールの方針に合わせた使い分けが現実的です。どちらの場合でも、変更履歴がGitに残る宣言的管理が運用品質を高めます。

基盤の継続運用とドリフト検知（§6）では、Landing Zoneのバージョン更新・ドリフト検知・IAM Identity Center連携を扱いました。構築後の「維持・更新」こそが長期的なガバナンス品質を左右します。AWS Security HubのControl Towerインテグレーションを活用して継続的なコンプライアンス監視を実現します。

実戦統合（§7）では、これらの実装軸を本番マルチアカウント設計に組み合わせるパターンと、既存記事との責務分界を整理しました。Control Tower Landing Zoneを中核とした基盤の上に、AFT/CfCTによる自動化とSCP/RCPによる統制を積み上げる設計が、エンタープライズ規模でのスケーラビリティを実現します。

実装ロードマップ

マルチアカウント基盤を段階的に整備する場合の推奨ロードマップを示します。

Step 1: OU/SCP設計

まずOrganizationsのOU階層と基本SCPを設計します。Security/Infrastructure/Workloads/SandboxのOU構成と、各OUに適用するSCPのDenyルールをドキュメント化します。この設計フェーズを省略すると、後からSCP変更が全アカウントに影響し手戻りコストが高くなります。SCPのDenyルールは保守的に設計し（狭い範囲から始め徐々に拡大）、段階的に強化する方針を推奨します。

Step 2: Control Tower有効化・Landing Zone構築

OU/SCP設計が固まったらControl Towerを有効化し、Landing Zoneを構築します。ログアーカイブ・監査アカウントのリージョン選択と保持期間を組織のコンプライアンス要件に合わせて設定します。Landing Zoneのバージョンを確認し、v4.0以降であればコントロールの適用計画を立てます。初期構築後の最初のコントロール棚卸しは必ず実施します。

Step 3: AFT導入・GitOps化

Landing Zoneが安定したらAFTを導入します。4リポジトリをGitリポジトリに作成し、既存アカウントをaft-account-requestに取り込みます。aft-global-customizationsに全アカウント共通の設定（VPC/CloudWatch/S3保持期間）を定義し、新規アカウント払い出しを自動化します。既存アカウントのEnrollは段階的に実施し、各バッチでCloudTrail二重課金の有無を確認します。

Step 4: CfCTベースライン適用

AFTによるアカウント払い出しが安定したら、CfCTを導入して組織全体のベースラインリソース（共通セキュリティグループ/IAMポリシー/SCP追加）をCodePipelineで自動デプロイします。manifest.yamlに既存のStackSet定義を移行し、手動管理を廃止します。CfCTとAFTの役割分担（CfCT=CFN+SCP管理、AFT=Terraform+アカウント単位カスタマイズ）を明確化します。

Step 5: 継続運用・ドリフト検知体制の確立

CfCTとAFTによる自動化が整ったら、Landing Zoneのバージョン更新サイクル、コントロールの定期棚卸し、ドリフト検知アラートの設定を運用設計に組み込みます。AWS Security HubのControl Towerインテグレーションで継続的なコンプライアンス監視を実現し、SCP/RCPの変更管理プロセス（Pull Request → レビュー → 適用）を確立します。

本シリーズの位置づけ

本記事は「AWSマルチアカウント基盤」シリーズのVol1として、Control Tower Landing Zoneを基盤に据えた実装設計を体系化しています。

既存のOrganizations/Control Tower概要（M&Gシリーズ）、IAMマルチアカウント設計、マルチアカウント運用入門が「概念と全体像」を担うのに対し、本記事は「実装層の構築・自動化・継続運用」に特化します。AFT/CfCTの4リポジトリ設計からSCP/RCPの具体的なCondition条件、Landing Zoneのバージョン管理まで、プラットフォームチームがすぐに使える設計パターンとトラブルシュートを提供することが本記事の価値です。

AWS環境の拡張に伴いアカウント数が増えるほど、自動化と統制の重要性は指数的に高まります。本記事で体系化した実装パターンを起点に、マルチアカウント基盤を段階的に強化することを推奨します。

8-4. 関連記事（クロスリンク）

本記事の理解を深めるために、Organizations/Control Tower概要・IAMマルチアカウント設計・マルチアカウント運用入門の関連記事も合わせて参照することを推奨します。

Organizations/Control Tower本番運用を読む