AWS Organizations で実現するマルチアカウント管理 - OU 設計と SCP によるガバナンス
OU 階層の設計と SCP によるアクセス制御でマルチアカウント環境のガバナンスを確立する。一括請求によるコスト管理も紹介します。
Organizations の概要
Organizations は最大数千の AWS アカウントを一元管理するサービスです。単一アカウントで全環境を運用するとセキュリティ境界が曖昧になり、請求の分離も困難です。Organizations でアカウントを分離し、OU 階層でグループ化することで、環境ごとのセキュリティ境界と請求の分離を実現します。組織のルートの下に OU (Organizational Unit) を作成し、その OU にアカウントを配置する木構造で管理します。管理アカウント (旧称マスターアカウント) は組織全体を統括し、SCP の制限を受けません。オンプレミス環境では環境分離にネットワークセグメンテーションや物理サーバーの分離が必要で構築 / 運用コストが高いのに対し、AWS ではアカウント作成が API 1 つで完了し追加インフラコストは不要です。
SCP と一括請求
SCP は OU またはアカウントに適用するアクセス制御ポリシーで、IAM ポリシーの上限を設定します。例えば本番 OU に「特定リージョン以外の使用を禁止」する SCP を適用すると、配下のアカウントでは IAM で許可されていても制限リージョンのリソースを作成できません。SCP は許可リスト方式 (Allow) と拒否リスト方式 (Deny) のどちらでも記述でき、拒否リスト方式が運用上シンプルで推奨されます。SCP は OU の階層を下方向に継承するため、親 OU の SCP は子 OU とその配下のアカウントすべてに適用されます。一括請求では組織内の全アカウントの使用量が合算され、S3 や EC2 のボリュームディスカウントが適用されます。RI や Savings Plans も組織内で共有され、購入アカウント以外でも割引が適用されます。AWS Cost Explorer と組み合わせて OU 別 / アカウント別のコスト分析が可能で、AWS Budgets でアカウント単位の予算アラートを設定すればコスト超過を未然に防止できます。
OU 設計とアカウント戦略
OU (Organizational Unit) の設計はセキュリティ境界とガバナンスの基盤です。推奨される OU 構造は、 Security OU (ログアーカイブ、セキュリティ監査)、 Infrastructure OU (ネットワーク、共有サービス)、 Workloads OU (本番、開発、ステージング)、 Sandbox OU (実験用) です。 SCP は OU に適用し、配下の全アカウントに継承されます。委任管理者機能で、セキュリティ関連のサービス (GuardDuty 、 Security Hub 、 Config) の管理をセキュリティアカウントに委任し、管理アカウントの操作を最小限に保ちます。CloudTrail の組織トレイルにより全アカウントの API 操作をログアーカイブアカウントに集約し、セキュリティ監査とコンプライアンス対応を効率化します。タグポリシーで全アカウントのリソースタグを標準化し、コスト配分の精度を向上させます。
RAM によるクロスアカウントリソース共有
AWS RAM (Resource Access Manager) はアカウント間でリソースを安全に共有するサービスです。VPC サブネット、Transit Gateway、Route 53 Resolver ルール、Network Firewall ポリシーなど多様なリソースタイプの共有をサポートします。Organizations と統合することで OU 単位でのリソース共有を自動化でき、新規アカウントが OU に追加された時点で自動的に共有リソースへのアクセスが付与されます。中央のネットワークアカウントが管理する VPC のサブネットを各ワークロードアカウントに共有することで、IP アドレス空間の効率的な管理とネットワークポリシーの一元制御を実現します。リソースの所有権は共有元アカウントが保持するため、セキュリティとガバナンスを維持しながら効率的なリソース利用が可能です。
Control Tower との使い分け
Organizations は組織構造の基盤サービスであり、Control Tower は Organizations の上に構築されたベストプラクティス自動化サービスです。Organizations 単体で利用する場合、OU 設計 / SCP 作成 / ログ集約の設定をすべて手動で行う必要があります。Control Tower を有効化すると、Landing Zone として推奨 OU 構造、400 以上の事前定義ガードレール (SCP + Config ルール、CIS Benchmark や NIST 800-53 対応)、Account Factory による新規アカウント自動プロビジョニングが提供されます。少数アカウント (5 アカウント程度) のシンプルな構成なら Organizations 単体で十分ですが、10 アカウント以上に拡大する見込みがあれば Control Tower の導入を推奨します。Control Tower は Organizations の機能をすべて内包するため、後から Control Tower を有効化しても既存の OU 構造は維持されます。
設計の落とし穴と注意点
Organizations 運用でよくある落とし穴の 1 つは、管理アカウントでワークロードを実行することです。管理アカウントは SCP の制限を受けないため、セキュリティガードレールが適用されません。管理アカウントは組織管理と請求のみに使い、ワークロードは必ずメンバーアカウントに配置します。SCP の設計では、Allow リストを使うと新サービスのリリース時に毎回 SCP を更新する運用負荷が生じるため、Deny リストで禁止事項だけを明示する方式が実用的です。OU のネスト深度は最大 5 階層ですが、深くしすぎると SCP の継承が複雑になり、どのポリシーがどのアカウントに適用されているか把握しづらくなります。2〜3 階層に留めるのが運用上のベストプラクティスです。各アカウントは独立した IAM 境界を持つため、あるアカウントでのセキュリティインシデントが他のアカウントに波及するリスクを最小化できる点がマルチアカウント戦略の最大の利点です。
Organizations の料金
Organizations 自体に追加料金は発生しません。一括請求でメンバーアカウントの使用量が集約され、ボリュームディスカウントの恩恵を受けられます。RI と Savings Plans の共有を有効にすると、購入アカウント以外のアカウントでも割引が適用されます。アカウント数が増えると、各アカウントで有効化されるサービス (CloudTrail、Config、GuardDuty) のコストが積み上がるため、必要なサービスのみを有効化する方針を OU レベルで管理します。タグポリシーを Organizations で強制することで全アカウントで一貫したタグ付けルールを維持し、正確なコスト配分を実現します。
まとめ
Organizations はマルチアカウント環境のガバナンスとコスト管理を一元化するサービスです。OU 階層と SCP でセキュリティ境界を確立し、委任管理者機能でセキュリティサービスの管理を専用アカウントに委任します。RAM によるリソース共有でネットワーク設計を簡素化し、一括請求でボリュームディスカウントと RI/Savings Plans の共有を活用します。タグポリシーで組織全体のリソースタグを標準化し、CloudTrail 組織トレイルで全アカウントの API 操作を一元監査します。10 アカウント以上の規模では Control Tower との併用で自動化を強化し、管理アカウントでのワークロード実行を避けることがセキュリティ維持の鍵です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。