Instiq
第1章 · 組織の複雑さに対応する設計·v2.1.0·更新 2026/7/16·読了目安 約11分

変更要約: 軸B網羅: ガバナンス/セキュリティ/EUC 関連サービスのカタログ節(s4)を追加

1.1マルチアカウント戦略とガバナンス

この節の要点

大規模組織の基盤となる AWS Organizations、組織単位（OU）、サービスコントロールポリシー（SCP）、一括請求、Control Tower を理解します。複数アカウントを安全・統制的に運用します。

プロフェッショナルでは複数アカウントの統制が中心テーマです。AWS Organizations でアカウントを階層化し、ガードレールと請求を一元化します。

1.1.1AWS Organizations の構成

管理アカウント（management account）を頂点に、ルートの下に組織単位（OU）が階層化され（例: Security OU・Workloads OU・Sandbox OU）、各 OU にメンバーアカウントが属する AWS Organizations の構造を示し、OU やアカウントに SCP（サービスコントロールポリシー＝許可の上限）が適用され、一括請求でコストを集約、Control Tower が複数アカウントのセットアップとガードレールを自動化する様子を示した図。
AWS Organizations と統制
  • AWS Organizations：複数アカウントをルート→OU→アカウントの階層で一元管理する。
  • SCP（サービスコントロールポリシー）：OU/アカウントの許可の上限（ガードレール）を定義する。権限を付与するのではなく制限する。
  • 一括請求：組織全体の請求を統合し、ボリューム割引や RI/Savings Plans を共有する。
  • Control Tower：マルチアカウント環境（ランディングゾーン）のセットアップとガードレールを自動化する。
試験ポイント

「SCP は許可の上限であって権限付与ではない」（IAM の許可と SCP の両方で許可されて初めて有効）「組織横断の請求集約＝一括請求」「ランディングゾーン自動化＝Control Tower」 は SAP-C02 で頻出です。管理アカウントのルートユーザーには SCP が効かない点にも注意。

補足

SCP は管理アカウント自体には適用されません。重要な統制は専用の OU（例: Security/Infrastructure）に分けて適用するのが定石です。

プロのマルチアカウント設計は AWS Organizations を土台に、用途別アカウントを OU でグループ化します（例：Security OU＝ログアーカイブ/監査、Infrastructure OU＝共有ネットワーク、Workloads OU＝本番/開発、Sandbox OU）。アカウント分離は爆発半径の局所化・課金/権限境界・サービスクォータ確保に有効です。SCP は 許可の上限（ガードレール） で、実効権限は IAM の許可 ∩ SCP の許可（DENY が常に優先）。FullAWSAccess の継承や、明示 Deny でのリージョン/サービス制限を組み合わせます。Control Tower は ランディングゾーン（複数 OU・ログ集約・SSO）を自動構築し、コントロール（旧ガードレール） を予防的（SCP）/発見的（Config ルール）/プロアクティブ（CloudFormation Hooks）で適用、Account Factory（や AFT）で標準化アカウントを払い出します。横断ガバナンスは Config アグリゲーター・CloudTrail 組織証跡・委任管理者（GuardDuty/Security Hub 等を Security アカウントに集約）で実現。一括請求は RI/Savings Plans とボリューム割引を組織で共有しつつ、コスト配分タグ と AWS Budgets でアカウント別に可視化します。

仕組み役割効力
SCPOU/アカウントの許可の上限IAM と両方で許可・DENY 優先
IAM ポリシープリンシパルへの権限付与実際に許可を与える
Control Towerランディングゾーン/コントロール自動化予防/発見/プロアクティブ
一括請求請求の集約・割引共有組織全体で最適化
補足

シナリオ： 全アカウントで「承認リージョン以外の利用を禁止」「ルートユーザーのアクセスキー作成を禁止」したい。→ ルート/該当 OU に Deny ベースの SCP を割り当て（未承認リージョンの全アクション Deny、iam:CreateAccessKey をルート向けに Deny）。新規アカウントは Control Tower の Account Factory で同じガードレール付きに払い出し、逸脱は Config と Security Hub で検出します。

補足

FAQ： Q. SCP で許可を「付与」できますか？ → A. いいえ。SCP は上限を定めるだけで、実際の付与は IAM。両方で許可されて初めて操作でき、Deny は常に優先します。Q. 組織全体の脅威検知を一元化するには？ → A. GuardDuty/Security Hub を委任管理者（Security アカウント）に集約し、組織で有効化します。

注意

ひっかけ： 「SCP を割り当てればユーザーに権限が付与される」は誤りです。SCP は上限で、付与は IAM（両方で許可＋Deny 優先）。また「SCP は管理アカウントにも効く」も誤り（管理アカウントには適用されない＝重要統制は専用 OU 配下のメンバーアカウントで行う）。

1.1.2この節のまとめ

  • Organizations＝ルート→OU→アカウントの階層統制
  • SCP＝許可の上限／請求＝一括請求／自動化＝Control Tower

進捗の記録にはログインが必要です。

理解度チェック

（軽い確認用）

Q1. 組織内の特定の OU 配下のアカウントで「絶対に特定リージョン以外を使わせない」ガードレールを課したい。何を使いますか？

Q2. SCP の性質として正しいものはどれですか？

Q3. 多数の新規アカウントを、標準化されたガードレール付きで素早く払い出すマネージドな仕組みはどれですか？

理解度を確認第1章「組織の複雑さに対応する設計」の問題を解く