Master IAM Role in AWS: Secure Access Guide

IAM Role in AWS are essential for managing secure access to AWS resources. When 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 Role in AWS — it’s more secure and scalable.”

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

---

🧠 What is an IAM Role in AWS?

Think of an IAM Role in AWS 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

IAM Role in AWS is NOT login accounts. They are assumed only when needed — by services, applications, or external users.

---

🤝 IAM Users vs IAM Role in AWS – What’s the Difference?

Aspect	IAM User in AWS	IAM Role in AWS
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 in AWS

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:

1. Create Role: Define permissions (what the role can do).
2. Set Trust Policy: Define who can assume it (trusted entity).
3. Assume the Role: AWS generates temporary credentials.
4. Use Credentials: The entity uses those creds to perform actions.
5. 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 Role in AWS.

---

📝 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

---

Read More on AWS Advanced IAM

• Master IAM Role in AWS: Secure Access Guide
• IAM Roles vs Resource-Based Policies: Clear Guide
• Master IAM Permission Boundaries in AWS
• IAM Identity Center: One Secure Login for All
• Master IAM Role vs Resource Policy in AWS Fast
• Master IAM Policy Conditions for AWS Security

Follow me for more such content

• My Site
• My Blogs
• My YouTube Channel
• AWS Community
• Medium
• LinkedIn
• Instagram
• Github
• Dev
• X