AWS Organizations

AWS Organizations は、複数の AWS アカウントを 1 つの組織としてまとめ、ガバナンス・請求・ポリシーを一元的に管理するためのサービスです。企業規模が大きくなり、本番・検証・開発・監査などの目的でアカウントが増えていくと、個々のアカウントを手作業で統制するのは現実的ではなくなります。Organizations はマルチアカウント戦略の土台となり、後続の Control Tower や IAM Identity Center とも密接に連携します。

解決する課題

単一の AWS アカウントにすべてのワークロードを詰め込むと、環境間の分離が弱くなり、課金の按分やセキュリティ境界の管理が難しくなります。一方でアカウントを分割すると、今度は「数十・数百のアカウントをどう統一的に統制するか」という新たな問題が生じます。

AWS Organizations は次のような課題を解決します。

• アカウントごとにバラバラだった権限境界を、組織全体で一貫したガードレールとして適用したい
• 各アカウントの請求を集約し、ボリューム割引や予約・Savings Plans の共有を効かせたい
• 部門・環境ごとにアカウントをグルーピングし、ポリシーを階層的に継承させたい
• CloudTrail や GuardDuty などのセキュリティサービスを組織全体で一括有効化したい

主要概念と用語

• 組織（Organization）: 管理対象となる複数アカウントの集合体。1 つのルートを頂点とする階層構造を持つ。
• 管理アカウント（Management Account）: 組織を作成したアカウント。請求の支払い責任を持ち、SCP の適用やアカウント招待などの管理操作を行える特権的な存在。以前はマスターアカウントと呼ばれていた。
• メンバーアカウント（Member Account）: 組織に所属する管理アカウント以外のアカウント。
• ルート（Root）: 組織階層の最上位。すべての OU とアカウントはルートの配下に置かれる。組織内に 1 つだけ存在する。
• 組織単位（OU: Organizational Unit）: アカウントをまとめるための入れ物。OU は入れ子にでき、ポリシーは親から子へ継承される。
• サービスコントロールポリシー（SCP: Service Control Policy）: メンバーアカウント内の IAM プリンシパルが実行できる最大権限（ガードレール）を定義するポリシー。許可そのものは付与せず、上限を絞り込む。
• 一括請求（Consolidated Billing）: 組織内すべてのアカウントの利用料を管理アカウントにまとめて請求する仕組み。
• 信頼されたアクセス（Trusted Access）: 他の AWS サービスが組織情報にアクセスできるようにする連携設定。
• 委任管理者（Delegated Administrator）: 特定の管理機能を管理アカウント以外のメンバーアカウントに委任する仕組み。

仕様・制限・クォータ

Organizations にはいくつかの構造的な制約があります。具体的な数値は変動するため、設計時は最新の公式ドキュメントで確認してください。

• 1 つのアカウントが同時に所属できる組織は 1 つだけです。複数組織への重複所属はできません。
• 組織内に作成できるアカウント数や OU の階層の深さには上限があります。大規模化を見込む場合は事前にクォータを確認し、必要に応じて引き上げを申請します。
• ルートは組織内に 1 つだけで、削除や複数作成はできません。
• 機能セットには「すべての機能（All features）」と「一括請求のみ（Consolidated Billing only）」の 2 種類があります。SCP などのポリシー制御を使うには「すべての機能」を有効化する必要があります。
• SCP は管理アカウント内のプリンシパルには適用されません。この点は試験でも実務でも重要な落とし穴です。

内部の仕組み

Organizations はルートを頂点とし、その下に OU を入れ子状に配置し、末端に個々のアカウントをぶら下げる木構造でアカウントを表現します。ポリシーはこの階層に沿って継承されます。あるアカウントに実際に効くポリシーは、ルートから対象アカウントに至る経路上で適用されたすべてのポリシーの組み合わせとして評価されます。

SCP はあくまで「許可の上限」を決めるフィルターであり、それ自体は何の権限も付与しません。実際にある操作が許可されるためには、IAM のアイデンティティベースまたはリソースベースのポリシーで明示的に許可されていて、かつ経路上のすべての SCP でも許可されている必要があります。どこか一段でも拒否（暗黙の拒否を含む）があれば、その操作はブロックされます。つまり SCP と IAM 権限の論理積（AND）で実効権限が決まる、と理解すると整理しやすいです。

Trusted Access を有効にすると、CloudTrail・Config・GuardDuty・Security Hub などのサービスが組織のアカウント一覧やメタデータを参照できるようになり、組織全体への一括展開や集約が可能になります。これらの管理を管理アカウントに集中させすぎないよう、委任管理者の仕組みで運用負荷とリスクを分散できます。

