AWS Organizationsの仕組みと設計｜OU・SCP/RCP・委任管理者・IaCでの組織管理

AWSのアカウントが増えたら、AWS Organizationsで束ねます。管理アカウント/Root/OUの構造、SCPとRCPのガードレール、委任管理者による分権、そしてIaCでの組織管理まで——Organizationsの仕組みそのものを、マルチアカウント統制の実務目線で整理します。

01アカウントが増えたら、Organizationsで束ねる

AWSを本気で使い始めると、アカウントは1つでは足りなくなります。本番と検証を分け、セキュリティを分け、部署やプロジェクトで分け——気づけば十数〜数十アカウント。これをバラバラに管理すると破綻します。

その"束ね役"が AWS Organizations です。複数アカウントをOU（組織単位）でグルーピングし、Root・OUにガードレール（SCP/RCP）を敷き、サービスの組織管理を委任管理者に寄せる。全体像はこうなります。

この記事では、Organizations の仕組みそのもの——構造、OU設計、SCP/RCP、委任管理者、そしてIaC（コード）での管理——を実務目線で整理します。「なぜ複数アカウントに分けるのか」という戦略面は姉妹編のAWSアカウントの考え方（マルチアカウント戦略）をどうぞ。

02構造 — 管理アカウント／Root／OU／メンバー

Organizations は、Root を頂点に OU をネストしたツリー構造です。構成要素はシンプル。

• 管理アカウント（Management、旧マスター）：組織を作成した唯一の特別なアカウント。アカウント作成/招待、委任管理者の指定、ポリシー付与、支払いを担う。変更不可。
• Root：組織に1つだけの最上位コンテナ（自動作成・削除不可）。
• OU（組織単位）：アカウントの論理グループ。ネスト可能で、Rootから最下層まで最大5階層。親OUのポリシーは子に継承される。
• メンバーアカウント：管理アカウント以外のアカウント。

03OU設計 — 「組織図」ではなく「共通コントロール単位」で切る

OU設計の原則は、組織図（指揮系統）で切らないこと。機能・共通コントロール単位でグルーピングします。AWS推奨は、まず Security と Infrastructure から着手する形です。

• Security OU：ログアーカイブ、セキュリティツール、監査（読み取り専用）、break-glass 用アカウント
• Infrastructure OU：ネットワーク等の共有インフラ／ITサービス
• Workloads OU：業務ワークロード。配下を SDLC（非本番）／ Prod に分け、本番を隔離
• Sandbox OU：開発者の実験用（社内ネットから切り離せること）
• ほかに Policy Staging（ポリシー検証）／Suspended（閉鎖待ち・全拒否SCP）／Exceptions（特殊要件）など

04SCP と RCP — Root・OU に敷くガードレール

OU/Root に付ける"ガードレール"が SCP（Service Control Policy） と RCP（Resource Control Policy） です。どちらも権限を"与えず"、上限を絞るだけ——実効権限は各IAMポリシーとの論理積になります。

05委任管理者 — 管理アカウントで運用しない

管理アカウントは「組織の金庫番」。ここで日々のサービス運用をやると、権限集中に加えてSCPが効かない特権まで抱え、攻撃対象が肥大化します。だから運用は 委任管理者（delegated administrator） で他アカウントへ寄せます。

• 委任管理者＝特定サービスの組織全体管理を専用メンバーアカウントに任せる仕組み。前提として trusted access（信頼されたアクセス）を有効化（多くはサービス側の操作で同時に有効化される）。
• 委任できる代表サービス：GuardDuty／Security Hub／Detective／Macie／Inspector／IAM Access Analyzer／Config／CloudTrail（組織証跡）／Firewall Manager／Security Lake／IAM Identity Center／CloudFormation StackSets／AWS Backup など。
• 定番パターン：セキュリティ系を監査専用の Security（Audit）アカウントに委任集約し、管理アカウントにセキュリティ運用権限を持たせない。
• 委任できないもの：Control Tower／RAM／Directory Service／Billing 等は管理アカウント運用のまま。

