DEV Community

Cover image for AWS IAM Deep Dive — Roles, Policies, Groups, EC2 & Everything in Between
Tejas Shinkar
Tejas Shinkar

Posted on • Edited on

AWS IAM Deep Dive — Roles, Policies, Groups, EC2 & Everything in Between

#aws #cloud #devops #beginners

🔐 AWS IAM Deep Dive

Authentication · Authorization · Accounting · Roles · EC2 Basics

This is part of my ongoing AWS learning journey as I transition from Systems Engineer to Cloud/DevOps. I'm documenting everything I learn — concepts, hands-on steps, and the "why" behind each one.

Why IAM Exists — The Real Answer

When you first create an AWS account, you get a Root user. It has zero restrictions — it can delete everything, rack up unlimited bills, create or destroy any resource. That's exactly why you should almost never use it.

Real teams have multiple people — developers, DevOps engineers, auditors, managers. You don't want everyone logging into the same all-powerful Root account. You need controlled, tracked, individual access. That's what IAM solves.

IAM answers one fundamental question: Who can do what, on which AWS resource — and is it being recorded?

That question maps perfectly to a security framework called AAA.

The AAA Framework

Every access control system — not just AWS — is built on three pillars:

Pillar Question it answers How AWS implements it
Authentication Who are you? Credentials (username + password) + MFA
Authorization What can you do? IAM Policies and Roles
Accounting What did you do? AWS CloudTrail (full audit logs)

When you log into AWS and try to start an EC2 instance, all three happen in sequence — AWS verifies your identity, checks if you're allowed to start EC2, and logs that you did it. Every single time.

MFA — The Second Lock

A password alone isn't enough. If someone gets your password, they're in. MFA adds a second factor — a time-based OTP from your phone — so even a stolen password is useless without the physical device.

Three MFA types:

Type How it works When to use
Virtual MFA Google Authenticator / Authy app ✅ Default choice for learning
Hardware MFA Physical YubiKey device ✅✅ Best for Root account
SMS/Voice OTP via text message ⚠️ Weakest, avoid if possible

Always enable MFA on Root first. Then on your IAM user too.

IAM Users

An IAM User is an identity created inside your AWS account for a specific person or application. Unlike Root, it starts with zero permissions — it can log in but can't do anything until you attach a policy.

Creating an IAM User (what you actually did):

IAM Console → Users → Create User
→ Set username
→ Enable Console access + set password
→ (Optional) Add tags
→ Attach policy directly OR add to a group
→ Done — user can now log in with limited access
Enter fullscreen mode Exit fullscreen mode

One important thing: an IAM user with permission to create users can create more IAM users. Permissions propagate — so be careful what you give.

IAM Groups — Managing at Scale

Imagine you have 10 developers. Attaching policies to each one individually is painful and error-prone. Groups solve this.

A Group is a collection of IAM users. Attach a policy to the group once — every user in it inherits those permissions automatically.

Group: DevOpsTeam  →  Policy: PowerUserAccess
   ├── User: tejas        → gets PowerUserAccess ✅
   ├── User: ravi         → gets PowerUserAccess ✅
   └── User: priya        → gets PowerUserAccess ✅

Add a new team member → add to group → done.
Remove someone → remove from group → done.
Enter fullscreen mode Exit fullscreen mode

Key rules:

  • One user can belong to multiple groups
  • Groups cannot contain other groups (no nesting)
  • Default quota: 300 groups per account

Creating via Group (the cleaner approach):

Create IAM Group → Attach policy to group
→ Create IAM User → Add user to group
→ User inherits group's permissions automatically
Enter fullscreen mode Exit fullscreen mode

IAM Policies — The Permission Document

A Policy is a JSON document that defines exactly what is allowed or denied. Every time you make a request in AWS — clicking a button, running a CLI command, an app calling an API — AWS checks the relevant policies to decide: allow or deny?

Basic structure:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}
Enter fullscreen mode Exit fullscreen mode
Field What it means
Effect Allow or Deny
Action Which API operation (e.g. s3:GetObject, ec2:*)
Resource Which specific resource (by ARN)
Condition Optional — e.g. "only if MFA is active"

The one rule that matters most:

Explicit Deny > Everything else
No Policy = Denied by default
Explicit Allow = Access granted (unless a Deny exists)
Enter fullscreen mode Exit fullscreen mode

If a Deny exists anywhere in any applicable policy, it always wins — even if an Allow exists somewhere else.

What about combined permissions?
AWS combines all Allow permissions across all sources:

