※本記事にはアフィリエイト広告が含まれます。
AWSで作業していて「AccessDenied」「is not authorized to perform」に当たると、つい手元のIAMポリシーにAllowを足して再実行したくなります。ですが、原因がSCPやアクセス許可の境界にある場合、IAMポリシーをいくら直しても通りません。
実は、多くのAccessDeniedのエラー文には「どの種類のポリシーで止まったか」が書かれています。この記事では、IAMの公式ドキュメント「Troubleshoot access denied error messages」に載っているエラー文の形式を、同じく公式の評価ロジック（どの順番でポリシーを評価するか）の各ステップに対応づけて整理します。エラー文から逆引きして「評価のどこで止まったか」「どのポリシーを確認するか」まで1ページで追えるようにするのが目的です。
なお、本記事の仕様・エラー文はすべて2026-10-01時点の公式ドキュメント（英語版）から引用しています。記事中のエラー文の例は公式ドキュメントの例文であり、私の環境で発生させたものではありません。用語は日本語版ドキュメントの訳語（明示的な拒否・暗黙的な拒否・アクセス許可の境界など）に合わせています。
結論：AccessDeniedの文末を見れば、どのポリシーで止まったかがわかる
公式ドキュメントによると、ほとんどのアクセス拒否のエラーメッセージは次の形式です。
User {user} is not authorized to perform {action} on {resource} because {context}{user} は拒否されたプリンシパルのARN、{action} は拒否されたサービスのアクション、{resource} は対象リソースのARNです。見るべきは最後の {context} で、ここに「拒否したポリシーの種類」が入り、場合によっては拒否したポリシーのARNも入る、と公式に書かれています。
文末の言い回しは2パターンです。
| 文末の言い回し | 意味 | 直し方の方向 |
|---|---|---|
with an explicit deny in a {type} policy（後ろに : {policy ARN} が付くこともある） | 明示的な拒否。その種類のポリシーに該当アクションの Deny 文がある | 該当する Deny 文を探して外す・条件を見直す |
because no {type} policy allows the {action} action | 暗黙的な拒否。Deny はないが、Allow もない | その種類のポリシーに Allow を足す |
公式のトラブルシュート手順も、まず「エラーメッセージにポリシーの種類とARNが含まれているか」を確認し、ARNがあればそのポリシーの Deny 文を、種類だけならその種類のポリシー全体を確認する、という順番になっています。
ただし注意点があります。公式ドキュメントには「一部のAWSサービスはこのエラーメッセージ形式に対応しておらず、メッセージの内容は認可を行うサービスによって異なる」と書かれています。文末にポリシーの種類が出ていない場合は、この記事の後半の評価順序を頼りに、アイデンティティベースのポリシーから順に確認していくことになります。
背景：AWSがリクエストを許可・拒否する評価の順番
エラー文の「種類」を正しく読むには、AWSがどの順番でポリシーを評価しているかを押さえておくと早いです。公式ドキュメントの前提は次の3つです。
- 既定では、AWSアカウントのルートユーザーを除き、すべてのリクエストは暗黙的に拒否される
- 許可されるには、評価ロジックに沿ってポリシーで明示的に許可されている必要がある
- 明示的な拒否は明示的な許可より優先される
そのうえで、評価は次のステップで進みます（同一アカウント内のリクエストの場合。クロスアカウントは別ページで扱われています）。
| 順番 | ステップ | ここで拒否（Deny）になる条件 |
|---|---|---|
| 1 | 明示的な拒否の評価 | SCP・RCP・リソースベースのポリシー・アイデンティティベースのポリシー・アクセス許可の境界・セッションポリシーのどれかに、該当する Deny 文が1つでもある |
| 2 | RCP（リソースコントロールポリシー） | 該当する Allow 文がない |
| 3 | SCP（サービスコントロールポリシー） | 該当する Allow 文がない |
| 4 | リソースベースのポリシー | （プリンシパルの種類によっては、ここの Allow で最終的に許可になることがある） |
| 5 | アイデンティティベースのポリシー | 許可する文がない |
| 6 | アクセス許可の境界 | 境界が設定されていて、境界のポリシーが許可していない |
| 7 | セッションポリシー | セッションプリンシパルで、渡されたセッションポリシーが許可していない |
公式の説明では、ステップ1で該当する明示的な拒否が1つでも見つかった時点で、最終判定は拒否になります。そのため、エラー文が with an explicit deny in ... なら「ステップ1で止まった」、because no ... policy allows なら「ステップ2以降のどこかで Allow が見つからなかった」と読めます。
RCPについては、RCPを有効にすると RCPFullAWSAccess というAWS管理ポリシーが組織のルート・各OU・各アカウントに自動でアタッチされ、デタッチできないため、常に Allow 文が存在する、と公式に書かれています。後述する公式のエラー文の例でも、RCPについては明示的な拒否の例だけが載っています。
もう1つ大事なのが、SCP・RCP・アクセス許可の境界は「許可を与えるもの」ではなく「上限を決めるもの」だという点です。Organizationsのドキュメントでは、SCPは権限を付与せず、IAMユーザーとIAMロールが使える最大の権限を定めるガードレールだと説明されています。アクセス許可の境界も、IAMプリンシパル（ユーザー・ロール）が持てる最大の権限を制御するもの、とされています。つまり、これらで許可されていても、アイデンティティベースのポリシーなどで別途許可しない限り使えません。
早見表：エラー文×評価ステップ×確認する場所
公式ドキュメントに載っているエラー文のパターンを、評価ステップと確認する場所に対応づけると次のようになります。「文末の表記」は公式の例文から該当部分だけを抜き出したものです。
| 文末の表記 | 種類 | 評価ステップ | 確認する場所 |
|---|---|---|---|
because no service control policy allows | SCP・暗黙的 | 3 | SCPに該当アクションの Allow がない。Organizationsの管理者に確認 |
with an explicit deny in a service control policy | SCP・明示的 | 1 | ARNが出ていればそのSCP、なければ適用されるSCP全体の Deny 文 |
with an explicit deny in a resource control policy | RCP・明示的 | 1 | ARNが出ていればそのRCP、なければRCP全体の Deny 文 |
because no VPC endpoint policy allows | VPCエンドポイントポリシー・暗黙的 | — | 経由したVPCエンドポイントのポリシーに Allow がない |
with an explicit deny in a VPC endpoint policy | VPCエンドポイントポリシー・明示的 | — | VPCエンドポイントのポリシーの Deny 文 |
because no permissions boundary allows | アクセス許可の境界・暗黙的 | 6 | プリンシパルに設定された境界のポリシーに Allow がない |
with an explicit deny in a permissions boundary | アクセス許可の境界・明示的 | 1 | 境界のポリシーの Deny 文 |
because no session policy allows | セッションポリシー・暗黙的 | 7 | AssumeRole等で渡したセッションポリシー（Policy／PolicyArns パラメータ）に Allow がない |
with an explicit deny in a session policy | セッションポリシー・明示的 | 1 | セッションポリシーの Deny 文 |
because no resource-based policy allows | リソースベース・暗黙的 | 4 | バケットポリシー等のリソース側ポリシーに Allow がない |
with an explicit deny in a resource-based policy | リソースベース・明示的 | 1 | リソース側ポリシーの Deny 文 |
because no role trust policy allows the sts:AssumeRole action | ロールの信頼ポリシー・暗黙的 | 4 | 引き受ける側のロールの信頼ポリシー |
with an explicit deny in the role trust policy | ロールの信頼ポリシー・明示的 | 1 | 信頼ポリシーの Deny 文 |
because no identity-based policy allows | アイデンティティベース・暗黙的 | 5 | ユーザー・グループ・ロールにアタッチされたポリシーに Allow がない |
with an explicit deny in an identity-based policy | アイデンティティベース・明示的 | 1 | ARNが出ていればそのポリシー、なければアタッチされたポリシー全体の Deny 文 |
VPCエンドポイントポリシーは、評価ロジックのページの7ステップには独立した項目として出てこないため、表では評価ステップを「—」にしています。エラー文には種類として明記されるので、VPCエンドポイント経由でアクセスしている環境ではこの表記も覚えておくと切り分けが早くなります。また公式ドキュメントでは、CloudTrailに記録されないアクセス拒否がVPCエンドポイントポリシー使用時に出る場合、VPCエンドポイントの所有アカウントが呼び出し元のアカウントやターゲットロールのアカウントと異なることが原因かもしれない、とされています。
細かい点ですが、公式の例文では、明示的な拒否の言い回しがほかの種類は in a service control policy・in a permissions boundary・in an identity-based policy のように不定冠詞（a／an）なのに対し、信頼ポリシーだけは with an explicit deny in the role trust policy と定冠詞（the）になっています。エラー文をそのまま検索するときは、この違いに注意してください。
具体例：よくある3つの場面で読み解く
例1：Organizations配下のアカウントで「no service control policy allows」が出た
公式ドキュメントには次の例文が載っています。
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codecommit:ListRepositories
because no service control policy allows the codecommit:ListRepositories actionこれは評価ステップ3（SCP）で、該当アクションを許可する Allow 文が見つからなかったケースです。ここで自分のIAMポリシーに codecommit:ListRepositories を足しても解決しません。Organizationsのドキュメントには、アカウントより上のどの階層でも許可がブロックされていれば、ユーザーに AdministratorAccess をアタッチしてもその権限は使えない、と書かれています。
確認するのは、アカウントとその上のOU・ルートにアタッチされたSCPです。IAMのドキュメントでは、SCPやRCPが拒否しているかを知りたい場合や有効な権限を変えたい場合は、AWS Organizationsの管理者に問い合わせるよう案内されています。なお、SCPは管理アカウントのユーザー・ロールには影響せず、メンバーアカウントにだけ効きます。
例2：ロールに権限を足したのに「no permissions boundary allows」が出る
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
because no permissions boundary allows the codedeploy:ListDeployments actionアイデンティティベースのポリシーは許可しているのに、境界が許可していないケースです。公式ドキュメントでは、アイデンティティベースのポリシーとアクセス許可の境界を評価した結果の権限は「両者の積集合（intersection）」だと説明されています。アイデンティティベースのポリシーにいくら Allow を足しても、境界に含まれないアクションは使えません。
確認するのは、そのユーザー（またはロール）に「アクセス許可の境界」として設定されているポリシーです。公式のトラブルシュートページも、境界がある場合は境界に使われているポリシーがそのリクエストを許可しているかを確認するよう案内しており、アイデンティティベースのポリシーが許可していても境界が許可していなければリクエストは拒否される、と書いています。アイデンティティベースのポリシーだけを見ていると気づけないので、エラー文に permissions boundary と出たら境界のほうを開いてください。
例3：別ロールへの切り替えで「no role trust policy allows the sts:AssumeRole action」が出る
User: arn:aws:iam::123456789012:user/John is not authorized to perform: sts:AssumeRole
because no role trust policy allows the sts:AssumeRole action引き受けようとしているロールの信頼ポリシーに、自分（呼び出し元のプリンシパル）を許可する Allow 文がないケースです。公式の手順でも、ロールの信頼ポリシーに該当アクションの Allow 文が欠けていないかを確認するよう書かれています。確認するのは、自分のIAMポリシーではなく「引き受ける先のロール」の信頼ポリシーの Principal と Action、それに条件（Condition）です。
公式の評価ロジックでは、ほとんどのリソースはアイデンティティベースかリソースベースのどちらかで明示的に許可されていればアクセスできるのに対し、IAMロールの信頼ポリシーとKMSキーポリシーは例外で、プリンシパルへのアクセスを明示的に許可しなければならない、とされています。同じアカウント内のロールでも、信頼ポリシーで許可されていなければ引き受けられない、ということです。
よくある誤解
誤解1：エラーに出たポリシーだけ直せばよい
公式ドキュメントには、複数の種類のポリシーが拒否している場合、エラーメッセージにはそのうち1種類しか含まれない、と明記されています。また、同じ種類の複数のポリシーが拒否していても、評価したポリシーの数は示されません。エラーに出た種類のポリシーを直したら、今度は別の種類の拒否が出る、ということは起こりえます。公式も「エラーメッセージで示されたポリシーに加えて、適用されるすべてのポリシーを確認する」よう勧めています。
誤解2：Allowを足せばDenyを上書きできる
明示的な拒否は明示的な許可より優先されます。評価ステップ1で明示的な拒否が1つでも見つかれば、その時点で最終判定は拒否です。explicit deny と出ているのに別のポリシーへ Allow を足すのは、評価の仕組み上意味がありません。Deny 文そのもの（または Deny 文の条件）を見直す必要があります。
誤解3：同一アカウントならリソースベースのポリシーも境界で必ず絞られる
同一アカウント内では、リソースベースのポリシーが「どのARNを許可しているか」で結果が変わります。公式ドキュメントの説明を整理すると次のとおりです。
- IAMユーザーのARNを許可している場合：アイデンティティベースのポリシーやアクセス許可の境界の暗黙的な拒否には制限されない
- IAMロールセッションのARN（
arn:aws:sts::...:assumed-role/...）を許可している場合：セッションに直接付与された権限として扱われ、アイデンティティベースのポリシー・境界・セッションポリシーの暗黙的な拒否には制限されない - IAMロールのARN（
arn:aws:iam::...:role/...）を許可している場合：境界やセッションポリシーの暗黙的な拒否で制限される
「バケットポリシーでロールを許可しているのに no permissions boundary allows が出る」という場合は、この3つ目に当たっている可能性があります。なお、いずれも「暗黙的な拒否」に影響されないという話で、明示的な拒否は常に優先されます。
誤解4：同一アカウントなら、どちらか一方で許可すれば必ず通る
例3で触れたとおり、IAMロールの信頼ポリシーとKMSキーポリシーは、同一アカウントでもプリンシパルを明示的に許可する必要があります。公式ドキュメントでは、IAMとAWS KMS以外のサービスのリソースベースのポリシーでも同一アカウント内で明示的な Allow が必要な場合があり、個別のサービスのドキュメントを確認するよう書かれています。
まとめ：AccessDeniedに当たったときの確認手順
ここまでの内容を、AccessDeniedに当たったときの手順にまとめます。
- エラー文の文末を読む。
explicit denyかbecause no ... allowsか、ポリシーの種類とARNが出ているかを確認する - 早見表で、評価のどのステップで止まったかと、確認する場所を特定する
- 明示的な拒否なら
Deny文とその条件を、暗黙的な拒否ならAllowが足りない箇所を確認する。SCP・RCPなど自分で変えられないものは管理者に相談する - 直したあとも、別の種類のポリシーが拒否している可能性を念頭に置く（エラーには1種類しか出ないため）
- 文末にポリシーの種類が出ていない場合は、評価ロジックの順番に沿って各ポリシーを確認する
私はAWSのアソシエイト3資格（Solutions Architect・CloudOps Engineer（旧SysOps Administrator）・Developer）を取得していますが、評価ロジックは試験では「覚える知識」として出てきがちです。エラー文のどこを見れば評価のどのステップかがわかる、という対応で押さえておくと、実務のトラブルシュートでも使える知識になります。資格の勉強法については、以下の記事にまとめています。
IAMやAWSのセキュリティ設計を体系的に学び直したい場合は、公式ドキュメントとあわせて、IAMやAWSセキュリティを扱った技術書を1冊手元に置いておくのも一つの方法です。
楽天ブックスでも同じ技術書を探せるので、普段使っている方で比べてみてください。
