š§ What This Session Covers
Think of this session as answering one big question:
"Who can do what, on which AWS resource ā and how do we control that?"
Topics flow in this order:
- Why IAM even exists (AAA Framework)
- Root vs IAM User
- MFA
- Groups, Roles, Service Principals
- Policies (Identity-based & Resource-based)
- ARN ā What it is
- IAM Instance Profile ā EC2 accessing S3
- Role Switching & Assume Role
- EC2 Basics + Key-Pair + AMI
- AWS Pricing Calculator
ā SECTION 1 ā Why IAM? (Your Question Answered)
"I have my computer, my credentials, I'll just log into Root ā why bother with IAM?"
Here's the honest answer:
Root has zero restrictions. It can delete your entire AWS account, rack up unlimited bills, create/destroy anything. When you're learning alone, that feels fine ā but the moment anything goes wrong (compromised password, accidental command, someone else uses your laptop), the damage is total and irreversible.
IAM exists to answer: "What's the minimum access this person/service actually needs?"
Real-world example: A junior developer on your team should be able to deploy code ā not delete production databases or view billing. IAM lets you give them exactly what they need and nothing more.
Also ā AWS has a concept called AAA Framework which explains WHY access control systems exist:
| A | Name | Question it answers | AWS Tool |
|---|---|---|---|
| A | Authentication | Who are you? | Username + Password + MFA |
| A | Authorization | What can you do? | IAM Policies & Permissions |
| A | Accounting | What did you do? | AWS CloudTrail (audit logs) |
Without IAM: Every user = admin = massive security risk. One mistake wipes everything.
š¤ SECTION 2 ā Root User vs IAM User
| Root User | IAM User | |
|---|---|---|
| Created | When you open AWS account | By Root or an admin |
| Access | Unrestricted ā everything | Only what policies allow |
| Can be restricted? | ā No | ā Yes |
| Use for | Initial setup only | All daily tasks |
| MFA | Enable immediately | Strongly recommended |
The rule is simple:
- Root = lock it away with MFA, use only for billing or account recovery
- IAM User = what you actually log in with daily
š SECTION 3 ā MFA (Multi-Factor Authentication)
Password alone isn't enough. MFA adds a second check ā a time-based OTP from your phone.
Three types:
| Type | How | Security Level |
|---|---|---|
| Virtual MFA | Google Authenticator / Authy app | ā Good ā use this |
| Hardware MFA | Physical YubiKey token | ā ā Best ā for Root |
| SMS/Voice | OTP via text message | ā ļø Avoid if possible |
Steps to enable:
IAM Console ā Security Credentials
ā Assign MFA Device
ā Choose: Virtual / Hardware / SMS
ā Scan QR code with authenticator app
ā Enter two consecutive 6-digit codes
ā Done
š„ SECTION 4 ā IAM Groups
A Group is a collection of IAM users. Instead of attaching policies to every user individually, you attach to a Group once ā all users in that group inherit those permissions.
Group: DevOpsTeam
Policy attached: PowerUserAccess
āāā User: tejas ā gets PowerUserAccess ā
āāā User: ravi ā gets PowerUserAccess ā
āāā User: priya ā gets PowerUserAccess ā
Key rules:
- One user can be in multiple groups
- Groups cannot contain other groups (no nesting)
- Default quota: 300 groups/account (can request increase up to 500)
When to use:
Use groups to manage teams ā AdminGroup, DevGroup, ReadOnlyGroup. Adding someone to a team = add them to the group. Removing access = remove from group. Simple.
š SECTION 5 ā IAM Roles (Your Questions Answered)
"What is a Role? What is Assume? What is Trust Relationship? Why switch roles?"
Let's build understanding from scratch.
What is a Role?
A Role is like a temporary identity with permissions ā it has no username or password. It's meant to be assumed (picked up and used temporarily) by a user or a service.
Think of it like a visitor badge at an office:
- The visitor (IAM user or AWS service) picks up the badge
- The badge gives access to specific areas (S3, EC2, etc.)
- When done, they return the badge ā access is gone
- No permanent credentials involved
IAM User vs IAM Role
| IAM User | IAM Role | |
|---|---|---|
| Has password? | ā Yes | ā No |
| Permanent? | ā Yes | ā Temporary (assumed) |
| For? | Humans logging in | Services or temporary access |
| Credentials | Long-term | Short-term, auto-rotated |
What is "Assume Role"?
Assuming a Role = temporarily taking on a role's permissions.
Normal: IAM User (tejas) ā has EC2FullAccess via direct policy
Assumes S3Role:
IAM User (tejas) ā temporarily becomes S3Role ā can now access S3
ā EC2 access is SUSPENDED during this time
ā Role session ends ā back to original EC2 permissions
This is exactly what you observed: "when you switched to S3 role, you couldn't access EC2 anymore" ā correct! Role switching is temporary and replaces your current permissions for that session.
What is a Trust Relationship?
A Trust Relationship is the permission for an identity to assume a role.
It's a JSON document attached to the role that says: "Who is allowed to pick up this badge?"
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789:user/tejas"
},
"Action": "sts:AssumeRole"
}]
}
This says: "Only the IAM user 'tejas' can assume this role."
Full flow of what you did in class:
1. Created a Role (e.g., S3AccessRole) with S3FullAccess permission
2. Edited the Trust Relationship JSON ā added ARN of IAM user tejas
3. Tejas logs in as IAM user
4. Tejas switches to S3AccessRole (assumes the role)
5. Tejas can now access S3 ā but EC2 access is gone (role replaced permissions)
6. Session ends or tejas switches back ā original permissions restored
What is a Service Principal?
A Service Principal is the identity of an AWS service ā used in trust relationships to let services assume roles.
Examples:
ec2.amazonaws.com ā EC2 service identity
lambda.amazonaws.com ā Lambda service identity
s3.amazonaws.com ā S3 service identity
When you want EC2 to access S3 automatically (without hardcoding credentials), you create a role with:
-
Trust policy:
ec2.amazonaws.comcan assume this role - Permission policy: S3FullAccess (or specific S3 access)
Then attach that role to EC2 ā EC2 can now talk to S3. No passwords, no keys.
š SECTION 6 ā IAM Permissions & Policies
What is a Policy?
A Policy is a JSON document that defines what actions are allowed or denied on which resources.
When a new IAM user is created, they have zero permissions ā they can log in but can't access any service. Policies are how you grant access.
Basic policy structure:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}]
}
| Element | What it means |
|---|---|
Effect |
Allow or Deny
|
Action |
What API operation (e.g. s3:GetObject, ec2:*) |
Resource |
Which specific resource (ARN) |
Condition |
Optional ā e.g. "only if MFA is enabled" |
Principal |
Who this applies to (used in resource-based policies) |
Critical rule:
Explicit Deny > No Policy (implicit deny) > Explicit Allow
If a Deny exists anywhere, it always wins ā even if an Allow exists too.
AmazonEC2FullAccess ā What's Inside?
The policy you explored in class. It allows:
-
ec2:*ā all EC2 actions (Describe, Start, Stop, Terminate, Launch, etc.) - Describe actions for related services (Auto Scaling, ELB, etc.)
ec2:* means every EC2 API action ā that's why it's "Full Access". More restricted policies might only allow ec2:DescribeInstances (view only) or ec2:StartInstances + ec2:StopInstances (start/stop but not delete).
Two Types of Policies
Identity-Based Policy
- Attached to a user, group, or role
- Says: "This identity can do X"
- Example: Attaching
AmazonEC2FullAccessto user tejas
Resource-Based Policy
- Attached to a resource (like an S3 bucket)
- Says: "These identities can access me"
- Example: S3 bucket policy allowing specific IAM user to read from it
- Has a
Principalfield (who can access)
How You Can Assign Permissions (3 Ways)
Method 1 ā Direct to User:
IAM User ā Attach Policy directly
ā
Quick | ā Hard to manage at scale
Method 2 ā Via Group:
IAM Group ā Attach Policy ā Add User to Group
ā
Best for teams | ā
Easy to manage
Method 3 ā Via Role (Assume):
Create Role ā User assumes Role ā Gets temp permissions
ā
Best for temporary/cross-service access
š SECTION 7 ā What is an ARN?
ARN = Amazon Resource Name
Every single resource in AWS has a unique ID called an ARN. It's like a URL but for AWS resources.
Format:
arn:aws:SERVICE:REGION:ACCOUNT-ID:RESOURCE
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-abc123 ā EC2 Instance
ARNs are used in:
- Trust relationship JSON (to say which user can assume a role)
- Resource-based policies (to target specific resources)
- CloudTrail logs (to identify what was accessed)
š„ļø SECTION 8 ā IAM Instance Profile (EC2 ā S3 Access)
"EC2 instance with EC2FullAccess wants to access S3 ā how?"
The Problem with Hardcoding Credentials
Bad approach:
# hardcoded in your code ā NEVER do this
s3 = boto3.client('s3',
aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
)
If this code goes to GitHub, your keys are exposed. Anyone can use them.
The Right Way ā IAM Instance Profile
An Instance Profile is a container that holds one IAM Role and attaches it to an EC2 instance. The EC2 instance then automatically gets temporary credentials ā no hardcoding needed.
IAM Role (S3AccessRole)
ā wrapped in
Instance Profile
ā attached to
EC2 Instance
ā app code calls
AWS Metadata Service (169.254.169.254)
ā returns
Temporary credentials (auto-rotated every hour)
ā used to
Access S3 Bucket ā
How to Set It Up
Step 1: Create IAM Role
IAM Console ā Roles ā Create Role
Trusted entity: EC2 (ec2.amazonaws.com as service principal)
Attach policy: AmazonS3FullAccess (or specific S3 policy)
Name: EC2-S3-AccessRole
Step 2: Attach to EC2 Instance
EC2 Console ā Select Instance ā Actions
ā Security ā Modify IAM Role
ā Select: EC2-S3-AccessRole ā Update
(Or set during launch: Advanced Settings ā IAM Instance Profile)
Step 3: Test from EC2
SSH into EC2 ā run: aws s3 ls
ā Lists your S3 buckets ā
(no credentials configured!)
The Instance Profile is created automatically when you create a role for EC2 via the Console ā you don't create it separately. One profile holds exactly one role.
āļø SECTION 9 ā EC2 Basics (What You Need to Know)
What is EC2?
EC2 = Elastic Compute Cloud ā it's a virtual machine (server) running on AWS hardware. When you launch an EC2 instance, you're renting a slice of a physical server in an AWS data center.
Key EC2 Terms
AMI (Amazon Machine Image)
- A pre-built template/snapshot that contains the OS + software for your EC2 instance
- Like a blueprint ā choose it once and EC2 launches with that OS ready
- Examples: Amazon Linux 2, Ubuntu 22.04, Windows Server 2022
- Free tier eligible: Amazon Linux 2 AMI or Ubuntu
Key Pair
- Used to SSH into your EC2 instance securely
- AWS generates a public-private key pair
- AWS keeps the public key, you download the private key (
.pemfile) - You use the
.pemfile to connect:ssh -i key.pem ec2-user@<ip> - Download once ā never available again. If you lose it, you lose SSH access.
Instance Type
- Defines the CPU, RAM, and network capacity of your EC2
- Free tier:
t2.micro(1 vCPU, 1 GB RAM) ort3.micro - Naming:
t3.mediumā t=family, 3=generation, medium=size
User Data (Startup Script)
- A script that runs once when EC2 first boots
- Used to auto-install software, configure servers
- Example: install Apache web server automatically on launch
#!/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
Lab: Launch EC2 as Web Server
Step 1: EC2 Console ā Launch Instance
Step 2: Choose AMI: Amazon Linux 2
Step 3: Instance type: t2.micro (free tier)
Step 4: Key pair: Create new ā Download .pem file
Step 5: Security Group: Allow HTTP (port 80) + SSH (port 22)
Step 6: Advanced ā User data ā paste startup script above
Step 7: Launch
Access: http://<EC2-Public-IP> ā "Hello from EC2!" ā
š° SECTION 10 ā AWS Pricing Calculator
Before launching anything in AWS ā estimate the cost first.
Tool: calculator.aws
How to use:
1. Go to calculator.aws ā Create estimate
2. Search for a service (e.g., EC2)
3. Choose Region (ap-south-1 for India)
4. Select instance type, OS, hours/month
5. Add storage, data transfer if needed
6. View monthly + annual estimate
7. Share or export the estimate
Why it matters for DevOps:
Before proposing any infrastructure to a client or manager, you run a cost estimate. "This architecture will cost ā¹8,000/month" is far more useful than "I think it'll be cheap."
ā” QUICK REVISION
WHY IAM
Root = total power = total risk
IAM = controlled, audited, least privilege access
AAA = Authentication + Authorization + Accounting
KEY CONCEPTS
Group ā Collection of users, attach policy once
Role ā Temporary identity, no password, assumed by user/service
Policy ā JSON doc defining Allow/Deny on which resource
ARN ā Unique ID for every AWS resource
Trust Rel ā JSON saying who can assume a role
Principal ā Service identity (ec2.amazonaws.com)
POLICY RULE
Explicit Deny > No Policy > Explicit Allow
INSTANCE PROFILE
IAM Role ā Instance Profile ā EC2 ā accesses S3
No hardcoded credentials. Auto-rotated temp creds.
EC2 BASICS
AMI = OS template/blueprint
Key Pair = SSH access (.pem file ā save it!)
User Data = startup script (runs once at boot)
t2.micro = free tier instance type
ROLE SWITCHING
Assume Role = temporarily take on role's permissions
Your original permissions are SUSPENDED during that session
Session ends = back to original
š¼ INTERVIEW QUESTIONS
Q1: What is the difference between an IAM User and an IAM Role?
A: An IAM User has permanent credentials (username + password). An IAM Role has no password ā it provides temporary credentials and is assumed by users or services. Roles are the best practice for giving AWS services access to other AWS services.
Q2: An EC2 instance needs to read files from S3. How do you set this up securely?
A: Create an IAM Role with S3 read permissions and ec2.amazonaws.com as the trusted service principal. Attach this role to the EC2 instance via an Instance Profile. The EC2 instance automatically gets temporary, rotating credentials ā no hardcoded access keys needed.
Q3: What is a Trust Relationship in IAM?
A: A Trust Relationship is a JSON policy on an IAM Role that defines who is allowed to assume that role ā whether it's a specific IAM user (via ARN) or an AWS service (like ec2.amazonaws.com).
Q4: What happens if a Deny and an Allow both exist in IAM policies for the same action?
A: Deny always wins. The evaluation order is: Explicit Deny > No Policy (implicit deny) > Explicit Allow.
Q5: What is an Instance Profile?
A: An Instance Profile is a container that wraps an IAM Role and attaches it to an EC2 instance. It allows EC2 to call AWS services using temporary credentials from the metadata service ā no hardcoded keys.
Q6: What's the difference between Identity-based and Resource-based policies?
A: Identity-based policies are attached to a user, group, or role and say "this identity can do X." Resource-based policies are attached to a resource (like S3) and say "these identities can access me." Resource-based policies have a Principal field; identity-based ones don't.
š¬ PRACTICE TASKS
- Create an IAM Group called
DevOpsTeam, attachPowerUserAccess, create a user and add to the group. Log in as that user and verify access. - Create an IAM Role for EC2 with
AmazonS3ReadOnlyAccess. Launch an EC2 instance, attach this role, SSH in, and runaws s3 lsā confirm it works without any credentials configured. - Open the
AmazonEC2FullAccesspolicy JSON in IAM Console. Identify whatec2:*means and find 3 specific actions it covers. - Create a Role, edit its Trust Relationship to allow your IAM user to assume it. Use "Switch Role" in the Console ā observe what changes.
- Use the AWS Pricing Calculator to estimate monthly cost of: 1 x t3.micro EC2 (Linux, ap-south-1, running 24/7) + 20 GB EBS storage.
Top comments (0)