ハンズオンや業務で AccessDenied や is not authorized to perform が出ると、とりあえず管理者権限を付けたくなります。けれど、文面をよく読むと、止めたのが「許可が無いこと」なのか「Deny があること」なのか、どの種類のポリシーなのかまで書いてあることがあります。この記事では、そのメッセージを読んで見る場所を順に絞る運用を説明します。ポリシー評価の詳細は IAM ポリシーの仕組み に任せます。
この記事の結論
- AccessDenied は「許可が無い（暗黙の拒否）」か「Deny がある（明示の拒否）」のどちらかです。まずここを分けます。
- メッセージの
because no ○○ policy allowsやwith an explicit deny in a ○○ policyが、止めたポリシーの種類を教えてくれます。 - 種類が分かれば見る場所が決まります。ID ベース・リソースベース・権限境界・SCP・セッションポリシー・信頼ポリシーのどれかです。
- 種類が出ないときは、ID ベース → リソースベースと条件 → 境界・SCP・セッションの順に確認します。複数の種類が拒否していても、メッセージに出るのは1種類だけです。
- 管理者権限で黙らせず、足りない許可を1つ足すか、Deny を外すかを決めます。
AccessDenied とは何か｜暗黙の拒否と明示の拒否の違い
AccessDenied は、リクエストが認可されなかったことを示すエラーです。IAM の評価では、拒否の理由は2つに分かれます。
- 暗黙の拒否: どのポリシーにも、そのリクエストを許す Allow が無い。Deny も書かれていない。初期状態は拒否なので、許可が無ければ通りません。
- 明示の拒否: どこかのポリシーに、そのリクエストに当てはまる Deny がある。Deny は Allow より強いので、ほかのどこかで許可していても通りません。
この2つで直し方が逆になります。暗黙の拒否なら Allow を足し、明示の拒否なら Deny を探して外すか条件を直します。暗黙の拒否のつもりで Allow を足し続けても、Deny があれば通りません。
TWO KINDS OF DENY直し方が逆になる
拒否は許可が無いのかDeny があるのかで、直し方が逆になる
暗黙の拒否
because no … policy allows
- Allow が無いだけ
- 足りない許可を足す
- 範囲は最小限に絞る
明示の拒否
with an explicit deny in a … policy
- どこかに Deny がある
- Deny を外す・条件を直す
- Allow を足しても通らない
| 暗黙の拒否 | 明示の拒否 | |
|---|---|---|
| 状態 | Allow が無い | Deny がある |
| メッセージの目印 | because no … policy allows |
with an explicit deny in a … policy |
| 直し方 | 足りない許可を足す | Deny を外す、または条件を見直す |
| 管理者権限を足すと | 通ることがあるが権限が広がりすぎる | 通らない |
CHECK 1ここまでの確認
許可も Deny もどのポリシーにも書かれていないとき、リクエストはどう扱われる?
答えと解説
答え: 1. 暗黙の拒否になる。Allow が無いだけなので、必要な許可を足せば通る
何も書かれていない状態は暗黙の拒否で、足りないのは Allow だけです。「暗黙と明示」の章を読み直してください。
エラーメッセージのどこを読むか｜is not authorized to perform と because 以降
メッセージは次の順に読みます。
- 誰が:
User: arn:aws:…や、ロールの場合は引き受けたセッションの ARN。想定した主体で呼ばれているかをまず確かめます。 - 何をしようとして:
is not authorized to perform: s3:GetObjectのようなアクション名。 - 何に対して:
on resource: arn:aws:…のリソース。 - because 以降: 暗黙か明示か、どの種類のポリシーか。
READ THE MESSAGEメッセージを読む順
メッセージは誰が・何を・何に・becauseの順に読む
-
誰が
User / 引き受けたセッションの ARN
-
何を
is not authorized to perform
-
何に
on resource の ARN
-
because
暗黙か明示か、ポリシーの種類
特に大事なのは最後の because 以降です。because no identity-based policy allows the action なら、ID ベースポリシーに Allow が無いという意味で、暗黙の拒否です。with an explicit deny in a service control policy なら、SCP に Deny があるという意味で、明示の拒否です。
なお、サービスやアクションによってはメッセージが簡素で、種類が書かれていないことがあります。その場合は後の章の確認順に進みます。書式の最新の説明は公式の AccessDenied トラブルシューティングで確かめてください。
CHECK 2ここまでの確認
メッセージに「with an explicit deny in a service control policy」とあるとき、分かることは?
答えと解説
答え: 2. Organizations の SCP のどこかに Deny があり、それが止めている
because 以降の「explicit deny」と「ポリシーの種類」の組で、Deny の場所が決まります。「メッセージを読む」の章を読み直してください。
止めたポリシーの種類ごとに見る場所｜ID ベース・リソースベース・境界・SCP・セッション・信頼ポリシー
種類が分かれば、見る場所が決まります。
| メッセージが示す種類 | 見る場所 | 直し方の方向 |
|---|---|---|
| identity-based policy | 呼んだユーザー・ロールに付いているポリシー | 暗黙なら Allow を足す。明示なら Deny を外す |
| resource-based policy | 対象リソース側のポリシー（バケットポリシーなど） | 暗黙なら呼んだ主体を許可する。明示なら Deny の条件を見る |
| permissions boundary | 主体に設定された権限境界 | 境界は上限。ID ベースが許していても境界の外なら拒否される |
| service control policy | Organizations の SCP | 上限を決める側で許可する。アカウントの管理者にも効く |
| session policy | ロールを引き受けるときに渡されたセッションポリシー | 渡している側の設定を見直す |
権限境界と SCP はどちらも「上限」です。許可を与えるのではなく、与えられる範囲を狭めます。ID ベースポリシーに Allow があるのに通らないときは、この上限を疑います。SCP の設計そのものは別の記事で扱います。
もう1つ、ロールを引き受ける操作（sts:AssumeRole）で拒否されたときは、ロールの信頼ポリシーが見る場所です。信頼ポリシーは「誰が引き受けてよいか」を決める入口で、権限ポリシーとは別物です。仕組みは IAM ロールの仕組み にあります。
やってはいけない3つ
- メッセージを読まずに、管理者権限を足して黙らせる
- 暗黙の拒否か明示の拒否かを分けずに、Allow だけを足し続ける
- 1つ直して通ったように見えたのに、再実行で確かめない
メッセージに種類が出ないときの調べる順番
種類が文面から読めないときは、次の順に確認します。
- ID ベースポリシー: 呼んだ主体に、そのアクションとリソースを許す Allow があるか。アクション名の綴りやリソース ARN の範囲も見る。
- リソースベースポリシーと条件: 対象リソース側に Deny が無いか。ポリシーの
Condition（送信元、タグなど）に当てはまっているか。 - 境界・SCP・セッションポリシー: 上限として効いているものが無いか。
CHECK ORDER種類が出ないとき
種類が出ないときは下から上限へ順に絞る
-
ID ベースポリシー
呼んだ主体に Allow があるか
-
リソースベースポリシーと条件
対象側の Deny、Condition
-
境界・SCP・セッション
上限として効いていないか
ここで知っておきたいのは、複数の種類のポリシーが拒否していても、メッセージに出るのは1種類だけということです。1つ直したら別の種類の拒否が出ることがあります。直したら必ず再実行して、通るかを確かめます。
たとえば、本番に移したら Bedrock の呼び出しで AccessDenied になった場合、まず疑うのは実行ロールです。開発では通っていたなら、本番側のロールのポリシーに、使うモデルに対する許可があるかを見ます。ロールに許可を足すのが筋で、ほかの場所をいじるのは、ロールに許可があると確かめてからです。
CHECK 3ここまでの確認
複数の種類のポリシーが同時にリクエストを拒否しているとき、メッセージに出るのは?
答えと解説
答え: 2. そのうち1種類だけ。直すと次の種類が出ることがある
メッセージに出る種類は1つだけです。1つ直して終わりにせず、再実行して確かめます。「調べる順番」の章を読み直してください。
一時的な認証情報（ロールを引き受けたとき）で追加で疑うこと
EC2 や Lambda のロール、AssumeRole で引き受けたロールでは、呼び出しは一時的な認証情報で行われます。このときに追加で疑う点があります。
- 想定したロールで呼ばれているか: 手元の認証情報が別のロールやユーザーのままだと、見ているポリシーが違います。メッセージの主体の ARN を確かめます。
- セッションポリシー: 引き受けるときに渡されたセッションポリシーは、ロールの権限をさらに絞ります。ロールに Allow があっても、セッション側で絞られていれば拒否されます。
- 権限境界: ロールに境界が付いていれば、その外のことはできません。
権限境界は、権限を広げられることを防ぐ目的でも使われます。たとえば、開発者に実行ロールを作らせつつ、作ったロールが管理者並みにならないようにするには、境界で上限を定めます。このとき、実際に使える権限は「ポリシーと境界の重なり」です。
直すときの判断｜許可を足すか、Deny を外すか、管理者権限で黙らせない
原因が分かったら、直し方を決めます。
- 暗黙の拒否: 足りない許可を、そのアクションとそのリソースに限って足します。範囲は 権限の決め方 の考え方に沿って絞ります。
- 明示の拒否: Deny が意図したものか確かめます。意図したものなら、Deny の側ではなく依頼の方を見直します。意図していない Deny なら、外すか条件を直します。SCP や境界のように別の管理者が持っている上限は、その持ち主に依頼します。
- 管理者権限は足さない: 一度広げた権限は、あとで戻しにくくなります。
迷ったら、「いま足したい許可は、最小限か」を自分に問います。
直したあとに記録する
直したら、何を足した（外した）かを記録に残します。誰がいつどの操作をしたかを後から追うには AWS CloudTrail のイベント履歴を使います。拒否されたリクエストの呼び出し主体と操作を確かめる手がかりにもなります。ログの読み方の基本は ログの仕組み にあります。CloudTrail のイベントの項目名など詳細は、公式のドキュメントで確かめてください。
Cloudory 執筆者（AWS 認定 全冠）
AccessDenied は、IAM が「どこで止めたか」を教えてくれているエラーです。管理者権限を足す前に、because 以降の一文だけ読んでください。それだけで見る場所が1つか2つに絞れます。
まとめ
- AccessDenied は暗黙の拒否（Allow が無い）と明示の拒否（Deny がある）に分けて考えます。
- メッセージの because 以降が、種類の手がかりです。
- 種類が出ないときは、ID ベース → リソースベースと条件 → 境界・SCP・セッションの順に見ます。
- 複数の種類が拒否していても、メッセージには1種類しか出ません。直したら再実行します。
- 管理者権限で黙らせず、最小限の許可を足すか、Deny を直します。
参照ソース
- AWS 公式: AccessDenied エラーのトラブルシューティング（IAM ユーザーガイド） — 暗黙の拒否と明示の拒否、メッセージの書式、ポリシーの種類ごとの確認先、メッセージに出る種類は1つだけという点の根拠（2026-11 時点）
- AWS 公式: ポリシーの評価論理（IAM ユーザーガイド） — 暗黙の拒否が初期状態であり、明示の Deny が Allow より優先されることの根拠
