AWS マルチアカウント統制の設計力 - Organizations・Control Tower・SCP による組織ガバナンス
AWS Organizations、Control Tower、SCP (Service Control Policies) を中心とするマルチアカウント統制の仕組みを、Azure Management Groups と比較し、エンタープライズガバナンスの設計力の差を解説します。
マルチアカウント戦略はエンタープライズクラウドの基盤である
エンタープライズ規模のクラウド利用では、単一アカウントでの運用は現実的ではありません。開発環境と本番環境の分離、部門ごとのコスト管理、セキュリティ境界の確立、コンプライアンス要件への対応。これらの要求を満たすには、複数のアカウントを体系的に管理するマルチアカウント戦略が不可欠です。AWS は Organizations を基盤として、Control Tower による自動化されたランディングゾーンの構築、SCP による予防的ガードレールの適用、AWS Config による検出的ガードレールの実装という多層的なガバナンス体系を提供しています。この体系の成熟度が、エンタープライズ顧客が AWS を選択する大きな理由の一つです。
AWS Organizations と SCP による階層的統制
AWS Organizations は、複数の AWS アカウントを組織単位 (OU: Organizational Unit) の階層構造で管理するサービスです。OU はツリー構造で構成でき、企業の組織構造やワークロードの分類に合わせた柔軟な階層設計が可能です。SCP (Service Control Policies) は、OU またはアカウントに適用する予防的ガードレールです。SCP は IAM ポリシーとは異なり、アカウント内のすべてのプリンシパル (ルートユーザーを含む) に対して、許可される API アクションの上限を定義します。たとえば、特定のリージョン以外でのリソース作成を禁止する、特定のインスタンスタイプの起動を制限する、CloudTrail の無効化を防止するといったガードレールを、OU 単位で一括適用できます。SCP は拒否リスト方式と許可リスト方式の両方をサポートしており、組織のセキュリティポリシーに応じた柔軟な制御が可能です。OU の階層に沿って SCP が継承されるため、上位 OU で定義したポリシーが下位の OU とアカウントに自動的に適用されます。
Control Tower によるランディングゾーンの自動構築
AWS Control Tower は、マルチアカウント環境のベストプラクティスに基づいたランディングゾーンを自動構築するサービスです。ランディングゾーンとは、セキュリティ、ログ集約、アカウント管理の基盤が整備された、マルチアカウント環境の出発点です。Control Tower は Organizations、IAM Identity Center (旧 SSO)、CloudTrail、AWS Config、S3 を自動的に設定し、ログアーカイブアカウントと監査アカウントを含む基本構成を構築します。ガードレールは予防的 (SCP ベース) と検出的 (AWS Config Rules ベース) の 2 種類が提供され、必須・強く推奨・選択的の 3 段階で適用できます。Account Factory は新規アカウントの作成を標準化し、事前定義されたネットワーク設定、IAM 設定、ガードレールが自動適用されたアカウントをセルフサービスでプロビジョニングできます。Account Factory for Terraform (AFT) により、Terraform ユーザーもこの自動化の恩恵を受けられます。
Azure Management Groups との比較
Azure は Management Groups を使用してサブスクリプション (AWS のアカウントに相当) を階層的に管理します。Management Groups は最大 6 階層のツリー構造をサポートし、Azure Policy をグループ単位で適用できます。Azure Policy は AWS の SCP と AWS Config Rules を組み合わせたような機能を持ち、リソースの作成時に準拠性を強制する (deny 効果) ことも、既存リソースの準拠性を監査する (audit 効果) こともできます。Azure Policy の強みは、deny と audit を同一のポリシーフレームワークで管理できる点です。AWS では予防的制御 (SCP) と検出的制御 (AWS Config Rules) が別のサービスとして提供されており、管理の一元性では Azure に利点があります。一方で、Azure にはControl Tower に相当するランディングゾーンの自動構築サービスがありません。Azure Landing Zone は参照アーキテクチャとして提供されていますが、Bicep や Terraform のテンプレートを自分でデプロイする必要があり、Control Tower のようなマネージドサービスとしての自動化レベルには達していません。また、Azure の Management Groups は最大 6 階層という制限があり、大規模組織では階層設計に制約が生じる場合があります。
GCP のリソース階層との比較
GCP は Organization、Folder、Project の 3 層構造でリソースを管理します。Organization は Google Workspace または Cloud Identity のドメインに紐づき、Folder は最大 10 階層のネストが可能です。Organization Policy Service は SCP に相当する制約を Folder または Project 単位で適用できます。GCP のリソース階層はシンプルで理解しやすい設計ですが、AWS Organizations や Azure Management Groups と比較すると、ガバナンス機能の深さに差があります。GCP には Control Tower に相当するランディングゾーンの自動構築サービスがなく、Terraform Foundation Toolkit や Cloud Foundation Toolkit を使用して手動で構築する必要があります。Organization Policy の制約タイプも AWS の SCP ほど柔軟ではなく、条件付きポリシーの表現力に限界があります。GCP の強みは、IAM の継承モデルがシンプルで直感的な点です。上位の Folder で付与された IAM ロールが下位の Project に自動継承され、AWS の SCP のような明示的な境界設定なしにアクセス制御が伝播します。しかし、この継承モデルは大規模組織では過剰な権限の伝播リスクを生む場合があり、SCP による明示的な制限の方がガバナンス上は安全です。
マルチアカウント設計のベストプラクティス
AWS のマルチアカウント設計では、ワークロードの分離、環境の分離、セキュリティ境界の確立を目的として OU 構造を設計します。一般的なパターンとして、Security OU (ログアーカイブ、監査)、Infrastructure OU (共有ネットワーク、DNS)、Sandbox OU (開発者の実験用)、Workloads OU (本番・ステージング・開発) という構成が推奨されています。AWS Config の集約機能により、全アカウントのコンプライアンス状態を管理アカウントから一元的に監視できます。Security Hub は複数アカウントのセキュリティ検出結果を集約し、CIS Benchmarks や AWS Foundational Security Best Practices に基づく自動評価を提供します。マルチアカウントガバナンスの設計パターンを体系的に学ぶには関連書籍 (Amazon) も参考になります。
まとめ
AWS のマルチアカウント統制は、Organizations による階層管理、SCP による予防的ガードレール、Control Tower によるランディングゾーンの自動構築という 3 層構造で構成されています。Azure は Management Groups と Azure Policy による統合的なポリシー管理に強みがありますが、Control Tower に相当するマネージドなランディングゾーン構築サービスが不足しています。GCP はシンプルなリソース階層と IAM 継承モデルが特徴ですが、ガバナンス機能の深さで AWS に後れを取っています。エンタープライズ規模のクラウド運用では、マルチアカウント統制の成熟度がセキュリティとコンプライアンスの品質に直結します。Control Tower の自動化されたランディングゾーン構築と、SCP による強力な予防的制御の組み合わせは、AWS の最も差別化されたガバナンス機能です。