AWS Organizations における全ポリシーを整理して理解する (2025年11月版)

セキュリティサービス部佐竹です。
2025年11月26日現在の AWS Organizations における全ポリシーを整理して理解するためのブログです。AWS re:Invent 2025 でさらに追加された場合は本ブログに追記予定です*1。

はじめに
「承認ポリシー」と「管理ポリシー」の違いを知る
承認ポリシー (Authorization policies)
管理ポリシー (Management policies)
まとめ

はじめに

本ブログは以下のブログの最新版として記載しています。

blog.serverworks.co.jp

また、「継承」の用語問題については、以下のブログでも言及しました通りです。

blog.serverworks.co.jp

想定読者層は、既に AWS Organizations にある程度詳しい「マルチアカウント管理を業務範囲とする中級/上級エンジニア」で、最新の AWS Organizations に関する全ポリシーを本ブログを通じてキャッチアップすることを目的とします。ではこれらを踏まえまして、本題です。

AWS Organizations の機能拡張は都度、継続的に行われています。特に2024年後半から2025年にかけて、組織全体を統制するための「ポリシー」の種類が大幅に増えました。

上画像はマネジメントコンソールのポリシータイプにおける画面キャプチャです。こちらをご覧ください。以前は数種類しかなかったポリシータイプが、今では 12種類 にまで拡大しています。かつては組織の統制には「SCP だけを理解しておけば良い」という状況でしたが、現在は目的に応じてこれらのポリシーを適切に使い分ける必要があります。

本ブログでは、2025年11月26日時点での全ポリシーを網羅的に解説し、それぞれの違いと使いどころを整理することを目的としています。

「承認ポリシー」と「管理ポリシー」の違いを知る

まず、各ポリシータイプは大別される「2つのカテゴリ」を持ちます。

それが「承認ポリシー」と「管理ポリシー」です。この前提を踏まえて組織ポリシーをまずはカテゴリ分けする必要があります。何故かというと、「承認ポリシー」と「管理ポリシー」では、機能の設計思想も動作も異なるためです。

まずは、11種のポリシータイプを一覧で区分けしました。本ブログはこの順番で解説していきます。

カテゴリ	ポリシー名	ポリシー名 (日本語)
承認ポリシー	Service control policies (SCPs)	サービスコントロールポリシー
	Resource control policies (RCPs)	リソースコントロールポリシー
管理ポリシー	Declarative policies for EC2	EC2 の宣言型ポリシー
	Backup policies	バックアップポリシー
	Tag policies	タグポリシー
	Chat applications policies	チャットアプリケーションポリシー
	AI services opt-out policies	AI サービスのオプトアウトポリシー
	Security Hub policies	Security Hub ポリシー
	Bedrock policies	Bedrock ポリシー
	Inspector policies	Inspector ポリシー
	Upgrade rollout policies	アップグレードロールアウトポリシー
	S3 policies	S3 ポリシー

また、以下が「承認ポリシー」と「管理ポリシー」の動作の違いです。先にご紹介したブログの内容と重複していますが、以下の3点を押さえておきましょう。

① 管理アカウントへの効力

承認ポリシー : 管理アカウント（Management Account）には効力を発揮しません。管理アカウントは組織全体の請求や契約を管理する特権的な立ち位置にあり、誤設定によって自身をロックアウトしないよう設計されています。
管理ポリシー: 管理アカウント自身にも適用が可能なものが多くあります（例：タグポリシーやバックアップポリシーは管理アカウントのリソースにも適用されます）。

※画像はウェビナーからの抜粋となります https://www.serverworks.co.jp/event/ou_webinar_ondemand.html.html

② 権限の評価ロジック（明示的な許可と継承）

承認ポリシー : 「拒否 (Deny)」だけでなく、「許可 (Allow)」も重要です。Root から対象アカウントまでの階層のすべてで明示的な許可（通常は FullAWSAccess）が存在しないと、アクセスは拒否されます（暗黙的な拒否）。これを理解していないと、「FullAWSAccess を外してしまったためにリソースへアクセスできない」といったようなトラブルにつながります。
管理ポリシー: 許可・拒否という概念ではなく、「設定値の継承」です。親で設定された値が子に降りていきます。

③ 継承演算子の有無