設計パターン / ベストプラクティス

• OU は組織構造ではなく「適用したいポリシーの単位」で設計します。たとえば「本番」「非本番」「サンドボックス」「セキュリティ」「インフラ共有」といった機能・環境ベースの分け方が一般的です。
• 管理アカウントは請求と組織管理に専念させ、ワークロードや日常運用のための IAM ユーザーを置かないようにします。
• ログ集約用アカウントやセキュリティ監査用アカウントを専用に分離し、強い権限を持つ操作を局所化します。
• SCP は最初から細かく絞り込むより、まず広めのガードレール（特定リージョンの禁止、ルートユーザーの危険操作の禁止など）から始め、段階的に厳格化します。
• 新規アカウントの発行や標準設定の適用を自動化したい場合は、上位レイヤーの Control Tower や Account Factory の利用を検討します。

運用・監視

組織全体の API 操作は CloudTrail で記録し、できれば組織証跡（Organization Trail）として管理アカウントから一括で有効化し、改ざんされにくい専用のログ集約アカウントへ集めます。これによりメンバーアカウント側で証跡を無効化されても、組織レベルの記録が残ります。

アカウントの作成・削除・移動、SCP のアタッチ・デタッチといった構成変更は影響範囲が大きいため、変更管理プロセスに乗せて記録を残すことが重要です。SCP を変更する際は、まず限定的な OU やサンドボックスで影響を検証してから本番 OU へ展開すると、想定外の権限ブロックによる障害を避けられます。

Config を組織全体に展開すれば、各アカウントの構成順守状況を集約して可視化でき、ガバナンスの実効性を継続的に確認できます。

コスト

AWS Organizations 自体の利用に追加料金はかかりません。コスト面の主役は一括請求であり、組織内すべてのアカウントの利用量が合算されて評価されるため、ボリュームベースの段階割引が効きやすくなり、リザーブドインスタンスや Savings Plans の割引も組織内で共有されます。

支払いは管理アカウントに集約されますが、Cost Explorer やコスト配分タグを使えば、アカウントや OU 単位で費用を分析・按分できます。アカウントを分けることはコスト把握の単位を明確にする効果もあるため、課金の見える化とガバナンスは表裏一体で設計するとよいです。

セキュリティ

セキュリティの観点で最重要なのは、管理アカウントの保護です。管理アカウントは組織全体に対する強力な権限を持つため、ルートユーザーには多要素認証を必須化し、日常運用では使わず、アクセスを厳格に制限します。

SCP は「上限を絞る」ガードレールであることを正しく理解する必要があります。SCP で許可しても権限は付与されず、別途 IAM で許可が必要です。逆に SCP で拒否すれば、メンバーアカウント内の管理者であってもその操作はできなくなります。これにより、誤操作や権限昇格に対する組織レベルの防御線を引けます。代表的な使い方として、利用を認めないリージョンの全面禁止、組織の証跡やセキュリティ設定の無効化操作の禁止、ルートユーザーによる危険な操作の禁止などがあります。

Well-Architected の観点

• セキュリティ: SCP による組織レベルのガードレール、アカウント分離による爆発半径の限定、ログ集約アカウントへの証跡集中が、最小権限と多層防御を支えます。
• コスト最適化: 一括請求によるボリューム割引と予約・Savings Plans の共有、アカウント単位でのコスト可視化により、無駄を発見しやすくなります。
• 運用上の優秀性: 新規アカウントの標準化された払い出しやポリシーの一括適用により、手作業を減らし、構成のドリフトを抑制できます。

試験で問われるポイント

関連サービス・比較

AWS Organizations はマルチアカウントの「土台」であり、AWS Control Tower はその上に乗るマネージドなガバナンスのフレームワークです。Control Tower は内部で Organizations を利用しつつ、ベストプラクティスに沿った初期構成（ランディングゾーン）やガードレールを自動セットアップしてくれます。

ハンズオン / CLI例

次の例は、組織内に新しい OU を作成し、その OU に SCP をアタッチする流れの一部です。実行には管理アカウントの権限と、機能セットが「すべての機能」であることが前提です。

# ルートの ID を確認する
aws organizations list-roots --query "Roots[0].Id" --output text

# ルート配下に新しい OU を作成する
aws organizations create-organizational-unit \
  --parent-id r-examplerootid \
  --name "Production"

# 既存の SCP を OU にアタッチしてガードレールを適用する
aws organizations attach-policy \
  --policy-id p-examplescpid \
  --target-id ou-exampleouid

# 対象に効いている SCP を一覧で確認する
aws organizations list-policies-for-target \
  --target-id ou-exampleouid \
  --filter SERVICE_CONTROL_POLICY