AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説

AWS Organizationsは、複数のAWSアカウントを1つの組織として束ね、権限の上限・請求・設定基準を横断で管理するサービスです。単一アカウントで始めた環境が、部門やプロジェクトの増加で統制しきれなくなったときに導入を検討します。この記事では、管理アカウント・OU・SCP/RCP・宣言型ポリシー・一括請求といった構成要素の仕組みを実装者目線で整理し、IAMやControl Towerとの役割分担、OU設計と導入の手順、そして「どの組織規模なら採用すべきか・単一アカウントで十分な場面はどこか」までを判断軸として示します。AWSのアカウント設計を外注先と詰める前の下地としても役立つ内容です。

まとめ：AWS Organizationsは「アカウントをまたぐ統制」を担う土台

AWS Organizationsの役割は、アカウント単位で分けたワークロードに対し、組織全体のガードレールと請求集約をかけることに尽きます。個々のアカウント内で「誰が何をできるか」を決めるIAMとは層が違い、Organizationsは「そのアカウントで何を許すか・許さないか」の上限をSCPで縛り、支払いを管理アカウントに寄せます。本体の利用料は無料です。コストは各メンバーアカウントの実利用分にのみ発生します。

導入判断の分かれ目は組織の規模と分離要件です。本番と検証を分けたい、部門ごとに請求を可視化したい、監査要件でアカウント境界を引きたい——この3条件のいずれかが常態化したら採用の目安になります。逆に、扱うワークロードが1つでチームが数名なら、OUやSCPは運用負荷が先に立ちます。以降で扱うのは、各機能の中身と、採用・見送りを分ける具体的な条件です。

AWS Organizationsの全体像とマルチアカウントが必要になる実務上の理由

最初に、Organizationsが何を管理する単位なのかを押さえます。ここを曖昧にすると、後段のSCPやOU設計がすべてぼやけます。

定義と、管理アカウント・メンバーアカウント・OU・ルートの階層構造

AWS Organizationsは、複数のAWSアカウントを「組織（Organization）」という単位でまとめ、ポリシーと請求を一元管理する仕組みです。組織の頂点にはRootがあり、その下に組織単位（OU：Organizational Unit）を階層で配置し、各OUや直下にメンバーアカウントを所属させます。OUは入れ子にでき、実務では階層が深くなりすぎないよう2〜3段に収めるのが扱いやすい設計です。

組織を作成した最初のアカウントが管理アカウント（management account）となり、OUの作成・ポリシー適用・アカウント招待などの操作権限を持ちます。それ以外はメンバーアカウントで、SCPなどの制約を受ける側です。管理アカウントは強力なので、日常のワークロードは置かず、組織運用だけに用途を絞るのが定石です。

シングルアカウント運用の限界と、アカウントを分割する判断材料

1つのAWSアカウントに本番・検証・部門システムを同居させると、IAMの権限設計だけで境界を作ることになります。これは設定ミス1つで本番リソースに影響が及ぶ構造で、監査時の説明も容易ではありません。アカウントを分ければ、境界がAWSの課金・APIレベルで物理的に引かれ、事故の波及とコストの混在を同時に断てます。

分割の代表的な軸は次の3つです。実務ではまず「環境別（本番／ステージング／開発）」から入り、組織が育つにつれ部門別・ワークロード別へ広げるのが無理のない順序です。

• 環境別：本番と検証を別アカウントにし、検証の実験が本番へ波及しない構造にする
• 部門・チーム別：請求とアクセスを部門境界で分け、コスト按分と権限委譲を単純化する
• ワークロード・セキュリティ要件別：機密度の高いシステムを隔離し、監査範囲を絞り込む

ガバナンスを効かせる主要機能：SCP・RCP・宣言型ポリシー・一括請求

Organizationsの実力は、アカウントを束ねたうえで横断的に効かせるポリシーと請求集約にあります。ポリシーは大きく「認可を絞るもの（SCP／RCP）」と「設定を強制するもの（宣言型ポリシーほか）」に分かれます。

SCP（サービスコントロールポリシー）によるアクション上限の設定

SCPは、メンバーアカウント内のIAMプリンシパル（ユーザーやロール）が実行できるアクションの上限を定めるガードレールです。ここで外せない性質が1つあります。SCPは権限を付与しません。あくまで「これ以上は許さない」という枠を決めるだけで、実際の許可はアカウント内のIAMポリシーで別途与えます。両者のANDが実効権限になります。

典型的な使い方は、特定リージョン以外での操作を拒否する、ルートユーザーの危険な操作を封じる、退避不能な組織ポリシー（CloudTrailの停止など）をブロックする、といったガードレールです。なお管理アカウント自身にはSCPが効かない点は設計時の前提として外せません。

RCP（リソースコントロールポリシー）と宣言型ポリシーで広がる統制範囲