承認ポリシー : 継承演算子はありません。論理積（AND 条件）で評価されるため、親で Deny されたものは、子が Allow しても覆りません。「明示的な拒否 → 暗黙的な拒否 → 明示的な許可」の順で常に制御されます。
管理ポリシー: 継承演算子 (Inheritance operators) が存在します。継承された各管理ポリシーの構文は互いに影響しあいます。親ポリシーの設定を、子ポリシーで「上書き」「追加」「削除」するといった制御が可能です。

ここまでのまとめ（比較のための一枚絵）

ここまでの振り返りのために、「承認ポリシー」と「管理ポリシー」の違いを一枚絵で比較してみます。

上図は、Gemini に生成させた一枚絵になっております。向かって左側が「承認ポリシー」で、右側が「管理ポリシー」を図示しています。最近画像生成のレベルが一気にあがったので、理解のためにこういう絵を Gemini に描かせるのもよいかと考えて試しに入れてみました。

では、ここから各ポリシーの解説となります。

承認ポリシー (Authorization policies)

まず最初に、セキュリティの根幹となる「承認ポリシー」について解説します。これらは、「誰が、何を実行できるか」という 権限の境界線（ガードレール） を引くためのポリシーです。コンソール画像にもある通り、現在以下の2種類が存在します。

1. Service Control Policies (SCPs)

「プリンシパル（人・プログラム）」に対する制限

SCP は、組織内のメンバーアカウントにおける「最大権限」を規定するものです。IAM ユーザーや IAM ロール（プリンシパル）が実行できるアクションの上限を設定します。

実際の運用では SCP を「予防的統制(禁止)」のメインとして設計及び運用することになります。

制御対象: 組織内の IAM ユーザー、IAM ロール等のプリンシパル
期待される動作: SCP は「許可の範囲を絞り込む」フィルターとして機能します。IAM ポリシーで Allow されていても、SCP で Allow されていない（または Deny されている）アクションは実行できません。これにより、管理者権限（AdministratorAccess）を持つユーザーであっても、絶対に実行させたくない操作（例: CloudTrail の停止、特定リージョンの利用）を強制的に禁止することが可能です。
主な用途:
- リージョン制限: 東京リージョンや大阪リージョンなど、業務で許可されたリージョン以外でのリソース作成を禁止する。
- ガバナンス維持: CloudTrail や AWS Config などの監査ログ設定の変更・無効化を禁止する。
- ルートユーザー制御: 強力な権限を持つルートユーザーの使用を制限する。
注意点: 管理アカウント（Management Account）自体には適用されません。管理アカウントは特権的な位置づけにあり、自身をロックアウトしないための仕様です。

具体的な SCP の例は以下の AWS 公式ドキュメントが参考になります。

docs.aws.amazon.com

2. Resource Control Policies (RCPs)

「リソース（データ）」に対する制限

RCP は、2024年11月に登場した新しい概念です。SCP が「人（プリンシパル）」を縛るのに対し、RCP は「リソース（データ）」を縛ります。組織内のリソース（S3 バケットや SQS キューなど）に対して、誰からのアクセスを許可するかを組織レベルで規定します。

制御対象: 組織内の AWS リソース（S3, KMS, SQS, Secrets Manager など）
期待される動作: これまでは、S3 バケットポリシーなどで個別に「Deny（拒否）」ルールを書くことで組織外からのアクセスを防いでいましたが、設定漏れのリスクがありました。RCP を使うことで、個々のリソースポリシーに拒否ルールを記載せずとも、組織全体のリソースに対して一括して「データ境界（Data Perimeter）」を適用できます。例えば、「組織外の IAM プリンシパルからのアクセスは、たとえリソースポリシーで許可されていても拒否する」といった強力な制限が可能です。
主な用途:
- データペリメータの構築: 「組織外のプリンシパル」からのアクセスを遮断し、データの流出を防ぐ。
- 通信経路の強制: リソースへのアクセスを HTTPS（TLS）通信のみに限定する。
SCP との違い: SCP は「社内の人間が外部へデータを持ち出す」のを防ぐのに役立ちますが、「社外の人間が社内のリソースにアクセスする」のを防ぐことはできません（それは S3 のバケットポリシー等、各リソースで設定が必要となる各ポリシーの役割でした）。RCP を使うことで、リソースポリシーを個別に設定せずとも、組織全体で「外部からのアクセス禁止」を一括強制できるようになります。

