AWS Control Tower - 自動化されたガバナンスとランディングゾーン構築 ​

大企業では部門ごとに異なるAWSアカウントを使用するマルチアカウント環境が一般的ですが、アカウント数が増加すると統制管理が複雑になります。AWS Control Tower は、このような課題を解決するマルチアカウント環境の統制とガバナンスを自動化するサービスです。

ランディングゾーンという安全な基盤環境の自動構築、ガードレール（コントロール）による継続的な統制、Account Factory による標準化されたアカウント作成を通じて、大規模組織でのクラウド活用を安全かつ効率的に実現します。

Control Tower の基本アーキテクチャ ​

ランディングゾーンの構成要素 ​

ランディングゾーンとは、セキュリティとコンプライアンスのベストプラクティスに基づいて設計された、マルチアカウント環境の安全な土台のことです。従来は手動で何週間もかけて構築していた複雑な設定を、Control Tower が自動的に構築してくれます。

ランディングゾーンは以下の3つの主要構成要素で成り立っています：

  1. コアアカウント：組織全体の管理とセキュリティを担う専用アカウント群
  2. 組織単位（OU）：アカウントをグループ化し、異なるポリシーを適用するためのコンテナ
  3. ガードレール（コントロール）：すべてのアカウントに適用される統制ルール

コアアカウントの役割 ​

Control Tower は3つの特別なコアアカウントを自動作成し、それぞれが組織全体の異なる側面を管理します。これにより責任の分離と専門性の向上を実現しています。

管理アカウント（Management Account） ​

管理アカウントは、組織全体のコントロールセンターとして機能します。「司令塔」の役割を担い、すべてのアカウントとポリシーを統括管理します。

主な責任領域：

  • Control Tower の運用管理：ランディングゾーンの設定変更、新しいコントロール（ガードレール）の適用、Account Factory によるアカウント作成プロセスの管理を行います
  • 組織レベルの統制：AWS Organizations を通じた全アカウントの階層管理、Service Control Policies（SCP）によるアクセス制限、全社の AWS 利用料金の統合管理を担当します
  • セキュリティの最高責任：IAM Identity Center による従業員のアクセス管理、ルートユーザーレベルの緊急対応、セキュリティインシデント時の最終決定権を持ちます

重要な特徴：管理アカウントには予防的コントロールが適用されないため、緊急時でも管理者が必要な操作を実行できます。

ログアーカイブアカウント ​

ログアーカイブアカウントは、組織全体の「記録保管庫」として機能します。すべてのアカウントで発生する操作履歴やシステムログを一箇所に集約し、長期間安全に保存します。

なぜ専用アカウントが必要か：各部門のアカウントにログを保存すると、担当者が意図的または誤ってログを削除してしまう可能性があります。専用アカウントに分離することで、ログの完全性と改ざん防止を確保できます。

主な機能：

  • 中央ログ収集：全アカウントのCloudTrail（操作履歴）、AWS Config（設定変更履歴）、VPC Flow Logs（ネットワーク通信ログ）を自動収集します
  • 長期保存とコスト最適化：S3 Intelligent-Tiering により使用頻度に応じた自動的なストレージクラス変更、Glacier を活用した長期アーカイブ、法的要件（例：7年保存）に応じた保持期間設定を行います

監査アカウント ​

監査アカウントは、組織全体の「セキュリティ監視センター」として機能します。すべてのアカウントのセキュリティ状況を一元的に監視し、問題の早期発見と対応を行います。

なぜ専用アカウントが必要か：監査機能を各部門のアカウントに置くと、監査される側が監査システムを無効化してしまうリスクがあります。独立した監査アカウントにより、客観的で継続的な監視を保証できます。

主な機能：

  • リアルタイムセキュリティ監視：AWS Security Hub で組織全体のセキュリティ状況を統合管理し、GuardDuty による脅威検出、AWS Config Rules による設定監視を一元化します
  • コンプライアンス管理：定期的な監査レポートの自動生成、各種規制（SOX法、ISO27001等）への準拠状況の可視化、発見された問題の是正措置進捗をトラッキングします

コントロール（ガードレール）による統制管理 ​

コントロールの分類と実装タイプ ​

Control Tower のガードレール（コントロール）は、予防的統制、検出的統制、プロアクティブ統制の3つの実装タイプを提供します。

  • 予防的コントロール（Preventive）: リソース作成や操作を事前に制限（Service Control Policies使用）
  • 検出的コントロール（Detective）: 設定変更や非準拠状態を事後検出（AWS Config Rules使用）
  • プロアクティブコントロール（Proactive）: リソース作成時に要件をチェックし、非準拠リソースの作成を防止