User has: AmazonEC2FullAccess (direct policy)
Group has: ReadOnlyAccess
Result:    EC2 Full Access + ReadOnly on everything else
           (the more permissive wins, unless there's an explicit Deny)
Enter fullscreen mode Exit fullscreen mode

SCP — The Ceiling Above IAM

You now understand IAM policies. But there's something that sits above IAM entirely.

SCP = Service Control Policy — it's part of AWS Organizations (used when you manage multiple AWS accounts together).

The key distinction:

IAM Policy SCP
Attached to Users, Groups, Roles AWS Accounts / Organizational Units
Does it grant permissions? ✅ Yes ❌ No — only limits
Can it restrict Root? ❌ No ✅ Yes
Who uses it? Everyone Enterprises with multiple accounts

SCP defines the maximum permissions possible in an account. IAM policies still need to grant the actual access — but they can never exceed what SCP allows.

Example: SCP says "no S3 access allowed in this account." Even if an IAM policy gives a user S3FullAccess, they still can't access S3. SCP wins.

For now, SCP is mostly relevant at enterprise scale. Keep it in mind — it'll come up in interviews.

ARN — Every Resource Has a Unique ID

ARN = Amazon Resource Name. Every single thing in AWS — users, roles, buckets, instances — has a globally unique ARN.

Format:

arn:aws:SERVICE:REGION:ACCOUNT-ID:RESOURCE
Enter fullscreen mode Exit fullscreen mode

Examples:

arn:aws:iam::123456789012:user/tejas           → IAM User
arn:aws:iam::123456789012:role/S3AccessRole    → IAM Role
arn:aws:s3:::my-bucket                          → S3 Bucket
arn:aws:ec2:ap-south-1:123456789:instance/i-abc → EC2 Instance
Enter fullscreen mode Exit fullscreen mode

ARNs are used everywhere — in trust policies, resource-based policies, CloudTrail logs. When you're adding a user to a role's trust policy, you paste their ARN.

IAM Roles — Temporary Identity, No Password

This is where most beginners get confused. Let's clear it up completely.

An IAM Role is a temporary identity with permissions — no username, no password. It's meant to be assumed — picked up temporarily by a user or an AWS service, used, and then dropped.

The visitor badge analogy:
Think of a role as a visitor badge at an office. A visitor picks up the badge at reception (assumes the role), gets access to specific floors (permissions), and returns the badge when done (session ends). No permanent access. No long-term credentials.

IAM User vs IAM Role

IAM User IAM Role
Has password? ✅ Yes ❌ No
Permanent? ✅ Yes ❌ Temporary (assumed)
For? Human beings Services or temporary access
Credentials Long-term Short-term, auto-rotated

Trust Policy — Who Can Assume a Role?

Every IAM Role has two things attached:

  1. Permission Policy — what the role is allowed to do
  2. Trust Policy — who is allowed to assume this role

The Trust Policy is a JSON document that answers: "Who gets to pick up this badge?"

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:user/tejas"
    },
    "Action": "sts:AssumeRole"
  }]
}
Enter fullscreen mode Exit fullscreen mode

This says: only the IAM user tejas can assume this role.

Role Switching:

Here's the complete flow:

Step 1: Create a Role
  IAM → Roles → Create Role
  → Attach permission: AmazonS3FullAccess
  → Name it: S3AccessRole

Step 2: By default, nobody can assume it
  Your IAM user tries to switch → fails ❌

Step 3: Edit the Trust Policy
  Open S3AccessRole → Trust Relationships → Edit
  → Add your IAM user's ARN as a trusted principal
  → Save

Step 4: Switch Role (from Console top-right)
  Click your username → Switch Role
  → Enter Account ID + Role name
  → You're now operating AS the role

Step 5: What changes?
  ✅ You can now access S3
  ❌ Your original EC2 permissions are SUSPENDED
  → Role permissions fully replace your user permissions for this session

Step 6: Switch back
  Click role name (top-right) → Switch Back
  → Back to your original IAM user permissions
  → S3 access gone
Enter fullscreen mode Exit fullscreen mode

That EC2 access disappearing when you switched to S3 role wasn't a bug — that's exactly how role switching works. The role's permissions replace your current ones for the duration of the session.

Service Principal — Roles for AWS Services

So far, roles have been assumed by IAM users (humans). But AWS services need to access other services too — and they use roles for that.

A Service Principal is the identity of an AWS service, used in trust policies:

ec2.amazonaws.com      → EC2 can assume roles
lambda.amazonaws.com   → Lambda can assume roles
s3.amazonaws.com       → S3 can assume roles
Enter fullscreen mode Exit fullscreen mode

