- 1 1. はじめに — D1「組織的複雑性への設計」とは
- 2 2. AWS Organizations / SCP / OU構造 — マルチアカウント統治の核心
- 3 3. AWS Control Tower / Landing Zone / AFT — ガバナンス自動化の選択軸
- 4 4. マルチアカウントネットワーク統合 — TGW/Direct Connect/VPN/PrivateLink
- 5 5. ハイブリッドDNS — Route 53 Resolver Endpoints の設計
- 6 6. IAM Identity Center（SSO）とフェデレーション — 統合認証基盤
- 7 7. Service Catalog / CloudFormation StackSets — ガバナンス自動化
- 8 8. DR戦略（RTO/RPO）とコスト可視化 — 組織横断の回復性管理
- 9 9. CertTrend LMS D1問題演習
- 10 10. 実務で深掘り — D1関連 本番運用記事
1. はじめに — D1「組織的複雑性への設計」とは
本記事は「AWS SAP-C02 試験対策」シリーズの Vol1 です。
まだシリーズ全体像をつかんでいない方は、4ドメインの俯瞰と300問LMSへの導線を解説した Vol0 ロードマップを先にご覧ください。
AWS Certified Solutions Architect – Professional（SAP-C02）は75問・180分の試験で、出題は4つのドメインに分かれています。
そのなかで D1「Design Solutions for Organizational Complexity（組織的複雑性への設計）」 は配点26%・約78問と、単独ドメインとしては第2位の出題比率を持ちます。
Professional 帯の最大の特徴は「なぜそのアーキテクチャを選ぶか」という設計判断とトレードオフ評価が問われる点です。
単一サービスの機能暗記だけでは正答できない設問が多く、「複数サービスを組み合わせて要件を満たす最適解を選ぶ」能力が試されます。
- D1の出題範囲と6つの設計領域の全体像（§1〜§2）
- AWS Organizations / SCP / OU構造 — マルチアカウント統治の核心（§2）
- AWS Control Tower / Landing Zone / AFT — ガバナンス自動化の選択軸（§3）
- マルチアカウントネットワーク統合 — TGW/Direct Connect/VPN/PrivateLinkのトレードオフ（§4）
- ハイブリッドDNS — Route 53 Resolver Endpointsの設計判断（§5）
- IAM Identity Center（SSO）とフェデレーション — 統合認証基盤（§6）
- Service Catalog / CloudFormation StackSets — ガバナンス自動化の実践（§7）
- DR戦略（RTO/RPO）とコスト可視化 — 組織横断の回復性とコスト管理（§8）
1-1. D1の出題範囲を6軸で整理する
D1 は名称こそ「組織的複雑性」ですが、実際は マルチアカウント統治・ネットワーク統合・アイデンティティ・DR・コスト可視化 という広範な領域をカバーします。
| 軸 | テーマ | 代表サービス |
|---|---|---|
| 1 | マルチアカウント統治 | Organizations / SCP / Control Tower |
| 2 | ネットワーク接続戦略 | Transit Gateway / Direct Connect / VPN / PrivateLink |
| 3 | ハイブリッドDNS | Route 53 Resolver Inbound/Outbound Endpoints |
| 4 | 統合アイデンティティ | IAM Identity Center / SAML 2.0 / SCIM |
| 5 | ガバナンス自動化 | Service Catalog / CloudFormation StackSets |
| 6 | 回復性とコスト管理 | DR戦略（RTO/RPO）/ Cost Explorer / Budgets |
試験での設問は「100アカウントの組織でセキュリティポリシーを一元施行するにはどうするか」「オンプレミスのActive Directoryと AWS の IAM を統合するには何が最短か」という組織横断の設計シナリオが典型です。
- Professional は「Associate と何が違うか」を常に意識しましょう。Associate が「どのサービスを使うか」を問うのに対し、Professional は「なぜその設計か・トレードオフは何か」を問います
- マルチアカウント設計の問題では「SCP vs IAM Policy」「Control Tower vs Organizations単独」「TGW vs VPC Peering」という比較軸が頻出です
- 「設計の判断基準」として RTO/RPO・コスト・運用負荷・セキュリティのどれを優先するかが設問の分かれ目になります
2. AWS Organizations / SCP / OU構造 — マルチアカウント統治の核心
問題バンク実測では Organizations は19回出現し、 Control Tower は29回という高頻度です。
なぜマルチアカウントにするのか という根本から押さえましょう。
2-1. なぜマルチアカウントか — 単一アカウントとの比較
| 比較軸 | 単一アカウント | マルチアカウント |
|---|---|---|
| 障害爆発半径 | 全システムに波及 | アカウント単位で隔離 |
| セキュリティ境界 | IAM Policy のみ | IAM + アカウント境界（物理的分離） |
| 請求・コスト管理 | 全体一括請求のみ | 部門/プロジェクト別可視化 |
| コンプライアンス | 全環境に同一統制 | 環境別（本番/ステージング/開発）に統制レベルを変更 |
| SCP（サービス制御ポリシー） | 使用不可 | OU単位で強制適用 |
マルチアカウントは「管理オーバーヘッドが増える」デメリットがありますが、大規模組織ではセキュリティと運用効率のバランスを取る唯一の現実解です。
試験では「大規模な企業でアカウントが200を超えている」という前提のシナリオが多く登場します。
2-2. OU（組織単位）の設計思想
OU はツリー構造で、ルートの直下にいくつかのトップレベル OU を置くのが一般的です。
典型的な OU 設計パターンは以下の通りです。
Root
├── Infrastructure OU（共有インフラ：Network Hub・ログ集約・セキュリティツール）
├── Workloads OU
│├── Production OU
│├── Staging OU
│└── Dev OU
├── Sandbox OU（実験的アカウント・緩い制限）
├── Security OU（セキュリティログ・監査専用）
└── Suspended OU（廃止予定アカウントの隔離）
設計のポイント（Professional 差別化）:
- Sandbox OU を本番 OU と分離することで、開発者が自由に実験しながら本番への影響ゼロを保証できます
- Security OU に集約ログアカウントを置くことで、セキュリティチームは本番アカウントへのアクセスなしに全ログを参照できます
- OU の深さは3〜4層が推奨です。深すぎる OU ツリーは SCP の継承関係が複雑になり、トラブルシュートが困難になります
2-3. SCP（サービス制御ポリシー）— 予防的ガードレールの設計軸
SCP は「特定のアクションを永続的に禁止する」予防的ガードレールです。
IAM Policy が「特定のユーザーに何を許可するか」を制御するのに対し、SCP は アカウント・OU レベルで何が実行可能かの最大範囲 を絞ります。
SCP の核心を一文で言えば：「SCP が許可 + IAM Policy が許可 = 実行可能（どちらかが拒否すれば拒否）」です。
| SCP タイプ | 内容 | 使い所 |
|---|---|---|
| Deny リスト（許可ベース + 明示的 Deny） | FullAWSAccess を継承した上で特定アクションを Deny | 禁止事項を明示したい場合（推奨） |
| Allow リスト（明示的 Allow のみ） | FullAWSAccess を外してホワイトリストで許可 | 極めて厳密な統制が必要な場合。管理コストが高い |
Professional 頻出シナリオ: 「特定のリージョンのみ使用を許可する」SCPは以下のような構造になります。
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
}
}
}
SCP の設計判断 — よくある誤解:
- SCP は IAM の代替ではなく補完です。SCP で「S3:DeleteBucket を全 OU に Deny」してもバックアップポリシーやリソースポリシーには影響しません
- Management Account（旧 Master Account）には SCP が適用されません。そのため管理アカウントでの作業は最小化し、ほぼ使用しない運用が推奨されます
- SCP の変更は OU 配下の全アカウントに即時適用されます。テストは Sandbox OU で行い、本番 OU への適用は慎重に進める設計が必要です
3. AWS Control Tower / Landing Zone / AFT — ガバナンス自動化の選択軸
Control Tower は Organizations の上にガバナンスレイヤーを追加するマネージドサービスです。
「Organizations だけでいいか Control Tower も使うべきか」はProfessional 頻出の設計判断です。
3-1. Organizations vs Control Tower — 選択の判断軸
| 項目 | Organizations 単独 | Control Tower + Organizations |
|---|---|---|
| アカウント発行の自動化 | 手動 or カスタムスクリプト | Account Factory（GUI/API/Terraform）で自動化 |
| ガードレール（SCP + Config Rules） | 手動設定 | 事前定義ガードレールがあらかじめ適用 |
| 監査ログ集約 | 手動設定 | Log Archive アカウントへ自動集約 |
| セキュリティ監視 | 手動設定 | Audit アカウントへ自動集約 |
| カスタマイズ性 | 高い（すべて自由設定） | ガードレールの枠内で制限あり |
| 導入工数 | 高い（ゼロから設計） | 低い（数時間で Landing Zone 完成） |
設計の判断基準: 「100アカウント以上の大規模組織で一貫したガバナンスを素早く立ち上げる」場合は Control Tower が最適解です。
逆に「既存の Organizations 設計に特殊な要件がありコントロール外の OU が必要」な場合は Organizations 単独の管理が合う場合もあります。
3-2. Landing Zone の構成要素
Control Tower が作成する Landing Zone は以下の構成です。
- Management Account: 組織全体の請求と Organizations の管理
- Log Archive Account: CloudTrail・Config の全ログを集約（Security OU 配下）
- Audit Account: セキュリティアラート・AWS Security Hub・IAM Access Analyzer（Security OU 配下）
- デフォルト OU 構造: Security OU / Sandbox OU（カスタマイズ可能）
3-3. Account Factory for Terraform（AFT）とAccount Factory
新規アカウントの発行方法には3種類あります。
| 方法 | 特徴 | 適した場面 |
|---|---|---|
| Account Factory（コンソール） | GUI から発行・即時 | 少数のアカウントを都度発行 |
| Account Factory API / Service Catalog | プログラマティックに発行 | CI/CD から自動発行 |
| AFT（Account Factory for Terraform） | Terraform ベースで GitOps 的に管理 | IaC 管理を標準化したい大規模組織 |
AFT は Terraform によって Account Factory の呼び出しを管理し、アカウント発行後のカスタマイズ（ランディングゾーン後の追加設定）も Terraform で定義できます。
「アカウントをコードで管理したい」という要件が出た場合は AFT が最適解です。
3-4. Customizations for Control Tower（CfCT）
CfCT は CloudFormation StackSets と Service Catalog を組み合わせて、アカウント発行後に追加のリソース（追加 SCP・IAM Role・Config Rules など）を自動デプロイするフレームワークです。
AFT が Terraform ベースなのに対し、CfCT は CloudFormation ベースであり、既存の CloudFormation 資産が豊富な組織に向いています。
4. マルチアカウントネットワーク統合 — TGW/Direct Connect/VPN/PrivateLink
D1 のネットワーク設問は「オンプレミスと複数の VPC をどのように接続するか」というハイブリッド接続設計が中心です。
問題バンクでは VPC が179回・Transit Gateway が24回・PrivateLink が19回出現します。
4-1. VPC 間接続の選択肢とトレードオフ
| 接続方式 | 帯域 | 推移的ルーティング | 管理コスト | 適した場面 |
|---|---|---|---|---|
| VPC Peering | 高い | 不可 | 低い（接続先が少ない場合） | 少数 VPC 間の直接接続 |
| Transit Gateway（TGW） | 高い | 可能 | 中程度 | 多数 VPC・マルチアカウント間の hub-and-spoke 接続 |
| AWS PrivateLink | 高い | サービス公開のみ | 低い〜中程度 | 特定サービスをプライベートに公開 |
| Cloud WAN | 高い | 可能 | 高い | グローバル・マルチリージョンのWANをマネージドに管理 |
Professional 頻出の判断軸:
- 「50 VPC を接続する」→ VPC Peering は N×(N-1)/2 の接続数が必要（フルメッシュ）→ TGW が最適解
- 「SaaS サービスを他アカウントに安全に公開する」→ PrivateLink
- 「推移的ルーティングが必要か」→ VPC Peering は不可（A→B→C の推移は通らない）→ TGW
4-2. Transit Gateway の設計ポイント
TGW はリージョン内のハブです。複数の VPC・VPN・Direct Connect Gateway をアタッチして中央ルーティングを提供します。
オンプレミス
│ (Direct Connect / VPN)
▼
Transit Gateway
├── 本番 VPC
├── ステージング VPC
├── 共有サービス VPC（DNS, LDAP）
└── セキュリティ検査 VPC（Firewall Appliance）
TGW ルートテーブルの設計:
– 本番 VPC とステージング VPC を分離するために 複数の TGW ルートテーブル を使います
– セキュリティ検査 VPC を挟む場合は、Appliance Mode を有効にして対称ルーティングを保証します
4-3. Direct Connect vs VPN — 接続品質のトレードオフ
| 比較軸 | Direct Connect（専用線） | Site-to-Site VPN（インターネット経由） |
|---|---|---|
| 帯域保証 | あり（1Gbps / 10Gbps / 100Gbps） | なし（ベストエフォート） |
| レイテンシ安定性 | 高い | インターネット状況に依存 |
| 冗長化 | 別ロケーションで2回線が推奨 | 2トンネルで自動冗長 |
| 導入リードタイム | 数週間〜数ヶ月 | 即日 |
| コスト | 高い（回線費用 + アウトバウンドデータ転送） | 低い |
設計の典型パターン: 「Direct Connect をプライマリ、VPN をフェイルオーバー」とするハイブリッド構成が Professional 頻出です。
Direct Connect のフェイルオーバーとして VPN を BFD で自動切り替えする設計が問われます。
4-4. PrivateLink — サービス公開の標準パターン
PrivateLink は「サービス提供側 VPC にエンドポイントサービスを作成し、消費側 VPC に Interface VPC Endpoint を作成する」ことでプライベートアクセスを実現します。
- 利点: サービス提供 VPC の IP 帯域が消費側に露出しない。VPC Peering と異なり CIDR 重複を気にしない
- 注意点: 双方向通信（消費側→提供側のみ）。提供側→消費側への接続は PrivateLink では不可
5. ハイブリッドDNS — Route 53 Resolver Endpoints の設計
マルチアカウント・ハイブリッド環境では DNS 解決が複雑になります。
問題バンクでは Route 53 が複数ドメインをまたいで言及されており、Resolver Endpoints の仕組みを正確に理解することが重要です。
5-1. DNS 解決の課題と Resolver Endpoints の役割
オンプレミスに独自の DNS サーバーがある場合、以下の2方向の解決が必要です。
| 方向 | 課題 | 解決策 |
|---|---|---|
| AWS → オンプレミス | VPC 内からオンプレミスの FQDN を解決できない | Resolver Outbound Endpoint（フォワーダー）を設置し、オンプレDNSへ転送 |
| オンプレミス → AWS | オンプレからプライベートホストゾーンの FQDN を解決できない | Resolver Inbound Endpoint（リゾルバー受付口）を設置し、オンプレDNSからのクエリを受け付け |
オンプレミス DNS Server
│ クエリ (corp.example.com の解決要求)
▼
Route 53 Inbound Endpoint（ENI × 2、2AZ）
│
▼
Route 53 Resolver → プライベートホストゾーン
5-2. マルチアカウントでの共有 DNS 設計
複数アカウントが同じ DNS ゾーンを参照する場合、Route 53 のプライベートホストゾーンを RAM（Resource Access Manager）でアカウント間共有します。
- 共有サービス VPC アカウントにプライベートホストゾーンを作成
- RAM で各ワークロードアカウントの VPC に共有
- Inbound/Outbound Endpoint も共有サービス VPC に集中配置して運用コストを削減
6. IAM Identity Center（SSO）とフェデレーション — 統合認証基盤
大規模組織では「何十ものAWSアカウントに個別のIAM Userを作る」アンチパターンを避け、一元的なID管理が必要です。
6-1. IAM Identity Center の全体像
IAM Identity Center（旧 AWS SSO）は Organizations と統合し、Permission Sets を OU やアカウントに割り当てることで一元的なアクセス管理を実現します。
| 要素 | 内容 |
|---|---|
| Identity Source | Identity Center 内部ストア / 外部 IdP（Okta、Azure AD 等）/ AD Connector |
| Permission Sets | AWS マネージドポリシーまたはカスタムポリシーの組み合わせ。アカウントにアタッチすると IAM Role として具現化 |
| SCIM プロビジョニング | 外部 IdP からユーザー/グループを自動同期（手動管理不要） |
| ABAC（属性ベースアクセス制御） | ユーザー属性（部署・職位）に基づいて Permission Sets を動的に割り当て |
6-2. 外部 IdP との SAML 2.0 フェデレーション
企業が既存の Active Directory や Okta を持つ場合、SAML 2.0 フェデレーションで統合します。
フローの概要：
- ユーザーが企業ポータルにログイン（Okta / Azure AD など）
- IdP が SAML アサーションを生成
- IAM Identity Center または STS が一時クレデンシャルを発行
- AWS マネジメントコンソールまたは CLI でアクセス
設計の判断軸:
– IAM Identity Center経由SAML: アカウント横断のSSO管理が容易。Permission Sets で複数アカウントへの一括アクセス割り当て可能。Organizations連携が前提
– IAM単独SAML（AssumeRoleWithSAML）: Identity Center なしで単一アカウント向けに直接統合。Control Towerなし・Organizations 未使用の場合に選択
6-3. ABAC（属性ベースアクセス制御）の活用
ABAC は「ユーザーの属性（department=Finance）とリソースのタグ（CostCenter=Finance）を照合してアクセスを制御する」設計です。
- メリット: 数万人規模でも Permission Sets のメンテナンスが最小。新規サービス・リソース追加時にポリシー更新が不要
- デメリット: タグの一貫性を強制する仕組み（SCP + Tag Policy）が必要。タグ付けが不完全な環境では機能しない
SAP の設問では「大規模組織で Role の爆発的増加を避けるには」という文脈で ABAC が正答候補として登場します。
7. Service Catalog / CloudFormation StackSets — ガバナンス自動化
7-1. Service Catalog — セルフサービスと統制の両立
Service Catalog は「承認済みの CloudFormation テンプレートをカタログとして公開し、利用者がセルフサービスでプロビジョニングできる」サービスです。
| 役割 | 内容 |
|---|---|
| 管理者（Portfolio 管理） | CloudFormation テンプレートを製品として登録。バージョン管理・アクセス制御 |
| 利用者（End User） | カタログから承認済み製品を選択・デプロイ（IAM 権限なしでプロビジョニング可能） |
Professional の典型用途: 開発者が「自由にEC2を作れるが会社標準のセキュリティ設定（SSM Agent・CW Agent 自動インストール・暗号化）は強制される」という要件を Service Catalog で実現します。
7-2. CloudFormation StackSets — 複数アカウント・リージョンへの一斉展開
StackSets は CloudFormation スタックを 複数のアカウントと複数のリージョンへ同時に展開するサービスです。
| 展開モード | 内容 | 適した場面 |
|---|---|---|
| Self-managed | デプロイ先アカウントの IAM Role を手動で設定 | Organizations 未使用または既存アカウントへの展開 |
| Service-managed（推奨） | Organizations と統合。OU を指定するだけでアカウント自動検出 | Control Tower + Organizations 環境 |
設計のトレードオフ:
– Service-managed StackSets と Control Tower の Customizations（CfCT）は目的の重なる部分があります
– CfCT は「アカウント発行トリガーで自動デプロイ」に特化しており、既存アカウントへの一斉更新には StackSets が適しています
8. DR戦略（RTO/RPO）とコスト可視化 — 組織横断の回復性管理
8-1. DR戦略4パターンの比較
SAP の D1 では DR 戦略を「複数アカウント・複数リージョン」規模で設計する問題が出ます。
| DR 戦略 | RTO | RPO | コスト | 概要 |
|---|---|---|---|---|
| Backup & Restore | 数時間 | 数時間〜1日 | 最低 | スナップショット/バックアップを別リージョンにコピー。障害時に復元 |
| Pilot Light | 数十分〜1時間 | 数分〜数十分 | 低〜中 | コアコンポーネント（DBなど）を DR リージョンで最小起動。障害時にスケールアップ |
| Warm Standby | 数分〜数十分 | 数秒〜数分 | 中〜高 | 縮小スケールで DR リージョンで常時稼働。障害時に本番規模にスケールアップ |
| Multi-Site Active-Active | ほぼゼロ | ほぼゼロ | 高い（約2倍） | 両リージョンが同時に本番トラフィックを処理 |
設計の判断軸: 「RTO 15分・RPO 1分以内」という要件が出た場合、Backup & Restore（RTO 数時間）は不適切であり、Warm Standby または Active-Active が正答候補になります。
コスト制約と RTO/RPO の数値を照らし合わせて「最もコスト効率のよい選択肢」を選ぶのが Professional 的な視点です。
8-2. コスト可視化 — 組織横断のコスト管理
大規模マルチアカウント環境では「どのアカウントのどのプロジェクトがどれだけコストを使っているか」を把握することが重要です。
| サービス | 機能 | 用途 |
|---|---|---|
| AWS Cost Explorer | コスト分析・トレンド表示 | アカウント別・サービス別・タグ別コスト分析 |
| AWS Budgets | コストアラート | 予算上限設定・超過前の通知・Savings Plans活用率追跡 |
| Cost Allocation Tags | コストの属性付け | タグ（Project=A / CostCenter=B）でコストを分類 |
| Cost Anomaly Detection | ML によるコスト異常検知 | 突発的なコスト増加を自動検知・通知 |
| AWS Compute Optimizer | リソース最適化推薦 | EC2・Lambda・ECS のサイジング改善提案 |
Professional 的設計: Cost Allocation Tags の強制は SCP ではなくTag Policies（Organizations の機能）で実施します。
SCP ではタグのない起動を Deny できますが、Tag Policies は組織全体のタグ命名規則を一元管理するためのより適切なメカニズムです。
8-3. 組織横断のセキュリティ統制
D1 の範囲には以下のセキュリティサービスが含まれます。
| サービス | 役割 | 組織横断での使い方 |
|---|---|---|
| AWS Security Hub | セキュリティ発見事項の集約 | Delegated Administrator アカウントに全 OU の発見事項を集約 |
| Amazon GuardDuty | 脅威検知 | Organizations 統合で全アカウントを自動有効化。管理アカウントから一元管理 |
| AWS Firewall Manager | WAF/SG/NF ルールの一元管理 | Firewall Manager 管理者アカウントから OU に WAF WebACL を自動適用 |
| AWS Config | 設定コンプライアンス評価 | Aggregator で全アカウントの Config データを集約。StackSets でカスタムルールを一斉展開 |
9. CertTrend LMS D1問題演習
ここまで D1「組織的複雑性への設計」の主要6領域を解説しました。
概念の理解を試験力に変換するには、実際の問題形式（Multiple choice / Multiple response）での演習が不可欠です。
CertTrend LMS の SAP-C02 コースには、D1 の Organizations/SCP/Control Tower/TGW/DR 戦略を網羅した 300問の問題バンク（75問×本番形式模試含む） があります。
ぜひ活用して、設計判断の選択速度を上げてください。
10. 実務で深掘り — D1関連 本番運用記事
本記事では試験対策の観点から D1 の主要トピックを広く解説しました。
各トピックを実装レベルで深く学びたい方向けに、関連する本番運用解説記事をご紹介します。