AWS Organizations 入門

Last updated at 2025-10-16Posted at 2025-10-16

執筆の背景

AWSの利用が進むにつれ、セキュリティ・ガバナンスの観点から「開発」「検証」「本番」のように、環境ごとにアカウントを分離する必要性が高まっています。
これらを一元管理できる仕組みとして、AWS Organizationsがありますが、自社の環境や、お客様環境を見ると、まだまだ普及していないように感じています。
この記事では、AWS Organizationsがどのようなものかについて、改めて入門記事として照会し、未導入の方の一助となればと思い執筆しました。

AWS Organizationsとは

AWS Organizations は、 AWS リソースの拡大とスケーリングに合わせて環境を一元管理および管理するのに役立ちます。Organizations を使用すると、アカウントの作成、リソースの割り当て、ワークロードを整理するためのアカウントのグループ化、ガバナンスへのポリシーの適用、すべてのアカウントに単一の支払い方法を使用した請求の簡素化が可能になります

AWS Organizationsには以下の2種類のアカウントの概念が存在します。

管理アカウント（全体統括用）
メンバーアカウント

管理アカウントは常に1つのみ登録可能です。

また、メンバーアカウントを階層的に統制するための「OU（Organizational Unit）」やアカウントに適用する「組織ポリシー（Organization Policies）」等の仕組みがあります。
この記事では主に、組織ポリシーのうち「承認ポリシー」について解説します。

AWS Organizationsの構成要素

AWS Organizationsは、複数の要素を組み合わせて階層的な構造を作ります。
主な構成要素を以下です。

構成要素一覧

構成要素	説明	主な特徴	制約・注意点
組織（Organization）	複数のAWSアカウントを統合管理するための最上位のコンテナ	・1つのAWSアカウントで組織を作成・組織の作成自体に料金は発生しない	・1つのAWSアカウントは1つの組織にのみ所属可能・組織を削除すると全メンバーアカウントが独立
ルート（Root）	組織内のすべてのアカウントとOUを含む親コンテナ	・組織には必ず1つのルートが存在・ルートに適用されたポリシーは全体に継承	・削除不可・必ず1つのみ存在
管理アカウント（Management Account）	組織全体を管理する特権を持つアカウント	・組織の作成と削除・メンバーアカウントの招待と作成・OUの作成と管理・組織ポリシーの作成と適用・一括請求の管理	・SCPは管理アカウントに適用されない（重要）・組織から離脱不可・本番ワークロードを動かさないことを推奨
メンバーアカウント（Member Account）	組織に招待または作成された子アカウント	・実際のワークロードを実行・完全に独立したAWS環境を提供・SCPによる制御を受ける	・複数可能（デフォルト上限10、申請で増加可能）・管理アカウントの承認があれば組織から離脱可能・1つのOUにのみ所属可能
組織単位（OU）	アカウントをグループ化するための論理的なコンテナ	・最大5階層まで作成可能・複数のアカウントと子OUを含められる・OUに適用されたポリシーは配下に継承	・アカウントは複数のOUに同時所属不可・階層は最大5レベルまで
組織ポリシー（Organization Policies）	組織全体やOU、個別アカウントに適用できるルールセット	・Root、OU、アカウントレベルで適用可能・上位のポリシーは下位に継承・複数ポリシーは論理積（AND）で評価	・Deny（拒否）が1つでもあればアクション実行不可・管理アカウントにはSCPが適用されない

アカウントタイプの詳細比較

比較項目	管理アカウント	メンバーアカウント
数	1つのみ	複数可能（デフォルト上限10）
作成方法	組織作成時に自動的に設定	招待または新規作成
SCPの適用	適用されない	適用される
組織からの離脱	不可	管理アカウントの承認があれば可能
推奨される使い方	管理専用（ワークロード実行は非推奨）	環境やプロジェクトごとに分離して使用
主な権限	・組織の作成/削除・アカウント管理・OU管理・ポリシー管理・請求管理	・リソースの作成/管理・アプリケーションの実行

SCPとRCP

AWS Organizationsの組織ポリシーには、主に以下の2種類の承認ポリシーがあります。

SCP（Service Control Policy：サービスコントロールポリシー）

SCPは、組織内のアカウントで実行可能なAWSサービスのアクションを制御するポリシーです。

SCPの特徴

アカウントレベルでの制御: 特定のアカウントやOU配下のアカウントに対して、実行可能なアクションの上限を設定
階層的な適用: Root、OU、個別アカウントに適用可能で、上位のポリシーは下位に継承される
権限の制限のみ: SCPは権限を付与するのではなく、利用可能なアクションの範囲を制限する
管理アカウントには適用されない: 管理アカウント自体にはSCPの制限が適用されないため注意が必要

SCPの動作原理

実際にユーザーが実行できるアクションは、以下の論理積で決まります。

実効権限 = SCP で許可された範囲 ∩ IAM で許可された権限

要するに、IAMで広範な権限が付与されていても、SCPで制限されているアクションは実行できないということになります。

SCPの記述例

例1: 特定リージョン以外でのリソース作成を禁止

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1"
          ]
        }
      }
    }
  ]
}

このSCPにより、東京リージョンとバージニア北部リージョン以外でのすべてのアクションが禁止されます。

例2: ルートユーザーの使用を禁止

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

例3: 特定のインスタンスタイプのみ許可

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLargeInstances",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": [
            "t3.micro",
            "t3.small",
            "t3.medium"
          ]
        }
      }
    }
  ]
}

開発環境OUに適用することで、コスト増大を防ぐことができます。

RCP（Resource Control Policy：リソースコントロールポリシー）

RCPは、2023年11月に発表された比較的新しいポリシータイプです。
https://aws.amazon.com/jp/blogs/news/introducing-resource-control-policies-rcps-a-new-authorization-policy/

RCPの特徴

リソースレベルでの制御: 特定のAWSリソースに対するアクションを制御
プリンシパル（実行者）に基づく制御: どのアカウントやロールからのアクセスを許可するかを定義
SCPとの違い: SCPはアカウント全体の権限上限を設定するのに対し、RCPは特定リソースへのアクセスを制御

RCPのユースケース

クロスアカウントアクセスの制御: 組織外のアカウントからのアクセスを防止
特定リソースの保護: 重要なS3バケットやKMSキーへのアクセスを厳密に制御
データ境界の実装: 組織のデータが外部に流出しないよう境界を設定

RCPの記述例

例: 組織外のプリンシパルによるS3バケットへのアクセスを拒否

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExternalAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        }
      }
    }
  ]
}

SCPとRCPの使い分け

観点	SCP	RCP
制御対象	アカウント内で実行可能なアクション	特定リソースへのアクセス
主な用途	ガードレールの設定、コンプライアンス	データ保護、クロスアカウント制御
適用範囲	Root、OU、アカウント	リソース
優先して使うべき場面	組織全体のガバナンス	機密データの保護

実務では、SCPで大枠のガードレールを設定し、RCPで特定の重要リソースを保護するという組み合わせが効果的になってきます。

次記事

次記事では、実際にAWS Organizationsを始めるためのステップを紹介します。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up