Policy Types and Evaluation Logic

What it is

Every AWS request is checked against all applicable policies. The result is deny unless something allows the request and nothing denies it.

Knowing the policy types and the order of evaluation is the foundation for almost every authorization question on the exam.

How it works

The policy types

SCPs, RCPs, boundaries and session policies never grant anything on their own. They only filter what other policies grant.

The evaluation order

For a request in one account, AWS evaluates in this logic.

1. Explicit deny. If any applicable policy denies the action, the answer is deny. This always wins.
2. SCPs. If the account is in an organization, the SCPs must allow the action.
3. RCPs. For supported resources, the resource control policies must allow it too.
4. Resource based policy. In the same account, a resource policy that names an IAM user can allow the request by itself.
5. Identity based policy. Otherwise an identity policy must allow the action.
6. Permissions boundary. If the principal has a boundary, it must allow the action.
7. Session policy. If the session has one, it must allow the action.
8. Default. Anything else is an implicit deny.

In short, an identity policy grant must pass through the SCP, RCP, boundary and session filters, and a request that matches none of the allows is denied.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApprovedRegions",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*"],
    "Resource": "*",
    "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "eu-west-1"] } }
  }]
}

This SCP denies actions in any other Region, while exempting global services that work from us-east-1. Because it is a deny, it cannot be overridden by an allow elsewhere.

Cross account access

For a principal in account A to use a resource in account B, both sides must allow it. The identity policy (and any boundary or SCP) in account A must allow the call, and the resource policy in account B must allow account A or its principal.

A role is an alternative. The principal assumes a role in account B, and then acts as that role under account B's rules, so only the role's policies in B matter after the assume step.

SCP and RCP details

• SCPs affect principals in member accounts, including the root user of those accounts. They do not affect the management account.
• SCPs do not affect service linked roles.
• An SCP allow list approach removes FullAWSAccess and lists permitted services, and a deny list approach keeps FullAWSAccess and adds denies. Both work, and the deny list is easier to run.
• RCPs apply to supported resources in member accounts, even when the caller is an outside principal. They help enforce a data perimeter, such as requiring TLS or blocking access from outside the organization.
• Neither SCPs nor RCPs apply to the management account.

Permission boundaries and session policies

A permissions boundary limits the maximum permissions of a user or role, and it is the basis of safe delegation: a developer may create roles, but only roles that carry the boundary. Effective permissions are the intersection of the identity policy and the boundary.

A session policy narrows one session. A role session's effective permissions are the intersection of the role's identity policy, its boundary if any, and the session policy.

Notable exceptions

• KMS keys. A key policy is required. If the key policy does not allow the account to use IAM policies, identity policies alone cannot grant access.
• Anonymous requests. Only resource policies can allow unauthenticated principals, as in a public bucket.