AWS Control Towerは便利ですが、再販/MSPの請求や組織構造の都合で「管理アカウントを自分で握れず有効化できない」ケースが実在します。そんなときに、Control Towerの各機能をどう自前（スクラッチ）で作るか——ランディングゾーンからガードレール、ドリフト検知まで、素のAWSプリミティブでの代替を実務目線で整理します。
01Control Towerが使えない、その正体
AWS Control Tower は、マルチアカウントのランディングゾーンを"ボタンひとつ"で用意してくれる便利なサービスです。ところが、使えないケースが実在します。最大の壁は管理アカウント——CTは既存のOrganizationsの管理アカウント上で有効化する必要があり、再販/MSPの請求・組織構造で顧客が管理アカウントを握れないと、そもそも有効化できません。
しかも重要なのは、代替とされる Landing Zone Accelerator（LZA）も同じ管理アカウントを要求すること。だから「管理アカウントを握れない」問題はLZAでも解決しません。独立したOrganizationsを確保するか、各機能を素のAWSで自前（スクラッチ）に組む知識が要ります。
この記事では、Control Towerが何を自動でやり、それをどう自前で代替するかを対応表つきで整理します。前提のOrganizationsの構造はAWS Organizationsの仕組みと設計、SCP/RCPの雛形は最低限のガードレールをどうぞ。
02Control Towerが"まとめて"やってくれること
まず、CTが自動でやってくれることを押さえます。これが「自前で組む対象」になります。
- ランディングゾーンのセットアップと OU（Security 等）作成
- 共有アカウントの作成：Log Archive（全アカウントのCloudTrail/Configログを集中）と Audit（Security）（セキュリティ/委任管理用）
- IAM Identity Center の構成（SSO・権限セット。外部IdPも選択可）
- 組織CloudTrail（集中ログ）と AWS Config（検知。2025年からservice-linked Config rulesで各アカウントへ直接展開）
- コントロール：予防（SCP）／検知（Config）／事前（CloudFormation Hooks）。Control Catalog（750+のマネージドコントロール）
- Account Factory（アカウント払い出しの標準化）／AFT、ダッシュボード、ドリフト検知
03なぜ使えない／使いにくいのか
便利なCTが使えない・使いにくい主因はこれです。
- ① 管理アカウントを握れない（最大の理由）：CTは既存の管理アカウント上で有効化する。顧客アカウントが他社（再販/MSP）のOrganizationsや一括請求（consolidated billing）配下にぶら下がっていると、顧客側でCTを有効化できない。
- ② LZAも同じ前提：LZAも管理アカウントを要求するため、①の状況ではLZAでも解決しない。独立したOrganizations（自前の管理アカウント）を用意しない限り、CTもLZAも土俵に上がらない。
- ③ 既存リソースとの衝突：CTが作るSCPを直接編集できない、既存OU/アカウントは Enroll / Register が必要、といった制約。
- ④ リージョン：中国パーティションは非対応（要確認）、GovCloud (US)は対応するが Account Factory でのアカウント作成不可などの制約。
04その前に — LZA と CfCT という中間解
完全自前に走る前に、AWSが用意する中間解も知っておきます（いずれも管理アカウントは必要）。
- Landing Zone Accelerator（LZA）：CDK/CloudFormation＋YAMLのAWSソリューション。CTの上でも、CT無し（Organizationsのみ）でも動く。規制業種・GovCloud/中国等の特殊パーティション・高度なカスタマイズ向け。
- CfCT（Customizations for Control Tower）：CT前提の拡張（既存ランディングゾーンのカスタマイズ）。CTが使えないなら選択肢外。
| 選択肢 | 管理アカウント | 向く状況 | 実装 |
|---|---|---|---|
| Control Tower | 必要 | 標準リージョン・素早く標準構成 | マネージド（no-code） |
| LZA | 必要 | 規制・GovCloud/中国・高度カスタム | CDK/CloudFormation＋YAML |
| CfCT | 必要（CT前提） | 既存CTの軽い拡張 | CloudFormation＋SCP/RCP |
| 完全自前 | （自組織の管理アカウント） | CT/LZAが要件を満たせない／全て掌握したい | Organizationsを直接運用 |
05Control Tower機能 → スクラッチ代替の対応表
本題です。CTの各機能を、素のAWSプリミティブでどう作るか。
| Control Towerの機能 | 自前（スクラッチ）での実現 | 使うサービス |
|---|---|---|
| ランディングゾーン一式 | Organizationsを手動作成しOU設計、共有アカウントを手動払い出し | AWS Organizations |
| OU構成 | AWS推奨のOUベストプラクティスに沿って手動でOU階層を構築 | Organizations（OU） |
| Log Archive／集中ログ | 専用アカウント＋組織CloudTrail（organization trail）を中央S3へ。改ざん防止にS3 Object Lock（WORM）＋KMS＋ログ整合性検証 | 専用アカウント＋CloudTrail＋S3（Object Lock）＋KMS |
| Config集約（Audit/Security） | 各アカウントでConfig有効化（StackSetsで一括）→AWS Config 組織アグリゲータで集約 | AWS Config（レコーダ＋組織アグリゲータ） |
| 検知コントロール | 組織Configルール／組織コンフォーマンスパックを委任管理者から展開＋Security Hub（CSPM）で標準を集約 | AWS Config＋Security Hub |
| 予防コントロール | SCP／RCP／宣言的ポリシーをOU/アカウントへ手動適用 | Organizations（SCP/RCP/宣言的ポリシー） |
| アカウント払い出し | Terraform aws_organizations_account または自作AVM（Service Catalog＋Lambda＋CreateAccount）。AFTはCT前提で使用不可 | Terraform／Service Catalog／Lambda |
| ベースライン配布 | CloudFormation StackSets（service-managed＋auto-deployment）でOU単位に自動展開 | CloudFormation StackSets |
| IAM Identity Center | 手動で有効化・権限セット・外部IdP連携（SAML/SCIM） | IAM Identity Center |
| ドリフト検知 | 自作：Config非準拠＋EventBridge、terraform plan定期実行、CFnドリフト検知 | Config／EventBridge／Terraform |
| ダッシュボード/可視化 | Security Hubの集約ビュー、Configアグリゲータ、必要ならQuickSight | Security Hub／Config／QuickSight |
06自前ランディングゾーンの最小手順
対応表を"順序"にするとこうなります。
- ① 管理アカウントで Organizations を作成（All features）
- ② OU設計（Security／Infrastructure／Workloads(Prod/SDLC)／Sandbox …）
- ③ 共有アカウント払い出し（Log Archive／Audit＋break-glass）
- ④ 組織CloudTrail → 中央S3（Object Lock／KMS／整合性検証、
aws:SourceOrgIDで組織外書込を遮断） - ⑤ Config を全アカウント有効化（StackSets）→ Audit/Securityに組織アグリゲータ
- ⑥ 予防コントロール（SCP／RCP／宣言的ポリシー）を各OUへ適用
- ⑦ IAM Identity Center 有効化（権限セット・外部IdP）
- ⑧ 検知コントロール（組織Configルール／コンフォーマンスパック＋Security Hub）
- ⑨ StackSets（service-managed＋auto-deployment）でベースライン配布
- ⑩ アカウント払い出しの自動化（Terraform／自作AVM）＋ドリフト検知を自作
07自前構築の落とし穴
「作れる」と「作り続けられる」は別です。CTが標準で肩代わりしていたものが、全部こちらの負担になります。
- ドリフト検知が標準で無い：CTは自動で検知するが、自前ではConfig/EventBridge/
terraform planで作り込まないと逸脱に気付けない。 - メンテ・属人化：Config・CloudTrail・StackSets・SCP/RCP・Identity Centerを個別にバージョン管理。新機能・リージョン追加への追従も手動。IaC化しないと属人化する。
- 抜け漏れ：CTが標準でやることを個別に組む分、S3バケットポリシー・KMS権限・Config記録範囲・リージョン制限（Region deny相当のSCP）の設定漏れが起きやすい。
- 管理アカウントへの非適用：StackSets（service-managed）は管理アカウントに配布されず、SCPも効かない。中央ログ・監査の抜けに注意。
- Security HubはConfig依存：FSBP等の多くはConfigルールで評価されるため、Config未有効だと検知が機能しない。
- AFTは使えない：CT前提。払い出しは Terraform
aws_organizations_accountか自作AVMで。
08まとめ — まず"独立Org"、無理なら自前を作り込む
Control Towerが使えない最大の理由は「管理アカウントを握れない」こと。そしてLZAも同じ前提なので解決しません。まず独立したOrganizationsの確保を検討し、それも無理なら——Organizations＋組織CloudTrail＋Config集約＋SCP/RCP＋StackSets＋Identity Center を自前で組み、ドリフト検知まで作り込む。CTが無償でやっていた保守を背負う点を、最初から設計に織り込みます。
EMWは、Control Towerが使えない環境でのランディングゾーン自前構築・ガバナンス設計を実務で扱ってきました。既存の請求/組織構造を踏まえ、マルチアカウント戦略から現実的な形を一緒に描きます。
09よくある質問（FAQ）
なぜ Control Tower が使えないことがあるのですか？
最大の理由は管理アカウントを握れないことです。Control Towerは既存のOrganizationsの管理アカウント上で有効化する必要があり、再販/MSPの請求・組織構造で顧客アカウントが他社のOrganizations配下にあると、顧客側でCTを有効化できません。
Landing Zone Accelerator（LZA）を使えば解決しますか？
この「管理アカウントを握れない」問題は解決しません。LZAも同じ管理アカウントを要求します。独立したOrganizations（自前の管理アカウント）を用意できて初めて、CTもLZAも選択肢になります。
Control Towerの機能は自前で全部作れますか？
主要機能は素のAWSで代替できます。Organizations＋OU、専用のLog Archive/Auditアカウント、組織CloudTrail、AWS Config組織アグリゲータ、SCP/RCP、StackSetsでのベースライン配布、IAM Identity Center。ただしドリフト検知は標準で無いため自作が必要で、CTが無償でやる保守を全部背負う点に注意します。
自前構築でいちばん抜けやすいのはどこですか？
ドリフト検知（自作しないと逸脱に気付けない）、管理アカウントへの非適用（StackSets/SCPが効かない）、S3バケットポリシーやConfig記録範囲の設定漏れ、Security HubがConfig依存で未有効だと機能しない点です。IaCでコード化して属人化を防ぐのが前提になります。
Control Towerが使えない環境でのランディングゾーン設計・ガバナンス自前構築でお困りなら、既存の請求/組織構造を踏まえて現実的な形を一緒に描きます。
相談する