██FR█████ █INTELL███████████

🔐 Hands-On with AWS IAM: Users, Groups, and Policies in Action


This content originally appeared on DEV Community and was authored by Chioma Nwosu

AWS Identity & Access Management (IAM)<br>
Cloud platforms are powerful, but with great power comes great responsibility — especially when it comes to ‘who has access to what’. Recently, I completed a guided lab on “AWS Identity and Access Management (IAM)”, and I want to share what I learned with other builders in the community.

🌍 Why IAM Matters

IAM is AWS’s way of managing identities (users) and their permissions.

  • Users by default have no access.
  • Permissions are granted through policies.
  • Groups make it easier to assign policies to multiple users at once.

This lab reinforced the ‘principle of least privilege’ — always give just enough permissions to get the job done.

🛠 Lab Breakdown

The lab gave me:

*3 users: user-1, user-2, user-3
*3 groups:

  • S3-Support → AmazonS3ReadOnlyAccess (managed policy)
  • EC2-Support → AmazonEC2ReadOnlyAccess (managed policy)
  • EC2-Admin → Custom inline policy

Here’s an example of the inline policy for EC2-Admin:

json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“ec2:DescribeInstances”,
“ec2:StartInstances”,
“ec2:StopInstances”
],
“Resource”: “*”
}
]
}

This policy allows admins to view, start, and stop EC2 instances.

👥 Assigning Users to Roles

I assigned each user based on their job function:

  • user-1 → S3-Support (read-only S3 access)
  • user-2 → EC2-Support (read-only EC2 access)
  • user-3 → EC2-Admin (can start/stop EC2 instances)

🔑 Testing Permissions

This was the fun part — logging in as each user via the IAM sign-in URL.

  • user-1: Could browse S3 buckets ✅ but denied in EC2 ❌
  • user-2: Could view EC2 instances ✅ but couldn’t stop them ❌, no S3 access ❌
  • user-3: Could view/start/stop EC2 ✅

Seeing the difference in permissions really drove home how IAM boundaries work.

💡 Key Takeaways

  1. Start with zero access – AWS gives nothing until you explicitly allow it.
  2. Groups > Direct permissions – Easier to scale as teams grow.
  3. Managed vs Inline Policies – Managed = reusable; Inline = custom-fit.
  4. Always test – what’s in the JSON doesn’t always feel real until you log in as the user.
  5. Least Privilege is real – This isn’t just theory; IAM enforces it strictly.

🚀 Why It Matters for Devs

As developers, we often focus on building apps and services. But in the cloud, ‘who has permission to deploy, read, or stop resources’ can make or break a system.

This lab reminded me that IAM isn’t “just an admin’s job” — developers need to understand it too, especially if you’re working in teams or deploying production workloads.

✅ Final Thoughts

This IAM lab was a practical way to see how access control works in AWS. Instead of reading docs, I actually lived through what happens when users have too much, too little, or just the right amount of access.

👉 Question for the DEV community:
Do you usually stick with AWS managed policies for simplicity, or do you create custom inline policies for fine-grained control?

If you found this useful, follow me here on DEV — I’ll be sharing more hands-on AWS learning journeys.

#AWS #Cloud #IAM #Security #DevOps


This content originally appeared on DEV Community and was authored by Chioma Nwosu