承認ポリシー (SCP/RCP) の比較

ここで一度、「承認ポリシー」の整理をしておきましょう。

特徴	SCP (Service Control Policies)	RCP (Resource Control Policies)
視点	プリンシパル中心「誰が」何をするか	リソース中心「誰に」アクセスさせるか
主な役割	社内ユーザーの操作ミス防止	データ境界の構築 (外部からのアクセス遮断)
制限対象	IAM ユーザー、IAM ロール	S3, KMS などの AWS リソース
外部アクセス制御	不可自組織のプリンシパルが対象	可能組織外からのアクセスも制限対象

管理ポリシー (Management policies)

次に、AWS サービスの「設定」や「状態」を一元管理するための「管理ポリシー」について解説します。これらは権限を縛るのではなく、「あるべき設定」を組織全体に配布・強制するためのものです。

AWS 公式ドキュメントのリスト順序に従い、全9種類の管理ポリシーを解説します。

なお、「Upgrade rollout policies」については運用上、気になる点がいくつかありましたので、他と比較しても詳細に記述しています。

1. Declarative policies for EC2 (宣言型ポリシー)

AWS サービスの設定状態（Configuration）を強制する

これは2024年12月にリリースされた比較的新しいポリシータイプです。SCP が「API アクション（操作）」を禁止するのに対し、宣言型ポリシーは「サービスの設定値（状態）」を強制的に固定します。現在は EC2 関連（VPC, EBS等）のみに対応しています。

期待される動作:
- 「操作」ではなく「状態」を定義します。例えば「VPC を公開しない」と宣言すれば、誰が（管理者や AWS サービス自身を含む）どんな手段を使っても、その設定以外には変更できなくなります。
- ブロック時に表示されるエラーメッセージをカスタマイズでき、「申請が必要です。詳細は社内 Wiki へ」といった運用を鑑みた案内も可能となります。
主な用途:
- VPC Block Public Access: アカウント内の VPC がインターネットと通信することを強制的に遮断する。
- Image / Snapshot Block Public Access: AMI や EBS スナップショットの誤った「公開設定」を防ぐ。
- IMDS Defaults: EC2 メタデータサービス (IMDSv2) の利用を強制する。
メリット:
- 抜け穴がない: SCP では防げない「AWS サービス自身による操作（Service-Linked Role）」や、将来追加される新しい API にも自動的に適用され、設定のドリフト（乖離）を完全に防ぎます。

弊社市野が記載した以下のブログも合わせて参考ください。

blog.serverworks.co.jp

また、このポリシーは Amazon EC2 の「データ保護とセキュリティ」設定に関連するポリシーでもありますので、合わせて以下もご覧ください。

blog.serverworks.co.jp

最後に、AWS 公式ドキュメントのリンクです。

docs.aws.amazon.com

2. Backup policies (バックアップポリシー)

バックアップ計画の統一と強制

AWS Backup の設定（バックアッププラン）を組織全体で標準化し、配布します。

期待される動作: バックアップの頻度（例: 毎日 1回）、保持期間（例: 7年間）、対象リソースなどを定義したポリシーを組織階層に割り当てます。 AWS Organizations の継承機能により、親 OU で「全リソース必須のバックアップ設定」を定義しつつ、子 OU 側で「特定のプロジェクト用の追加設定」をマージするといった柔軟な運用が可能です。配布されたバックアッププランは、メンバーアカウント側では変更不可（イミュータブル）となるため、現場の誤操作による設定変更を防げます。
メリット:
- きめ細かな制御 (Granular Control): 組織のルートで「全リソース必須」を定義しつつ、各 OU（開発環境や本番環境）の要件に応じてバックアップ頻度を上書きするなど、組織構造に合わせた柔軟な管理が可能です。
- 設定の保護 (Immutability): ポリシーによって作成されたバックアッププランは、メンバーアカウント側では「変更不可」として表示されます。ユーザーは内容を確認できますが、勝手に変更したり削除したりすることはできません。
- 一元的な監視: 「trusted service access」により管理アカウントから、組織内のすべてのバックアップジョブのステータスやエラーを一元的に確認・監視できます。

