AWS Control Tower

AWS Control Tower は、ベストプラクティスに沿ったマルチアカウント環境（ランディングゾーン）を自動で構築し、ガードレールによって継続的に統制するためのマネージドサービスです。Organizations や IAM Identity Center、Config、CloudTrail といった複数のサービスを個別に組み合わせて手作業でガバナンス基盤を組み上げる代わりに、Control Tower はそれらを束ねた「型」を用意し、初期構築と日々の統制を肩代わりします。マルチアカウント戦略を素早く・安全に立ち上げたい組織にとっての出発点になります。

解決する課題

マルチアカウント環境を一から自前で設計しようとすると、Organizations の OU 設計、SCP の作成、ログ集約アカウントの分離、CloudTrail の組織証跡、Config の組織展開、シングルサインオンの設定などを正しい順序で漏れなく組み合わせる必要があり、専門知識と工数を大量に要します。さらに、いったん構築しても設定のドリフトを継続的に検出し続ける仕組みがなければ、時間とともにガバナンスは形骸化します。

AWS Control Tower は次のような課題を解決します。

• マルチアカウントのベストプラクティス構成を、設計・構築の手間をかけずに素早く立ち上げたい
• 環境全体に共通のガードレールを適用し、逸脱を継続的に検出・防止したい
• 新規アカウントの払い出しを標準化し、安全で再現性のある形で自動化したい
• ログ集約や監査用のアカウントを分離し、組織全体の操作証跡を一元的に集めたい

主要概念と用語

• ランディングゾーン（Landing Zone）: ベストプラクティスに沿って自動構築されるマルチアカウント環境の全体像。OU、共有アカウント、ガードレール、ログ集約などがセットで用意される。
• コントロール（旧称ガードレール）: 環境へ適用する統制。望ましくない操作を止める予防、事後評価する発見、CloudFormationで展開前に検査するプロアクティブがある。
• 予防的コントロール（Preventive）: SCP・RCP・宣言型ポリシーなどで、禁止操作や必須の設定を事前に強制する。
• 発見的コントロール（Detective）: Configルールなどで既存リソースの逸脱を検知し、非準拠として報告する。
• プロアクティブコントロール（Proactive）: CloudFormationフックでプロビジョニング前にリソースプロパティを検査し、不適合な展開を止める。
• 必須（Mandatory）・強く推奨（Strongly recommended）・任意（Elective）: コントロールのガイダンス区分。ランディングゾーン4.0以降は必須コントロールも既定で有効化されないため、要件に応じて明示的に選ぶ。
• Account Factory: 標準化された設定でメンバーアカウントを払い出すためのテンプレート機能。ネットワークや既定設定を統一できる。
• 管理アカウント（Management Account）: ランディングゾーンを設定する Organizations の管理アカウント。
• ログアーカイブアカウント（Log Archive）: CloudTrail や Config のログを集約する専用の共有アカウント。
• 監査アカウント（Audit）: セキュリティ通知や横断的な監査アクセスを担う専用の共有アカウント。
• ドリフト（Drift）: Control Tower が想定する構成と実際の構成がずれた状態。Control Tower がこれを検出する。

仕様・制限・クォータ

Control Tower はマネージドな「型」であるがゆえの前提と制約があります。具体的な数値は変動するため、設計時は最新の公式ドキュメントで確認してください。

• Control Tower は内部で AWS Organizations を利用します。ランディングゾーンのセットアップは Organizations の管理アカウントから行います。
• セットアップ時に、ログアーカイブと監査という共有アカウントが自動的に作成され、専用の OU に配置されます。
• コントロールには予防・発見・プロアクティブの3つの動作区分があります。予防は SCP・RCP・宣言型ポリシー、発見は Config ルール、プロアクティブは CloudFormation フックなどで実装され、適用時点を分けて統制します。
• 利用できるリージョンや、ランディングゾーンが統制対象とするリージョンには範囲の指定があります。統制対象外のリージョンでの操作は Control Tower のガードレールの管轄外になる点に注意します。
• 既存の Organizations 環境の上に Control Tower を導入する場合、既存の OU やアカウントを取り込む手順があり、前提条件の確認が必要です。

内部の仕組み

横にスクロール

Control Tower はそれ自体が独立した巨大なエンジンというより、既存の AWS サービスをベストプラクティスに沿って組み合わせ、オーケストレーションするレイヤーです。ランディングゾーンを作成すると、Organizations 上に OU 構造が用意され、ログアーカイブと監査の共有アカウントが作成され、組織レベルの CloudTrail 証跡が有効化され、ログがログアーカイブアカウントへ集約され、IAM Identity Center によるシングルサインオンが構成されます。

コントロールは適用時点ごとに仕組みが異なります。予防的コントロールは Organizations の SCP・RCP や宣言型ポリシーなどで操作または設定を事前に制限し、発見的コントロールは Config ルールで作成済みリソースを継続評価します。プロアクティブコントロールは CloudFormation フックでプロビジョニング前のテンプレートを検査します。「実行前に制限」「作成前に検査」「作成後に検出」を要件に応じて組み合わせます。

