AWS Organizations

は、複数の AWS アカウントを組織としてまとめ、権限境界、アカウント構成、請求を一元管理するサービスです。SAA では、とサービスコントロールポリシー（）を使い、開発・本番・セキュリティなどのアカウントへ共通の制約を適用する設計が重要です。

概要

AWS アカウントは、権限、請求、障害影響、サービスを分離する境界として利用できます。では管理アカウントの下にメンバーアカウントを置き、組織単位（）で階層化します。

は権限を付与するポリシーではありません。メンバーアカウント内で許可できる権限の上限を定めます。実際の操作には、SCP の範囲内で IAM ポリシーなどによる Allow が必要です。

主要技術

①組織、管理アカウント、メンバーアカウント

要素	役割	判断ポイント
管理アカウント	組織と請求の管理	日常ワークロードを置かず、アクセスを厳格にします。
メンバーアカウント	業務システムや環境を配置	本番、開発、ログ、セキュリティなどを分離します。
	アカウントの論理グループ	共通ポリシーをまとめて適用します。

組織には有効化する機能のレベルが 2 つあります。既定で使える一括請求だけの組織と、ポリシーによる制御まで使える全機能の組織です。をはじめとする管理ポリシー、の組織インスタンス、他サービスの委任管理者といった機能は、全機能を有効にした組織が前提になります。

有効化のレベル	できること	判断ポイント
一括請求のみ	請求の統合と使用量の合算	費用をまとめるだけの構成です。
全機能	一括請求に加え、SCP などのポリシー制御と他サービスとの統合	権限のや全社的なを作るならこちらが必要です。

一括請求だけの組織は、組織を作り直さずに全機能へ切り替えられます。切り替えるときは、招待で参加したメンバーアカウントがそれぞれ変更を承認する必要があります (組織の中で作成したアカウントは承認不要です)。

複数アカウントへのシングルサインオンを作る場合は、まず全機能を有効にした組織を用意し、そのうえで IAM Identity Center を組織レベルで有効化します。アカウントを新設しても、組織の下に作れば同じ許可セットの割り当てで管理できるため、アカウントが増えても設定作業が増えにくくなります。

⚠️ 頻出: 「複数アカウントを一元管理して全社 SSO を作る」は、の全機能を有効にしたうえで IAM Identity Center を組織レベルで有効化する、という 2 段構えで考えます。

1 つの AWS アカウントが所属できる組織は、同時に 1 つだけです。買収や事業統合で別の組織にあるアカウントを自社の組織へ移す場合は、アカウントを作り直すのではなく、移行先の組織から招待し、そのアカウント側で承諾します。 2025 年 11 月から組織間の直接移管ができるようになり、元の組織に所属したまま招待を承諾すれば、そのまま移行先の組織へ移ります。以前のように先に組織から外して単独のアカウントとして運用する期間を挟む必要はなく、移管のためだけに支払い方法、連絡先、を各アカウントへ登録する作業も要りません。

手順	実行する場所	判断ポイント
移行先から招待を送る	移行先の組織の管理アカウント	アカウント ID かメールアドレスを指定します。元の組織に所属したままのアカウントにも送れます。
招待を承諾する	対象のメンバーアカウント	承諾した時点で移行先の組織のルートへ入ります。その後に目的の OU へ移します。

移るのはアカウントそのものなので、アカウント ID は変わらず、その中のインスタンスやなどのリソースもそのまま維持されます。アカウントを閉鎖して新しく作り直す方法では、リソースを引き継げません。移行前には、他サービスの委任管理者になっていれば登録を解除し、元の組織の ID を aws:PrincipalOrgID 条件で参照しているポリシーを洗い出しておきます。

一方、組織を離れて単独の AWS アカウントにする場合 (どの組織にも属さなくなる場合) は、単独の AWS アカウントとして運用できる状態になっている必要があります。組織の中で作成したアカウントは、支払い方法、連絡先情報、サポートプランなどが登録されていないことがあり、そのままでは組織からの削除や脱退が ConstraintViolationException で失敗します。「手順は正しいのに組織から外せない」という問題では、この前提条件を疑います。他にも、組織で作成してから 4 日たっていないアカウントや、他サービスの委任管理者になっているアカウントは外せません。なお、管理アカウントは招待で他の組織へ移せません。先に自身の組織を削除して単独のアカウントへ戻します。

はやなどのリソースを別のアカウントへ共有する仕組みで、アカウントの所属そのものを変えるものではありません。 StackSets も複数アカウントへスタックを展開する仕組みで、組織の移動には使えません。

⚠️ 頻出: 「別の組織にあるアカウントをリソースごと自社の組織へ統合する」は、移行先からの招待 → 対象アカウントでの承諾です (直接移管)。リソース共有の AWS RAM やスタック展開の StackSets は所属を変えません。

②SCPによる最大権限の制御 ⚠️ 頻出

はまたはアカウントに適用し、利用可能なサービス、操作、などを制限します。明示的な Deny は下位 OU やの Allow より優先されます。SCP は管理アカウントには適用されず、SCP で Allow しただけでは操作権限は付与されません。

SCP はメンバーアカウントのを含むすべての IAM ユーザーとロールに効きます。管理アカウントには効かないため、管理アカウントにはワークロードを置かず、利用者も最小限に絞ります。

よく使う SCP	書き方の要点	注意点
許可したリージョン以外を禁止	`aws:RequestedRegion` が許可リストに一致しない要求を Deny します。	IAM、、、、などのグローバルサービスは us-east-1 ので動くため、`NotAction` で除外しないとこれらの操作まで止まります。
組織からの脱退を禁止	`organizations:LeaveOrganization` を Deny します。	メンバーアカウントの管理者が自分で脱退して SCP の制約から逃れることを防ぎます。
監査ログの停止を禁止	`cloudtrail:StopLogging` や `cloudtrail:DeleteTrail` を Deny します。	各アカウントの管理者でも外せない予防的な統制になります。検出だけならです。

③マルチアカウントのセキュリティ設計

ログ保管、セキュリティ監視、ネットワーク管理を専用アカウントへ分離すると、ワークロード管理者による改変を防ぎやすくなります。、、などは委任管理者を設定して組織全体を集約できます。

④一括請求とリソース共有

一括請求では、請求上は組織のすべてのアカウントを1つのアカウントとして扱います。やデータ転送のように使用量が多いほど単価が下がる段階料金があるサービスでは、全アカウントの使用量を合算して段階を判定するため、アカウントごとに請求されるより安くなります。は一括請求を提供しますが、請求の統合と権限の共有は別機能です。やなどの対応リソースを共有する場合はを使用します。

試験対策

問題文のキーワード	選ぶ機能	理由
複数アカウントで特定サービスを禁止		より上位の権限上限を組織単位で適用できます。
開発と本番の影響範囲を分離	複数アカウント	権限やの境界を分けられます。
新規アカウントを標準構成で払い出す		ランディングゾーンと Account Factory を利用できます。
ユーザーへ複数アカウントの権限を割り当てる		人のアクセスを一元管理できます。

SCP と IAM ポリシーを混同しないことが最重要です。SCP は権限を与えず、メンバーアカウントで使用できる最大範囲を制限します。