docs.aws.amazon.com

3. Tag policies (タグポリシー)

タグ付けルールの標準化

リソースに付与するタグのキー（Key）と値（Value）のルールを定義します。

期待される動作: タグキーの大文字・小文字の表記揺れ（例: CostCenter vs cost-center）を統一させることができます。また、タグの値として許可するリスト（例: Marketing, Engineering）を定義し、それ以外の値の入力を禁止することも可能です。非準拠のタグが付与されているリソースを特定するためのレポート機能も提供されており、既存リソースの是正にも役立ちます。
メリット: コスト配分タグの精度が向上し、正確なコスト管理が可能になります。また、タグベースのアクセス制御（ABAC）を導入する際の下地作りとして非常に重要です。

docs.aws.amazon.com

4. Chat applications policies (チャットアプリケーションポリシー)

チャットツール連携の制御

Amazon Q Developer in chat applications (旧: AWS Chatbot) を介した Slack や Microsoft Teams へのアクセス権限を制御します。

期待される動作: 組織内のアカウントから接続を許可するワークスペース ID（Slack）やテナント ID（Teams）をホワイトリスト形式で指定します。これにより、会社が管理していない個人のワークスペースへの接続をブロックできます。また、チャットツールから実行可能な操作（読み取りのみ、Lambda 実行許可など）の権限範囲を制御することも可能です。
メリット: シャドー IT の防止に役立ちます。社員が個人の Slack ワークスペースに AWS の通知を飛ばしたり、未認可のチャットツールへ機密情報を持ち出したりするリスクを低減します。

docs.aws.amazon.com

5. AI services opt-out policies (AI サービスのオプトアウトポリシー)

AI 学習データ利用の拒否

AWS の AI サービスが、機能改善のために顧客データを利用することを「オプトアウト（拒否）」するためのポリシーです。

期待される動作: Amazon Rekognition や Amazon Transcribe などの AI サービスにおいて、処理されたデータが AWS 側の学習モデル改善に使用されることを、組織レベルで一括して拒否します。ポリシーでオプトアウトを設定すると、各アカウント側で個別に設定変更することはできなくなります。
メリット: 金融機関や医療機関など、機密性の高いデータを扱うエンタープライズ環境において、データガバナンス要件やコンプライアンス基準を満たすために必須の設定です。

docs.aws.amazon.com

6. Security Hub policies (Security Hub ポリシー)

セキュリティ基準の一元管理

2025年6月17日に追加されたポリシーで、AWS Security Hub CSPM の有効化設定や構成を組織全体で管理します*2。

期待される動作: 組織内の全アカウント、あるいは特定の OU に対して Security Hub CSPM を強制的に有効化します。また、適用するセキュリティ基準（FSBP や CIS ベンチマークなど）も指定できます。 ALL_SUPPORTED を指定することで、将来追加されるリージョンも含めて自動的に有効化設定を適用することが可能です。
メリット: 新規アカウントが作成された瞬間に Security Hub CSPM が有効になり、セキュリティ監視の空白期間（タイムラグ）をなくすことができます。また、メンバーアカウント側での勝手な無効化を防ぎ、常に監視状態を維持します。これにより「セキュリティ設定の一貫性を確保」することが目的となります。

docs.aws.amazon.com

7. Bedrock policies (Bedrock ポリシー)

生成 AI ガードレールの強制適用

Amazon Bedrock の利用において、組織の管理アカウントで定義した「ガードレール (Guardrails)」を強制的に適用します*3。

期待される動作: まず、管理アカウントで Bedrock の「ガードレール（不適切なコンテンツのフィルタリング、個人情報のマスキング設定など）」を作成します。次に、Bedrock ポリシーを作成し、そのガードレールの ARN を指定して OU やアカウントにアタッチします。対象のアカウントで Bedrock のモデル推論（Inference）が行われる際、指定されたガードレールが自動的に適用されます。
メリット: 個々のアカウントごとにガードレールを作成・設定する手間を省き、組織全体で統一された生成 AI の利用ポリシー（安全性基準）を適用できます。

docs.aws.amazon.com

