組織要件からMulti-Account Governanceを設計する

1. 要件から設計を始める

最初に確認するのは「どのAWSサービスを使うか」ではなく、何を分離・共通化・禁止・標準化・共有・記録・通知する必要があるかです。

2. 分離境界を先に決め、制御範囲を後から作る

セキュリティ・環境・所有責任・影響範囲などを分離する必要があるなら、まずアカウント境界を評価します。その後、同じガバナンス要件を持つアカウントをOUへグループ化します。

分離が必要
→ アカウント境界

同じガバナンスを適用したいアカウント群
→ OU範囲

アカウントは分離、OUはグループ化 / ガバナンス範囲という責任を混同しません。

3. 厳格なガードレールが必要かを判断する

メンバーアカウント管理者にも実行させたくない運用があるなら、組織レベルの権限ガードレールを評価します。単にプリンシパルへ通常権限を与えたい要件とは別です。

プリンシパルへ実際の権限を付与
→ IAM等

組織として越えさせない上限
→ SCP等

共通ガードレールは、アカウントIDを個別列挙するより、可能ならOU範囲へ適用してアカウントライフサイクルに追従させます。

4. OrganizationsネイティブかAWS Control Towerかを選ぶ

マルチアカウントであること自体はAWS Control Towerの決定打ではありません。

アカウント数ではなく、アカウントライフサイクルとガバナンス運用モデルをどこまで標準化したいかで判断します。

5. 必要最小限のガバナンスを選ぶ

要件を満たすために不要なレイヤーまで追加しません。例えば「本番OUで危険なAPIを1つ禁止する」だけなら、Organizations + OU + SCPで成立する可能性があります。

必要な機能が1つ
→ 最小構成を優先

プロビジョニング / ベースライン / コントロールライフサイクルまで必要
→ AWS Control Tower等を追加

SAP-C02では、高機能な構成より要件を過不足なく満たす構成を選びます。

6. 中央所有責任とクロスアカウントアクセスを分ける

複数アカウントで同じ対応リソースを共同利用し、インフラストラクチャチームが中央所有したいならAWS RAMを評価します。一方、運用チームが別アカウントへアイデンティティとして入り、そのアカウントのリソースを操作したいならクロスアカウントIAMアクセスの問題です。

リソースそのものを共同利用
→ 中央所有 + AWS RAM

別アカウントへアイデンティティとしてアクセス
→ クロスアカウントロール等

7. 可視性はレコードプレーンとイベントプレーンに分ける

監査要件と即時対応要件は別です。全アカウントの監査レコードを保護するなら中央ログ記録をガバナンスベースラインへ入れ、重要イベントへ即時対応するならイベントプレーンを追加します。

監査 / フォレンジック
→ 集中ログ記録 / ログアーカイブ

即時対応
→ EventBridge / 運用ワークフロー

ログ保存だけで通知は成立せず、イベント通知だけで監査レコードも代替できません。

8. アカウントライフサイクルにガバナンスが追従するかを見る

現在のアカウント数だけでなく、追加・移動・終了まで考えます。アカウントが増えるたびにSCP、リソース共有、ログ記録、通知をアカウントID単位で手動追加する設計はスケールしにくくなります。

アカウント追加
↓
正しいOU / 標準化されたプロビジョニング
↓
制御 / 共有 / ログ記録がグループ範囲で追従

固定アカウントリストよりグループベースのガバナンスを優先し、必要ならAWS Control Towerなどでアカウントライフサイクル自体を標準化します。

9. アーキテクチャは複数レイヤーを組み合わせて完成させる

1つのサービスですべてを解こうとしません。例えば、本番 / 開発の隔離、本番共通ガードレール、継続的アカウント追加、中央ネットワークリソース、中央監査、重要イベント通知が必要なら、複数レイヤーを組み合わせます。

アカウント境界
+ OU / ガードレール
+ AWS Control Tower（ライフサイクル標準化が必要なら）
+ AWS RAM（中央リソース）
+ 集中ログ記録
+ イベントプレーン

逆に要件が存在しないレイヤーは追加しません。

10. シナリオ：Organizationsネイティブで十分な場合

アカウント追加は年に数回、OU構造は安定しており、本番アカウント群へ共通の禁止運用を適用するだけなら、Organizationsネイティブガバナンスを優先評価できます。

本番アカウント
↓
本番OU
↓
SCP

アカウントプロビジョニング / ランディングゾーン自動化
→ 要件なし

マルチアカウントだからという理由だけでAWS Control Towerを追加しません。

11. シナリオ：標準化されたガバナンスが必要な場合

プロジェクトごとにアカウントを継続作成し、決められたOU・ベースライン・制御へ自動的に組み込みたいなら、AWS Control Tower / アカウントファクトリーを含む運用モデルを評価します。

新しいプロジェクト
↓
標準化されたアカウントプロビジョニング
↓
対象OU
↓
ガバナンスベースライン / 制御
↓
共有リソース / ログ記録 / イベントプレーンへ接続

決定打はアカウント数ではなく、再現可能なアカウントライフサイクルです。

12. 障害モード

マルチアカウントだから必ずAWS Control Towerを選ぶ

Organizationsネイティブで要件を満たせる場合があります。

OUだけでセキュリティ分離を作ろうとする

分離境界が必要ならアカウント分離を評価します。

共有リソースとクロスアカウントアクセスを同じ問題として扱う

中央リソース共有とアイデンティティアクセスは別要件です。

中央ログ記録だけで即時対応も満たす

監査レコードとイベント対応は別プレーンです。

アカウント追加のたびに設定を個別複製する

OU / 組織範囲や標準化されたプロビジョニングでライフサイクルに追従できる構成を優先します。

AWS Control Towerを導入すれば他の要件設計が不要になる

AWS Control Towerはガバナンスを標準化しますが、アカウント境界・リソース共有・ログ記録・イベント要件そのものは引き続き設計します。

13. SAP-C02判断フロー

組織の要件
        │
        ▼
分離が必要？
        ↓
アカウント境界
        ↓
共通制御範囲？
        ↓
OU
        ↓
厳格な権限ガードレール？
        ↓
SCP等
        ↓
アカウントライフサイクル / ランディングゾーン標準化？
   ┌────┴────┐
   │         │
  はい      いいえ
   │         │
AWS Control Tower   Organizations
                    ネイティブ
   │         │
   └────┬────┘
        ▼
中央所有？ → AWS RAM
        ↓
監査？ → 集中ログ記録
        ↓
即時対応？ → イベントプレーン
        ↓
アカウント増減にも追従する？
        ↓
マルチアカウントガバナンスモデル

14. まとめ

マルチアカウントガバナンスはサービス選択ではなく、要件をレイヤーへマッピングして組み立てます。

分離 → アカウント
共通制御 → OU
厳格なガードレール → SCP等
標準化されたライフサイクル → AWS Control Tower
中央リソース → AWS RAM
監査記録 → 集中ログ記録
即時対応 → イベントプレーン

最終判断は必要なレイヤーを組み合わせ、不必要なレイヤーを除外し、アカウントライフサイクルまで成立させることです。

15. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 — ドメイン 1 / タスク 1.4
• AWS Organizations — マルチアカウント環境のベストプラクティス
• AWS Organizations — 組織単位（OU）のベストプラクティス
• 複数のAWSアカウントを使用したAWS環境の整理 — 設計原則
• AWS Control Tower — マルチアカウント戦略
• AWS Organizations — サービスコントロールポリシー
• AWS Resource Access Manager
• AWS CloudTrail — 組織の証跡
• Amazon EventBridge — クロスアカウントイベント