IAMの not authorized / AccessDenied を5分で切り分けるデバッグ手順

前提: 権限が通る条件

AWSの権限評価は「明示的なAllowがあり、かつ明示的なDenyがない」とき通ります。

明示的Deny → 何より優先（Allowがあっても拒否）
Allowなし  → 暗黙のDeny（デフォルト全拒否）

「Allowを足したのに通らない」＝どこかのDeny か、SCP/Permissions Boundary の上限。

手順

Step 1. エラーメッセージを最後まで読む

User: arn:aws:iam::xxx:user/alice is not authorized to perform:
s3:GetObject on resource: ... with an explicit deny in a service control policy

誰が・何を・どのリソースに・どこのDenyで、まで書いてあることが多い。読み飛ばさない。

Step 2. 実行者を確認

aws sts get-caller-identity

Step 3. アイデンティティ側のポリシー確認

aws iam list-attached-user-policies --user-name alice
aws iam list-user-policies --user-name alice

Action名・リソースARNが一致しているか（ロールなら list-attached-role-policies）。

Step 4. Deny / SCP / Permissions Boundary

• ポリシー内の Effect: Deny
• Organizations の SCP（マルチアカウントの盲点。ルートユーザーにも効く）
• Permissions Boundary の上限

Step 5. リソース側ポリシー

S3バケットポリシー・KMSキーポリシーなど。クロスアカウントは両側必要。

Step 6. ロールなら信頼ポリシー

「ポリシーは正しいのにAssumeRoleできない」の犯人はほぼ信頼ポリシー（Trust Policy）です。

裏取りの武器

# 実行できるかをシミュレート
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alice \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/file.txt

EvalDecision が explicitDeny / implicitDeny のどちらかで原因の種類が分かります。

---

評価ロジックの図解・よくある原因トップ5・CloudTrailでの追跡まで含めた完全版はZennにあります:
https://zenn.dev/naoto_tech_AI/articles/aws-11-iam-permission-error-debugging