8. Inspector policies (Inspector ポリシー)

脆弱性診断の自動有効化

2025年11月19日に追加された新しいポリシーです。Amazon Inspector (EC2, ECR, Lambda などの脆弱性スキャン) の有効化設定を一元管理します。

期待される動作: EC2 スキャン、ECR スキャン、Lambda スタンダードスキャン、Lambda コードスキャンなど、スキャンタイプごとの有効/無効を定義し、組織全体に適用します。特定のアカウントや OU を対象にすることや、逆に特定のアカウントを除外することも可能です。ポリシーが適用された OU に移動したアカウントは、自動的に Amazon Inspector が有効化され、委任された管理者アカウント（Delegated Administrator）にリンクされます。
メリット:
- スキャン漏れの防止: アカウント作成と同時に脆弱性スキャンを開始できるため、大規模な組織においても導入の空白期間をなくし、セキュリティベースラインを維持する運用負荷が激減します。
- スキャンタイプの制御: 親ポリシーで全体的な有効化を定義しつつ、特定の子 OU では開発環境向けにスキャンタイプを制限するなど、継承演算子を利用した柔軟な制御が可能です。
- リージョン対応の自動化: ALL_SUPPORTED オプションを使用することで、将来追加される新しいリージョンに対しても自動的にスキャンを適用できます。

aws.amazon.com

docs.aws.amazon.com

9. Upgrade rollout policies (アップグレードロールアウトポリシー)

DB アップグレード順序の制御

2025年11月21日に追加された最も新しいポリシーです。Amazon RDS や Amazon Aurora のマイナーバージョン自動アップグレードのタイミングを制御します。

期待される動作: リソースに対してタグやポリシー設定を適用し、アップグレードの適用順序を以下の3段階（patch_order）に分類して制御します。
- First: 新しいマイナーバージョンが利用可能になると、設定されたメンテナンスウィンドウ中に最初にアップグレードされます（主に開発環境向け）。
- Second: First の適用からサービス固有の待機期間（通常1週間程度）を経て、アップグレード対象となります（主にステージング/検証環境向け）。
- Last : さらに待機期間を経て、最後にアップグレードが適用されます（本番環境向け）。
各フェーズの間には検証期間が設けられており、AWS Health 通知や Amazon EventBridge で進行状況をモニタリングできます。もし初期の段階（First）で問題が検知された場合は、自動進行を停止することで、後続の環境への影響を防ぐことが可能であるとのことです。
ただ「自動進行を停止」に関して、News には You can also disable automatic progression at any time と記載があるため、何らかの方法が実装されていると思われたのですが、公式ドキュメントを読んでも停止する方法は記載されていないので、メンテナンスウィンドウをズラすか、自動マイナーバージョンアップを無効化するなどの運用回避が必要かもしれません。
メリット:
- 安全な自動化: 「開発環境でアップグレードを試し、問題がなければ本番環境に適用する」という安全な運用フローを、手動介入なしに実現できます。
- 運用コストの削減: これまで数百のデータベースリソースに対して手動やスクリプトで行っていたスケジュール調整のオーバーヘッドを排除します。
- 対応サービス: Amazon Aurora (MySQL/PostgreSQL 互換) および Amazon RDS (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, Db2) に対応しています。
- *Oracle については、2026年1月以降にリリースされるエンジンバージョンが対象です。

aws.amazon.com

docs.aws.amazon.com

ポリシーの一例

理解の促進のため、ポリシーの一例を記載してみます。

以下は、Environment というタグによって制御される Upgrade rollout policies の例です。

{
  "upgrade_rollout": {
    "default": {
      "patch_order": {
        "@@assign": "second"
      }
    },
    "tags": {
      "Environment": {
        "tag_values": {
          "Dev": {
            "patch_order": {
              "@@assign": "first"
            }
          },
          "Staging": {
            "patch_order": {
              "@@assign": "second"
            }
          },
          "Production": {
            "patch_order": {
              "@@assign": "last"
            }
          }
        }
      }
    }
  }
}

json をマネジメントコンソール上で確認すると以下のように表示されます。

また先の json に解説をコメントで加えてみると、以下のようになります。