RCP（Resource Control Policy）は2024年11月に一般提供が始まった比較的新しいポリシーです。SCPが「呼び出す側（プリンシパル）」を縛るのに対し、RCPはリソース側へのアクセス上限を組織横断で定めます。狙いは、組織外からのアクセスを遮断するデータ境界（data perimeter）の構築です。対応サービスは提供当初はS3・STS・SQS・Secrets Manager・KMS等に限られ、2025年6月時点ではAmazon ECRなどへ対応範囲が広がりました。全サービス一律ではないため、対象範囲は導入時に公式ドキュメントで確認してください。

宣言型ポリシー（declarative policies）は2024年12月に一般提供された管理ポリシーで、認可ではなく設定そのものを強制します。サービスのコントロールプレーンで適用されるため、対象サービスが新機能やAPIを追加しても意図した構成が保たれるのが特徴です。提供時点ではEC2・EBS・VPCの構成（パブリックAMIの制限、VPCのデフォルト設定など）が対象で、対応サービスは順次拡大しています。SCP/RCPが「操作を止める」のに対し、宣言型ポリシーは「状態を固定する」役割と捉えると整理しやすいです。

一括請求（Consolidated Billing）とボリューム割引・コスト集約

一括請求は、組織内の全メンバーアカウントの利用料を管理アカウントに集約して支払う仕組みです。支払いが1本化されるだけでなく、使用量が合算されることでボリューム割引が組織全体で効きやすくなり、Savings PlansやReserved Instances（RI）の割引を複数アカウント間で共有できます。単一アカウントを個別契約するより、割引の適用効率が上がる余地があります。

コストの見え方としては、Cost Explorerや請求ダッシュボードでアカウント別・OU別・タグ別に按分して把握できます。部門ごとに請求を切り出したい要件は、Organizationsによるアカウント分割と一括請求の組み合わせで素直に満たせます。

IAM・Control Tower・IAM Identity Centerとの役割分担

Organizationsは単独で使うより、IAMや周辺サービスと層を分けて組み合わせます。ここを取り違えると「SCPで許可したのに動かない」といった典型的なつまずきに直結します。

IAMとOrganizationsの違いと、両者を組み合わせた権限設計

IAMは1アカウント内で、ユーザー・ロール・ポリシーを通じて「誰が何をできるか」を定義します。対してOrganizationsはアカウントをまたいで、そのアカウントで許される操作の上限（SCP）やリソース境界（RCP）を決めます。実効権限は「IAMで付与した許可」と「SCP/RCPで許した枠」の重なりです。SCPで拒否したアクションは、IAM側でAdministratorAccessを付けても実行できません。IAMのユーザー・ロール・ポリシー設計の基礎は、AWS IAMの仕組みとユーザー/ロール/ポリシーの違いを実装者目線で解説した記事に整理しているので、アカウント内の権限設計とあわせて確認してください。

Control Towerによるランディングゾーン自動構築との使い分け

AWS Control Towerは、Organizationsを土台に、マルチアカウントのベースライン（ログ集約用アカウント、監査用アカウント、ガードレール群）を自動で組み上げるサービスです。Organizationsが「素材とルールの器」だとすれば、Control Towerは「推奨構成へセットアップする自動化」に当たる位置づけです。ゼロから設計する体力がある、あるいは独自要件が強い場合はOrganizationsを直接組みます。標準的なランディングゾーンを短時間で用意したい場合はControl Towerが選択肢になります。Control Towerのガードレールの一部はSCPやRCPとして実装されており、両者は排他ではなく重ねて使う関係です。

認証・シングルサインオンの面では、IAM Identity Center（旧AWS SSO）がOrganizations全体に対して権限セットを配布し、複数アカウントへの横断ログインを束ねます。「アカウント分割はしたいが、利用者のログインは1本化したい」という要件はこの組み合わせで満たします。

マルチアカウント設計の実務ステップとOU分割・ポリシー適用の考え方

機能を理解したら、実際に組織を設計する順序に落とします。設計の巧拙はOUの切り方とSCPの当て方でほぼ決まります。

OU設計のパターン（環境別・部門別・セキュリティ別）と選定基準

OUの設計単位は「同じポリシーを当てたいアカウントの束」です。AWSが公開する推奨構成では、Security（ログ・監査）、Infrastructure（共有ネットワーク等）、Workloads（本番・非本番）といった機能別のOUを基幹に置く形が示されています。次の3パターンを組み合わせて自組織に合わせます。

選定基準は「そのOUに属する全アカウントへ同じ制約を当てて破綻しないか」です。例外が多いOUは分割が粗すぎるサインなので、階層を1段足すか別OUへ切り出します。

導入の手順と、既存アカウントを組織へ招待・移行する際の注意点

新規に組織を立ち上げる場合の流れは次の通りです。既存の本番アカウントをいきなり管理アカウントにしないことが、後戻りを避ける最大の勘所です。

1. 組織運用専用の新規アカウントを作り、これを管理アカウントとして組織を作成する
2. Security・Workloads等の基幹OUを作成し、階層方針を先に固める
3. 既存アカウントを組織へ招待（invite）、または新規メンバーアカウントを発行してOUへ配置する
4. まずは検証OUにSCPを当てて挙動を確認し、影響範囲を見てから本番OUへ広げる
5. 一括請求・Cost Explorer・IAM Identity Centerを有効化し、請求とログインの集約を確認する

