AWS 🔐 IAM Basics: Users, Groups, Roles & Policies

🎯 Target Audience: Beginners in DevOps & DevSecOps
🧠 Key Concepts: IAM Users, Groups, Roles, Policies, Least Privilege
⏱ Estimated Read Time: ~9 minutes
📚 Series: Part of “AWS & Cloud Computing for DevOps Beginners”
🌍 Real-World Focus: Securing access & automation in AWS

Why IAM Matters in DevOps

Imagine AWS as a huge airport ✈️.
EC2 = airplanes, S3 = hangars, RDS = control towers…

Now, who decides who gets into which area? That’s IAM (Identity & Access Management).

Without IAM, AWS would be like an airport without security gates. Total chaos 😅.

As a DevOps engineer, IAM is your first line of defense: it’s where DevOps meets DevSecOps.

1️⃣ IAM Users → People with Access

An IAM User = an actual person (or sometimes a bot) who needs to log in.

Example:

• A Developer who needs to pull artifacts from S3.

• Ops engineer who deploys to EC2.

Command Line Example:

aws iam create-user --user-name devops_engineer

⚠️ Mistake to Avoid: Don’t use the root AWS account for daily tasks. Create IAM users with just the permissions they need.

2️⃣ IAM Groups → Teams, Not Individuals

Groups = collections of users with the same permissions.

Example:

• Developers group → read-only access to logs.

• Admins group → elevated permissions.

This way, instead of editing 10 user accounts, you update the group once.

Quick Command Example:

aws iam create-group --group-name Developers
aws iam add-user-to-group --user-name devops_engineer --group-name Developers

👉 Real-World Use Case: Onboarding a new junior DevOps → just add them to the right group. Done ✅.

3️⃣ IAM Roles → Temporary Permission Jackets

Roles are like uniforms 👔. You “wear” them to temporarily get permissions.

• EC2 instance role → allows EC2 to pull from S3.

• Lambda role → lets your function write logs to CloudWatch.

The beauty? No hardcoding AWS keys.
Instead, AWS hands out temporary credentials behind the scenes.

Example: Attach role to EC2

aws iam create-role --role-name S3AccessRole \
  --assume-role-policy-document file://trust-policy.json

👉 DevSecOps Tip: Always prefer roles over static keys.

4️⃣ IAM Policies → The Rulebook

Policies = JSON documents that spell out who can do what.

Example policy to allow read-only S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::mybucket/*"]
    }
  ]
}

Attach this to a user, group, or role, and they’ll only have read access.

👉 Real-World Example: Your CI/CD pipeline role only needs s3:GetObject and ec2:DescribeInstances — not AdministratorAccess.

Common Mistakes to Avoid

⚠️ Giving AdministratorAccess to everyone → recipe for disaster.
⚠️ Using root account for automation → never.
⚠️ Leaving old users active after offboarding → security hole.
⚠️ Hardcoding AWS keys in GitHub repos → huge 🚨.

Quick Recap

• 

  IAM Users → individual accounts.

• IAM Groups → manage teams efficiently.

• IAM Roles → temporary access for apps/services.

• IAM Policies → JSON rules for permissions.

Master IAM early = you build secure pipelines and sleep better at night 😴.

IAM might look “basic,” but it’s the backbone of AWS security.
Next up: AWS Management Console vs CLI vs SDK: What DevOps Engineers Should Use.

👉 Question for you: Have you ever seen someone accidentally leave AdministratorAccess on a user? What happened? 😅

👨‍💻 Written by: Abdulrahman A. Muhamad
🌐 LinkedIn | GitHub | Portfolio