{
  "upgrade_rollout": {
    // 【デフォルト設定】
    // タグが付いていない、またはタグの値が一致しないリソースは、この設定に従います。
    // 今回は標準的な "second" にしていますが、より安全に倒すなら "last" でも構いません。
    "default": {
      "patch_order": {
        "@@assign": "second"
      }
    },
    // 【タグによる上書き設定】
    "tags": {
      // ここで指定する "Environment" が、各AWSリソースに付ける「タグのキー」になります。
      "Environment": {
        "tag_values": {
          
          // タグの値が "Dev" のリソースは「最初」にアップデート
          "Dev": {
            "patch_order": {
              "@@assign": "first"
            }
          },

          // タグの値が "Staging" のリソースは「2番目」にアップデート
          "Staging": {
            "patch_order": {
              "@@assign": "second"
            }
          },

          // タグの値が "Production" のリソースは「最後」にアップデート
          "Production": {
            "patch_order": {
              "@@assign": "last"
            }
          }
        }
      }
    }
  }
}

DB アップグレード順序のみ制御が可能

このポリシーでは、DB アップグレード順序のみ制御が可能となっています。

各フェーズに「どの程度のインターバルを用意するのか」というのは、制御できません。First から Second へは以下の通りおよそ一週間程度の待機期間があるようです。

When a supported AWS service releases an upgrade, it consults the upgrade rollout policies to determine the order in which resources should receive the upgrade. The service first applies the upgrade to resources marked as "First" during their configured maintenance windows. After a service-specific waiting period, typically around one week, resources marked as "Second" become eligible for the upgrade. Finally, after another waiting period, resources marked as "Last" receive the upgrade.

(日本語訳)

サポートされているAWSサービスがアップグレードをリリースすると、アップグレードのロールアウトポリシーを参照して、リソースがアップグレードを受け取る順序が決定されます。サービスはまず、「First」とマークされたリソースに、設定されたメンテナンスウィンドウ中にアップグレードを適用します。サービス固有の待機期間（通常約1週間）が経過すると、「Second」とマークされたリソースがアップグレードの対象になります。最後に、さらに待機期間が経過すると、「Last」とマークされたリソースがアップグレードを受け取ります。

ドキュメントにある記述はこれだけです。具体的に First から Second へ15日間待たせたい、といった任意の期間指定を行う制御は提供されていません。

例えば仮に、各 First のリソースも Second、Last のリソースも、全てのメンテナンスウィンドウの設定が「毎週日曜日」だったとします。この場合、まず First のリソースへとパッチが配布され、その後の最初の日曜日に実際に RDS (Aurora) へとパッチが適用されます。その後、次の日曜日に Second のリソースが、最後に次の次の日曜日に Last のリソースへパッチが適用されると考えられます。

ただ、パッチの配布が1週間ごとに確実に行われるかは不明ですため、場合によってはインターバルが2週間以上となってしまうこともあるでしょう。

ここまでで、Upgrade rollout policies の解説を終わりにします。

10. S3 policies (S3 ポリシー)

S3 パブリックアクセスブロックの一元管理

2025年11月26日に追加されたばかりの最新のポリシーです*4。Amazon S3 の「パブリックアクセスブロック (Block Public Access)」設定を組織全体で一元管理が可能です。

期待される動作:
- 組織内の全アカウント、あるいは特定の OU に対して、S3 のパブリックアクセスブロック設定（以下4項目すべて）を強制的に「有効（Block All）」にするか、あるいは「無効（各アカウントの自由にさせる）」にするかを定義します。
  - BlockPublicAcls
  - BlockPublicPolicy
  - IgnorePublicAcls
  - RestrictPublicBuckets
- ポリシーで @@assign: "all" を設定すると、対象アカウント内のすべての S3 リソースに対してこれら4つのブロック設定が強制的に適用され、アカウント側での変更はできなくなります。
- ポリシーをデタッチ（解除）すると、各アカウントは自動的にポリシー適用前の設定に戻ります（復元機能）。
メリット:
- セキュリティベースラインの徹底: 「意図しない S3 公開」はセキュリティ事故の代表例ですが、これを組織レベルで強制的に防ぐことができます。
- 設定の一貫性: 新規作成されたアカウントやバケットに対しても自動的にブロック設定が継承されるため、設定漏れを防げます。
- シンプルな管理: 4つの設定項目を個別に制御するのではなく、「全ブロック(all)」か「各アカウントに任せる(none)」かの二択で管理するため、運用が複雑になりません。

