Resource-Based vs Identity-Based Policies: What It Is and When to Use It

Definition

In AWS Identity and Access Management (IAM), identity-based policies and resource-based policies are the two primary ways to manage permissions. Identity-based policies are attached to an IAM identity (a user, group, or role) and define what actions that identity can perform on which resources. In contrast, resource-based policies are attached directly to an AWS resource (like an Amazon S3 bucket or an AWS Lambda function) and specify which principals (identities) are allowed to perform what actions on that specific resource.

How It Works

Understanding how these policies interact is crucial for effective access control. AWS evaluates all applicable policies to determine if a request is allowed or denied.

Identity-Based Policies: These policies are the most common type. When you create an IAM user or role, you attach policies to it that grant permissions. For example, you might attach a policy to a developer's IAM user that allows them to start and stop Amazon EC2 instances.

• Managed Policies: Standalone policies created and managed by AWS (AWS Managed) or by you (Customer Managed) that can be attached to multiple identities.
• Inline Policies: Policies embedded directly into a single user, group, or role. They are best used sparingly as they are harder to manage at scale.

Resource-Based Policies: These policies are attached to the resource itself. A key structural difference is the inclusion of a Principal element, which specifies the IAM identities (users, roles, accounts, or services) that the policy applies to. For example, an S3 bucket policy can grant read access to a user from a completely different AWS account.

Policy Evaluation Logic: When a principal makes a request in AWS, the evaluation logic is as follows:

1. Explicit Deny: If any applicable policy (identity-based, resource-based, permissions boundary, SCP, etc.) contains an explicit "Effect": "Deny" for the requested action, the request is immediately denied. An explicit deny always overrides an allow.
2. Service Control Policies (SCPs): In an AWS Organization, an SCP can set permission guardrails for member accounts. If the SCP denies the action, the request is denied.
3. Resource-Based Policies: If the resource being accessed has a resource-based policy, AWS evaluates it. If the policy allows the request, the request is permitted (unless denied by another policy type).
4. Identity-Based Policies: AWS then evaluates the identity-based policies attached to the requesting principal. An allow here can grant access.
5. Permissions Boundaries & Session Policies: These policies can further restrict permissions but cannot grant them. They set the maximum allowable permissions.
6. Implicit Deny: If no policy explicitly allows the action, the request is denied by default.

For an action within a single account, an Allow in either the identity-based policy or the resource-based policy is sufficient to grant access (assuming no explicit deny). For cross-account access (without using IAM Roles), both the calling principal's identity-based policy and the target resource's resource-based policy must grant permission.

Key Features and Limits

• Supported Services: Not all AWS services support resource-based policies. Major services that do include Amazon S3, Amazon SQS, Amazon SNS, AWS Lambda, AWS KMS, and Amazon ECR.
• Policy Structure: Both policy types use a JSON structure with elements like Version, Statement, Effect, Action, and Resource. Resource-based policies uniquely include the Principal element.
• Cross-Account Access: Resource-based policies are a primary method for granting direct cross-account access without needing to create and assume an IAM Role.
• Policy Limits (as of 2026):
  • Managed Policies per Role: You can attach up to 25 managed policies to a role.
  • Managed Policies per User: You can attach up to 20 managed policies to a user.
  • Customer Managed Policies per Account: The quota has been increased to 10,000.
  • Policy Size: The maximum size for a managed policy is 6,144 characters. Inline policy limits are 2,048 for users, 10,240 for roles, and 5,120 for groups.

Common Use Cases