予防的ガードレール（Preventive Guardrails）の詳細 ​

予防的ガードレールは、違反行為を実行前に防ぐことに特化したコントロールです。AWS Organizations の Service Control Policy（SCP）を使用して実装され、ユーザーやアプリケーションが危険な操作を実行しようとした時点で、その操作を即座にブロックします。

主な特徴：

  • 事前ブロック機能：危険な操作を実行前の段階で阻止するため、インシデント発生を根本的に防ぎます
  • ステータス：Enforced（適用済み）または Not Enabled（無効）の2状態のみ
  • 適用範囲：全AWSリージョンで利用可能なため、グローバルな統制が可能
  • 即時効果：SCPによる制御のため、ポリシー適用後は即座に効力を発揮します

実装の仕組み：

予防的ガードレールは Service Control Policy（SCP）を使用して実装されます。例えば、「S3バケットのパブリック読み取り禁止」のガードレールは、以下のような制御を行います：

  • S3バケットにパブリックアクセスを許可するポリシー設定を拒否
  • パブリックACL（Access Control List）の設定を拒否
  • HTTPSを使用しない非暗号化通信での設定変更を拒否

これらの制御により、開発者がうっかりS3バケットを公開設定にしようとしても、そのAPI呼び出しが実行前にブロックされます。結果として、機密データの意図しない公開を技術的に防止できます。

検出的ガードレール（Detective Guardrails）の詳細 ​

検出的ガードレールは、違反が発生した後に検出・通知することに特化したコントロールです。AWS Config ルールを使用して実装され、定期的にリソースの設定を評価し、問題を発見した時点で管理者に通知します。

主な特徴：

  • 事後検知システム：リソースが作成された後、または設定が変更された後に、その状態をチェックします
  • ステータス：Clear（問題なし）、In Violation（違反中）、Not Enabled（無効）の3状態で管理
  • 適用範囲：AWS Control Tower がサポートするリージョンのみ（全リージョンではない点に注意）
  • 継続的監視：定期的な評価により、環境の変化を継続的に追跡します

検出例：

  • MFA未設定のIAMユーザー検出：多要素認証が有効になっていないアカウントを特定し、セキュリティリスクを可視化します
  • パブリックアクセス可能なS3バケット検出：外部から読み取り可能な状態になっているバケットを発見し、データ漏洩リスクを警告します
  • 暗号化されていないEBSボリューム検出：暗号化が有効になっていないストレージを特定し、コンプライアンス違反を報告します
  • 過度な権限を持つIAMロール検出：最小権限の原則に反する広範な権限を持つロールを発見します

予防的と検出的の違い ​

項目予防的（Preventive）検出的（Detective）
目的違反行為の防止違反の検出・通知
実装技術SCP（Service Control Policy）AWS Config Rules
動作タイミング実行前（リアルタイム）実行後（定期評価）
適用範囲全アカウント（登録済み・未登録問わず）登録済みアカウントのみ
リージョン対応全AWSリージョンControl Tower対応リージョン
対応方法操作を自動ブロックアラート通知と是正推奨
評価結果Enforced / Not EnabledClear / In Violation / Not Enabled

使い分けの考え方：

  • 予防的コントロールは、「絶対に起きてはならない」重大なセキュリティ違反（機密データの公開、重要ログの削除等）を防ぐために使用します
  • 検出的コントロールは、「望ましくないが一時的に許容される可能性がある」状況（暗号化未設定、MFA未適用等）を監視し、改善を促すために使用します

必須コントロール（Mandatory Controls） ​

必須コントロールは、Control Tower 環境において無効化できない基本的なセキュリティ統制です。AWS が長年の運用経験から「これがないと危険」と判断した最低限の防御策で、組織の基盤を重大な脅威から守ります。

コントロールタイプの内訳： 必須コントロールの大半は予防的（Preventive）コントロールで構成されており、危険な操作を事前に阻止します。ただし、以下の3つの重要な検出的コントロールも含まれています：

  1. Log Archive アカウントのパブリック読み取り検出：ログの不正閲覧を監視
  2. Log Archive アカウントのパブリック書き込み検出：ログの改ざんを監視
  3. Security OU 配下の CloudTrail 有効化検出：監査証跡の継続性を確認

これらの検出的コントロールは、ログの完全性とセキュリティ監視の継続性という「後から気づく必要がある」要素を監視するために設けられています。

セキュリティ基盤の保護 ​

ログ保護の重要性：サイバー攻撃や内部不正の証拠となる操作履歴が改ざん・削除されると、インシデントの原因究明や法的対応が困難になります。

  • CloudTrail設定変更の禁止：誰がいつ何をしたかの記録システムを保護し、証跡の改ざんを防ぎます
  • S3バケット公開読み取り・書き込みの禁止：機密データの意図しない漏洩や外部からの悪意あるファイル投入を防止します

