IAM Role vs Policy: What It Is and When to Use It

Definition

In AWS Identity and Access Management (IAM), a Role is an identity that can be assumed by a trusted entity (like a user, an application, or an AWS service) to gain temporary permissions. A Policy is a JSON document that explicitly defines a set of permissions (e.g., allow s3:GetObject on a specific bucket) that can be attached to an identity like a user, group, or role. The fundamental difference is that a Role is who can act, while a Policy is what they are allowed to do.

How It Works

Understanding the relationship between roles and policies is key to mastering AWS security. They are distinct but work together to grant access.

IAM Policies

A policy is a formal statement of one or more permissions. It's a JSON document with several key elements:

• Effect: Allow or Deny. An explicit Deny always overrides any Allow.
• Action: The specific AWS service API calls that are allowed or denied (e.g., ec2:StartInstances, dynamodb:PutItem).
• Resource: The Amazon Resource Name (ARN) of the object(s) the action applies to.
• Condition (Optional): Specifies circumstances under which the policy is in effect (e.g., only allow access from a specific IP address).

There are several types of policies:

• Identity-Based Policies: These are attached directly to an IAM identity (user, group, or role).
  • AWS Managed Policies: Created and managed by AWS for common use cases (e.g., AmazonS3ReadOnlyAccess).
  • Customer Managed Policies: Standalone, reusable policies you create and manage in your account.
  • Inline Policies: Tightly coupled to a single user, group, or role. They are deleted when the identity is deleted and are best for one-off, specific permissions.
• Resource-Based Policies: Attached directly to a resource, like an Amazon S3 bucket or an AWS Lambda function. They specify which principals (users, roles, accounts) can access that specific resource.

IAM Roles

An IAM Role is not associated with a specific person or application and has no long-term credentials like a password or access keys. Instead, when an entity assumes a role, AWS Security Token Service (STS) provides temporary security credentials.

A role has two policies attached to it:

1. Trust Policy: This defines who is allowed to assume the role. The trusted entity is called the Principal (e.g., an EC2 service, another AWS account, or a federated user).
2. Permissions Policy (or Identity-Based Policy): This is a standard IAM policy that defines what actions the role can perform on which resources once it has been assumed.

The process works like this: A user or service makes an sts:AssumeRole API call. If the requestor is listed in the role's Trust Policy, STS returns a temporary access key ID, secret access key, and session token. The requestor then uses these temporary credentials to make API calls, and the permissions are governed by the role's Permissions Policy.

Key Features and Limits

As of early 2026, AWS has increased several IAM quotas to accommodate growing environments. Always check the official IAM and AWS STS quotas documentation for the most current information.

• Roles per AWS Account: 10,000 (increased from 5,000).
• Customer Managed Policies per Account: 10,000 (increased from 5,000).
• Managed Policies per Role: 25 (increased from 20).
• Role Trust Policy Size: 8,192 characters (increased from 4,096).
• Permissions Boundaries: An advanced feature where a managed policy is used to set the maximum permissions that an identity-based policy can grant to a role or user. It does not grant permissions itself but acts as a guardrail.
• Session Policies: When assuming a role programmatically, you can pass a policy that further restricts the permissions of the temporary session. The session's effective permissions are the intersection of the role's policies and the session policy.

Common Use Cases

Choosing between a role and a policy is about understanding the context. You don't choose one or the other; you use policies to grant permissions to roles, users, and groups.

When to Use an IAM Role:

1. Granting AWS Service Permissions: The most common use case. For example, creating a role that allows an Amazon EC2 instance to write logs to Amazon CloudWatch or read objects from an Amazon S3 bucket.
2. Cross-Account Access: Allowing users or services in Account A to access resources in Account B without creating separate IAM users in Account B. The role in Account B trusts Account A.
3. Identity Federation: Granting temporary access to users authenticated through an external identity provider (like Active Directory via SAML 2.0 or a web identity provider like Google/Facebook via OpenID Connect) without creating IAM users for them.
4. Temporary Elevated Permissions: A human user can assume a role to perform a specific administrative task (e.g., DatabaseAdminRole) instead of having those powerful permissions attached to their user identity at all times.

When to Use Different Policy Types:

