AWSの利用が複数のシステムや部門へ広がると、一つのアカウントに権限、ログ、請求を集めたままでは、誰が何を管理するのか分かりにくくなります。
AWS Organizationsは、複数のAWSアカウントを組織としてまとめ、階層とポリシーを使って管理するためのサービスです。
設計では、現在の組織図をそのまま写すのではなく、責任範囲、変更の影響、監査、費用管理の単位を基準にアカウントを分けます。本記事では、その考え方をGoogle CloudとAzureの階層に照らして整理します。
最初に押さえる設計原則
- 管理用アカウントと業務システムを動かすアカウントを分ける
- 本番環境と開発、検証環境を分け、変更の影響範囲を限定する
- SCPは権限を与える仕組みではなく、メンバーアカウントで利用できる権限の上限として扱う
- ログ、セキュリティ監視、請求の集約先と担当者を先に決める
- OUは人事組織よりも、共通の管理ルールと責任境界に合わせて設計する
AWS Organizationsの構成要素
AWS Organizationsでは、組織全体の階層を作り、AWSアカウントを適切な位置へ配置します。ここでいう「Root」はOrganizations階層の最上位ノードであり、各AWSアカウントのrootユーザーとは別の概念です。
| 構成要素 | 役割 | 設計時の注意 |
|---|---|---|
| Organization | 複数のAWSアカウントを束ねる組織全体 | SCPを使うには、組織で全機能を有効にする必要があります。 |
| Management account | 組織、アカウント、請求を管理するアカウント | SCPの制限対象ではありません。通常の業務ワークロードを置かず、アクセスを厳しく管理します。 |
| Member account | 組織に参加する通常のAWSアカウント | 業務システム、環境、責任範囲などに応じて分けます。 |
| Root | OUとメンバーアカウントを含む階層の最上位 | Rootに付けたSCPは配下のメンバーアカウントへ影響します。管理アカウントには適用されません。 |
| OU | 共通のルールを適用するアカウントのまとまり | 組織改編のたびに作り直さずに済むよう、管理目的で分けます。 |
AWS Organizations自体には追加料金がありません。ただし、メンバーアカウントで利用する各AWSサービスの料金は通常どおり発生し、管理アカウント側が組織の利用分を支払います。
AWS、Google Cloud、Azureの階層を比較する
三つのクラウドには、上位の管理単位から下位へポリシーやアクセス設定を継承する考え方があります。ただし、名称が似ていても、請求、ID、ポリシー評価の仕組みまで同一ではありません。対応表は設計会話の出発点として使い、最終判断は各クラウドの仕様に基づいて行います。
| 設計上の役割 | AWS | Google Cloud | Azure |
|---|---|---|---|
| 組織全体の管理範囲 | OrganizationとRoot | Organization | Microsoft Entraテナント内のRoot management group |
| 中間のグループ | OU | Folder | Management group |
| ワークロードの主な分離単位 | Account | Project | Subscription |
| 日常的なアクセス制御 | IAMポリシー | IAMのAllow/Denyポリシー | Azure RBAC |
| 組織レベルの統制 | SCPなどの組織ポリシー | Organization Policy | Azure Policy |
AWSのアカウント、Google Cloudのプロジェクト、Azureのサブスクリプションは、いずれもワークロードを分ける主要単位として使えます。一方で、IDの所属先や請求との結び付きは異なるため、「同じもの」として機械的に置き換えることはできません。
サービス選定そのものを比較したい場合は、中小企業向けクラウド比較も判断材料になります。
SCPとIAMポリシーの違い
Service Control Policy（SCP）は、OUやメンバーアカウントで利用できる権限の上限を定める仕組みです。SCPである操作を許可しても、その操作権限が利用者へ付与されるわけではありません。
実際に操作できるのは、SCPの範囲内で、IAMポリシーなどが利用者やロールへ権限を与えている場合です。反対に、IAMポリシーが許可していても、上位のSCPで明示的に拒否されている操作は実行できません。IAMの基礎は、AWS IAMの基礎と権限設計で詳しく解説しています。
SCPで制限できない範囲
SCPはメンバーアカウントのIAMユーザー、IAMロール、rootユーザーに影響しますが、管理アカウントの操作には影響しません。サービスリンクロールなど、SCPで制限されない対象もあります。
したがって、管理アカウントをSCPだけで守る設計は成立しません。管理アカウントでは、アクセス経路、認証、監視、利用目的を別途制限します。
リージョン制限は単純な拒否ルールにしない
aws:RequestedRegionを条件に使うと、指定外リージョンの操作を制限できます。ただし、IAMやRoute 53などのグローバルサービスは、単一のエンドポイントを通じて動作する場合があります。
例外を考慮せずに全操作を拒否すると、必要な管理操作まで止めるおそれがあります。利用サービス、グローバルサービス、例外となる管理操作を洗い出し、検証用OUでテストしてから適用範囲を広げます。
責任境界からアカウントを分ける
アカウントを分ける目的は、見た目の整理ではなく、変更や障害の影響範囲を狭め、担当者と管理ルールを明確にすることです。次の問いに対する答えが異なるワークロードは、別アカウントにする候補です。
- 誰が変更を承認し、誰が運用を担当するか
- 本番障害が発生したとき、どこまで影響を切り離したいか
- どのログを誰が閲覧し、どれだけ保護するか
- 費用をどの事業、製品、環境へ割り当てるか
- 同じセキュリティ基準と利用リージョンを適用できるか
- ワークロードの廃止や移管を独立して判断できるか
小規模構成の例
最初から多数のOUを作る必要はありません。たとえば、次の役割を基準に必要なアカウントから分離します。これは固定の正解ではなく、責任と運用を整理するための出発点です。
| 役割 | 主な用途 |
|---|---|
management |
Organizationsと請求の管理。業務ワークロードは置かない。 |
security |
セキュリティ監視と必要な管理機能。 |
log-archive |
監査ログの集約と保管。 |
shared-services |
ネットワークや共通の開発、運用基盤。 |
prod |
本番ワークロード。 |
nonprod |
開発、検証ワークロード。 |
システムやチームが増えたら、prodとnonprodを製品単位に分けます。同じSCPを適用するアカウントをOUにまとめれば、ルールの重複を減らせます。
ログ、セキュリティ、請求を設計する
ログは操作元と保管先を分ける
操作されるアカウントとログの保管先が同じでは、誤操作や侵害の影響が記録へ及ぶ可能性があります。ログ集約用アカウントを分け、収集対象、閲覧権限、保持方針、異常時の通知先を決めます。
API操作の記録についてはAWS CloudTrailの証跡設計、構成変更の追跡についてはAWS Configによる継続的な確認が参考になります。
請求の集約と費用配分を分けて考える
AWS Organizationsでは複数アカウントの請求と支払いを集約できます。ただし、請求書がOU構造をそのまま表すわけではありません。
費用を製品や部門へ配分するには、アカウントの用途を明確にし、必要に応じてコスト配分タグなどの管理方法を組み合わせます。アカウント名だけに頼らず、費用の確認担当と予算超過時の連絡先も決めておきます。
導入を安全に進める手順
- 現状を棚卸しする各アカウントの用途、責任者、環境、データ、ログ、請求先、外部連携を一覧にします。
- 分離する理由を決める
本番と非本番、セキュリティ、ログ、共有基盤など、異なる管理ルールが必要な境界を特定します。
- 最小限のOUとアカウントを作る
将来の完成形を一度に作らず、現在運用できる階層から始めます。
- SCPの目的を文章で定義する
「誰のどの操作を、どの範囲で、なぜ制限するか」を明記してからポリシーへ落とします。
- 検証用OUで影響を確認する
通常操作、緊急時の復旧、監視、デプロイ、サポート対応を試し、必要な例外を確認します。
- 少数のアカウントから段階的に適用する
監査ログと問い合わせを確認しながら、対象OUを広げます。変更手順と戻し方も残します。
よくある失敗と回避策
| 失敗 | 起きる問題 | 回避策 |
|---|---|---|
| OUを人事組織どおりに作る | 組織改編のたびにアカウント移動とポリシー再評価が必要になる。 | 共通ルール、責任、環境の違いを基準にする。 |
| 管理アカウントで業務を動かす | SCPで管理アカウントを制限できず、強い権限と日常作業が混在する。 | 管理用途に限定し、業務ワークロードをメンバーアカウントへ置く。 |
| SCPを権限付与に使う | SCPで許可したのに操作できないという誤解が生じる。 | SCPは上限、IAMポリシーは権限付与と役割を分ける。 |
| 広い拒否をRootへ直ちに適用する | 必要な管理操作やデプロイまで止まる可能性がある。 | 検証用OU、少数アカウント、段階展開の順で確認する。 |
| アカウントを分けただけで監査が完了したと考える | ログの収集漏れや閲覧権限の不備を見落とす。 | 収集、保管、監視、通知、定期確認を運用手順にする。 |
設計レビューで確認する項目
- 管理アカウントに通常の業務ワークロードがない
- 各アカウントの目的と責任者を説明できる
- 本番環境と開発、検証環境の影響範囲が分かれている
- OUごとに適用するルールと例外の理由が文書化されている
- SCPとIAMポリシーの役割を運用担当者が区別できる
- ログの送信先、閲覧者、保持方針、通知先が決まっている
- 費用を確認する単位と担当者が決まっている
- ポリシー変更の検証手順と戻し方がある
- Google CloudやAzureにも同じ統制目的を適用する場合、各クラウド固有の差を確認している
まとめ
AWS Organizationsの設計では、アカウント数やOUの見た目よりも、責任、変更の影響、ログ、請求、適用するルールを明確にすることが先です。
SCPはメンバーアカウントの権限上限を定めますが、権限そのものを与えず、管理アカウントも制限しません。この境界を理解したうえで、小さなOUから検証し、運用記録を確認しながら広げると、統制と開発速度を両立しやすくなります。
Google CloudやAzureでも、上位の管理範囲、中間のグループ、ワークロードの分離単位という順に整理できます。ただし、対応関係は設計の補助線です。権限、請求、IDの違いは各クラウドの公式仕様で確かめます。
参考資料
- AWS Organizationsユーザーガイド
- AWS OrganizationsのSCP解説
- AWS Organizationsの料金と請求
- Google Cloudのリソース階層
- Azure Management Groupsの概要
この記事に関連する株式会社greedenの取り組み
複数クラウドの階層や権限設計は、サービス名の対応表だけでは決められません。株式会社greedenは、要件整理から設計、実装、テスト、保守運用まで一気通貫で支援し、クラウド移行を含むWebシステム開発を段階的に進めます。