多要素認証（MFA）の強制：パスワードだけでは突破される可能性があるため、追加の認証要素で重要なアカウントを保護します。

  • ルートユーザーMFA必須：全権限を持つ最高権限アカウントの乗っ取りを防ぎます
  • 特権操作時MFA必須：重要なシステム変更時に本人確認を強化します

ネットワーク保護：外部からの不正アクセスや設定ミスによるセキュリティ侵害を防ぎます。

  • デフォルトVPC使用禁止：セキュリティ設定が甘いデフォルト環境での作業を禁止し、適切に設計されたネットワークの使用を強制します
  • SSH/RDPパブリックアクセス制限：インターネットから直接サーバーにアクセスできる危険な設定を防ぎます

推奨コントロールは、AWS のベストプラクティスに基づく追加的なセキュリティ統制です。必須コントロールでは最低限の防御しかできないため、より堅牢なセキュリティを実現するために強く推奨されています。組織の判断で無効化することも可能ですが、セキュリティレベルの向上のために有効化が推奨されます。

コントロールタイプの特徴： 推奨コントロールの大部分は検出的（Detective）コントロールで構成されています。これは、セキュリティのベストプラクティスを「強制」するのではなく、「監視して改善を促す」アプローチを取っているためです。デフォルトでは無効になっているため、組織のセキュリティポリシーに応じて段階的に有効化できます。

セキュリティベストプラクティス ​

データ暗号化の重要性：デフォルトでは暗号化されていないAWSリソースが多く、データ漏洩時の被害を最小化するために暗号化は必須の対策です。

  • EBS暗号化の有効化：サーバーのディスクが物理的に盗まれても、データを読み取れないようにします
  • S3バケット暗号化の有効化：クラウドストレージ上のファイルを暗号化し、不正アクセス時のデータ保護を実現します
  • RDS暗号化の有効化：データベース内の機密情報（個人情報、財務データ等）を暗号化して保護します

アクセス制御の検出：設定ミスや過度な権限付与により生じるセキュリティリスクを早期発見します。

  • 不要なインターネットゲートウェイ検出：外部接続が不要なプライベート環境に誤って外部アクセス経路が作られていないかをチェックします
  • パブリックサブネット内のデータベース検出：データベースがインターネットから直接アクセス可能な危険な配置になっていないかを監視します
  • 過度な権限のIAMポリシー検出：必要以上に広い権限を持つユーザーやロールを特定し、権限の最小化を促します

選択的コントロール（Elective Controls） ​

カスタマイズ可能な統制 ​

選択的コントロールは、組織の特定要件に合わせて有効化できるオプションのコントロールです。すべての組織に必要とは限らないが、特定の業界規制や企業ポリシーに対応するために用意されています。

コントロールタイプの特徴： 選択的コントロールには予防的（Preventive）と検出的（Detective）の両方が含まれています。これにより、組織は「事前に防ぐ」統制と「事後に検出する」統制を要件に応じて柔軟に選択できます。必須・推奨コントロールと同様に、デフォルトでは無効になっており、組織の判断で有効化します。

なぜオプションなのか：組織によって業界規制、技術要件、運用ポリシーが大きく異なるため、一律に適用すると業務に支障をきたす可能性があります。そのため必要な組織のみが選択的に有効化できる仕組みになっています。

リソース制限の例：

  • 特定インスタンスタイプの制限：コスト管理のため高額なインスタンス（GPU搭載型等）の使用を特定部門に限定します
  • 利用可能AWSリージョンの制限：データ主権要件やレイテンシ要件により、特定地域でのみリソース作成を許可します
  • ストレージ容量制限：予算管理や誤操作防止のため、部門ごとに使用可能な容量上限を設定します

運用統制の例：

  • 特定時間帯でのリソース作成制限：本番環境への影響を避けるため、営業時間外のみシステム変更を許可します
  • 承認されたAMIのみ使用許可：セキュリティ検証済みのOSイメージのみ使用を許可し、脆弱性のあるイメージの利用を防ぎます
  • タグ付け要求の強制：コスト管理や運用管理のため、すべてのリソースに部門名や用途の情報付与を義務化します

ガードレールの自動適用メカニズム ​

自動適用されるガードレール ​

Control Tower では、一部のガードレールが自動的に適用され、追加のガードレールは明示的な設定が必要になります。この違いを理解することは、効果的なガバナンス設計の基礎となります。

必須コントロールの自動適用：

