AWS Organizations は単なるアカウント集約ツールではなく、組織全体のガバナンス基盤 です。 OU 階層、SCP、タグポリシー、RCP、CloudTrail 集約を統合して設計する必要があります。本記事では Organizations を活用した総合ガバナンス設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

Organizations の基本構造

要素	説明
Organization	組織全体のルート管理単位
管理アカウント (Management Account)	組織のルート・請求統括
メンバーアカウント	組織に所属する個別アカウント
組織単位 (OU)	アカウントをグループ化するコンテナ
Root	OU 階層の最上位

SAA レベル：基礎概念

Organizations の基本は 「管理アカウント + OU 階層 + メンバーアカウント」 です。管理アカウントが組織のルートで請求を統括し、OU でアカウントをグループ化し、 SCP を OU/アカウントに適用してガードレールを設定します。この 3 層構造が SAA の基礎です。

請求統合 (Consolidated Billing)

Organizations の最も直接的な利点が 請求統合 です。

全メンバーアカウントの利用料が 管理アカウントに一本化
ボリューム割引 のしきい値を組織全体で到達しやすい
RI / Savings Plans を組織内で共有可能
コスト配分タグ で各アカウントの費用を可視化

SAA 試験のポイント

請求統合は 追加費用なし で利用できます。 RI / Savings Plans の組織内共有も ボリューム割引の恩恵 も無料。 SAA では「請求統合 = 無料のメリット」として頻出します。

SCP の基本（復習）

SCP は OU またはアカウントに適用される 許可の最大範囲 を定義します。詳細は前記事「SCP と RCP」を参照してください。ここでは ガバナンス統合 の視点で扱います。

SAA 頻出

SCP は 「許可を与える」のではなく「許可の上限を定める」 ものです。これをガバナンスの観点で言い換えると 「組織が許容する行動の境界線」 を定める機能と言えます。

SAP レベル：高度な設計シナリオ

OU 階層の設計

SAP では OU 階層そのものがガバナンスの骨格 になります。階層設計次第で SCP の適用粒度や管理効率が大きく変わります。

SAP レベル：高度な設計シナリオ

SAP の OU 階層設計の定石は 「機能別 OU + 環境別サブ OU」 です。トップレベルはセキュリティ / ワークロード / サンドボックス等の機能で分け、その下に本番 / 開発等の環境を分けることで、SCP を階層的に重ね適用できます。

Root
├── Security OU
│   ├── Audit-Account
│   └── LogArchive-Account
├── Workloads OU
│   ├── Production OU
│   │   ├── App-Prod
│   │   └── Data-Prod
│   ├── Pre-Production OU
│   │   └── App-Staging
│   └── Development OU
│       └── App-Dev
├── SharedServices OU
│   └── SharedServices-Account
└── Sandbox OU
    └── Individual-Sandboxes

OU	目的	SCP の傾向
Security OU	監査・ログ集約	厳格（変更禁止）
Workloads/Production	本番ワークロード	厳格（リージョン制限、承認要求）
Workloads/Development	開発環境	緩やか（自由度高）
Sandbox OU	実験・学習	緩やかだが本番リソースへのアクセス禁止

機能別アカウント分離

AWS が推奨するランディングゾーンは 機能別アカウント分離 が基本です。

アカウント	役割	SAP での設計論点
Management	組織のルート・請求	IAM ユーザーを置かない、強力な MFA
LogArchive	CloudTrail / Config 集約	変更不可な証跡保管、KMS CMK 分離
Audit (Security Tooling)	GuardDuty / Security Hub	自動修復 Lambda の実行起点
SharedServices	Transit Gateway / AD / DNS	共有インフラの SPOF 回避
Workloads	アプリごと環境分離	Prod / Pre-Prod / Dev のアカウント分離

管理アカウントの保護

管理アカウントは SCP 対象外 で最も権力が集中します。

IAM ユーザーを置かず Identity Center からのみアクセス
ルートユーザーは強力な MFA + 物理キーで保護
アプリやワークロードを置かないこれらが SAP の管理アカウント保護の定石です。

CloudTrail 集約設計

組織トレイル (Organization Trail) を使うと、全アカウントの CloudTrail ログを 1 つの S3 バケット（LogArchive アカウント）に集約 できます。

[各メンバーアカウント] ──(CloudTrail)── [LogArchive アカウントの S3]
  Management, Audit, Workloads...        (KMS 暗号化、書き込み専用)

組織トレイル: 管理アカウントから 1 つ作成するだけで全アカウント対象
LogArchive アカウント: 専用アカウントに集約、アプリからのアクセス不可
KMS 暗号化: LogArchive アカウントの CMK で暗号化、鍵を分離
不変性: S3 Object Lock でログの改ざん防止

