In AWS, policies are objects that define permissions when associated with an identity or a resource. The primary difference between identity-based policies and resource-based policies lies in what they are attached to and what they control.

Identity-Based Policies

• Attachment: These are attached directly to an IAM identity, such as a user, a group, or a role.
• Control Focus: They specify what that identity can do (its permissions) and which resources it is allowed to access.
• Default State: In a new account, identities start with no permissions; identity-based policies must be explicitly granted to allow actions.

Resource-Based Policies

• Attachment: These are attached directly to a resource, such as an Amazon S3 bucket, Amazon SQS queue, VPC endpoint, or AWS KMS encryption key.
• Control Focus: They specify who has access to that specific resource and what actions they can perform on it.
• Key Structural Difference: Resource-based policies include a Principal element, which defines the specific accounts, users, or roles that are affected by the policy. Identity-based policies do not have a Principal element because the principal is implicitly the identity they are attached to.

Comparison Table

Feature	Identity-Based Policy	Resource-Based Policy
Attached To	IAM User, Group, or Role	AWS Resource (e.g., S3 Bucket, KMS Key)
Primary Goal	Controls what an identity can do	Controls who can access the resource
Principal Element	Not required (implicit)	Required to define who is affected
Common Examples	Allowing "Alice" to list all S3 buckets	S3 Bucket Policy, KMS Key Policy, SQS Queue Policy

Evaluation Logic

When AWS evaluates these policies, an explicit deny in any attached policy (identity or resource) will always override an allow rule. These policies are often used together to provide granular security; for example, a centralized data lake might use bucket policies to grant access to various accounts while individual IAM roles control which specific users can access that data.