必須コントロール（Mandatory Controls）は、Control Tower のランディングゾーンを設定した時点で自動的に適用されます。これらは無効化できず、組織の基本的なセキュリティとコンプライアンスを保証します。

  • 全アカウントへの適用：予防的な必須コントロールは、Control Tower に登録済みか未登録かに関わらず、組織内のすべてのAWSアカウントに適用されます
  • 登録済みアカウントへの適用：検出的な必須コントロールは、Control Tower に登録されたアカウントのみに適用され、継続的に監視されます

具体例：

  • Root ユーザーのアクセスキー作成を禁止（予防的）
  • 外部への CloudTrail ログ配信を禁止（予防的）
  • S3 バケットの読み取りアクセス設定の検出（検出的）
  • MFA なしでの Console アクセスを禁止（予防的）

OUレベルでのガードレール継承 ​

Organizational Unit（OU）階層でガードレールを有効化すると、その設定は自動的に子OUと配下のアカウントに継承されます。この継承メカニズムにより、大規模な組織でも一貫したガバナンスを効率的に実現できます。

継承の仕組み：

  • 親OUでの設定：親OUで有効化されたガードレールは、その配下のすべての子OUとアカウントに自動的に適用されます
  • 予防的コントロール：登録・未登録に関わらず、組織内の全アカウントに即座に効力を発揮します
  • 検出的コントロール：Control Tower に登録済みのアカウントのみを対象に監視が行われます

実用例：

Root OU に「S3 バケット暗号化必須」のガードレールを適用すると、Production OU、Development OU、Sandbox OU など、すべての子OUとその配下のアカウントに自動的に適用されます。

明示的な設定が必要なガードレール ​

推奨コントロールと選択的コントロール：

これらのガードレールはデフォルトでは無効になっており、組織のセキュリティポリシーに応じて明示的に有効化する必要があります。

  • Strongly Recommended Controls（推奨コントロール）：AWS のベストプラクティスに基づくが、すべての組織に必須とは限らない統制です
  • Elective Controls（選択的コントロール）：特定の業界規制や企業ポリシーに対応するためのオプション統制です

有効化の方法：

  1. Control Tower コンソールから手動で有効化：OU または個別アカウントに対して、必要なガードレールを選択して有効化します
  2. Account Factory for Terraform（AFT）による自動化：標準化されたガードレール設定をコード化し、新規アカウント作成時に自動適用します

ガードレール適用の実際の動作パターン ​

Control Tower ランディングゾーン設定時：

初期セットアップ時に自動的に行われる設定です。

  • ✅ 必須の予防的コントロール → 全アカウントに即座に適用
  • ✅ 必須の検出的コントロール → 登録済みアカウントに適用
  • ❌ 推奨コントロール → 手動またはAFTによる設定が必要
  • ❌ 選択的コントロール → 手動またはAFTによる設定が必要

Account Factory でアカウント作成時：

新規アカウントが作成される際の自動処理内容です。

  • ✅ Control Tower への自動登録（Enrollment）
  • ✅ 必須コントロールの自動適用
  • ✅ 指定された OU への配置と OU レベルのガードレール継承
  • 🔧 追加の推奨・選択的コントロールは、AFT や手動設定が必要

ガードレール適用の比較表 ​

ガードレール種類自動適用明示的設定要適用対象有効化タイミング
必須・予防的✅❌全アカウントLanding Zone設定時
必須・検出的✅❌登録済みアカウントアカウント登録時
推奨❌✅明示的設定が必要手動またはAFT
選択的❌✅明示的設定が必要手動またはAFT
OU継承✅❌OU配下全体親OU設定時

重要な理解ポイント：

  • 基本的なガバナンス（必須コントロール）は Control Tower が自動的に適用します
  • 追加のセキュリティ強化（推奨・選択的コントロール）は組織の判断で明示的に設定します
  • OU階層でのガードレール継承により、大規模環境でも効率的な管理が可能です
  • **Account Factory for Terraform（AFT）**を活用することで、追加ガードレールの適用も標準化・自動化できます

Account Factory による標準化 ​

セルフサービス型アカウント作成 ​

従来の課題：手動でAWSアカウントを作成すると、担当者によって設定内容にばらつきが生じ、セキュリティ設定の漏れや標準から外れた設定が発生しがちでした。また、アカウント作成に数日から数週間かかることも珍しくありませんでした。

Account Factory の解決策：Account Factory は、これらの課題を解決する「アカウント作成の自動化工場」です。あらかじめ定義されたテンプレートに基づいて、セキュリティ設定やネットワーク設定が統一されたAWSアカウントを短時間で作成できます。

セルフサービスの利点：各部門の担当者が自分でアカウント作成を申請でき、承認されれば自動的に標準準拠のアカウントが提供されます。IT部門の負荷軽減と、事業部門の迅速なクラウド活用を両立できます。

