AWS Error: AccessDeniedException — IAM Permission Denied

An error occurred (AccessDeniedException) when calling the GetObject operation:
User: arn:aws:iam::123456789012:user/deploy-bot is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::my-prod-bucket/config.json"
because no identity-based policy allows the s3:GetObject action

AccessDeniedException is AWS’s universal “your IAM principal cannot do this” response. It’s HTTP 403 with a structured message that almost always names the principal, the action, and the resource. The fix is rarely to grant *:* — it’s to read the message, find the gap, and add a tightly-scoped Allow for the exact action the caller needs.

The single most useful debugging habit is to log aws sts get-caller-identity at the start of every failing code path. It tells you the actual principal ARN AWS is evaluating, which is often different from what you expected — especially when running on EC2 (instance profile), Lambda (execution role), or after AssumeRole chains.

Why this happens

• No identity-based policy grants the action. The IAM user or role attached to the request has no policy that includes an `Allow` for the specific action (e.g., `s3:GetObject`) on the specific resource. AWS denies by default — silence is denial.
• Explicit Deny in an SCP, permission boundary, or session policy. Even if the identity policy says Allow, an Organizations SCP, a permission boundary, or an `AssumeRole` session policy can override with an explicit Deny. The error message will say `with an explicit deny in a service control policy` or similar — read it carefully.
• Resource policy blocks the principal. S3 bucket policies, KMS key policies, SNS topic policies, and Lambda resource policies can deny access independent of the caller's IAM. Cross-account calls require BOTH the caller's IAM AND the resource policy to allow the action.
• Wrong region or partition in the resource ARN. Policies that use `arn:aws:s3:::bucket/*` won't match `arn:aws-cn:s3:::bucket/*` (China) or `arn:aws-us-gov:...` (GovCloud). For regional services, an ARN with the wrong region in a `Resource` block silently fails to match.
• Condition keys not satisfied. Conditions like `aws:SourceVpc`, `aws:PrincipalTag`, `s3:RequestObjectTag`, or MFA requirements (`aws:MultiFactorAuthPresent`) can cause an Allow to evaluate to false. The denied request matched the action and resource but failed a condition.

How to fix it

Fixes are ordered by likelihood. Start with the first one that matches your context.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowConfigRead",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-prod-bucket/config.json"
    }
  ]
}

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/deploy-bot \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-prod-bucket/config.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/deploy-bot" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-prod-bucket/*"
    }
  ]
}

Detection and monitoring in production

Alarm on `AccessDenied` events in CloudTrail at higher than baseline rates. A spike usually means a recent IAM change, a new SCP, or a rotated role that lost a policy attachment. Tag your CloudWatch alarm with the principal ARN so you know which service is degraded.