Control Tower は自分が構築した構成が手作業などで書き換えられていないかを監視し、ずれを「ドリフト」として検出します。ドリフトが見つかった場合は、ランディングゾーンの更新・修復操作によって想定状態へ戻すことができます。これにより、初期構築だけでなく構成の維持まで含めたガバナンスが成立します。

設計パターン / ベストプラクティス

• 共有アカウント（ログアーカイブ・監査）には日常的なワークロードを置かず、用途を限定して強い権限の操作を局所化します。
• 管理アカウントは Control Tower とランディングゾーンの管理に専念させ、本番ワークロードや一般ユーザーを同居させないようにします。
• OU は組織図ではなく「適用したいガードレールの単位」で設計します。本番・非本番・サンドボックス・セキュリティといった環境ベースの分け方が扱いやすいです。
• 新規アカウントは Account Factory を通じて払い出し、ネットワークや既定設定を標準化して再現性を確保します。手動でのアカウント作成は避けます。
• ガイダンス区分を優先度の目安にし、必須を含む必要なコントロールを明示的に有効化します。限定 OU で影響を検証してから段階的に広げます。
• Control Tower が用意する標準のガードレールで足りない要件は、独自の SCP や Config ルールで補完します。

運用・監視

Control Tower のダッシュボードでは、登録済みアカウント、有効なガードレール、非準拠リソース、ドリフトの有無などを俯瞰できます。ガバナンスの実効性は、ここで非準拠やドリフトが放置されていないかを定期的に確認することで担保します。

組織レベルの CloudTrail 証跡はランディングゾーン構築時に有効化され、すべてのアカウントの API 操作がログアーカイブアカウントへ集約されます。メンバーアカウント側で証跡を無効化されても組織レベルの記録が残るため、改ざんに強い監査基盤になります。発見的ガードレールが非準拠を検知した際の通知は監査アカウントを軸に集約され、セキュリティチームが横断的に状況を把握できます。

ランディングゾーンには版（バージョン）があり、機能追加に追従するには更新操作が必要になることがあります。更新やガードレールの追加は影響範囲が大きいため、変更管理プロセスに乗せ、まず限定的な OU で影響を検証してから全体へ展開すると安全です。

コスト

AWS Control Tower 自体の利用に対する直接的な追加料金は発生しません。一方で、Control Tower が裏側で有効化する各サービスの利用料は通常どおり課金されます。具体的には、組織レベルの CloudTrail 証跡、発見的ガードレールを支える Config の構成記録とルール評価、集約されたログを保管する S3 のストレージなどがコストの主因になります。

そのため、コスト最適化の観点では「ガードレールをむやみに増やしすぎない」「ログの保管期間とライフサイクルを適切に設計する」といった配慮が効きます。とはいえ、ガバナンス基盤を自前で構築・運用する人的コストと比較すれば、標準化による省力化のメリットが大きいケースが多いです。

セキュリティ

Control Tower のセキュリティ設計の核は、責務に応じたアカウント分離と、予防・発見・プロアクティブという3つの適用時点を使い分けるコントロールです。ログアーカイブアカウントにログを集約することで証跡を一元化し、監査アカウントにセキュリティ通知と横断アクセスを集約することで、強い権限を持つ操作を限定された場所に閉じ込めます。

予防的コントロールは望ましくない操作や設定を事前に制限し、プロアクティブコントロールは CloudFormation での作成前に検査し、発見的コントロールは既存リソースの逸脱を検知します。ただし SCP を使う予防的コントロールは、Organizations と同様に管理アカウント内のプリンシパルへ適用されません。管理アカウントは特権的な存在として厳格に保護し、ルートユーザーには多要素認証を必須化して日常運用では使わないようにします。

Well-Architected の観点

• セキュリティ: 責務別のアカウント分離、予防・プロアクティブ・発見の多層統制、ログアーカイブへの証跡集約により、最小権限と多層防御を仕組みとして実現します。
• 運用上の優秀性: ランディングゾーンの自動構築と Account Factory による標準化された払い出し、ドリフト検出により、手作業と構成のばらつきを減らし、ガバナンスを継続的に維持できます。

試験で問われるポイント

関連サービス・比較

AWS Control Tower はマルチアカウントの「土台」である AWS Organizations の上に乗る、マネージドなガバナンスのフレームワークです。Organizations を直接操作すれば自由度高くすべてを自前で設計できますが、その分だけ正しく組み上げる責任も負います。Control Tower はベストプラクティスの型を提供し、初期構築と継続統制を肩代わりします。

ハンズオン / CLI例

Control Tower の初期セットアップはコンソールから行うのが基本ですが、ランディングゾーンの状態確認や有効なガードレール（コントロール）の一覧は CLI で確認できます。次の例は、ランディングゾーンと有効なコントロールを確認する流れの一部です。実行には管理アカウントの権限が前提です。

# ランディングゾーンの一覧と ARN を確認する
aws controltower list-landing-zones

# 指定したランディングゾーンの詳細とバージョン・ドリフト状態を取得する
aws controltower get-landing-zone \
  --landing-zone-identifier "arn:aws:controltower:ap-northeast-1:111122223333:landingzone/EXAMPLEID"

# 特定の OU に対して有効化されているコントロール（ガードレール）を一覧する
aws controltower list-enabled-controls \
  --target-identifier "arn:aws:organizations::111122223333:ou/o-exampleorg/ou-exampleouid"