Identity-based Policy, Service Control Policy, Resource-based Policy, Permissions Boundary 😵‍💫

Identity-based Policy, Service Control Policy, Resource-based Policy, Permissions Boundary 😵‍💫

All of these are terms related to permissions you deal with on AWS, but what's the difference between them?

First, they're split into two types:

Granting Permission: Identity-based Policy, Resource-based Policy
Guardrail Permissions: Service Control Policy, Permissions Boundary

💰 Think of it like an ATM machine: the Guardrail sets the overall allowed permissions for the ATM (the upper ceiling), and the Granting is what actually gives you the right to execute the action.

Identity-based Policy

Gets attached to the user or role or group itself, and defines what they're allowed to do on which service.

Real example: a user with a policy that allows them s3:GetObject and s3:PutObject on any bucket.

💰 Like when you open a bank account, the bank activates certain services on your card: (you're allowed to withdraw, transfer, and pay online).

Service Control Policy (SCP)

Works at the AWS Organizations level (Org / OU / Account) and defines the maximum possible permissions — even if the identity policy allows it, if the SCP blocks the action it won't execute.

Real example: a company has an Organization with Dev and Prod accounts, and has an SCP on the Prod OU that blocks anyone (even admins) from doing s3:DeleteBucket or leaving the Organization, to protect the data from being deleted by mistake.

💰 Like the bank preventing any branch from allowing withdrawal in any currency other than Egyptian pounds, no matter what permissions the employee doing the withdrawal has.

Resource-based Policy

Gets placed on the resource itself (not the user), and must have a "Principal" specifying who's allowed to interact with it. Supported in S3, SNS, SQS, Lambda, KMS, and others.

Real example: a bucket called global-bucket with a policy that allows a specific group of accounts to read the data

💰 Like a specific ATM machine that's only linked to VIP accounts, and anyone else with a regular card won't be able to withdraw from it even if they have withdrawal permission in general.

Permissions Boundary

Defines the maximum possible permissions for a specific IAM user or role (i.e. individually, not across multiple accounts like SCP).

Real example: a DevOps team gives every developer permission to create new IAM roles for their projects, but sets a Permissions Boundary on them that prevents them from granting themselves or any role they create admin-level permissions like iam:* or organizations:*, so no one can do privilege escalation on themselves.

💰 Like a father giving his son a card linked to his own, but setting limits on the spending that can be withdrawn from the card, and it can't be exceeded.

Note: for any action to go through, it must not be denied in any of the intersecting policies, because a Deny from any single one of them is enough to stop the action ❌.

🤍I would appreciate If we connect together on LinkedIn : Visit