アカウントテンプレート設計 ​

標準ベースライン設定 ​

ベースライン設定とは、新しく作成されるすべてのアカウントに自動適用される「安全な初期設定」のことです。これにより、アカウント作成直後から組織の標準に準拠した安全な環境を利用できます。

ネットワーク構成の標準化： アカウント作成時に安全なネットワーク環境を自動構築します。

  • デフォルトVPC削除：AWSが提供するデフォルト環境はセキュリティ設定が甘いため削除し、組織の要件に合わせて設計された専用VPCを作成します
  • 適切なサブネット設計：インターネットアクセスが必要なリソース用のパブリックサブネットと、機密性の高いシステム用のプライベートサブネットを適切に分離します
  • 接続最適化：Transit Gateway による他のアカウントとの安全な接続、VPC Endpoints によるAWSサービスへの高速アクセス、適切なDNS設定を自動構成します

セキュリティ設定の自動化： 作成直後からセキュリティ監視が機能する環境を提供します。

  • IAM権限の適切な設計：アカウント間での安全な権限委譲（Cross-account roles）、AWSサービスが必要とする最小権限の自動付与（Service-linked roles）、管理者権限の適切な制限を実装します
  • 包括的監視の有効化：CloudTrail（操作履歴）、Config（設定変更監視）、GuardDuty（脅威検出）、Security Hub（セキュリティ状況統合）をすべて有効化し、作成直後から監視体制を確立します

カスタマイゼーション要件 ​

組織固有の要件対応 ​

標準のベースライン設定だけでは、すべての組織の要件を満たすことはできません。業界規制、技術的制約、運用ポリシーに応じて、Account Factory のテンプレートをカスタマイズする必要があります。

業界規制への対応： 法的要件を満たすための追加設定が必要な業界向けのカスタマイゼーションです。

  • HIPAA準拠設定：医療業界で患者データを扱う組織向けに、PHI（Protected Health Information）の保護要件を満たす暗号化とアクセス制御を実装します
  • PCI DSS準拠設定：クレジットカード情報を処理する組織向けに、カード会員データの保護基準を満たすネットワーク分離と監視を設定します
  • GDPR準拠設定：EU市民の個人データを扱う組織向けに、データ主体の権利保護とデータ処理の透明性を確保する設定を適用します

技術的制約への対応： 組織の技術的要件や制約に応じたカスタマイズです。

  • 特定リージョンでの展開：レイテンシ要件やデータ主権要件により、使用可能なAWSリージョンを制限します
  • カスタムAMI使用：組織独自のセキュリティ設定やソフトウェアを含む、検証済みのOSイメージのみを使用許可します
  • 専用インスタンス要求：規制要件やセキュリティポリシーにより、他の顧客と物理ハードウェアを共有しない専用インスタンスの使用を強制します

運用ポリシーへの対応： 組織の運用プロセスや既存ツールとの統合要件です。

  • 監視ツール統合：Datadog、New Relic等の既存監視ツールと連携し、統一されたダッシュボードで監視できるよう設定します
  • バックアップポリシー：組織のRPO/RTO要件に応じた自動バックアップスケジュールと復旧手順を標準設定に組み込みます
  • パッチ管理設定：Systems Manager Patch Manager を活用した定期的なセキュリティパッチ適用を自動化します

Account Factory for Terraform（AFT）によるガードレール管理 ​

Account Factory for Terraform（AFT）を活用することで、ガードレールの適用を Infrastructure as Code（IaC）として管理し、新規アカウント作成時に標準化されたガードレール設定を自動適用できます。

AFTでの自動処理：

AFTが新規アカウント作成時に自動的に実行する処理です。

  • ✅ Control Tower への登録（Enrollment）
  • ✅ 必須コントロールの自動適用
  • ✅ 指定されたOUへの配置

AFTで明示的に設定する項目：

組織の要件に応じてコード化する必要がある設定です。

  • 🔧 推奨コントロールの有効化
  • 🔧 選択的コントロールの有効化
  • 🔧 カスタムガードレールの適用

Global Customizations によるOUレベルのガードレール設定：

すべてのアカウントまたは特定のOUに適用するガードレールを、Terraformコードとして定義します。Gitリポジトリで管理されるTerraformファイルに、コントロールIDとターゲットOU IDを指定することで、OUレベルでのガードレール適用を自動化できます。

設定例として、以下のようなパターンが実現できます：

  • Production OU：MFA必須、セキュリティグループ制限、CloudTrail変更禁止などの厳格なコントロール
  • Development OU：基本的な暗号化要件と監視設定
  • 全OU共通：S3バケットバージョニング、ルートアクセスキー禁止などの基本ガバナンス

