AccessDenied
AWS AccessDenied means authorization failed for the requested action and resource. In S3 this is typically HTTP 403, while some AWS Query APIs return an AccessDenied variant with HTTP 400.
Last reviewed: March 30, 2026|Editorial standard: source-backed technical guidance
What Does Access Denied Mean?
When AccessDenied is returned, AWS blocks the request before any state change occurs, so deployment, upload, or admin workflows fail immediately until the policy path is corrected.
Common Causes
- -No identity-based allow statement grants the requested action and resource.
- -An explicit deny exists in an IAM policy, resource policy, SCP, RCP, permission boundary, or session policy.
- -Role trust policy does not allow the caller to assume the role used for the request.
- -Condition keys (for example source IP, VPC, tags, or org context) do not match runtime request attributes.
How to Fix Access Denied
- 1Capture principal ARN, action, resource ARN, and denial context from the exact error message.
- 2Identify whether denial is explicit or implicit, then inspect the matching policy type first.
- 3Add or adjust least-privilege allow statements at the exact action and resource scope.
- 4If role assumption is involved, verify trust policy, session policy, and session tags together.
Step-by-Step Diagnosis for Access Denied
- 1Review CloudTrail for the failing request ID and confirm the same action/resource pair.
- 2Run IAM Policy Simulator for the exact principal, action, and resource ARN.
- 3Check deny precedence across identity policy, resource policy, SCP/RCP, boundary, and session policy.
- 4For cross-account access, verify both caller-side identity permissions and target-side resource permissions.
Identity Context Validation
- -Verify effective caller identity with
sts:GetCallerIdentityand session issuer ARN (example: runtime uses an unexpected assumed-role ARN from another CI stage). - -Inspect session tags, external ID, and session duration assumptions in auth conditions (example:
aws:PrincipalTag/Environment=prodcondition is required but missing).
Policy Evaluation Trace
- -Audit deny precedence across SCP, permission boundary, session policy, identity policy, and resource policy (example: org SCP denies
s3:PutObjectonarn:aws:s3:::prod-logs/*). - -Confirm trust policy and resource policy both allow the cross-account path (example: role trust allows account A, but bucket policy omits that role ARN).
How to Verify the Fix
- -Replay the exact request with the same principal and confirm authorization succeeds.
- -Confirm CloudTrail no longer logs AccessDenied for the same action/resource path.
- -Run a least-privilege smoke test to verify only intended actions are now allowed.
How to Prevent Recurrence
- -Add policy-as-code checks for missing allows and unintended explicit denies in CI.
- -Standardize role trust templates and condition-key conventions across accounts.
- -Continuously monitor AccessDenied spikes by action and principal in CloudTrail analytics.
Pro Tip
- -persist denied action/resource plus request ID in structured logs so recurring denials map to a specific policy statement quickly.
Decision Support
Compare Guide
AWS AccessDenied vs GCP PERMISSION_DENIED (403)
Compare AWS AccessDenied and GCP PERMISSION_DENIED to isolate authorization deny layers, separate auth failures, and apply precise IAM fixes fast.
Compare Guide
401 Unauthorized vs 403 Forbidden: Auth vs Access Denied
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.