ポリシーの一例

S3 ポリシーの json 構文はシンプルです。以下は、組織全体でパブリックアクセスをブロックする場合の設定例です。

{
    "s3_attributes": {
        "public_access_block_configuration": {
            "@@assign": "all"
        }
    }
}

"@@assign": "none" とすると、組織レベルでの制御を行わない（各アカウント設定に任せる）となります。

docs.aws.amazon.com

まとめ

本ブログでは、2025年11月26日現在の AWS Organizations における全ポリシーを整理し、理解するため、各ポリシーについてそれぞれ解説を行いました。

AWS Organizations のポリシー機能は、年々その範囲を広げています。

かつては「やってはいけないこと（＝禁止）」を定義する SCP がポリシーの中心でしたが、ここ最近は「やるべき設定」を自動化・強制する管理ポリシーに関するリリースの比重が高まっています。これは、AWS が組織管理において 「統制（Governance）」から「管理の自動化（Management Automation）」、つまり「省力化」へとシフトしている ことの表れにも見て取れます。省力化、ひいては認知負荷の軽減ともいえるこれらは、AWS re:Inforce 2025 におけるキーノートの大きなテーマの1つでした。

特に、2025年11月に追加された3つ、Amazon Inspector policies、Upgrade rollout policies や S3 policies は、セキュリティや運用保守といった、これまで人手に頼らざるを得なかった領域にまでポリシーの適用範囲を拡張してきています。

これらを使いこなすことは、単にルールを守らせるだけでなく、エンジニアを「設定作業」や「スケジュール調整」といった「差別化につながらない重労働」から解放することに繋がります。

まずは自社の運用課題と照らし合わせ、効果の大きそうなポリシーから試験的に導入してみてはいかがでしょうか。本ブログが、皆様の AWS 組織管理の一助となれば幸いです。

では、またお会いしましょう。

*1:11月26日に S3 ポリシーが増えたので追記しています

*2:旧 AWS Security Hub は AWS re:Inforce 2025 で全く新しい Security Hub がリリースされたことを受け、Security Hub CSPM という名称に変更されました

*3:いくら探してもリリース日がわかりませんでした。ドキュメントヒストリーにも記載がありません

*4:News リリースがブログ記述時点では見つけられませんでしたが、コンソール上では実装が確認できています

AWS Organizations における全ポリシーを整理して理解する (2025年11月版)

はじめに

「承認ポリシー」と「管理ポリシー」の違いを知る

① 管理アカウントへの効力

② 権限の評価ロジック（明示的な許可と継承）

③ 継承演算子の有無

ここまでのまとめ（比較のための一枚絵）

承認ポリシー (Authorization policies)

1. Service Control Policies (SCPs)

2. Resource Control Policies (RCPs)

承認ポリシー (SCP/RCP) の比較

管理ポリシー (Management policies)

1. Declarative policies for EC2 (宣言型ポリシー)

2. Backup policies (バックアップポリシー)

3. Tag policies (タグポリシー)

4. Chat applications policies (チャットアプリケーションポリシー)

5. AI services opt-out policies (AI サービスのオプトアウトポリシー)

6. Security Hub policies (Security Hub ポリシー)

7. Bedrock policies (Bedrock ポリシー)

8. Inspector policies (Inspector ポリシー)

9. Upgrade rollout policies (アップグレードロールアウトポリシー)

ポリシーの一例

DB アップグレード順序のみ制御が可能

10. S3 policies (S3 ポリシー)

ポリシーの一例

まとめ

これからの開発で考えておくべきこと(生成AI/AI-DLC/ZTP)

【AWS re:Invent 2025】[NEW LAUNCH] Retire technical debt at scale with automated code transformation [REPEAT] (DVT338-R) 参加レポート

Regional NAT Gatewayか、それともZonal NAT Gatewayか

【AWS re:Invent 2025】Amazon Leo（旧 Project Kuiper）ブース訪問レポート

【AWS re:Invent 2025】AWS DevOps Agent の自動調査機能をNew Relicと連携して試してみた【5 人目】