Account Customizations による個別アカウント設定：

特定のアカウント要件に応じた追加のガードレール設定を、Lambda関数で実装します。アカウント作成後のカスタマイゼーションパイプラインで自動実行され、以下のような柔軟な制御が可能です：

  • 環境別の追加コントロール：本番環境アカウントには追加のセキュリティコントロール、開発環境には基本コントロールのみ
  • 部門別のポリシー適用：財務部門には監査強化、開発部門にはイノベーション重視の柔軟な設定
  • コンプライアンス要件対応：HIPAA、PCI DSS などの特定規制に準拠したコントロールセット

AFTによるガードレール管理の利点：

  • 標準化：すべてのアカウントに一貫したガードレール設定を適用できます
  • 自動化：新規アカウント作成時に手動作業なしでガードレールが適用されます
  • バージョン管理：GitによるIaC管理により、ガードレール設定の変更履歴を追跡できます
  • 監査可能性：コードレビュープロセスを通じて、ガードレール変更の承認管理が可能です
  • 再現性：災害復旧時や環境再構築時に、同じ設定を確実に再現できます

AFT以外のガバナンス拡大方法 ​

複数の選択肢によるガバナンス強化 ​

Account Factory for Terraform（AFT）は強力なツールですが、組織のガバナンスを拡大する唯一の方法ではありません。要件の複雑さ、技術スタック、組織の成熟度に応じて、より適切な代替手段や補完的なアプローチが存在します。

AWS Organizations による直接的なガバナンス ​

Service Control Policies（SCP）：

SCPは、組織全体またはOU単位で即座にアクセス制御を実装できる最も強力な予防的統制メカニズムです。Control Tower のガードレールに含まれない独自の制御を追加できます。

主な利用シーン：

  • 本番環境での危険な操作制限：特定の管理者ロール以外によるEC2インスタンス削除やRDSデータベース削除を禁止
  • リージョン制限の実装：データ主権要件により、特定リージョン（例：日本国内のみ）でのリソース作成に制限
  • サービス利用制限：開発環境でのコスト管理のため、GPU搭載インスタンスなど高額サービスの利用を禁止

Tag Policies（タグポリシー）：

組織全体で一貫したタグ付けルールを強制し、コスト配分や運用管理を効率化します。

実装例：

  • 必須タグの定義：Environment（環境）、Team（チーム）、CostCenter（コストセンター）を全リソースに必須化
  • 許可値の制限：Environment タグは "Production"、"Development"、"Staging" のみ許可
  • 適用リソースの指定：EC2インスタンス、S3バケット、RDSデータベースなど重要リソースに限定

Backup Policies（バックアップポリシー）：

組織レベルで統一されたバックアップ戦略を自動実施します。

設定パターン：

  • 環境別バックアップ頻度：本番環境は毎日、開発環境は週次
  • リージョン横断バックアップ：災害対策のため複数リージョンにバックアップコピー
  • 保持期間の自動管理：規制要件に応じた自動削除（例：7年保持後削除）

AWS Config Organizations による監視強化 ​

組織レベルでの Config Rules 展開：

AWS Config の評価ルールを組織全体に一括展開し、一貫したコンプライアンス監視を実現します。Control Tower の検出的ガードレールを補完する追加ルールを設定できます。

活用例：

  • カスタムセキュリティ要件：組織独自のセキュリティ基準（例：特定ポートの使用禁止）を全アカウントで監視
  • コスト最適化の監視：未使用のElastic IP、停止中のEC2インスタンスなどの無駄を検出
  • ライセンスコンプライアンス：特定ソフトウェアのライセンス数を超える使用を検出

Conformance Packs の一括展開：

複数の Config Rules をセットにしたコンプライアンスパッケージを、組織全体に展開できます。

標準パック例：

  • Operational Best Practices for PCI DSS：クレジットカード業界のセキュリティ基準
  • Operational Best Practices for HIPAA：医療情報保護法の要件
  • AWS Foundational Security Best Practices：AWS推奨のセキュリティ基準

Systems Manager による運用自動化 ​

Multi-Account Automation（マルチアカウント自動化）：

複数のアカウントに対して、運用タスクを自動実行できます。Control Tower が「作成時の設定」を担当するのに対し、Systems Manager は「継続的な運用」を自動化します。

実装シナリオ：

  • セキュリティベースライン適用：新規アカウント作成後に、CloudTrail、GuardDuty、Security Hub を自動有効化
  • 定期的なセキュリティチェック：週次でセキュリティ設定を評価し、ドリフト（設定逸脱）を検出
  • インシデント対応の自動化：セキュリティ違反検出時に、該当リソースを自動隔離

