スイッチロールで足りる？ AWS Organizationsは必要？
アカウント数と環境数で決める、マルチアカウント管理の判断基準
「別のAWSアカウントのリソースを触りたいだけなら、スイッチロールで十分ではないか」
「Organizationsは大規模向けで、自分たちにはまだ早いのではないか」
マルチアカウントの相談で、最初に迷うのはこの線引きです。
設定手順そのものは公式ドキュメントや先行記事が充実していますが、「どの規模からOrganizationsに寄せるべきか」という判断基準を整理した資料は意外と多くありません。
本稿では手順には踏み込まず、この判断基準だけに絞って整理します。
結論：目安は「4アカウント」と「環境分離の有無」
先に結論を置きます。
- アカウントが3〜4個までで、目的が「他アカウントのリソースを操作すること」だけなら、クロスアカウントのスイッチロールで十分です。
- アカウントが5個以上になる、または開発／本番のような環境分離や部門別の管理が必要なら、AWS Organizationsによる組織管理を前提に設計した方が、後々の運用負荷が小さくなります。
数字は絶対の境界ではありません。ただ、アカウントが増えるにつれてスイッチロール単独運用の管理コストは素直には増えず、組み合わせ的に膨らんでいくため、どこかで転換点が来ます。その転換点の目安が、経験上このあたりです。
前提：この2つは対立するものではない
混同しやすいのですが、スイッチロールとOrganizationsは役割が違います。
- スイッチロールは「他のアカウントへどうやって入るか」というアクセスの手段です。
- AWS Organizationsは「複数アカウントをどう統治するか」という管理の仕組みです。
実際、Organizationsで作成したメンバーアカウントへアクセスするときにも、内部では OrganizationAccountAccessRole へのスイッチロールを使います。
つまり問いは「どちらか一方を選ぶ」ではなく、**「スイッチロールという手段だけで足りる規模か、それを束ねる統治の仕組みまで必要か」**です。
判断基準チェックリスト
スイッチロールだけで十分なケース
以下にすべて当てはまるなら、Organizationsを持ち出す必要性は低いはずです。
- アカウントは3〜4個以内で、今後も大きく増える見込みがない
- アカウントの用途が固定的で、払い出しや廃止がほとんど発生しない
- 必要なのは「特定のユーザーが、特定のアカウントのリソースを操作できること」だけ
- 請求はアカウント単位で分かれていても問題ない
- 「このサービスは使うな」「このリージョン以外は使うな」といった全社的な統制要件がない
- 監査ログやセキュリティ検知は、アカウントごとに設定できれば足りる
この規模なら、ロールと信頼ポリシーをアカウントの数だけきちんと管理する方が、シンプルで分かりやすい構成になります。
Organizationsを検討すべきサイン
逆に、以下に1つでも強く当てはまるなら、スイッチロール単独運用はすでに限界に近づいています。
- アカウントが5個を超えた、または超えることが見えている
- 開発／検証／本番など、環境ごとにアカウントを分離したい
- 事業部門やプロジェクトごとにアカウントを払い出す運用がある
- 請求を1つにまとめたい、利用料を部門単位で把握したい
- SCPで「許可するサービスやリージョンを組織として制限したい」
- GuardDuty、CloudTrail、AWS Config、Security Hubなどを全アカウントへ漏れなく有効化したい
- 誰がどのアカウントに何の権限で入れるかを、組織として説明できなければならない
特に効いてくるのは3番目と5番目以降です。アカウントの払い出しが日常運用になった時点で「アカウントを作る・束ねる・統制する」仕組みなしでは回らなくなり、統制要件はスイッチロールでは原理的に実現できません。権限の切り替え手段に、ガバナンスの機能はないからです。
比較表：判断に関わる項目だけ
| 観点 | スイッチロール単独 | AWS Organizations併用 |
|---|---|---|
| 解決すること | 他アカウントへのアクセス | アクセスに加え、アカウント全体の統治 |
| 管理の単位 | アカウントとロールの組み合わせごと | OU（組織単位）による階層管理 |
| 規模の限界 | 4アカウント前後から煩雑さが目立ち始める | 数十〜数百アカウントを前提に設計されている |
| 請求 | アカウントごとに個別管理 | 一括請求に集約でき、OU単位での把握もしやすい |
| 統制（ガバナンス） | できない。各アカウントのIAM設定に依存 | SCPでサービス／リージョンなどを組織横断で制限可能 |
| セキュリティ対策の展開 | アカウントごとに個別設定。漏れが起きやすい | GuardDutyやCloudTrailなどを組織単位で一括有効化できる |
| アカウント追加 | その都度、手作業で作成と設定 | 組織配下へ作成・招待でき、OUに応じた統制を最初から効かせられる |
| ログイン体験 | アカウントごとにロール切り替え | IAM Identity Centerと併用すると、共通画面から各アカウントへ入れる |
なぜ「5アカウント」が転換点になるのか
スイッチロール単独運用で管理する対象は、アカウントそのものよりも**「ユーザー（または元アカウント）× 対象アカウント × ロール」の組み合わせ**です。
- 3アカウントなら、意識すべき組み合わせはまだ一桁で収まります。
- 10アカウントになれば、ロールの命名、信頼ポリシー、権限の棚卸しが一気に属人化し始めます。
- 棚卸しができない状態は、そのまま「誰が本番に管理者で入れるか説明できない」状態です。
OrganizationsのOUとSCPは、この組み合わせ爆発を「階層へのポリシー適用」に置き換えるための仕組みだと捉えると分かりやすくなります。アカウント数ではなく、組み合わせの管理が破綻し始めたかどうかが本来の判断軸で、5アカウントという数字はその目安に過ぎません。
移行は「全部入り」から始めなくてよい
Organizationsと聞くと大掛かりに感じるかもしれませんが、判断と導入は分けて考えられます。
- まず組織を作り、既存アカウントを招待してOUに入れる（この時点では統制は最小限でよい）
- 請求の一括化と、監査・セキュリティ系サービスの一括有効化だけ先に効かせる
- SCPによる制限は、業務影響を見ながら段階的に強める
- ログインはIAM Identity Centerへ寄せ、スイッチロールは非常時や個別作業用に残す
スイッチロールはOrganizations導入後も消えません。日常の入り口をIdentity Centerに寄せつつ、仕組みとしては残る、というのが現実的な着地点です。
よくある誤解
-
「Organizationsは有料の大企業向け」
Organizations自体に追加料金はかかりません。費用が発生するのは、配下のアカウントで使うAWSサービス分だけです。規模よりも、統制と払い出しの有無で判断すべきです。 -
「アカウントが少ないうちは入れるだけ無駄」
むしろ逆で、アカウントが少ない時期の方がOU構成を素直に設計できます。増え切ってから階層を組み替える方が、はるかに高くつきます。 -
「スイッチロールができているなら管理もできている」
入れることと、統治できていることは別です。全アカウントで同じ統制が効いているか、漏れなく監査できているかを説明できなければ、管理ではなく「個別対応の集積」です。
まとめ
判断の軸はシンプルです。(私個人の思いもあるが・・・)
他アカウントの「リソースを触りたいだけ」か？
├─ YES かつ アカウント 3〜4個以内
│ → スイッチロールで十分
└─ NO、または アカウント 5個以上／環境分離／部門別払い出しあり
→ AWS Organizations を前提に設計する
- スイッチロールはアクセス手段、Organizationsは統治の仕組み。対立ではなく階層の違いです。
- 転換点の本質はアカウント数そのものではなく、「組み合わせ管理の破綻」と「統制要件の有無」です。
- 5アカウント、複数環境、払い出し運用。このどれかが見えたら、Organizations前提で設計を始めるサインです。