1. Customer Managed Policy: The best practice for most situations. Use when you need to assign the same set of permissions to multiple identities (users, roles). It's reusable and easier to manage.
2. Inline Policy: Use for permissions that are unique and tightly coupled to a single identity and should not be shared.
3. Resource-Based Policy: Use when you want to control access to a single resource from multiple principals, especially for simple cross-account access to one resource (e.g., allowing another account to access a specific S3 bucket).

Pricing Model

AWS Identity and Access Management (IAM) is a foundational service and is available at no additional charge. Creating and using IAM users, groups, roles, and policies does not incur any cost.

However, some advanced features within the IAM Access Analyzer service have associated costs:

• Unused Access Analysis: Priced per IAM role or user analyzed per month.
• Internal Access Analysis: Priced per resource monitored per month.
• Custom Policy Checks: Priced per API call to the policy check API.

External access analysis (checking for public and cross-account access) and standard policy validation remain free.

Pros and Cons

IAM Roles

• Pros:
  • Enhanced Security: Automatically rotates temporary credentials, eliminating the risk of leaked long-lived access keys.
  • Delegation: Excellent for delegating access to services, applications, and third parties without sharing permanent credentials.
  • Centralized Management: Permissions for an application can be managed in one role, rather than being duplicated across multiple users.
• Cons:
  • Complexity: The concept of assuming roles and trust policies can be more complex to understand initially compared to attaching a policy directly to a user.

IAM Policies

• Pros:
  • Granular Control: Provides fine-grained control over every action and resource in AWS.
  • Flexibility: Multiple policy types (managed, inline, resource-based) cover nearly every access control scenario.
  • Reusable: Managed policies reduce administrative overhead and prevent configuration drift.
• Cons:
  • Complexity in Logic: The policy evaluation logic can be complex, especially with multiple policies, explicit denies, and conditions.
  • Character Limits: Policy documents have size limits, which can be a constraint in highly complex environments with many resource ARNs.

Comparison with Alternatives

IAM Role vs. IAM User with Access Keys

The primary alternative to using an IAM Role for programmatic access is creating an IAM User and generating long-lived access keys.

• IAM Role: Provides temporary credentials via STS. This is the AWS best practice for applications, services, and any scenario where temporary access is feasible. It is more secure because the credentials expire and are automatically rotated.
• IAM User: Has permanent credentials (access key ID and secret access key). This is strongly discouraged for applications running on AWS (e.g., on EC2 or Lambda) because managing and rotating these keys is a significant security burden. IAM users are primarily intended for human users who need long-term, persistent identity for console access or for specific workloads outside of AWS where roles are not an option.

Exam Relevance

IAM is a cornerstone of every AWS certification exam, from Foundational to Specialty.

• AWS Certified Cloud Practitioner (CLF): Understand the basic difference between a user, role, and policy. Know that roles are used to grant permissions to AWS services.
• AWS Certified Solutions Architect - Associate (SAA): Deeply understand use cases for IAM Roles, including EC2 instance profiles, Lambda execution roles, and cross-account access. Be able to read and interpret simple IAM policies and understand the principle of least privilege.
• AWS Certified Security - Specialty (SCS): Expect complex questions on policy evaluation logic, including the interaction between identity policies, resource policies, permissions boundaries, and Service Control Policies (SCPs). Mastery of all policy types and federation is required.

For all exams, remember the most critical rule of policy evaluation: an explicit Deny in any policy always overrides any Allow statement.

Frequently Asked Questions

Q: What is the difference between an inline policy and a managed policy?

A: A managed policy is a standalone, reusable policy that you can attach to multiple users, groups, and roles. An inline policy is embedded directly within a single user, group, or role. Best practice is to use managed policies for reusability and easier management; use inline policies only for permissions that are strictly one-to-one with an identity.

Q: Can an IAM Role exist without a permissions policy?

A: Yes, a role can be created without a permissions policy attached. However, if it has no permissions policy, it cannot perform any actions on AWS resources. It still requires a trust policy to define who can assume it, but the assumed session would have no permissions.

Q: When should I use a resource-based policy versus a role for cross-account access?

A: A resource-based policy is often simpler for granting access to a single resource (like an S3 bucket or SQS queue) to principals in another account. An IAM role is more flexible and better suited when you need to grant access to multiple resources or services within your account, as you can attach multiple permissions policies to the role.

---

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.