CloudTrail 集約の論点

組織トレイルは 管理アカウントから有効化 するだけで全メンバーアカウントに自動適用されます。新規アカウントが組織に追加されても自動的にトレイル対象に含まれるため、「新規アカウントのログ漏れ」を構造的に防げるのが SAP の論点です。

Config 集約と Security Hub 集約

CloudTrail だけでなく、Config と Security Hub も集約設計 します。

サービス	集約先	設計論点
CloudTrail	LogArchive アカウントの S3	不変性、KMS 分離
Config	Audit アカウント（Aggregator）	全リージョン・全アカウント集約
Security Hub	Audit アカウント（Administrator）	全アカウントのセキュリティ状況統合
GuardDuty	Audit アカウント（Administrator）	全アカウントの脅威検知統合

委任管理者 (Delegated Administrator)

Security Hub / GuardDuty / Macie などは 委任管理者 (Delegated Administrator) 機能で管理アカウント以外に管理権限を委任できます。Audit アカウントを委任管理者にすることで、管理アカウントの権限集中を避けつつセキュリティ運用を集約できます。SAP の定石です。

タグポリシー + SCP + Config の連携

ガバナンスを完全にするには 3 つのポリシーを連携 させます。

1. タグポリシー (Organizations)
   → タグの標準化（キー/値の定義）
2. SCP (Resource Control)
   → 必須タグ未付与のリソース作成を Deny（予防的ガードレール）
3. Config Rules
   → 既存リソースのタグ不備を検知・修復（是正的ガードレール）
4. Cost Explorer / CUR
   → 標準化タグで粒度細かいコスト分析

SAP レベル：高度な設計シナリオ

SAP では 「予防的 (Preventive)」と「是正的 (Detective)」の両方のガードレール を設計します。予防的 = SCP（作成時にブロック）、是正的 = Config（作成後に検知・修復）。この 2 段構えで、タグ付けのガバナンスを完全にします。

請求とコストガバナンス

Organizations の請求統合を活かしたコストガバナンス設計も SAP の論点です。

機能	説明	設計論点
請求統合	全アカウント料金を管理アカウントに集約	一括支払い
コスト配分タグ	タグで費用を分類	タグポリシー連携
Cost Explorer	費用の可視化・分析	部門別 / プロジェクト別集計
Budgets	予算アラート	超過時の通知・自動アクション
Cost and Usage Report (CUR)	詳細費用データ	Athena + QuickSight で BI

RI / Savings Plans の共有

RI と Savings Plans は組織内で共有可能 です。あるアカウントで購入した RI を、利用率の低いアカウントが活用できるため、組織全体の割引効率が最大化します。これを意識した RI/S.P 購入計画が SAP のコスト論点です。

新規アカウントの自動プロビジョニング

SAP では 新規アカウントの自動プロビジョニング もガバナンスの一部です。

Control Tower Account Factory: 標準設定済みアカウントを自動作成
AWS Service Catalog: 承認ベースのアカウント要求
Control Tower Guardrails: 新規アカウントに自動適用

手動アカウント作成のリスク

手動でアカウントを作成すると、SCP / CloudTrail / タグ付けの標準が適用されない リスクがあります。 Control Tower / Account Factory 経由で作成することで、全ガードレールが自動適用 されます。「アカウント作成のルートを 1 つに統一」が SAP のガバナンス定石です。

OU 階層設計のアンチパターン

アンチパターン	問題	是正
OU の深すぎるネスト	SCP 適用が複雑化	3〜4 階層以内に収める
環境だけのトップレベル OU	機能別 SCP が適用しにくい	機能別をトップに、環境をサブに
全アカウントを Root 直下	SCP の局所化が不可	機能別 OU に振り分け
Sandbox と本番の混在	ブラストレディウス拡大	Sandbox は独立 OU に隔離

階層設計の目安

OU 階層は 3〜4 階層以内 が管理性の目安です。深すぎると SCP の継承が複雑になり「どの SCP が有効か」が分かりにくくなります。 SAP では「最小限の階層で最大の表現力」を目指します。

制約と考慮事項

項目	制約
組織あたりアカウント数	クォータ拡張可能
OU 階層の深さ	推奨 3〜4 階層
1 アカウントあたり SCP	5（拡張可）
組織トレイル	管理アカウントから 1 つ

まとめ

SAA: Organizations の基本構造、請求統合（無料）、SCP はガードレール、を理解する。
SAP: OU 階層設計、機能別アカウント分離、CloudTrail/Config/Security Hub 集約、タグポリシー連携、新規アカウント自動プロビジョニングの統合ガバナンスが求められる。

ここまででアイデンティティ・アクセス管理編は完了。次は AWS KMS からデータ保護・暗号化の設計に入ります。