Identity Based vs Resource Based Policy in AWS: Key Differences and Usage

In AWS, a identity-based policy is attached to users, groups, or roles to define what actions they can perform, while a resource-based policy is attached directly to resources like S3 buckets or Lambda functions to specify who can access them. Identity-based policies control permissions from the user side, and resource-based policies control permissions from the resource side.

Quick Comparison

Here is a quick side-by-side comparison of identity-based and resource-based policies in AWS.

Factor	Identity-Based Policy	Resource-Based Policy
Attachment	Attached to IAM users, groups, or roles	Attached directly to AWS resources
Permission Control	Defines what actions identities can perform	Defines who can access the resource and what actions they can perform
Cross-Account Access	Requires roles or trust policies for cross-account access	Can directly grant cross-account permissions
Examples	IAM user policy, IAM role policy	S3 bucket policy, Lambda function policy
Evaluation	Checked when user makes a request	Checked when resource receives a request
Use Case	Control user permissions centrally	Control resource access and sharing

Key Differences

Identity-based policies are attached to IAM identities like users, groups, or roles. They specify what actions those identities are allowed or denied to perform on AWS resources. These policies are evaluated when the identity makes a request to AWS services.

Resource-based policies are attached directly to AWS resources such as S3 buckets, Lambda functions, or SQS queues. They specify who (which identities) can access the resource and what actions they can perform. These policies are evaluated when a request is made to the resource, allowing the resource owner to control access.

One major difference is cross-account access: resource-based policies can directly grant permissions to identities in other AWS accounts, while identity-based policies require roles and trust relationships to enable cross-account access. This makes resource-based policies useful for sharing resources securely across accounts.

Code Comparison

Here is an example of an identity-based policy attached to an IAM role that allows reading objects from a specific S3 bucket.

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-bucket/*"]
    }
  ]
}

Output

Allows the IAM role to read objects from the example-bucket.

Resource-Based Policy Equivalent

Here is an equivalent resource-based policy attached directly to the S3 bucket to allow a specific IAM user to read objects.

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/ExampleUser"},
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-bucket/*"]
    }
  ]
}

Output

Allows the specified IAM user to read objects from the example-bucket.

When to Use Which

Choose identity-based policies when you want to centrally manage permissions for users, groups, or roles within your AWS account. They are best for controlling what actions your identities can perform across many resources.

Choose resource-based policies when you want to control access directly on the resource, especially for sharing resources across AWS accounts. They simplify cross-account access by attaching permissions to the resource itself.

In practice, use identity-based policies for most permission management and resource-based policies for resource sharing and fine-grained access control.

Key Takeaways

Identity-based policies attach permissions to users, groups, or roles to control their actions.

Resource-based policies attach permissions directly to resources to control who can access them.

Resource-based policies simplify cross-account access by granting permissions on the resource.

Use identity-based policies for central user permission management.

Use resource-based policies for sharing resources and fine-grained access control.