Example: EC2 accessing S3 automatically

You want your EC2 instance to read/write S3 without hardcoding any credentials in your code.

Bad approach ❌:
  aws_access_key_id = 'AKIAIOSFODNN7EXAMPLE'  ← hardcoded in code
  aws_secret_access_key = 'wJalrXUt...'        ← if pushed to GitHub, you're done

Right approach ✅:
  Create a Role with S3 permissions
  Trust Policy: ec2.amazonaws.com can assume this role
  Attach role to EC2 via Instance Profile
  EC2 automatically gets temporary, rotating credentials
  Your code just calls S3 — no credentials anywhere
Enter fullscreen mode Exit fullscreen mode

IAM Instance Profile — The Bridge Between EC2 and IAM

An Instance Profile is a container that wraps an IAM Role and delivers it to an EC2 instance. When you attach a role to EC2 via the Console, an Instance Profile is created automatically behind the scenes.

Complete flow:

IAM Role (S3AccessRole)
    ↓ wrapped in
Instance Profile
    ↓ attached to
EC2 Instance
    ↓ app calls
AWS Metadata Service (169.254.169.254) — internal AWS endpoint
    ↓ returns
Temporary credentials (auto-rotated every hour)
    ↓ used to
Access S3 ✅ — no hardcoded keys, no manual rotation
Enter fullscreen mode Exit fullscreen mode

Lab steps:

Step 1: Create Role
  IAM → Roles → Create Role
  Trusted entity: AWS Service → EC2
  Attach policy: AmazonS3FullAccess
  Name: EC2-S3-Role

Step 2: Attach to EC2
  EC2 Console → Select Instance
  Actions → Security → Modify IAM Role
  Select: EC2-S3-Role → Update

Step 3: Test
  SSH into EC2 → run: aws s3 ls
  → Lists your S3 buckets ✅ (zero credentials configured)
Enter fullscreen mode Exit fullscreen mode

EC2 Basics — Launching Your First Instance

EC2 = Elastic Compute Cloud — a virtual machine running on AWS hardware. When you launch one, you're renting a slice of a physical server in an AWS data center.

The Key Components

AMI (Amazon Machine Image)
A pre-built template containing the OS, software, and configuration. It's the blueprint your EC2 instance is built from.

  • Amazon Linux 2, Ubuntu 22.04, Windows Server — these are all AMIs
  • AMIs are Region-specific — if you want the same AMI in another Region, you must manually copy it. AWS does not auto-replicate AMIs.

Instance Type
Defines CPU, RAM, and network capacity.

  • t2.micro — 1 vCPU, 1 GB RAM — Free Tier eligible ✅
  • Naming: t3.medium → t = family, 3 = generation, medium = size

Key Pair
Used to SSH into your EC2 instance securely — no password needed.

  • AWS puts the public key on your EC2 instance
  • You download the private key (.pem file)
  • You use .pem to prove your identity: ssh -i key.pem ec2-user@<ip>
  • Download once. If you lose it, you lose SSH access. No recovery.

Security Group
Acts as a virtual firewall. Controls what traffic can reach your instance.

  • Port 22 (SSH) — for terminal access
  • Port 80 (HTTP) — for web traffic
  • Port 443 (HTTPS) — for secure web traffic

User Data
A script that runs once automatically the first time EC2 boots. Used to install software, configure servers, deploy apps — all without manual steps.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from EC2!</h1>" > /var/www/html/index.html
Enter fullscreen mode Exit fullscreen mode

This script installs Apache web server and creates a basic webpage — automatically on first boot.

EC2 Launch Flow (What You Did) 

EC2 Console → Launch Instance
  ↓
Name/Tags → give it a meaningful name
  ↓
AMI → Amazon Linux 2 (Free Tier)
  ↓
Instance Type → t2.micro (Free Tier)
  ↓
Key Pair → Create new → Download .pem file (save it!)
  ↓
Security Group → Allow SSH (22) + HTTP (80)
  ↓
Storage → Default 8 GB (Free Tier covers this)
  ↓
Advanced → User Data → paste startup script
  ↓
Launch Instance
  ↓
Wait ~2 minutes → Instance state: Running
  ↓
Copy Public IP → open in browser → "Hello from EC2!" ✅
Enter fullscreen mode Exit fullscreen mode

Two Policy Types — Identity vs Resource Based

You've now seen policies attached to users, groups, and roles. But policies can also be attached to resources directly.