State Manager Associations（状態管理）：

組織全体のEC2インスタンスやオンプレミスサーバーに対して、継続的な設定管理を実施します。

管理対象：

  • パッチ管理：OSやアプリケーションのセキュリティパッチを定期的に自動適用
  • ソフトウェアインベントリ：インストールされているソフトウェアのバージョンを追跡し、脆弱性を検出
  • 設定ドリフト検出：サーバー設定が標準から逸脱した場合に自動修正

CloudFormation StackSets による標準化 ​

組織全体へのリソース一括展開：

CloudFormation テンプレートを使用して、複数のアカウントとリージョンに標準化されたリソースを展開します。Control Tower Account Factory が「アカウント全体」を作成するのに対し、StackSets は「特定のリソースセット」を展開します。

典型的な使用例：

  • セキュリティベースラインリソース：全アカウントに CloudTrail、Config、GuardDuty を統一設定で展開
  • ネットワーク基盤：標準化されたVPC、サブネット、セキュリティグループを自動作成
  • モニタリング基盤：CloudWatch ダッシュボード、アラーム、SNSトピックを一括設定

自動デプロイ機能：

新しいアカウントが組織に追加されると、自動的にStackSetが展開される機能により、手動作業を排除できます。

サードパーティツールとの統合 ​

Terraform Cloud/Enterprise：

AFTと同様にTerraformベースですが、より柔軟なマルチアカウント管理が可能です。AWS専用ではないため、マルチクラウド環境に適しています。

AFTとの違い：

  • 適用範囲：AWS以外のクラウド（Azure、GCP）も同時管理可能
  • ワークフロー：Terraform Cloudの豊富なワークフロー機能（承認プロセス、コスト見積もり等）
  • 学習曲線：Terraformの深い知識が必要

Policy as Code ツール（Checkov、OPA等）：

コード化されたインフラに対して、作成前にポリシー違反をチェックします。

検証内容：

  • セキュリティ違反：暗号化未設定、パブリックアクセス許可などを検出
  • コスト最適化：過剰なインスタンスサイズ、不要なリソースを指摘
  • ベストプラクティス：AWS推奨の設定からの逸脱を警告

ガバナンス手法の比較 ​

手法複雑度適用範囲リアルタイム制御カスタマイズ性学習コスト主な用途
Organizations SCP低全組織✅ 即座中低アクセス制限
Tag/Backup Policy低全組織✅ 即座低低タグ統制・バックアップ
Config Organizations中全組織❌ 定期評価中中コンプライアンス監視
Systems Manager中選択的⚡ 実行時高中運用自動化
StackSets中選択的❌ デプロイ時高中リソース標準化
AFT高選択的❌ 作成時最高高複雑なアカウント作成
Terraform Cloud高任意❌ 適用時最高高マルチクラウド管理

使い分けの指針 ​

シナリオ別の推奨アプローチ：

  1. 即座の制御が必要な場合 → Organizations SCP

    • 例：本番環境での危険な操作を即座に阻止したい

  2. コンプライアンス監視が目的 → Config Organizations

    • 例：全アカウントでセキュリティ設定の遵守状況を継続監視したい

  3. 運用作業の自動化 → Systems Manager

    • 例：定期的なパッチ適用やセキュリティ設定の修正を自動化したい

  4. 標準リソースの展開 → CloudFormation StackSets

    • 例：全アカウントに共通のセキュリティベースラインを展開したい

  5. 複雑なアカウント作成 → AFT

    • 例：部門ごとに異なる複雑なカスタマイゼーションが必要

  6. マルチクラウド環境 → Terraform Cloud

    • 例：AWS、Azure、GCPを統一的に管理したい

重要な理解ポイント：

  • AFTは「高度なカスタマイゼーションが必要な場合の選択肢」であり、すべての状況で最適とは限りません
  • よりシンプルな要件であれば、Organizations の標準機能や StackSets の方が導入・運用が容易です
  • 複数の手法を組み合わせることで、より強固で柔軟なガバナンス体制を構築できます
  • 組織の成熟度と要件の複雑さに応じて、段階的にガバナンスを強化していくアプローチが推奨されます

Control Tower とAWS Organizations の統合 ​

既存組織への適用 ​

段階的移行戦略 ​

既存アカウント統合 ​

Enroll Account プロセス ​

yaml
アカウント統合手順:
  事前準備:
    - 既存設定の評価
    - 競合する設定の特定
    - 移行計画の策定
  
  統合実行:
    - Control Tower への登録
    - ベースライン設定適用
    - ガードレール適用
  
  事後確認:
    - 機能検証
    - セキュリティ確認
    - 運用テスト