招待で加えた既存アカウントには、加入直後は制約が緩い状態でSCPが後追いで効きます。ポリシーは検証OUで先に試し、本番へは段階適用するのが安全です。組織からアカウントを離脱させる際は、請求方法など一部の前提条件を満たす必要があるため、離脱手順も導入前に確認しておきます。

AWS Organizationsを採用すべき組織要件と、過剰になる場面

ここでは判断を言い切ります。Organizationsは無料ですが、OUとポリシーの運用には確実に人手がかかる点は無視できません。導入の是非は「機能があるか」ではなく「統制の需要が運用コストを上回っているか」で決めます。

Organizationsを導入して効果が出る組織要件と採用の目安

次のいずれかが恒常的に発生しているなら、Organizationsの採用は妥当です。とくに(1)と(2)が重なる組織では、導入を先送りするほどアカウントの無秩序な増殖で移行コストが膨らみます。

• 本番・検証・部門システムを別アカウントで隔離する要件が固定化している
• 部門やプロジェクト単位でコストを按分・可視化する必要が定例化している
• 監査・コンプライアンスでアカウント境界とガードレール（操作禁止範囲）の証跡が求められる

こうしたアカウント境界の設計は、後から引き直すと移行の手間が大きくなります。マルチアカウント構成の初期設計やControl Tower導入の要否を含めて外部に相談したい場合は、AWS環境のインフラ構築・アカウント設計の支援で、要件に沿ったOU方針とガードレール設計から伴走できます。

単一アカウントで十分な場面と、SCPを絞りすぎる失敗パターン（見送り・注意）

逆に、扱うワークロードが1つでチームが数名、環境分離もタグとIAMで足りている段階では、Organizationsの導入は運用負荷が先に立ちます。この規模ではOU設計やSCPの検証に割く時間が、得られる統制効果を上回りがちで、当面は単一アカウントにIAMのロール分離を丁寧に当てるほうが費用対効果が出ます。導入は「アカウントを分ける実需が生まれてから」で遅くありません。

導入後の典型的な失敗は、SCPを最初から強く絞りすぎて開発チームの正当な操作まで止めてしまうパターンです。SCPは拒否が優先で効くため、広めのガードレールから始めて検証OUで挙動を見ながら段階的に締めるのが定石です。もう1つは管理アカウントに本番ワークロードを載せてしまうケースで、SCPが効かず被害範囲が読めなくなるため、管理アカウントは組織運用専用に保ちます。

よくある質問

AWS Organizationsの導入前に実務でよく問われる論点を、簡潔に整理します。

AWS Organizationsの利用に料金はかかりますか？

Organizations本体の利用料は無料です。課金されるのは各メンバーアカウントで実際に使ったAWSリソースの分だけで、SCPやOU、一括請求といった管理機能そのものに追加料金は発生しません。一括請求ではむしろ使用量が合算され、ボリューム割引やSavings Plans/RIの共有で割引効率が上がる余地があります。

SCPとIAMポリシーは何が違いますか？

IAMポリシーは権限を「付与」しますが、SCPは権限の「上限」を定めるだけで付与はしません。実効権限は両者の重なりで決まり、SCPで拒否したアクションはIAMで許可しても実行できません。IAMがアカウント内の許可、SCPがアカウントをまたぐガードレール、という層の違いで理解すると混同を避けられます。

Control Towerを使えばOrganizationsは不要ですか？

不要にはなりません。Control TowerはOrganizationsを土台にランディングゾーンを自動構築するサービスで、内部でOUやSCP/RCPを使っています。Control Towerは標準構成を短時間で用意する自動化、Organizationsはその素材とルールの器、という関係です。独自要件が強い場合はOrganizationsを直接設計する選択もあります。

RCPとSCPはどう使い分けますか？

SCPは操作する側（IAMプリンシパル）のアクション上限を、RCPはリソース側へのアクセス上限を定めます。組織外からのアクセスを遮断するデータ境界を作りたいときはRCPが向きます。RCPは2024年11月に一般提供され、対応サービスが順次拡大している段階のため、対象範囲は導入時に公式ドキュメントで確認してください。

既存のAWSアカウントを後から組織に加えられますか？

加えられます。管理アカウントから既存アカウントへ招待（invite）を送り、承諾されると組織のメンバーになります。加入直後は制約が後追いで効くため、SCPは検証用OUで挙動を確認してから本番OUへ段階適用するのが安全です。組織からの離脱には一部の前提条件があるため、離脱手順も事前に把握しておくとよいです。

関連記事

• AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティス：Organizationsのアカウント境界と組み合わせる、アカウント内の権限設計の基礎
• クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで事業者向けに解説：AWSやクラウド全体の前提を押さえたい方向けの入門
• AWS・Google Cloud・Azureの特徴と使い分けを徹底比較：マルチアカウント統制の前段となる、クラウド基盤そのものの選定