AWSを使っていると、突然「AccessDenied」エラーが発生して操作できなくなるケースは非常に多くあります。
特に IAM（Identity and Access Management）の設定は複雑で、少しの見落としが原因になることも少なくありません。
本記事では、AWSでAccessDeniedが出る代表的な原因と、IAM権限を確認する際の重要ポイントを実務視点でわかりやすく解説します。
AccessDeniedエラーとは？
AccessDeniedとは、実行しようとした操作に対して必要な権限が不足している場合に発生するエラーです。
AWSでは、ユーザー・ロール・サービスそれぞれに細かく権限が分かれており、
1つでも条件を満たしていないとAccessDeniedになります。
原因① IAMポリシーに必要なアクションが含まれていない
最も多い原因は、IAMポリシーに許可アクションが定義されていないケースです。
よくある例
-
ec2:DescribeInstancesがポリシーに含まれていない -
s3:GetObjectはあるがs3:ListBucketがない -
書き込みは許可されているが、読み取り権限がない
確認ポイント
-
実行しようとしている操作名（Action）を正確に確認
-
AWS公式ドキュメントで必要なアクションを確認
-
ワイルドカード（
*）を使いすぎていないかもチェック
原因② リソース指定（Resource）が間違っている
IAMポリシーでは、アクションだけでなくリソース指定も重要です。
よくあるミス
-
S3バケットARNとオブジェクトARNを混同している
-
リージョン違いのARNを指定している
-
特定リソースのみ許可しているつもりが対象外になっている
確認ポイント
-
ARNが正しい形式か
-
リージョン・アカウントIDが一致しているか
-
ワイルドカードの範囲が適切か
原因③ 明示的なDenyが設定されている
IAMでは、AllowよりもDenyが常に優先されます。
見落としがちなポイント
-
他のポリシーで
Effect: Denyが設定されている -
SCP（Service Control Policy）で制限されている
-
セッションポリシーで制限されている
確認ポイント
-
ユーザー／ロールにアタッチされている全ポリシーを確認
-
SCP（Organizations利用時）も必ずチェック
-
一部操作のみ拒否されていないか確認
原因④ ロールの引き受け（AssumeRole）が正しくない
IAMロールを使用している場合、**信頼ポリシー（Trust Policy）**の設定不備でもAccessDeniedが発生します。
よくある原因
-
AssumeRoleを許可するPrincipalが間違っている
-
サービスロールなのにユーザーから実行している
-
外部アカウントの指定ミス
確認ポイント
-
Trust Policyの
Principalを確認 -
実行主体（ユーザー／サービス）が正しいか
-
クロスアカウントの場合は特に注意
原因⑤ 実行しているIAMユーザー・ロールが想定と違う
CLIやSDKを使っている場合、想定とは別のIAMユーザーで実行しているケースも非常に多いです。
よくある例
-
ローカルに古いAWS認証情報が残っている
-
EC2のインスタンスロールが別のものに変更されている
-
CI/CD環境のロールが異なる
確認ポイント
-
aws sts get-caller-identityで実行主体を確認 -
利用中のプロファイルを明示的に指定
-
EC2 / ECS のロール設定を再確認
IAM権限確認のおすすめ手順（実務向け）
-
エラーメッセージに表示されるActionとResourceを確認
-
実行主体（User / Role）を特定
-
アタッチされているポリシーをすべて確認
-
明示的Denyがないかチェック
-
SCPやTrust Policyも含めて確認
まとめ
AWSのAccessDeniedエラーは、IAMの仕様を正しく理解していれば必ず原因を特定できます。
-
アクション不足
-
リソース指定ミス
-
明示的Deny
-
ロール・Trust Policyの設定不備
-
実行主体の取り違え
これらを順番に確認することで、無駄な試行錯誤を減らし、素早く復旧できます。
IAMは一度理解すると、AWS運用の安定性が大きく向上します。
AccessDeniedが出たら、焦らず1つずつ確認していきましょう。