Multi-Account Architecture

1. AWSアカウントはアーキテクチャ上の境界

AWSリソースはAWSアカウント内に作成されます。アカウントはリソースをまとめるコンテナであるだけでなく、セキュリティ、アクセス、管理、請求を分離する境界として利用できます。

AWSアカウント
├─ IAM / アクセス
├─ ネットワーク / コンピューティング
├─ データ
├─ セキュリティ制御
└─ 請求

したがって「どのリソースをどのアカウントへ置くか」は、組織全体の分離を決めるアーキテクチャ設計です。

2. 単一アカウントとマルチアカウント

アカウント数を増やすこと自体が目的ではありません。要件上、何を別境界として扱う必要があるかを先に決めます。

3. 本番と非本番を分離する

代表的なアカウント分離が本番と非本番の分離です。

本番アカウント
└─ 本番ワークロード

非本番アカウント
├─ 開発
└─ テスト

開発者が開発で広い変更権限を必要としても、その権限や誤操作の影響を本番へ持ち込みたくない場合、アカウント境界が強い決定要因になります。

4. セキュリティ / コンプライアンス要件が異なるワークロード

ワークロードごとにデータ機密度やコンプライアンス要件が大きく異なる場合、同一アカウント内でポリシーだけを積み重ねるのではなく、アカウント分離を評価します。

パブリックワークロード
        │
        │ セキュリティ要件が異なる
        │
規制対象ワークロード

別アカウントに分けることで、アイデンティティ、管理上の範囲、セキュリティ制御の適用範囲をワークロード単位で明確にできます。

5. 所有責任と影響範囲

セキュリティ要件が同じでも、所有者、リリースサイクル、変更承認、管理者が異なるワークロードがあります。

互いに無関係なワークロードを別アカウントへ分離すると、一方の高権限操作や設定ミスが他方へ及ぼす範囲を小さくできます。

アカウント A
└─ ワークロード A

アカウント B
└─ ワークロード B

ワークロード Aの管理ミス
↓
アカウント A内へ影響を限定しやすい

アカウント分離は管理上の分離と影響範囲の縮小としても利用します。

6. 請求境界

AWSアカウントは請求を分離する明確な単位として利用できます。

ビジネス単位 A
└─ アカウント A → コスト A

ビジネス単位 B
└─ アカウント B → コスト B

コスト割り当てタグでもコストを分類できますが、タグによる分類とアカウント自体を分けることは同じではありません。タグ運用に依存しない明確な請求境界が必要なら、アカウント分離を評価します。

7. サービスクォータの競合を分離する

AWSサービスクォータはAWSアカウントごとに独立して適用され、クォータによってはリージョン範囲も持ちます。

同一アカウント・同一リージョンで複数の大規模ワークロードがクォータを共有していると、一方のリソース増加がもう一方の拡張を妨げる場合があります。

同一アカウント
ワークロード A → クォータ大量消費
ワークロード B → 拡張できない

アカウント分離
ワークロード A → アカウント Aのクォータ
ワークロード B → アカウント Bのクォータ

したがってクォータ消費を別ワークロードと共有したくないこともアカウント戦略の判断材料です。

8. アカウント境界とVPC境界は別

本番と開発を別VPCへ分けても、同じAWSアカウントにある限りアカウントレベル境界は共有しています。

1つのAWSアカウント
├─ VPC 本番
└─ VPC 開発

ネットワーク境界は分離
アカウント境界は共有

ネットワーク分離が必要なのか、アカウントレベル分離が必要なのかを分けて判断します。

9. 密接に関連するワークロードは同じ本番アカウントも候補

マルチアカウントだからといって、リソース単位で機械的にアカウントを増やすわけではありません。

例えば注文API、注文ワーカー、注文データベースが1つのビジネスワークロードを構成し、所有者、セキュリティ要件、ライフサイクル、請求責任が共通なら、1つの本番アカウントへまとめることを評価できます。

同じ所有者
+ 同じセキュリティ要件
+ 同じライフサイクル
+ 同じ請求責任
↓
関連ワークロードとして同じアカウントも候補

アカウント単位はリソース数ではなく、必要な分離境界に基づいて決めます。

10. アカウント戦略の判断軸

11. 障害モード

別VPCなら別アカウントと同じだと考える

VPCはネットワーク境界です。アカウントレベルセキュリティ、管理、請求、クォータ境界とは別です。

タグ分離をアカウント分離と同一視する

タグはコストやリソースを分類する仕組みです。強い請求 / 管理上の境界が必要ならアカウント分離を評価します。

リソース数だけでアカウントを分ける

リソース単位で機械的に細分化するのではなく、セキュリティ、所有責任、ライフサイクル、請求などの要件でアカウント単位を決めます。

異なる環境やワークロードを同じ境界へ置き続ける

本番 / 非本番、コンプライアンス、所有者、影響範囲などの差が大きくなったらアカウント分離を再評価します。

12. 混同ポイント

13. SAP-C02判断フロー

ワークロード / 環境
        │
        ▼
セキュリティ / コンプライアンスは同じ？
        │
   ┌────┴────┐
   │         │
  いいえ      はい
   │         │
   ▼         ▼
アカウント    所有者 / ライフサイクルは同じ？
分離評価       │
          ┌────┴────┐
          │         │
         いいえ      はい
          │         │
          ▼         ▼
       アカウント請求 / 影響範囲 /
       分離評価クォータを分離すべき？
                    │
               ┌────┴────┐
               │         │
              はい      いいえ
               │         │
               ▼         ▼
            アカウント関連ワークロードとして
            分離評価同一アカウントも候補

「何アカウント作るか」ではなく、「何を別分離境界として扱う必要があるか」から考えます。

14. まとめ

AWSアカウントはセキュリティ、管理、請求などを分離するアーキテクチャ境界です。

分離したアカウントを評価するシグナル

本番 / 非本番
セキュリティ / コンプライアンス差
所有責任 / ライフサイクル差
影響範囲
請求境界
サービスクォータ分離

一方、同じ所有者・セキュリティ要件・ライフサイクルを持つ1つまたは少数の密接に関連するワークロードは、同じ本番アカウントへ配置することも候補です。

アカウント数を増やすことではなく、組織とワークロードの要件に必要な分離境界を設計することが目的です。

15. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) 試験ガイド — ドメイン 1 / タスク 1.4
• AWSアカウント管理 — 複数のAWSアカウントを使用する利点
• 複数のAWSアカウントを使用したAWS環境の整理 — 設計原則