Identity-Based Policy

  • Attached to: IAM user, group, or role
  • Says: "This identity can perform these actions"
  • No Principal field needed (the identity it's attached to is the principal)
  • Example: AmazonEC2FullAccess attached to your IAM user

Resource-Based Policy

  • Attached to: a resource (S3 bucket, SQS queue, etc.)
  • Says: "These identities are allowed to access me"
  • Has a Principal field — explicitly names who can access
  • Example: S3 bucket policy allowing a specific IAM user to read objects 
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789:user/tejas"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}
Enter fullscreen mode Exit fullscreen mode

Quick Revision 

AAA FRAMEWORK
  Authentication  → Who are you? (credentials + MFA)
  Authorization   → What can you do? (IAM policies)
  Accounting      → What did you do? (CloudTrail)

PERMISSION HIERARCHY
  SCP (Organizations) → ceiling, limits max permissions
  IAM Policies       → actual grants within that ceiling
  Explicit Deny      → always wins over everything

IAM BUILDING BLOCKS
  User    → permanent identity, has password, for humans
  Group   → collection of users, attach policy once
  Role    → temporary identity, no password, assumed
  Policy  → JSON doc defining Allow/Deny on resources
  ARN     → unique ID for every AWS resource

ROLE SWITCHING
  Add user ARN to role's Trust Policy
  User switches role → gets role permissions temporarily
  Original permissions suspended during session
  Switch back → original permissions restored

INSTANCE PROFILE (EC2 → S3)
  Create Role (trust: ec2.amazonaws.com) + S3 policy
  Attach to EC2 via Instance Profile
  EC2 auto-gets temp credentials → accesses S3
  Zero hardcoded credentials ✅

EC2 BASICS
  AMI      = OS template (Region-specific, must copy to use elsewhere)
  Key Pair = SSH access (.pem — download once, don't lose)
  User Data = startup script (runs once on first boot)
  t2.micro = Free Tier instance type
Enter fullscreen mode Exit fullscreen mode

Interview Questions

Q1: What is the difference between an IAM User and an IAM Role?
An IAM User has permanent credentials (username + password) and is meant for human beings. An IAM Role has no password — it provides temporary credentials and is assumed by users or AWS services when needed. Roles are best practice for service-to-service communication.

Q2: What is a Trust Policy and why is it needed?
A Trust Policy is a JSON document attached to an IAM Role that defines who is allowed to assume that role. Without it, nobody can use the role — not even admins. You explicitly add trusted principals (IAM user ARNs or service principals like ec2.amazonaws.com).

Q3: What happens when you switch roles in AWS?
Your current IAM user permissions are temporarily suspended and replaced by the role's permissions for that session. When you switch back, your original permissions are restored. This is why EC2 access disappeared when you switched to the S3 role.

Q4: What is an Instance Profile and why use it instead of access keys?
An Instance Profile is a container that delivers an IAM Role to an EC2 instance. It gives EC2 automatic, temporary, rotating credentials via the metadata service — no hardcoded keys needed. This is far more secure than embedding access keys in code, which can be accidentally exposed.

Q5: What is the difference between SCP and IAM policies?
IAM policies grant permissions to users, groups, or roles within an account. SCPs (Service Control Policies) sit above IAM at the Organizations level and define the maximum permissions allowed in an account — they restrict, not grant. Even the Root user is subject to SCP.

Q6: An IAM user has EC2FullAccess via direct policy and ReadOnlyAccess via their group. What's their effective permission?
They get EC2 Full Access plus ReadOnly on everything else. AWS combines all Allow permissions. However, if an Explicit Deny exists anywhere, that overrides all Allows.

Practice Tasks

  1. Create an IAM Group called DevOpsTeam, attach PowerUserAccess, create a user and add them to the group. Log in as that user and verify you can access EC2 but not billing.
  2. Create an IAM Role with AmazonS3ReadOnlyAccess. Edit its Trust Policy to add your IAM user's ARN. Switch to that role and verify S3 access. Notice EC2 access is gone.
  3. Launch an EC2 instance with a User Data script that installs Apache. Access the public IP in your browser and confirm the webpage loads.
  4. Create an IAM Role for EC2 with S3 access. Attach it to a running EC2 instance via Modify IAM Role. SSH in and run aws s3 ls — confirm it works without any credentials configured.
  5. Open AmazonEC2FullAccess policy JSON in the IAM Console. Find what ec2:* means and identify 3 specific actions it includes.

Part of my AWS Cloud + DevOps learning journey — documenting everything as I transition from Systems Engineer to Cloud/DevOps Engineer.

Top comments (0)