AWS Organizations — 組織管理と請求統合
AWS Organizations の組織構造、請求統合、RI/Savings Plans 共有、セキュリティ統合、AWS Service Catalog 連携を SAA 基礎から SAP 高度設計まで解説。
AWS Organizations は 複数 AWS アカウントを一元管理 するサービスで、 ガバナンス・マルチアカウント戦略の基盤です。 請求統合、SCP、IAM Identity Center 連携など多岐にわたる機能を提供します。 本記事では Organizations の組織管理と請求統合を SAA / SAP 両面から整理します。
SAA レベル：基礎概念
Organizations の基本構造
| 要素 | 説明 |
|---|---|
| 組織 (Organization) | 全アカウントを統括するルート管理単位 |
| 管理アカウント (Management Account) | 組織のルート、請求統括 |
| メンバーアカウント (Member Account) | 組織に所属する個別アカウント |
| 組織単位 (OU) | アカウントをグループ化するコンテナ |
| Root | OU 階層の最上位 |
SAA レベル：基礎概念
Organizations の核心構造は 「管理アカウント + OU 階層 + メンバーアカウント」 です。 管理アカウントが請求を統括し、OU でアカウントをグループ化し、SCP を適用してガードレールを設定。 SAA ではこの 3 層構造と役割分担が基礎として問われます。
請求統合 (Consolidated Billing)
Organizations の最も直接的なメリットが 請求統合 です。
- 一括請求: 全メンバーアカウントの利用料が管理アカウントに一本化
- ボリューム割引: 組織全体でしきい値到達しやすく割引が適用
- RI / Savings Plans 共有: 組織内で RI/S.P を共有可能
- コスト配分タグ: 各アカウントの費用を粒度細かく可視化
SAA 試験のポイント
請求統合は追加費用なし で利用できます。 RI / Savings Plans の組織内共有、ボリューム割引の恩恵もすべて無料。 SAA では「請求統合 = 無料のメリット」として頻出します。
SCP の基本（復習）
SCP は OU またはアカウントに適用される 許可の最大範囲 (ガードレール) です。 詳細は「SCP と RCP」記事を参照してください。
SAA 頻出
SCP は 「許可を与えるのではなく、許可の上限を定める」 ものです。 IAM ポリシーで許可されていても、SCP で許可されていなければアクセス拒否。 「SCP = ガードレール」が SAA の核心です。
招待 vs 新規作成
メンバーアカウントを組織に参加させるには 2 つの方法 があります。
| 方法 | 説明 | ユースケース |
|---|---|---|
| 招待 (Invitation) | 既存アカウントを組織に招待 | 既存アカウント統合 |
| 新規作成 | 組織内で新規アカウントを作成 | 新規プロジェクト用 |
新規作成の利点
組織内で新規作成したアカウントは自動的に SCP / CloudTrail 等のガバナンス対象 になります。 招待した既存アカウントは組織移行前に既に設定があるため、ガバナンス適用に追加作業が必要。 SAA では「新規作成の方がガバナンス上クリーン」という位置づけが頻出します。
SAP レベル：高度な設計シナリオ
OU 階層設計
SAP では OU 階層そのものがガバナンスの骨格 になります。
SAP レベル：高度な設計シナリオ
SAP の OU 階層定石は 「機能別トップ OU + 環境別サブ OU」 です。 トップは Security / Workloads / Sandbox 等の機能で分け、その下に Prod / Dev 等の環境を分ける。 これで SCP を階層的に重ね適用でき、局所的な要件は局所的な SCP で実現します。
Root
├── Security OU
│ ├── Audit-Account
│ └── LogArchive-Account
├── Workloads OU
│ ├── Production OU
│ │ ├── App-Prod
│ │ └── Data-Prod
│ └── Development OU
│ └── App-Dev
├── SharedServices OU
│ └── SharedServices-Account
└── Sandbox OU機能別アカウント分離
AWS 推奨のランディングゾーンは 機能別アカウント分離 が基本です。
| アカウント | 役割 | SAP 設計論点 |
|---|---|---|
| Management | 組織のルート・請求 | IAM ユーザーを置かない、強力 MFA |
| LogArchive | CloudTrail / Config 集約 | 不変性、KMS CMK 分離 |
| Audit (Security Tooling) | GuardDuty / Security Hub | 委任管理者、自動修復起点 |
| SharedServices | TGW / AD / DNS | 共有インフラ SPOF 回避 |
| Workloads | アプリごと環境分離 | Prod / Dev の分離 |
管理アカウントの保護
管理アカウントは SCP 対象外 で最も権力集中します。
- IAM ユーザーを置かず Identity Center からのみアクセス
- ルートユーザーは強力な MFA + 物理キー
- アプリやワークロードを置かない これらが SAP の管理アカウント保護定石です。
RI / Savings Plans の共有設計
SAP では RI / Savings Plans の組織内共有を最適化 します。
- 共有プール: 組織全体で RI/S.P の割引を共有
- 利用率の最大化: あるアカウントの RI を別アカウントが活用
- 集中購入: 管理アカウントで一括購入が推奨
[管理アカウント] (RI/S.P 一括購入)
│ (組織内共有)
▼
[全メンバーアカウント]
利用率に応じて割引を自動適用RI/S.P 共有のコスト最適化
RI/S.P を組織内で共有 すると、利用率の低いアカウントの RI を 利用率の高いアカウントが活用でき、組織全体の割引効率が最大化 します。 SAP では「集中購入 + 組織内共有」がコスト最適化の定石です。
CloudTrail 集約設計
組織トレイル で全アカウントの CloudTrail を 1 箇所に集約します。
- 管理アカウントから 1 つ作成: 全メンバーアカウントに自動適用
- 新規アカウント自動対象: 組織追加時に自動的にトレイル対象
- LogArchive アカウントの S3: 集約先を専用アカウントに分離
- KMS 暗号化: LogArchive の CMK で暗号化、鍵を分離
組織トレイルの論点
組織トレイルは新規アカウントが自動的にログ対象 になるため、 「新規アカウントのログ漏れ」を構造的に防げます。SAP では組織トレイルが推奨です。
AWS Service Catalog との連携
AWS Service Catalog で承認ベースのリソースプロビジョニングを実現します。
- ポートフォリオ: 承認済み製品（CloudFormation テンプレート等）をまとめたカタログ
- 製品: 個別のデプロイ可能テンプレート
- 制約: 起動時のパラメータ制限、IAM ロール制限
- クロスアカウント共有: ポートフォリオを別アカウントに共有
[共有サービスアカウント]
Service Catalog Portfolio
│ (クロスアカウント共有)
▼
[ワークロードアカウント]
エンドユーザーが承認済み製品を起動Service Catalog のガバナンス効果
Service Catalog で 「承認済みテンプレートだけ起動可能」 にすると、 エンドユーザーが自由な構成でリソースを作るのを防止できます。 SAP では「ガバナンスの効いたセルフサービス」実現手段として Service Catalog が頻出します。
請求とコスト管理の統合
Organizations の請求統合を活かしたコスト管理設計：
| 機能 | 説明 | 設計論点 |
|---|---|---|
| 請求統合 | 全アカウント料金を管理アカウントに集約 | 一括支払い |
| コスト配分タグ | タグで費用を分類 | タグポリシー連携 |
| Cost Explorer | 費用の可視化・分析 | 部門別 / プロジェクト別集計 |
| Budgets | 予算アラート | 超過時の通知・自動アクション |
| Cost and Usage Report | 詳細費用データ | Athena + QuickSight で BI |
コスト配分タグの標準化
タグポリシー (Organizations) でタグのキー/値を標準化 し、 SCP で必須タグ未付与リソース作成を拒否 すると、コスト配分の精度が劇的に向上します。 タグ付けバラバラだと Cost Explorer での集計が困難。SAP ではタグガバナンスがコスト管理の前提です。
アカウント分離粒度の判断
SAP では 「どこまでアカウントを分けるか」 が頻出論点です。
| 判断基準 | 分けるべき | 理由 |
|---|---|---|
| コンプライアンス要件が異なる | ✅ | 規制境界の分離 |
| 責任所在 (チーム) が異なる | ✅ | 責任分界 |
| 本番 vs 非本番 | ✅ 必須 | ブラストレディウス分離 |
| 同一チーム・同要件のマイクロサービス | ❌ (VPC 分離で十分) | 過剰分離回避 |
SAP レベル：高度な設計シナリオ
SAP の分離粒度判断は 「ブラストレディウス vs 管理コスト」のトレードオフ です。 分けすぎは管理コストとレイテンシを増やし、分けなさすぎは影響範囲を広げます。 「コンプライアンス / 責任 / 環境」が異なればアカウントを分け、 それ以外は VPC 分離で済ませるのが SAP の定石です。
新規アカウントの自動プロビジョニング
SAP では 新規アカウントの自動プロビジョニング がガバナンスの一部です。
- Control Tower Account Factory: 標準設定済みアカウントを自動作成
- AWS Service Catalog: 承認ベースのアカウント要求
- Control Tower Guardrails: 新規アカウントに自動適用
アカウント作成ルートの統一
アカウント作成のルートを 1 つに統一 すると、全ガードレールが自動適用されます。 手動作成すると SCP / CloudTrail / タグ付けの標準が適用されないリスク。 SAP では「Account Factory 経由のみ」が推奨です。
アカウントの退会とデータ保護
アカウント退会時も データ保護とガバナンス が必要です。
- バックアップ退避: LogArchive にバックアップを確保
- CloudTrail 保管: 監査ログは LogArchive に残る
- リソース削除: 退会前にリソースを完全削除
- 退会手順: Organizations からの除外 → アカウント閉鎖
退会時のデータ保護
退会アカウントのバックアップを LogArchive に退避 しておかないと、 アカウント閉鎖後にデータが永久に失われます。SAP では退会プロセスの標準化が重要です。
制約と考慮事項
| 項目 | 制約 |
|---|---|
| 組織あたりアカウント数 | クォータ拡張可能 |
| OU 階層の深さ | 推奨 3〜4 階層 |
| 1 アカウントあたり SCP | 5（拡張可） |
| 管理アカウント | SCP 対象外 |
| 組織トレイル | 管理アカウントから 1 つ |
まとめ
- SAA: Organizations の基本構造、請求統合（無料）、SCP はガードレール、 招待 vs 新規作成、を理解する。
- SAP: OU 階層設計、機能別アカウント分離、RI/S.P 共有最適化、CloudTrail 集約、 Service Catalog 連携、アカウント分離粒度判断、退会プロセスが求められる。
次は AWS Control Tower で、ランディングゾーンの自動構築を学びましょう。