AWS Control Tower入門｜Landing Zoneで複数AWSアカウントを自動標準化するガバナンス設計と運用ガイド

「AWSアカウントが増えすぎて、セキュリティポリシーの統一が追いつかない」「新しいプロジェクトのたびにアカウントを手作業で設定しているが、属人化が怖い」——マルチアカウント運用をOrganizationsだけで回していると、こういう壁にぶつかります。

オンプレ時代なら、サーバーの払い出し手順書とVLANの設計基準書があれば何とかなりました。しかしAWSアカウントは、作った瞬間からIAMもVPCもCloudTrailも「白紙」です。プロジェクトごとに担当者が異なる設定を入れていくと、半年後には監査対応で一苦労します。

この記事では、そうした課題を解決するAWS Control Towerについて、オンプレ経験者にもわかりやすく解説します。Landing Zoneの仕組みから、ガードレールの設計方針、Account Factoryによる新規アカウントの自動払い出しまで、現場で使える実務知識を網羅します。

OrganizationsとSCPだけでは足りない理由

AWS Organizationsを使うと、複数のAWSアカウントを一元管理できます。SCP（サービスコントロールポリシー）でアカウントレベルの制限もかけられます。では、Control Towerは何を加えるのでしょうか。

一言でいうと、Organizationsが「組織の骨格」を作るツールなら、Control Towerは「標準化された部屋の内装ごと用意する」ツールです。

Organizationsだけで運用すると、「アカウントを作ること」と「アカウントを安全に使える状態にすること」は別の作業になります。具体的には以下を手動で設定しなければなりません。

・CloudTrail: 全リージョンのAPI呼び出し記録を有効化
・AWS Config: リソース変更履歴の記録開始
・IAM Password Policy: 最低限のパスワード強度設定
・ルートユーザーのMFA: 払い出しごとに確認と設定
・デフォルトVPCの見直し: デフォルトVPCやインターネットゲートウェイの削除判断

これを10アカウント、20アカウントと増やすたびに繰り返すのは現実的ではありません。Control Towerはこれらをまとめて自動化し、「Landing Zone（ランディングゾーン）」と呼ばれる標準化された環境を一括で展開します。

Control Towerの主要コンポーネント

1. Landing Zone

Landing Zoneは、Control Towerが作成するマルチアカウント環境の基盤です。初回セットアップ時に以下が自動作成されます。

・Security OU: ログアーカイブアカウントと監査（Audit）アカウントを配置
・Sandbox OU: 開発・検証用アカウントを収容
・Log Archiveアカウント: CloudTrailログ・AWS Configの記録を集中保管
・Auditアカウント: セキュリティチームがクロスアカウント監査を行う拠点

オンプレで例えると、Log ArchiveアカウントはSyslogやSIEM（セキュリティ情報イベント管理）サーバーへの集中転送先、Auditアカウントはセキュリティチーム専用の監視端末のような役割です。

2. ガードレール（Guardrails）

ガードレールはControl Towerの目玉機能で、アカウントに適用するポリシー制御のセットです。性質によって2種類あります。

予防的ガードレール（Preventive Guardrails）
SCPをベースにした「させない」制御です。「CloudTrailの無効化を禁止」「東京・大阪リージョン以外へのリソース作成を禁止」といったルールを設定します。違反しようとする操作は実行時点で拒否されます。

探偵的ガードレール（Detective Guardrails）
AWS Configルールをベースにした「検知する」制御です。「MFAが設定されていないIAMユーザーの検出」「パブリックS3バケットの検出」のように、違反状態を見つけて通知します。予防的ガードレールと異なり操作を止めるわけではなく、発見と是正を促します。

2026年3月時点で400種類以上のガードレールが提供されています。必須（Mandatory）・強く推奨（Strongly Recommended）・選択的（Elective）の3段階で管理され、必須ガードレールはLanding Zoneセットアップ時に自動で有効化されます。

3. Account Factory

Account FactoryはAWSアカウントの「自動払い出し機」です。Service Catalogを通じてアカウントのリクエストから払い出しまでを自動化できます。払い出し時に事前定義されたテンプレートが適用されるため、全アカウントが同一の初期状態から始まることが保証されます。

4. IAM Identity CenterとのSSO統合

