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、共有アカウント、ガードレール、ログ集約などがセットで用意される。
• ガードレール（Guardrail / コントロール）: 環境に適用するガバナンスのルール。望ましくない操作を未然に防ぐ「予防的」と、逸脱を検知して通知する「発見的」がある。
• 予防的ガードレール（Preventive）: SCP として実装され、禁止された操作そのものを実行できないように上限を絞る。
• 発見的ガードレール（Detective）: Config ルールとして実装され、すでに存在するリソースの逸脱を検知して非準拠として報告する。
• 必須（Mandatory）・強く推奨（Strongly recommended）・任意（Elective）: ガードレールの推奨度の区分。必須ガードレールは常時有効化される。
• Account Factory: 標準化された設定でメンバーアカウントを払い出すためのテンプレート機能。ネットワークや既定設定を統一できる。
• 管理アカウント（Management Account）: ランディングゾーンを設定する Organizations の管理アカウント。
• ログアーカイブアカウント（Log Archive）: CloudTrail や Config のログを集約する専用の共有アカウント。
• 監査アカウント（Audit）: セキュリティ通知や横断的な監査アクセスを担う専用の共有アカウント。
• ドリフト（Drift）: Control Tower が想定する構成と実際の構成がずれた状態。Control Tower がこれを検出する。

仕様・制限・クォータ

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

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

内部の仕組み

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

ガードレールは内部的に 2 つの仕組みにマッピングされます。予防的ガードレールは Organizations の SCP として実装され、禁止された操作を実行できないように権限の上限を絞ります。発見的ガードレールは Config ルールとして実装され、すでに作成済みのリソースの状態を継続的に評価し、逸脱を非準拠として報告します。つまり「やらせない」は SCP、「ずれていないか見張る」は Config、という役割分担になっています。

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

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

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

運用・監視

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

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

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

コスト

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

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

セキュリティ

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

予防的ガードレール（SCP）は望ましくない操作そのものを禁止し、発見的ガードレール（Config ルール）は既存リソースの逸脱を検知します。ただし予防的ガードレールの実体は 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"