• Granting Permissions within an Account (Identity-Based): The most common scenario. Use identity-based policies to grant your IAM users and roles access to the resources they need to perform their jobs within your AWS account.
• Granting Cross-Account Access (Resource-Based): The canonical use case. For example, allowing an EC2 instance in Account A to write log files to an S3 bucket in Account B. The S3 bucket policy in Account B would specify Account A's role as a trusted principal.
• Allowing AWS Services to Access Resources (Resource-Based): When you configure an AWS service to act on your resources, a resource-based policy grants it permission. For example, an S3 bucket policy can allow Amazon SNS to publish event notifications.
• Defining Public Access (Resource-Based): An S3 bucket policy can be configured to make objects publicly readable, which is common for hosting static websites.
• Centralized Access Control for a Resource (Resource-Based): When you want the resource owner to have explicit control over who can access it, regardless of the permissions users have in other accounts.

Pricing Model

AWS Identity and Access Management (IAM), including the creation and use of identity-based and resource-based policies, is a feature of your AWS account offered at no additional charge. You are, however, charged for the use of other AWS services by the principals you manage with IAM.

IAM Access Analyzer, a tool that helps identify unintended resource access, has a free tier for checking external access and paid tiers for analyzing internal and unused access.

Pros and Cons

Identity-Based Policies

• Pros:
  • Centralizes permission management for a specific identity. It's easy to see all the permissions a user or role has in one place.
  • Universally supported across all AWS services.
• Cons:
  • Can become difficult to manage at scale without a clear strategy for policy organization.
  • Does not, by itself, enable cross-account access to resources (requires a corresponding resource policy or role assumption).

Resource-Based Policies

• Pros:
  • The simplest way to grant direct cross-account access.
  • Clearly defines and controls who can access a specific resource, making resource-level auditing straightforward.
  • Enables AWS services to perform actions on your resources on your behalf.
• Cons:
  • Not all AWS services support them.
  • Permissions are decentralized across resources, which can make it difficult to get a complete view of a single principal's effective permissions.

Comparison with Alternatives

While identity-based and resource-based policies are the primary tools for granting permissions, other IAM features act as guardrails:

• IAM Permissions Boundaries: These are advanced features used to set the maximum permissions that an identity-based policy can grant to an IAM role or user. A permissions boundary does not grant permissions on its own; it only sets a limit. This is useful for safely delegating permissions management to developers.
• Service Control Policies (SCPs): A feature of AWS Organizations, SCPs offer central control over the maximum permissions for all accounts in your organization. They act as a guardrail to ensure accounts stay within your organization's access control guidelines but do not grant permissions.

Exam Relevance

Understanding the distinction between identity-based and resource-based policies is fundamental for nearly all AWS certifications.

• AWS Certified Solutions Architect – Associate (SAA-C03): Expect scenario-based questions about choosing the correct policy type, especially for granting cross-account access to Amazon S3 buckets. Policy evaluation logic (explicit deny, implicit deny) is also a key topic.
• AWS Certified Security – Specialty (SCS-C02): This exam requires a deep understanding of the entire policy evaluation logic, including the interaction between identity, resource, SCPs, and permissions boundaries in complex multi-account scenarios.
• AWS Certified Developer – Associate (DVA-C02) & SysOps Administrator – Associate (SOA-C02): Both exams test practical knowledge of applying policies for applications and infrastructure, such as creating IAM roles for EC2 instances and Lambda functions that need to access other AWS resources.

Frequently Asked Questions

Q: When do I need both an identity-based and a resource-based policy?

A: For cross-account access, you generally need both. The IAM principal in the source account needs an identity-based policy allowing the action, and the resource in the destination account needs a resource-based policy that specifies the source principal and allows the same action.

Q: Which policy wins if an identity-based policy says "Allow" but a resource-based policy says "Deny"?

A: The "Deny" wins. An explicit Deny in any policy, whether it's identity-based, resource-based, or an SCP, will always override any Allow statement.

Q: Can I attach a resource-based policy to an EC2 instance?

A: No. Resource-based policies can only be attached to specific AWS services that support them, such as Amazon S3 buckets, SQS queues, SNS topics, and Lambda functions. EC2 instances are principals, not resources in this context; you control their permissions by attaching an identity-based policy to an IAM role, which the instance then assumes.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.