セキュリティサービス部 佐竹です。
表題の通りですが、AWS Organizations の SCP における仕様が緩和されました。
はじめに
2026年5月15日（日本時間では16日）に、以下のアップデートがリリースされました。
以下にサマリーを記述します。
アップデートサマリー
- AWS Organizations におけるエンティティ「ルート、OU、アカウント」にアタッチ可能な SCP の最大数が5から10に増加
- SCP に記述可能な文字数の最大サイズが5,120文字から10,240文字に増加
- 本アップデートは自動的にすべての組織に適用されており、ユーザー側のアクションは不要で利用が可能
これだけで全ての解説が終わってしまうくらいにシンプルな緩和のアップデートですが、せっかくなのでもう少々詳しく記載していきます。
何が嬉しいのか
AWS Organizations の SCP の設計と運用にあまり詳しくない方にもわかるように解説していこうと思います。
また、前提として以下のブログをまずはお読みいただけますとより理解が深まると存じます。
補足ですが、2024年の10月頃に、「SCP は継承という用語を利用しなくなった」ことについても以下でまとめておりますので、念のため紹介しておきます。
1つのエンティティにアタッチできる SCP の最大数が10になった
これまで
さて、先にご紹介しましたブログ記事「AWS Organizations の SCP で 設計時に気を付けるべきポイント」で記述している1つ目の注意点が、「1 つのエンティティにアタッチできる SCP の数」です。
過去の仕様としては、以下の通りでした。
- 最小：1
- 最大：5
これが緩和され、現在以下の通りです。
- 最小：1
- 最大：10
つまりこれまでは下図の通り、1つのエンティティに6つ目の SCP を付与することができませんでした。
図の通り「OU1」では「SCP5（6つ目）」をアタッチしたくても、上限緩和不可能な5つまでの制限に抵触したことでこれは不可能となります。
SCP に記述する内容を色々と考えて増やしていくと、実のところこの「5つ」というのは、かなり厳しい制限でした。「FullAWSAccess」は実質必須のため、役割別に分離すると4つの役割をアタッチすることしかできません。よって、役割別に分離すると比較的早期に制限に抵触してしまうため、1つの SCP に複数の役割を持たせ、マージを繰り返すことも多い状況でした。ただし、SCP 用 JSON のマージにも限界があります。
この運用上の緩和策として、SCP が上位エンティティから下位エンティティに引き継がれる仕様（intersection = 共通部分、積集合）を利用する方法がありました。
上図の通り、OU1 の配下に OU2 をつなげることにより、一番下に位置している各 AWS アカウントへは [SCP1] ～ [SCP5] までの全ての SCP の効果を波及させることができます。
[SCP5] をアタッチした状態を「intersection」を踏まえて正しく構成図として描くと、下図のようになります*1。
ですが、このような「入れ子」を繰り返すと今度は「OU ネスト数」の最大数が5であるという別の上限に抵触しやすくなる状況でした。
これから
現在はこの制限が緩和され、10までアタッチが可能になりました。
上図の通り、[SCP9] までをたった1つの OU1 へとアタッチしての運用が可能となります。
よって、これまでのように、SCP の疑似的な上限緩和のためだけに OU のネスト構造を増やす必要がなくなりました。
実際にマネジメントコンソールから SCP を最大の10までアタッチしてみたところ（赤枠は追加した5つの検証用 SCP）、エラーなくアタッチが可能でした。
なお、11個目の SCP を追加しようとすると、マネジメントコンソール上ではボタンがグレーアウトしてアタッチできなくなるという制限がかかります。
SCP に記述可能な文字数の最大が倍の10,240文字に増加
先に「役割別に分離すると比較的早期に制限に抵触してしまうため、1つの SCP に複数の役割を持たせ、マージを繰り返すことも多い状況でした」と記載した点に関連するのがもう1つの緩和アップデートです。
SCP は役割別に分離したポリシーをセットとして並べるという方式が少々採用しにくいため、1つの SCP には多くの記述が混ざることもありました。この時、JSON で「5,120」文字しか記述できないというのも、運用面からみて抵触してしまいやすい制限でした。
ここで利用可能としたインスタンスタイプを列挙するような SCP を考えてみます。
例えば、nano から 4xlarge までのインスタンスタイプしか許容しない SCP を考えてみます。すると、一例としては以下のような JSON が考えられます。
{ "Sid": "DenyLargeEC2Instances", "Effect": "Deny", "Action": [ "ec2:RunInstances", "ec2:StartInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotLike": { "ec2:InstanceType": [ "*.nano", "*.micro", "*.small", "*.medium", "*.large", "*.xlarge", "*.2xlarge", "*.3xlarge", "*.4xlarge" ] } } }, { "Sid": "DenyLargeEC2InstancesModify", "Effect": "Deny", "Action": "ec2:ModifyInstanceAttribute", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotLike": { "ec2:Attribute/InstanceType": [ "*.nano", "*.micro", "*.small", "*.medium", "*.large", "*.xlarge", "*.2xlarge", "*.3xlarge", "*.4xlarge" ] } } },
前者では、Launch と Start を制限しており、後者では Modify コマンドで構築済のインスタンスにおいてインスタンスタイプの変更を禁止しています。
このように、SCP での実装は場合によって文字数が増える場合も多く、5,120 文字というのはかなり抵触しやすいと感じていました。
ですが、これが「10,240 」文字までに緩和されたことによって、これまで 5,120 文字ギリギリで運用されていた SCP の編集においてかなりの余裕が生まれることになりました。
つまり
- 細かく SCP を分離して、役割別に管理運用したい
- SCP が実質的に4つまでしかアタッチできないため、分離しすぎるとアタッチが可能な上限に抵触
- 1つの SCP に設計をまとめて詳細に記述したい
- 5,120 文字という文字数制限に抵触してしまい、泣く泣く SCP JSON を2つ以上に分割せざるを得ない
SCP の設計と運用には、このようなジレンマ（トレードオフ）があったということです。
OU のネスト最大数は5のまま
OU は先の図の通り、複数の層としてネストすることが可能です。その場合の最大は 5 となっており、ネストできる OU は5階層までとなります。
この5階層というネスト最大数は今回のアップデートでは緩和されていません。
と言ってもこれはそこまで不便ではないでしょう。ネスト数が必要になるのは先の通り「SCP の疑似的な上限緩和のため」に行われることがありました。
現在、SCP が10までアタッチできるという点に加えて、記述できる JSON の文字数も倍の 10,240 文字になりました。これだけ緩和されればネスト最大数が5のままでも十分に運用が回ると考えられます。
まとめ
本日は、AWS Organizations の SCP における制限が倍に緩和されたことについて記述しました。
- SCP アタッチ上限数の増加： 5個 から 10個 へ
- SCP 文字数上限の増加： 5,120文字 から 10,240文字 へ
- OU ネスト最大数は現状維持： 5階層のまま（ただし上記緩和によりネスト数は課題になり難くなった）
これまでは上限を回避するために、複数ポリシーの無理なマージや、OU を深くネストさせるような少々苦しめのワークアラウンドが必要になる場面がありました。
今回のアップデートにより、まず役割別の SCP 分離がしやすくなりました。加えて、1つの SCP に詳細な設計が施せるようになったことで、まとめられずに複数に分割せざるを得なかった SCP を1つの SCP としてマージすることも可能となるでしょう。先に記述した「ジレンマ（トレードオフ）」の、どちらもが緩和されています。
ユーザー側のアクションなしで全アカウント（組織）に適用されているアップデートですので、本制限に困らされていた方は、是非現在の SCP 設計を見直すきっかけにしてみてください。
では、またお会いしましょう。
*1:実際には、下位の各エンティティには、上位の全「FullAWSAccess」も重ねて適用されるのですが、それを記述すると絵がごちゃごちゃとするので割愛しています
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