06IaCでのOrganizations管理 — コードで再現可能にする

手作業でOU・SCP・アカウントを作ると、再現も追跡もできません。IaCでコード化すれば、構造をレビュー・履歴管理・再現できます。ただしOrganizationsのIaCには「効きすぎるがゆえの注意」があります。

Terraform（主要リソース）：

• aws_organizations_organization（組織本体。feature_set=ALL、trusted accessを有効化する service principal、有効化ポリシー種別）／aws_organizations_organizational_unit／aws_organizations_account／aws_organizations_policy（type＝SCP／RCP／TAG／BACKUP 等）／aws_organizations_policy_attachment／aws_organizations_delegated_administrator
• 既存の組織は必ず import して起点にする。aws_organizations_organization を destroy すると組織全体の削除につながり得るため極めて危険。
• アカウントは非可逆：削除しても既定は「離脱」のみ（閉鎖は close_on_deletion=true）。誤 apply/destroy 防止に lifecycle{prevent_destroy=true}、読めない引数は ignore_changes=[role_name]。

CloudFormation StackSets（組織横断の展開）：

• service-managed 権限モデルなら、Organizations統合で必要なIAMロールをStackSetsが自動作成（self-managedと違い自動展開が使える）。
• automatic deployment：展開先にOUを指定すると、そのOUに将来追加されるアカウントへ自動でスタックが展開される（ベースライン配布の定番）。
• 委任管理者から回すなら call_as=DELEGATED_ADMIN（管理アカウントでの実行を減らす）。

AWS Control Tower / AFT：

• Control Tower は Organizations・StackSets・SCP・Config を内部でオーケストレートするマネージドサービス。ランディングゾーンで Security OU（Log Archive／Audit）・IAM Identity Center・予防的（SCP）/検出的（Config）コントロールを一括セットアップ。
• AFT（Account Factory for Terraform）：Control Towerのアカウント払い出しを Terraform＋GitOps で回す仕組み（専用のAFT管理アカウントが必要・既存ランディングゾーン前提）。
• 判断軸：マネージドで即ガードレールが欲しい→Control Tower、TFで払い出しを標準化→AFT、完全に自前で組む→素のOrganizations＋StackSetsをTerraform/CFnで。CT管理リソースをTerraformで書き換えない（ドリフトの元）。

07管理アカウントの衛生 — ここだけは過剰に守る

管理アカウントはSCPが効かない＝特権が素通しになります。だから最も厳重に扱います。

• ワークロード/データを置かない（SCPが効かないため）。リソースは他アカウントへ。
• root はハードウェアMFA・日常利用しない（root MFAは2024〜2025で全アカウント種別に必須化）。
• Centralized Root Access でメンバーの root 資格情報を中央削除、必要時のみ sts:AssumeRoot（最大15分・タスク限定）。
• 離脱防止SCP：Root に organizations:LeaveOrganization と account:CloseAccount を Deny（2026年7月以降にコンソールで作成した組織には自動付与、旧組織・CLI作成分は手動）。
• email／MFA／電話番号の保有者を定期棚卸し、復旧手順を特定個人に依存させない。

08まとめ — 束ねて、ガードレールを敷き、委任する

Organizations の骨格は4つ——①複数アカウントをOUで束ね、②Root・OUにSCP/RCPでガードレールを敷き、③運用は委任管理者へ寄せ、④管理アカウントは金庫番に徹する。そしてIaCでコード管理すれば、この構造を再現可能・追跡可能にできます。

EMWは、マルチアカウントの設計・統制基盤づくりを実務で扱ってきました。「アカウントが増えて管理が追いつかない」段階から、OU設計・ガードレール・委任の型を一緒に整えます。

あわせて、なぜ複数アカウントに分けるかはマルチアカウント戦略、IDでの束ね方はID統制の記事、サービス名の対応はAWS・Azure・GCP・オンプレ 対応表もどうぞ。

09よくある質問（FAQ）