Control TowerはAWS IAM Identity Centerと標準で統合されます。セットアップ後、管理者はIdentity Centerから各アカウントへのシングルサインオンを構成でき、「アカウントごとにIAMユーザーを個別作成する」という混乱した運用から脱却できます。

Control Towerのセットアップ手順（概要）

1. 前提条件の確認

セットアップ前に以下を確認します。

・管理アカウント: すでにOrganizationsの管理アカウントになっているか
・ホームリージョンの決定: Control TowerはホームリージョンのAWS Configを集中管理します。日本拠点なら東京（ap-northeast-1）が一般的です
・既存のOrganizationsリソース: すでに複数OUやSCPがある場合は事前に整理が必要です（詳細は後述）

2. コンソールからセットアップを開始

AWSコンソールで「AWS Control Tower」を検索し、「Set up landing zone」をクリックします。ウィザード形式で進み、主に以下を設定します。

・ホームリージョン: ap-northeast-1（東京リージョン）を選択
・ガバナンス対象リージョン: ap-northeast-3（大阪リージョン）など追加リージョンを任意で選択
・Log Archiveアカウント: 新規作成または既存アカウントの指定
・Auditアカウント: 同上

# AWS CLI: Control Towerが作成したOUを確認する（セットアップ完了後）
aws organizations list-organizational-units-for-parent \
  --parent-id $(aws organizations list-roots --query 'Roots[0].Id' --output text) \
  --query 'OrganizationalUnits[*].[Id,Name]' \
  --output table

# 出力例（東京リージョン ap-northeast-1 の環境）:
# -------------------------------------------
# |  ou-xxxx-xxxxxxxx  |  Security           |
# |  ou-yyyy-yyyyyyyy  |  Sandbox            |
# -------------------------------------------

初回のLanding Zoneセットアップは30～60分かかります。この間、Organizationsのアカウント作成・AWS Config・CloudTrailなどが並行して設定されます。マネジメントコンソールのアクティビティタブから進行状況を確認できます。

ガードレール設計の実務ポイント

必須ガードレールはデフォルトで有効

Landing Zoneをセットアップすると、以下の必須ガードレールが自動で有効になります。変更・無効化はできません。

・CloudTrailの無効化を禁止（予防的）
・CloudTrailの設定変更を禁止（予防的）
・Control TowerのIAMロール削除を禁止（予防的）
・Log Archiveアカウントへのルートアクセスを検出（探偵的）
・Auditアカウントへのルートアクセスを検出（探偵的）

追加ガードレールの選び方：優先度が高い3つ

S3バケットのパブリックアクセスを検出（探偵的）
意図しないパブリックバケットを全アカウントで横断検知できます。AWS Configルールベースのため、既存の違反状態も漏れなく検出されます。

MFAなしのルートユーザー操作を検出（探偵的）
Account Factoryで払い出した直後にMFAが未設定のアカウントを自動検知します。管理コンソールのダッシュボードで全アカウントの準拠状況を一覧確認できます。

特定リージョン外へのリソース作成を禁止（予防的）
データレジデンシーポリシーがある場合、東京・大阪以外へのリソース作成をSCPで一括禁止できます。個別アカウントへのSCP適用と異なり、新規アカウントが増えても自動で適用されます。

ガードレールの管理画面から確認できること

Control Towerの管理コンソールには「コントロール」ページがあり、各ガードレールの有効・無効状態と、どのOUに適用されているかを一覧で管理できます。また「コンプライアンス」ページでは、探偵的ガードレールに違反しているリソースをアカウント横断で確認できます。オンプレ時代に個別サーバーをエージェントで監視していた感覚とは異なり、全アカウントの状態を一か所で把握できる点が大きな強みです。

Account Factoryの実務活用

アカウント払い出しの主なパラメータ

Account Factoryを使ってアカウントを払い出す際に指定できる主なパラメータは以下のとおりです。

・メールアドレス: 新規AWSアカウントのルートメール（必須・重複不可）
・アカウント名: 識別しやすい命名規則を決めておく（例: proj-ec-dev）
・OU: どのOU（組織単位）に配置するか
・SSOメール: IAM Identity Centerでこのアカウントを管理するメールアドレス
・VPC設定（オプション）: デフォルトVPCを自動削除するか否か

Account Factory for Terraform（AFT）

