Understanding IAM Roles in AWS: Trusted Entities and Types

Arjun had just stepped into his new role as a Cloud Security Engineer. His team was building microservices on AWS. On Day 1, a developer pinged him:

“Hey bro, our EC2 instance needs access to S3. Can you create an IAM User and share the access key?”

But Arjun knew better. He replied:

“IAM Users are for humans. EC2 is a machine. Let’s use IAM Roles — it’s more secure and scalable.”

That decision set the foundation for Arjun’s journey toward AWS best practices.

🧠 What is an IAM Role?

Think of an IAM Role as a temporary identity in AWS.

It defines what permissions are allowed.
It defines who is trusted to assume the role (not just humans).
It provides temporary credentials that auto-expire.

IAM Role = permission set + trust relationship

Roles are NOT login accounts. They are assumed only when needed — by services, applications, or external users.

🤝 IAM Users vs IAM Roles – What’s the Difference?

Aspect	IAM User	IAM Role
Created for	A specific human (person)	AWS service, app, or external user
Credentials	Permanent (username & access key)	Temporary (auto-generated)
Login possible?	Yes	No direct login
Use case	Admins, developers	EC2, Lambda, federated access

🔐 The 5 Trusted Entities That Can Assume an IAM Role

Arjun learned that an IAM Role must “trust” someone to assume it.
That “someone” is called a Trusted Entity.

Here’s what AWS allows as trusted entities — each with a specific use case:

1. AWS Services (Service Roles)

These are roles that AWS services (like EC2, Lambda, ECS, etc.) can assume to perform tasks on your behalf.

🛠 Example:
Arjun’s EC2 instance needs to read from an S3 bucket.
He creates a role that allows s3:GetObject and attaches it to the EC2 instance.

EC2 automatically assumes the role using the Instance Metadata Service (IMDS).

2. Another AWS Account (Cross-Account Roles)

You can allow IAM users or roles in a different AWS account to assume a role in your account.

🛠 Example:
Arjun’s team has two AWS accounts — Dev and Prod.
He creates a role in the Prod account and allows users from Dev to assume it, without sharing credentials.

Cross-account access with proper control. No duplication of users.

3. Web Identity Providers (OIDC)

These are external identity providers that support OpenID Connect (OIDC) like:

Amazon Cognito
Google
Facebook
Apple

🛠 Example:
Arjun built a mobile app that uploads images to S3.
Instead of creating IAM users, he lets users sign in with Google, and the app assumes a role via Cognito to upload images.

No AWS credentials stored in the app. All access is temporary and scoped.

4. SAML 2.0 Federated Identities

You can link your corporate identity provider (like Azure AD, Okta, or Google Workspace) using SAML 2.0 and let your employees log in via SSO.

🛠 Example:
Arjun’s company uses Google Workspace.
He configures a SAML identity provider and creates a role that maps to Google users.

Employees log in to AWS Console with their Google ID — no separate AWS credentials needed.

5. Custom Trusted Identities (Defined in Trust Policy)

This is the flexible and advanced option where Arjun defines any custom AWS principal in the trust policy.

It could be:

An IAM Role
An IAM User (from the same or another account)
A Lambda function
An EC2 instance profile
A third-party OIDC identity

🛠 Example:
Arjun creates a role that only a specific Lambda function can assume to write logs to CloudWatch.

The trust policy explicitly names that Lambda function’s role ARN.

📦🔄 How Role Assumption Works (Simple Flow)

Here’s what happens behind the scenes when a role is assumed:

Create Role: Define permissions (what the role can do).
Set Trust Policy: Define who can assume it (trusted entity).
Assume the Role: AWS generates temporary credentials.
Use Credentials: The entity uses those creds to perform actions.
Auto Expiry: Credentials expire after session ends (default 1 hour).

💬 Final Words from Arjun

“Roles are like 🔑 guest passes — limited, monitored, and safer.
Never give your permanent house key to a delivery guy.”

So whenever you're asked to give access to EC2, Lambda, or external apps —
Don’t create IAM users.
Create IAM Roles.

📝 Quick Summary for AWS SAA

IAM Roles = temporary credentials + trust policy
5 Trusted Entities: AWS services, other accounts, web identity providers, SAML providers, custom trusted identities
Best for EC2, Lambda, cross-account access, SSO, and mobile apps
More secure than using IAM Users with access keys

Understanding IAM Roles in AWS: Trusted Entities, Types, and Practical Use Cases AWS SAA