AWS Organizations
複数の AWS アカウントを組織として一元管理し、請求統合やサービスコントロールポリシーで統制を効かせるアカウント管理サービス
概要
AWS Organizations は、複数の AWS アカウントを組織 (Organization) として束ね、一元的に管理するサービスです。組織単位 (OU: Organizational Unit) でアカウントを階層的にグループ化し、サービスコントロールポリシー (SCP) で各アカウントが実行できる操作の上限を制御します。請求の一括管理 (Consolidated Billing) により、全アカウントの利用料を管理アカウントに集約し、ボリュームディスカウントの恩恵を最大化できます。Control Tower、Config、GuardDuty、Security Hub など多くの AWS サービスが Organizations と統合されており、マルチアカウント戦略の基盤となるサービスです。
SCP によるガードレール設計と IAM との関係
SCP (Service Control Policy) は Organizations の最も強力なガバナンス機能で、アカウントが実行できる API アクションの上限を定義します。SCP は IAM ポリシーと似た JSON 形式で記述しますが、権限を付与するのではなく、許可の上限を設定する点が異なります。つまり、SCP で許可されていない操作は、たとえアカウント内の IAM ポリシーで許可されていても実行できません。Azure Management Groups の Azure Policy が「この設定でなければならない」という準拠性チェックと自動修復を中心とするのに対し、SCP は「この操作は絶対にできない」というガードレール型の制御に特化しており、モデルがよりシンプルです。実務では、拒否リスト方式 (デフォルトで全許可し、特定の操作を明示的に拒否) が管理しやすく推奨されます。典型的な SCP として、CloudTrail の無効化禁止、特定リージョン以外でのリソース作成禁止、ルートユーザーの使用制限などがあります。SCP は OU に適用し、OU 内の全アカウントに継承されるため、OU 構造の設計が SCP の効果を左右します。
OU 構造の設計と委任管理者の活用
Organizations の実務導入で最初に設計すべきは OU 構造です。AWS が推奨する構成は、Root 直下に Security OU (ログアーカイブ、セキュリティ監査)、Infrastructure OU (共有ネットワーク、DNS)、Sandbox OU (実験用)、Workloads OU (本番・ステージング・開発) を配置する階層です。OU 構造は SCP の適用単位になるため、セキュリティ要件が異なるアカウント群を別の OU に分離することが重要です。委任管理者 (Delegated Administrator) 機能を活用すると、管理アカウントに権限を集中させずに、セキュリティアカウントから GuardDuty や Security Hub を組織全体で管理できます。管理アカウントは請求と組織構造の管理に専念させ、日常的なセキュリティ運用は委任管理者アカウントに任せるのがベストプラクティスです。AWS マルチアカウント管理の書籍 (Amazon) で詳しく学べます。
Consolidated Billing と RI/Savings Plans の共有設計
Organizations の請求一括管理 (Consolidated Billing) は、全アカウントの利用料を管理アカウントに集約し、ボリュームディスカウントの恩恵を最大化します。S3 のストレージ料金や EC2 のデータ転送料金は、組織全体の合算使用量に基づいて割引が適用されるため、個別アカウントで契約するよりも単価が下がります。リザーブドインスタンスと Savings Plans の共有設定も強力で、あるアカウントで購入した RI や Savings Plans の割引が、組織内の他のアカウントにも自動的に適用されます。ただし、この共有を意図的に無効にして特定アカウントに割引を限定することも可能です。コスト配分タグを組織全体で統一し、Cost Explorer で OU 単位やアカウント単位のコスト分析を行うことで、どの部門がどれだけのコストを消費しているかを可視化できます。請求アラートは管理アカウントで組織全体の閾値を設定するだけでなく、各アカウントの予算を AWS Budgets で個別に管理する二層構造が効果的です。