AWS マルチアカウント組織制御戦略比較表
調査理由
AWSのアカウント管理や組織統制の仕方が多々あるが、サービスを整理し実務のイメージをすることができなかったため。
閲覧対象者
AWSのアカウント管理や組織統制の仕方が多々あり、サービスの整理が難しい方。
また、サービスの出来ることが分かったが、結局、実務のイメージが湧かない方。
例
1.マルチアカウントの管理が出来るのはわかったけど、結局何人くらいが目安なの？
2.初期段階からセキュア環境にしなくてはいけないの？システム開発でそれどころじゃないんだけど...
規模別推奨アプローチ
| 組織規模 | 人数 | アカウント数 | 推奨手法 | 理由 | 月額コスト目安 |
|---|---|---|---|---|---|
| スタートアップ | 5-15人 | 2-5アカウント | Organizations単体 | シンプルな構成で十分 | $10-50 |
| 小規模 | 16-50人 | 6-15アカウント | Organizations + 手動SCP | コスト効率と柔軟性のバランス | $50-200 |
| 中規模 | 51-200人 | 16-50アカウント | Organizations + 自動化ツール または Control Tower | 運用負荷軽減が必要 | $200-800 |
| 大規模 | 201-1000人 | 51-200アカウント | Control Tower | ガバナンス自動化が必須 | $800-3,000 |
| エンタープライズ | 1000人+ | 200+アカウント | Control Tower + カスタム拡張 | 企業レベルのガバナンス | $3,000+ |
制御方法とアカウント戦略
小規模組織（16-50人）
| 制御項目 | 実装方法 | 具体例 |
|---|---|---|
| 役職別制限 | IAM Groups + Cross-Account Role | ・エンジニア：Dev/Staging読み書き ・マネージャー：全環境読み取り ・役員：請求情報のみ |
| 業務別制限 | Account分離 + SCP | ・開発チーム：Dev Account ・本番運用：Prod Account ・財務：Billing Account |
| アカウント構成 | 機能別分離 | ・Management Account ・Security Account ・Shared Services ・Dev/Staging/Prod |
中規模組織（51-200人）
| 制御項目 | 実装方法 | 具体例 |
|---|---|---|
| 役職別制限 | SSO + Permission Sets | ・Junior Dev：特定サービスのみ ・Senior Dev：フルアクセス（本番除く） ・DevOps：本番含む全環境 |
| 業務別制限 | OU構造 + 段階的SCP | ・Product Teams OU ・Infrastructure OU ・Security OU |
| 自動化 | Systems Manager + Lambda | ・アカウント作成自動化 ・ポリシー適用自動化 ・コンプライアンス監視 |
Control Tower切り替え分岐点
| 判断基準 | Organizations単体 | Control Tower |
|---|---|---|
| アカウント数 | <20アカウント | 20+アカウント |
| 運用チーム規模 | 1-2名 | 3名以上 |
| ガバナンス要件 | 基本的なSCP | 詳細なガードレール |
| コンプライアンス | 手動チェック | 自動化必須 |
| 運用工数 | 週5-10時間 | 週40時間+ |
| 月額予算 | <$500 | $500+ |
代替ソリューション比較
| ソリューション | 適用規模 | 主な機能 | コスト | 複雑さ |
|---|---|---|---|---|
| Organizations単体 | 小-中規模 | ・アカウント管理 ・基本SCP ・請求統合 |
低 | 低 |
| Organizations + Config | 中規模 | ・リソース監視 ・コンプライアンス自動化 |
中 | 中 |
| Control Tower | 中-大規模 | ・包括的ガバナンス ・自動プロビジョニング ・ガードレール |
高 | 中 |
| Custom Solutions | 大規模 | ・完全カスタマイズ ・独自要件対応 |
最高 | 最高 |
| Terraform Enterprise | 全規模 | ・Infrastructure as Code ・ポリシー管理 ・ワークフロー |
中-高 | 中-高 |
実装パターン別詳細
パターン1：Organizations + 手動運用（小規模）
Management Account
├── Security OU
│ ├── Security Account (ログ集約、監査)
│ └── Compliance Account (Config、CloudTrail)
├── Production OU
│ └── Prod Account
└── Non-Production OU
├── Dev Account
└── Staging Account
制御方法:
- SCPで本番環境への制限
- IAM Cross-Account Roleで権限制御
- 手動でのアカウント作成・設定
パターン2：Control Tower（中-大規模）
Root
├── Security OU (ガードレール自動適用)
├── Sandbox OU (実験環境)
├── Production OU (厳格なガードレール)
└── Teams OU
├── Team A Accounts
└── Team B Accounts
制御方法:
- 予防的ガードレール（SCP自動適用）
- 検出的ガードレール（Config Rules）
- Account Factory（標準化されたアカウント作成）
切り替えタイミング
| シナリオ | Control Tower導入タイミング |
|---|---|
| 運用工数増大 | 週10時間以上のガバナンス作業 |
| コンプライアンス要件 | SOC2、ISO27001等の認証取得時 |
| 組織拡大 | エンジニア50名または月5アカウント以上の増加 |
| セキュリティ強化 | セキュリティインシデント後の体制強化 |
| M&A・子会社統合 | 複数組織のAWS環境統合時 |
まとめ
50名以下の組織: Organizations + 手動SCPで十分
51-200名の組織: Control Tower導入を検討する分岐点
200名以上の組織: Control Tower推奨、カスタム拡張も検討
AWS Control Towerに必要な関連サービスを表形式でまとめました。
主なポイント：
-
Control Tower自体は無料ですが、背後で動く関連サービス（特にConfigとCloudTrail）で料金が発生します
-
実際のコストはAWS Configで設定項目あたり$0.003、CloudTrailで管理イベント（最初の1つは無料）などが主要な費用となります
-
学習コストが高い理由：
- 組織レベルのガバナンス設計が必要
- 複数のAWSサービスの統合的な理解が必須
- 既存環境からの移行が複雑
-
隠れたコスト：エフェメラルワークロードでのConfig料金増加や、既存CloudTrailとの重複課金の可能性があります
中規模企業（50アカウント程度）でも月額$350-950程度のコストが見込まれるため、EBS暗号化という単一要件に対しては確かに「過剰なソリューション」と言えるでしょう。