Timedora

3 Policies and Permissions

Learn how AWS IAM policies match requests, how policy layers determine access, and how to troubleshoot AccessDenied errors.

Match a request to a policy

An defines what an authenticated principal, such as a user or an assumed role, may do to a resource. To evaluate a request, match the principal making it, the requested action, the target resource, and any relevant conditions.

Read policy statements

Most IAM permissions policies are JSON documents. A statement commonly includes an Effect of Allow or Deny, one or more Action values, and the Resource or resources to which it applies. A Condition is optional and can specify context requirements, such as a source IP address or a required tag.

A Principal identifies the user, role, account, or other principal addressed by a resource-based policy. omit this field because the attached identity is implied.

For example, this identity-based policy allows reading objects beneath a particular S3 bucket prefix:

The action is s3:GetObject, and the resource pattern matches objects beneath quarterly/ in example-reports. This permission does not also allow listing the bucket. s3:ListBucket is a separate action and normally uses the bucket ARN, arn:aws:s3:::example-reports, rather than an object ARN. A policy must match both the requested action and its applicable resource.

Understand allow and deny

For ordinary requests, AWS starts with an : if there is no applicable Allow, access is denied. An applicable overrides any Allow. Therefore, finding an Allow statement is not enough; check for applicable denies and other controls as well.

Account for policy layers

Different policy layers can contribute to or limit an access decision:

  • attach to users, groups, or roles and grant permissions to their principals.

  • attach to resources, such as an S3 bucket, and specify who may access them.

  • Permissions boundaries and session policies limit permissions but do not grant them by themselves.

  • Service control policies (SCPs) set permission limits for principals in organization accounts but do not grant permissions by themselves.

For a same-account request, identity-based and can both contribute an Allow, subject to applicable limits and explicit denies. The details vary with the principal named in a resource policy, so do not assume every allow or boundary is evaluated identically in every case.

For cross-account access, the caller's account must allow the request, and the resource-owning account must also grant access, typically through a resource-based policy or another supported sharing mechanism.

For example, a role policy might allow s3:GetObject on a bucket while the role's does not allow that action. The role cannot use the identity-based permission because the boundary caps what the identity policy can grant. An applicable policy that explicitly denies s3:GetObject also defeats an allow.

Troubleshoot access denied

When an AWS request returns AccessDenied, inspect the request and all applicable permissions and limits systematically:

  1. Confirm the principal. Check whether the request uses the intended user or assumed-role session and the expected account. A role session's permissions may differ from those of another identity.

  2. Check the exact action and resource. Verify the service action name and ARN format. For S3, listing a bucket and reading an object require different actions and resource ARNs.

  3. Find an applicable Allow. Check policies attached directly to the identity and, for a user, policies inherited through groups. Confirm that Action, Resource, and any Condition match the actual request.

  4. Look for an explicit Deny. Review identity and resource policies and any applicable organization, boundary, session, or endpoint policies.

  5. Check conditions and limits. Confirm that required context values, such as tags, source IP, or other condition keys, are present and match. Check permissions boundaries, session policies, SCPs, and VPC endpoint policies where relevant.

  6. For cross-account access, inspect both sides. Confirm that the caller is permitted to make the request and that the resource-owning account grants the required access.

  7. Use diagnostic tools. The can test selected actions, resources, policies, and context values without sending a request to the service. It is a troubleshooting aid, not proof that every real request will succeed: simulation coverage has limitations, and service-specific authorization behavior may matter. Review the service's error details and applicable policies as well.