SAA マルチアカウント設計パターン5選｜AWS Organizations・SCP・Control Tower・RAM 完全攻略
AWS SAA-C03 で頻出のマルチアカウント設計パターンを完全整理。AWS Organizations による OU 構造設計、SCP（Service Control Policy）のガードレール設計、Control Tower / Landing Zone による自動化、IAM Identity Center による一元アクセス管理、AWS RAM によるリソース共有の5パターンを、試験頻出シナリオと要件キーワードから即答できる粒度で解説。
「アカウントを分けること自体がセキュリティ境界であり、SCP がそのガードレールになる」 — SAA-C03 のマルチアカウント問題は「Organizations でアカウントをどう束ね、SCP でどう制御し、Control Tower でどう自動化し、IAM Identity Center でどう一元管理するか」の設計判断を問う。本記事では、要件キーワードからパターンへの逆引きができる粒度で、試験頻出の5つの設計パターンを整理する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：マルチアカウント設計パターン5選
- なぜマルチアカウント？3つの根拠
- パターン1：AWS Organizations / OU 構造設計
- パターン2：SCP（Service Control Policy）設計
- パターン3：Control Tower / Landing Zone 自動化
- パターン4：IAM Identity Center による一元アクセス管理
- パターン5：AWS RAM によるリソース共有
- 試験頻出シナリオ → 解法パターン早見表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：マルチアカウント設計パターン5選
SAA-C03 で問われるマルチアカウント設計パターンは大きく5つに集約される。
| パターン | 主なサービス | 主なユースケース |
|---|---|---|
| OU 構造設計 | AWS Organizations | 環境・部門・ワークロード単位のアカウント分離 |
| SCP 設計 | Service Control Policy | 全アカウントへの最大権限ガードレール適用 |
| Landing Zone 自動化 | AWS Control Tower | セキュアなマルチアカウント環境の一括セットアップ |
| 一元アクセス管理 | IAM Identity Center | SSO でのクロスアカウント・アプリアクセス |
| リソース共有 | AWS RAM | VPC サブネット・Transit Gateway・License Manager の共有 |
2. なぜマルチアカウント？3つの根拠
SAA 試験はマルチアカウントを「なぜ使うか」の根拠まで問う。
理由1：セキュリティ境界の確保
AWS では アカウント自体が最強のセキュリティ境界 だ。1アカウントで IAM ポリシーを設定しても、管理者が誤った権限を付与すれば全リソースが危険にさらされる。アカウントを分けることで、あるアカウントへの侵害が他アカウントに波及しない。
シングルアカウント構成（脆弱）
┌─────────────────────────────────────────┐
│ 本番 DB ／ 開発環境 ／ CI/CD ／ ログ が混在 │
│ 開発者が誤って本番 DB を削除できてしまう │
└─────────────────────────────────────────┘
マルチアカウント構成（推奨）
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 本番アカウント │ │ 開発アカウント │ │ ログアカウント │
│ 本番リソースのみ│ │ 開発リソースのみ│ │ ログ集約専用 │
└──────────┘ └──────────┘ └──────────┘
→ 開発者は開発アカウントしかアクセスできない理由2：コスト管理の明確化
アカウント単位でコストが自動集計されるため、部門・プロジェクト・環境（dev/stg/prod）ごとのコスト可視化が容易になる。Organizations の一括請求（Consolidated Billing）で合算請求しつつ、コスト配賦レポートで内訳を分離できる。
理由3：コンプライアンス・規制への対応
PCI DSS・HIPAA 対応が必要な環境を専用アカウントに分離することで、監査スコープを最小化できる。規制対象外のアカウントを別に設けることで、コンプライアンスコストを抑制できる。
3. パターン1：AWS Organizations / OU 構造設計
OU（組織単位）の役割
OU（Organizational Unit）はアカウントのグループだ。OU に SCP を適用することで、配下のすべてのアカウントに一括でポリシーを継承させられる。
推奨 OU 設計
Root（管理アカウント）
├─ Security OU
│ ├─ Log Archive アカウント ← CloudTrail ログ集約専用
│ └─ Audit アカウント ← セキュリティ監査専用
├─ Infrastructure OU
│ ├─ Network アカウント ← Transit Gateway / Direct Connect
│ └─ Shared Services アカウント ← Active Directory / DNS
├─ Workloads OU
│ ├─ Production OU
│ │ └─ Prod アカウント（製品ごと）
│ └─ Non-Production OU
│ ├─ Dev アカウント
│ └─ Staging アカウント
└─ Sandbox OU ← 実験用（本番 SCP より緩い）管理アカウント（旧マスターアカウント）の注意点
- 管理アカウントには SCP が適用されない（Organizations の制限）
- 管理アカウントでは メンバーアカウントの料金一括請求 のみ行う運用が推奨
- 管理アカウントに本番ワークロードを配置しない
4. パターン2：SCP（Service Control Policy）設計
SCP とは何か
SCP は 最大許可の上限（ガードレール）を定義するポリシーだ。IAM ポリシーと異なり、権限を直接付与しない。SCP と IAM ポリシーの論理積（AND）が実際に使用できる権限になる。
アカウントで使用できる権限 =
SCP で許可されている AND IAM ポリシーで許可されているSCP の設計パターン
ガードレール型（Deny リスト）：許可リストに載せた以外を Deny
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["ec2:RunInstances"],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"ec2:InstanceType": ["t3.micro", "t3.small", "t3.medium"]
}
}
}
]
}この例では、指定インスタンスタイプ以外の EC2 起動を組織全体で禁止できる。
ルート制限型：管理アカウント以外で特定リージョンを禁止
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
}
}
}| 評価項目 | SCP 推奨 | IAM ポリシー |
|---|---|---|
| 適用対象 | OU / アカウント全体 | ユーザー・ロール・グループ単位 |
| 権限の付与 | ❌ 付与しない（上限を定める） | ✅ 直接付与する |
| 管理アカウントへの適用 | ❌ 適用されない | ✅ 適用される |
| 明示的 Deny の優先 | ✅ 常に優先（IAM を上書き） | ✅ 常に優先 |
| 主な用途 | 組織全体のガードレール設定 | 個別のアクセス権限設定 |
5. パターン3：Control Tower / Landing Zone 自動化
Control Tower とは
AWS Control Tower は セキュアなマルチアカウント環境（Landing Zone）を自動セットアップするサービスだ。Organizations・Config・CloudTrail・IAM Identity Center・Security Hub などを一括で有効化し、ガードレール（Guardrails）を適用する。
Control Tower が自動セットアップするもの
| 自動化される設定 | 内容 |
|---|---|
| OU 構造 | Security OU / Sandbox OU の作成 |
| Log Archive アカウント | CloudTrail ・Config ログの集約アカウント |
| Audit アカウント | セキュリティ監査用アカウント |
| Guardrails（SCP） | 必須のセキュリティ SCP の一括適用 |
| Account Factory | 新規アカウント作成の自動化テンプレート |
| IAM Identity Center | SSO の自動設定 |
Guardrails の種類
Mandatory Guardrails（必須・変更不可）
→ S3 パブリックアクセスブロック必須
→ CloudTrail の無効化禁止
Strongly Recommended Guardrails（強く推奨）
→ MFA なしの root ユーザー操作禁止
→ 暗号化されていない EBS ボリューム禁止
Elective Guardrails（任意選択）
→ 特定リージョンのみ許可
→ 特定インスタンスタイプのみ許可6. パターン4：IAM Identity Center による一元アクセス管理
IAM Identity Center（旧 AWS SSO）とは
IAM Identity Center は 単一の ID で複数の AWS アカウントや SaaS アプリにアクセスできる SSO（シングルサインオン）サービスだ。企業の既存 IdP（Active Directory・Okta・Azure AD 等）と SAML 2.0 で連携できる。
仕組み
ユーザー
↓ 1回のログイン（SAML 2.0 / OIDC）
IAM Identity Center
↓ Permission Set（ロール定義）を各アカウントに展開
複数の AWS アカウント
├─ 本番アカウント（ReadOnly Permission Set）
├─ 開発アカウント（PowerUser Permission Set）
└─ 監査アカウント（SecurityAudit Permission Set）Permission Set
Permission Set は IAM ポリシーのテンプレートだ。Identity Center でセットを定義しておくと、各アカウントで対応する IAM ロールが自動作成される。
| Permission Set 例 | 適用ポリシー | 用途 |
|---|---|---|
| ReadOnly | ReadOnlyAccess | 閲覧専用ユーザー |
| PowerUser | PowerUserAccess | 開発者（IAM 操作のみ制限） |
| AdministratorAccess | AdministratorAccess | 管理者 |
| SecurityAudit | SecurityAudit | セキュリティ監査者 |
| 評価項目 | IAM Identity Center 推奨 | クロスアカウント AssumeRole |
|---|---|---|
| アクセス方法 | SSO ポータルで一元ログイン | ロールごとに assume-role コマンドが必要 |
| IdP 連携 | ✅ Active Directory / Okta / Azure AD 対応 | ❌ AWS IAM ユーザーが必要（外部 IdP は別途設定） |
| ロール管理 | ✅ Permission Set で一元管理 | △ アカウントごとに個別ロール定義が必要 |
| 監査ログ | ✅ CloudTrail に自動記録 | ✅ CloudTrail に自動記録 |
| 推奨用途 | 多アカウント組織のエンドユーザーアクセス | サービス間・自動化処理のロール連携 |
7. パターン5：AWS RAM によるリソース共有
AWS RAM（Resource Access Manager）とは
AWS RAM は 1つのアカウントで作成したリソースを、他のアカウントと共有するサービスだ。Organizations 内のアカウントと共有すれば、各アカウントが同じリソースを重複作成する必要がなくなる。
RAM で共有できる主なリソース
| リソース | 共有の目的 | SAA 頻出シナリオ |
|---|---|---|
| VPC サブネット | 共有 VPC でネットワークを一元管理 | Network アカウントの VPC をアプリアカウントと共有 |
| Transit Gateway | 複数 VPC・アカウントのハブ接続 | 全アカウントを Transit Gateway で集中ルーティング |
| Route 53 Resolver Rules | DNS 解決ルールの共有 | オンプレDNSへの名前解決を全アカウントで共有 |
| AWS License Manager | ソフトウェアライセンスの共有管理 | Windows Server ライセンスの組織横断管理 |
| AWS Outposts | オンプレミス環境の共有 | 物理インフラを複数アカウントで共有 |
共有 VPC アーキテクチャ（SAA 頻出パターン）
Network アカウント（VPC オーナー）
┌────────────────────────────────────────┐
│ VPC 10.0.0.0/16 │
│ ├─ サブネット A（RAM で App1 に共有） │
│ ├─ サブネット B（RAM で App2 に共有） │
│ └─ Transit Gateway（全アカウントに共有） │
└────────────────────────────────────────┘
↓ AWS RAM 共有
┌──────────────┐ ┌──────────────┐
│ App1 アカウント │ │ App2 アカウント │
│ サブネット A に │ │ サブネット B に │
│ EC2 を配置 │ │ RDS を配置 │
└──────────────┘ └──────────────┘8. 試験頻出シナリオ → 解法パターン早見表
SAA-C03 で出やすいシナリオを要件文のキーワードと正解選択肢で整理する。
| 要件文のキーワード | 正解サービス / 設定 | 落とし穴 |
|---|---|---|
| 複数アカウントに同じポリシーを一括適用 | Organizations + SCP | SCP 単体では権限を付与できない |
| 新しいアカウントに毎回同じセキュリティ設定を自動適用 | Control Tower + Account Factory | 手動で SCP を設定しても自動化されない |
| 社員が複数アカウントをSSO で横断アクセス | IAM Identity Center | IAM ユーザーを各アカウントに作成するのは非推奨 |
| 特定リージョン以外でのリソース作成を禁止 | SCP で aws:RequestedRegion 条件 | IAM ポリシーだけでは組織全体に適用できない |
| 本番アカウントのコスト誤超過を防ぐ | Organizations + Cost Explorer + 予算アラート | SCP はコスト制御ではなくアクション制御 |
| 複数 VPC を重複作成せず共有したい | AWS RAM（Shared VPC） | VPC Peering は共有ではなく接続 |
| 複数 VPC を接続してルーティングを集中管理 | Transit Gateway（+ RAM で共有） | VPC Peering はスケールしない（N対N） |
| CloudTrail ログを改ざんできない場所に保存 | Log Archive アカウント（S3） + SCP で削除禁止 | 同一アカウント内の S3 は管理者が削除できる |
| 管理アカウントにも SCP を適用したい | ❌ 不可（Organizations の制限） | 管理アカウントは SCP の対象外 |
| Azure AD / Okta のユーザーで AWS にサインイン | IAM Identity Center + SAML 2.0 連携 | IAM ユーザーを別途作成しない |
9. 次のアクション チェックリスト
SAA 試験本番でマルチアカウント問題を確実に正解するための確認事項：
- SCP は上限設定（ガードレール）であり権限付与ではない ことを即答できる
- 管理アカウントには SCP が適用されない ことを覚えている
- Organizations の OU 階層と SCP の継承（ルート → OU → アカウント の順に伝播）を理解している
- Control Tower = Landing Zone の自動化 であり、Account Factory で新規アカウントを標準化できることを知っている
- IAM Identity Center = 人間の SSO（サービス間の AssumeRole とは区別）を理解している
- AWS RAM = VPC・Transit Gateway などのリソース共有（VPC Peering・接続とは違う）を即答できる
- Log Archive アカウント の目的（CloudTrail ログの改ざん防止・監査用分離）を説明できる
10. 関連記事
- SAA IAM 設計問題の頻出パターン10選 — SCP の詳細・ポリシー評価ロジック
- SAA VPC 設計パターン — Shared VPC・Transit Gateway のネットワーク設計
- SAA 高可用性設計パターン — マルチ AZ・マルチリージョン設計
- SAA-C03 試験ガイド完全版 — 試験全体像と各ドメイン配点