IAM Users vs Roles

Concepts Covered

• IAM users
• IAM roles
• Long-term credentials
• Temporary credentials
• Federation
• IAM Identity Center
• Instance profiles
• Service roles
• Cross-account access
• Exam traps around access keys

1. Plain-English Definition

IAM users and IAM roles are both AWS identities, but they are designed for different access patterns.

An IAM user is a long-term identity created inside one AWS account. It can have a console password, access keys, permissions policies, MFA, and group membership. It is directly associated with credentials.

An IAM role is an identity with permissions that can be assumed by a trusted principal. The principal might be a human through federation, an EC2 instance, a Lambda function, another AWS account, an AWS service, or a third-party system. A role does not have normal long-term credentials. When it is assumed, AWS issues temporary credentials for that session.

The short version is:

IAM user = identity with long-term credentials
IAM role = assumable permission set that returns temporary credentials

Modern AWS architecture strongly favors roles and federation. IAM users still exist, but they should not be the default answer for people, workloads, or cross-account access.

2. Why This Matters In AWS

Credentials are one of the easiest ways to lose control of an AWS account.

Long-lived access keys can be copied into source code, pasted into scripts, left on laptops, committed to repositories, stored in CI logs, or forgotten after a project ends. If the key has broad permissions, the blast radius can be large.

Roles reduce this risk. A workload can assume a role and receive temporary credentials. Those credentials expire. The permissions can be changed centrally. The trust relationship can be controlled. CloudTrail can record role sessions. For EC2, Lambda, ECS, and many AWS services, roles are the normal way to grant AWS API access.

For SAA-C03, this comparison shows up constantly:

• EC2 needs access to S3
• Lambda needs to write to DynamoDB
• a third party needs access to your account
• a user in one account needs access to another account
• the company wants to avoid long-term credentials
• human workforce users need AWS console access

The answer is usually not "create an IAM user and share keys." It is usually a role, federation, IAM Identity Center, or temporary credentials.

3. The Beginner Mental Model

Think of an IAM user like a named badge with permanent keys.

Think of an IAM role like a job jacket someone can temporarily wear after proving they are trusted.

The badge model:

IAM user -> long-term credentials -> AWS API calls

The role model:

trusted principal -> assume role -> temporary session credentials -> AWS API calls

The role has two sides:

• trust policy: who can assume this role
• permissions policy: what the role can do after it is assumed

For an EC2 application, the trusted principal is the EC2 service. The role permissions might allow s3:GetObject for one bucket prefix. The application receives temporary credentials through the instance metadata service.

For a human user, federation lets the user sign in through an identity provider. The resulting AWS session can assume a role with the right permissions.

4. What That Mental Model Misses

The user-versus-role comparison is not "bad versus good." It is about credential lifetime and access pattern.

IAM users can still be useful in narrow cases. AWS documentation mentions cases such as specific service credentials, emergency access, or compatibility scenarios. But for normal workforce access, AWS recommends federation and temporary credentials. For applications, AWS recommends roles wherever possible.

Roles are not magic. A role can be dangerously broad. A trust policy can be too open. A third-party role without an external ID can be risky. A role assumed by many workloads can make audit trails harder to interpret. Temporary credentials reduce one class of risk, but permission design still matters.

Federation also does not remove IAM. It changes how the user proves identity. The resulting access still maps to AWS permissions, often through roles and permission sets.

The key exam correction is this: roles are not only for humans switching accounts. They are the standard pattern for workloads, AWS services, federation, and cross-account delegation.

5. AWS Mechanics

An IAM user can have console credentials and access keys. It can belong to groups and have managed or inline policies. Each IAM user belongs to one AWS account. IAM users should use MFA for console access and should not have broad permissions by default.

An IAM role has a trust policy and permissions policies. The trust policy names who can assume the role. The permissions policies define what the role can do after assumption.

AWS Security Token Service issues temporary credentials when a role is assumed. These credentials include an access key ID, secret access key, session token, and expiration.

An EC2 instance uses an instance profile to receive a role. Lambda functions use execution roles. ECS tasks use task roles. AWS services often use service roles or service-linked roles to perform actions on your behalf.

Cross-account access can use roles. Account A grants a role trust relationship to a principal in Account B. Account B's identity also needs permission to assume that role.

6. Architecture Examples

An application running on EC2 needs to read images from S3. The poor design is to create an IAM user, generate access keys, and place those keys on the instance. The better design is an EC2 instance role with only the required S3 read permissions.

A Lambda function needs to write order records to DynamoDB. Use a Lambda execution role with dynamodb:PutItem scoped to the table. Do not share a developer's credentials with the function.

A consulting vendor needs limited read access to your account. Create a cross-account role with a trust policy for the vendor's account, require an external ID when appropriate, and grant only the needed read actions.

An employee needs console access across multiple accounts. Use IAM Identity Center or federation and assign permission sets or roles, rather than creating separate IAM users in every account.

7. SAA-C03 Exam Signals

"Avoid long-term credentials" points to roles, federation, or temporary credentials.

"Application running on EC2 needs AWS API access" points to an IAM role attached through an instance profile.

"Lambda needs to access another AWS service" points to the function execution role.

"Third-party account needs access" often points to a cross-account role, commonly with external ID for vendor scenarios.

"Human workforce access across accounts" points to IAM Identity Center or federation.

"Emergency access if identity provider is unavailable" can justify tightly controlled IAM users, but that is not the default.

8. Common Traps

Do not store IAM user access keys on EC2 instances when an instance role works.

Do not create a new IAM user for every application by default.

Do not confuse a role's trust policy with its permissions. Trust controls who can assume it. Permissions control what it can do.

Do not assume roles are automatically least privilege. A role can be overpowered.

Do not forget session tokens. Temporary credentials are not just access key and secret key.

Do not create human IAM users in every account when federation or IAM Identity Center is the cleaner workforce pattern.

9. What To Learn Next

Next, learn Identity Policies vs Resource Policies. Users and roles explain who is making the request. Policies explain how AWS decides whether that request is allowed.

Then revisit Amazon EC2, because EC2 instance profiles are one of the most common role patterns on the exam.

Official AWS references:

• IAM users
• IAM roles
• IAM roles for Amazon EC2