Security Hub との統合 ​

中央セキュリティ監視 ​

組織全体のセキュリティ状況可視化 ​

自動修復プロセス ​

インシデント対応の自動化 ​

yaml
自動修復例:
  セキュリティグループ違反:
    検出: 不適切なインバウンドルール
    対応: ルールの自動削除
    通知: セキュリティチームへアラート
  
  暗号化未対応リソース:
    検出: 暗号化されていないS3バケット
    対応: デフォルト暗号化の有効化
    通知: リソース所有者への通知
  
  過度な権限:
    検出: 広範囲な権限を持つIAMロール
    対応: 権限の一時停止
    通知: 管理者への承認要求

運用とメンテナンス ​

Control Tower ダッシュボード ​

ガバナンス状況の可視化 ​

yaml
ダッシュボード機能:
  組織概要:
    - アカウント数と状態
    - OU構造の可視化
    - ガードレール適用状況
  
  コンプライアンス監視:
    - 非準拠アカウントの特定
    - 是正措置の進捗
    - コンプライアンス傾向分析
  
  アカウント健全性:
    - セキュリティスコア
    - 設定ドリフトの検出
    - 推奨アクションの提示

継続的改善プロセス ​

ガバナンスの最適化 ​

トラブルシューティングと最適化 ​

一般的な問題と解決策 ​

コントロール適用の問題 ​

Control Tower 運用中によく発生する問題とその対処法を、具体的な状況と併せて説明します。

コントロール適用失敗発生状況：既存のAWSアカウントをControl Tower に統合する際に最も多く発生します。例えば、すでに設定されているIAMロールやS3バケットポリシーが、新しく適用しようとするコントロールと矛盾している場合です。 対処法：一度にすべてのコントロールを適用せず、段階的に導入し、競合する既存設定を事前に調整または削除します。

Account Factory エラー
発生状況：新しいアカウント作成時にIAM権限が不足していると発生します。特に、管理アカウントの権限設定が不完全な場合や、Organization の設定が適切でない場合に起こります。 対処法：Account Factory に必要な権限（AWSControlTowerServiceRolePolicy等）が適切に付与されているかを確認し、不足している権限を追加します。

ログアーカイブ容量超過発生状況：大規模組織では数百のアカウントから大量のログが集約されるため、ログアーカイブアカウントのS3容量が急激に増加し、コストが予想以上に高くなる場合があります。 対処法：S3ライフサイクルポリシーを設定し、古いログを自動的に安価なストレージクラス（IA、Glacier）に移動させることで、コストを最適化します。

パフォーマンス最適化 ​

大規模環境での運用考慮事項 ​

組織の成長とともにアカウント数が増加すると、Control Tower の各機能にも負荷がかかり、パフォーマンスや安定性に影響する場合があります。

Account Factory の最適化： 数百のアカウントを管理する大規模組織では、同時に多数のアカウント作成要求が発生する可能性があります。

  • 並列アカウント作成の制限：AWS API の制限により、同時に作成できるアカウント数には上限があるため、順次処理のキューイング機能を活用します
  • リソース作成の最適化：アカウント作成時の自動設定プロセスを効率化し、作成時間を短縮します
  • エラー処理の強化：一時的なAPI制限やネットワーク問題によるエラーに対する自動リトライ機能を強化します

コントロール評価の負荷分散： 数千のリソースに対するコンプライアンス評価が集中すると、システム負荷が高くなります。

  • Config Rules の最適化：評価対象リソースを絞り込み、重要度の高いリソースを優先的にチェックします
  • 評価頻度の調整：重要なリソースは頻繁に、変更頻度の低いリソースは定期的にチェックするよう頻度を調整します
  • リソース負荷の分散：ピーク時間を避けた評価スケジューリングにより、システム負荷を分散します

ログ管理の効率化： 大量のログデータによるコストと性能への影響を最小化します。

  • ログ転送の最適化：重要度に応じたログの優先度設定と、転送タイミングの最適化を行います
  • 圧縮と保存効率：S3での保存時にgzip圧縮を活用し、ストレージコストを削減します
  • アクセス頻度に応じた階層化：頻繁にアクセスされるログは高速ストレージに、古いログは低コストストレージに自動移動させます

まとめ ​

AWS Control Tower は、マルチアカウント環境における自動化されたガバナンスプラットフォームです。ランディングゾーンの構築、コントロール（ガードレール）による継続的統制、Account Factory による標準化を通じて、大規模組織でのAWS活用を安全かつ効率的に実現します。既存環境への段階的適用、継続的な改善、適切な運用により、組織のクラウドガバナンス要件を効果的に満たすことができます。

引用元：