より高度なカスタマイズが必要な場合は、AFT（Account Factory for Terraform）と組み合わせます。AFTを使うと、アカウント払い出しのパイプラインをGitリポジトリで管理でき、アカウントの初期状態をコードとして定義できます。

例えば以下のような処理をTerraformで記述し、払い出しのたびに自動実行できます。

・全アカウントに特定のIAMロールを作成する（監視エージェント用など）
・デフォルトVPCを削除してプロジェクト専用VPCを自動作成する
・CloudWatch Logsの保管日数を統一する
・特定のAWS Configルールを追加で有効化する

オンプレでいえば「Ansibleのプレイブックがサーバー払い出し後に自動実行される」イメージに近いです。インフラコードとしてGitで管理できるため、設定変更の履歴追跡や複数人でのレビューも可能になります。

Control Towerの料金体系

Control Tower自体の利用料は無料です。ただし、内部で使う以下のサービスに料金が発生します（2026年3月時点）。

アカウント数が10程度であれば、Control Tower関連の追加コストは月額数十ドル以内に収まることがほとんどです。サービスクォータの上限管理と合わせて、アカウント数が増えたときのコスト変化も事前に試算しておくことを推奨します。

既存Organizations環境への後付け導入時の注意点

既存OUとSCPとの競合確認

すでにOrganizationsを使っている環境にControl Towerを後から導入する場合、既存のOU・SCP・アカウント構造との整合性確認が必須です。Control TowerはデフォルトでRoot直下にSecurityとSandbox OUを作成しようとするため、同名のOUや競合するSCPがあるとセットアップが失敗します。

事前に以下を確認します。

・既存のSCPがControl Towerの必須ガードレールと競合しないか
・Root OUにアタッチしているSCPがControl Towerの内部処理（IAMロール作成など）を阻害しないか
・既存アカウントをEnrollする場合、そのアカウントにControl Towerが前提とするIAMロールが存在するか

既存アカウントの「登録（Enroll）」の進め方

既存のAWSアカウントをControl Towerの管理下に入れることを「Enroll」と呼びます。既存設定との競合を避けるため、全アカウントを一度にEnrollせず、影響が少ない開発アカウントから段階的に行うのが現実的な進め方です。本番アカウントは十分な検証を経てから移行します。

よくあるトラブルと対処法

Landing Zoneのセットアップが途中で失敗する

コンソールのアクティビティログにエラー詳細が表示されます。よくある原因は3つです。

・サービスクォータ超過: AWSアカウント作成の上限（デフォルト10件）に達している場合、引き上げ申請が必要
・既存のCloudTrail証跡との競合: すでに組織単位の証跡がある場合、Control Towerが新たに作成しようとする証跡と重複する
・SCPによる操作ブロック: Root OUのSCPがControl Tower内部の操作（IAMロール作成等）をブロックしている

Account Factoryで払い出したアカウントにSSOでログインできない

Account Factoryはアカウントを作成するだけで、IAM Identity Centerへの Permission SetとユーザーのアサインはControl Towerコンソールまたは直接Identity Centerで行う必要があります。払い出し直後にアクセスできない場合は、Identity CenterのAssignments設定を確認します。

ガードレールを有効にしたら既存リソースがコンプライアンス違反になった

探偵的ガードレールを後から有効化した場合、既存リソースの違反状態が一気に検出されます。これ自体は意図した動作ですが、大量の違反アラートで混乱しないよう、有効化の前にまず「評価のみ（ドライラン相当）」として影響を把握してから適用する順序を推奨します。Control TowerのRegister OU操作時にプレビューを確認できます。

本記事のまとめ

AWS Control Towerは、マルチアカウント環境の「標準構成とガバナンスルール」を最初から組み込んだ状態でアカウントを払い出せるサービスです。Organizationsの骨格の上に、ログ収集・ガードレール・SSO統合・自動払い出しの仕組みをまとめて乗せることで、アカウントが増えても統制が崩れない運用基盤を作れます。

アカウント数が5～10を超えてきたタイミングでControl Towerの導入を検討する価値があります。OrganizationsとSCPで個別管理している状態からの移行も可能ですが、既存環境との整合性確認を丁寧に行うことが成功のポイントです。姉妹サイトLinuxMaster.JPでは、EC2上でのLinuxサーバー構築手順も詳しく解説しています。Control Towerで標準化されたアカウントにEC2を払い出す際の参考にしてください。