Managing Permissions with AWS IAM. Here's What I Learnt

So I recently worked on a project where I had to set up and manage permissions using AWS IAM, and honestly? It was one of those things that sounds intimidating at first but starts to click once you actually get your hands dirty with it.

In this post, I'll walk you through exactly what I did, setting up policies, creating users and groups, tagging EC2 instances, and testing whether the permissions actually worked. Let's get into it.

First Things First, What Even Is AWS IAM?

IAM stands for Identity and Access Management. It's a web service from AWS that lets you control who can access what in your AWS account.

Think of it like this: you're the admin of an office building. Some people should be able to enter every room, some only specific ones, and some shouldn't get past the lobby. IAM is basically your access-card system; you decide who gets in and where, and you can change that at any time.

For this project, I used IAM to:

• Create EC2 instances
• Manage users and groups
• Assign permissions to allow or deny access to resources

Setting Up EC2 Instances with Tags

Before touching IAM, I spun up two EC2 instances to use as test subjects. One for production, one for development.

To tell them apart (and to make the IAM policy work properly), I tagged them. Tags in AWS are key-value labels you attach to resources. They're useful for organising things, tracking costs, and, in our case, building conditions into policies.

The tag I used was Env, and I gave each instance a different value:

Instance	Tag Key	Tag Value
project-production-sristi	Env	production
project-development-sristi	Env	development

Simple, but this small detail becomes really important when we write the policy.

Writing the IAM Policy

This is where things get interesting. An IAM Policy is a set of rules written in JSON that tells AWS what actions are allowed or denied, on which resources, and under what conditions.

Here's the policy I wrote:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Env": "development"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:DeleteTags",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    }
  ]
}

Let me break down what each part does:

• Statement 1 — Allows all EC2 actions (ec2:*), but only on instances where the Env tag equals development. So anything tagged as production? Off limits.
• Statement 2 — Allows the user to describe (basically, view) EC2 resources. Without this, the user wouldn't even be able to see what instances exist.
• Statement 3 — Explicitly denies the ability to create or delete tags. This is important — you don't want users messing with the very tags that control their own permissions. That would be a bit of a security hole.

Three key things you always define in a policy statement:

• Effect — Allow or Deny
• Action — What operation you're allowing/denying (like stopping an instance, describing resources, etc.)
• Resource — Which AWS resource this applies to (* means all)

Creating an Account Alias

Small but useful thing, I set up an AWS Account Alias. Instead of sharing a URL with a long numeric account ID, you can create a friendly name for your account.

My sign-in URL went from something like 738565xxxxx.signin.aws.amazon.com/console to:

https://project-alias-sristi.signin.aws.amazon.com/console

Much cleaner to share with new users. And don't worry, IAM users can still use the original account ID URL if needed.

Creating a User Group + IAM User

Next up, creating a User Group and adding a user to it.

Why use groups instead of attaching policies directly to users?

Imagine you have 20 developers. If you attach permissions to each user individually, managing that becomes a nightmare, especially when something changes. With a group, you set the policy once, and every user in that group inherits it automatically. Way more scalable.

Here's what I set up:

• User Group: dev-group — I attached the policy I created to this group
• IAM User: dev-sristi — Added to dev-group

When creating the user, I ticked the option to allow console access. Once the user was created, AWS gave me two ways to share the credentials:

1. Email the sign-in instructions directly
2. Download a .csv file with the username and password

My Sign In user credentials

Testing It Out: IAM Policies in Action

This is the fun part. I logged into the AWS console as the new IAM user (dev-sristi) and immediately noticed the difference. The dashboard looked different from the root account, with lots of "Access Denied" errors across various panels like cost, security, and applications. That's expected. The user only has EC2-related permissions, nothing else.

Then I tested the actual policy by trying to stop both instances:

Stopping the Production Instance

Got a big red error banner. The user wasn't authorised to perform ec2:StopInstances on the production instance. The policy blocked it because the Env tag on that instance was production, not development.

Stopping the Development Instance

Green banner. "Successfully initiated stopping." The policy allowed it because the instance had Env: development exactly what the condition in the policy was looking for.

It worked exactly as intended. Honestly, pretty satisfying to see it play out in real time.

Summary: What I Built

Here's a quick recap of everything that was set up:

Component	Name	Purpose
IAM User Group	dev-group	Holds the permissions policy
IAM User	dev-sristi	Member of dev-group
EC2 Instance	project-development-sristi	Tag: Env=development
EC2 Instance	project-production-sristi	Tag: Env=production
IAM Policy	SristiDevEnvironmentPolicy	Allow dev access, deny prod

Key Takeaways

A few things I came away from this project understanding a lot better:

IAM Policies are how you define rules for what's allowed, what's denied, and on what resources. Writing them in JSON gives you a lot of flexibility, especially when you add conditions like tag-based access.

Account Aliases are a small quality-of-life thing but are really useful when onboarding new users. Nobody wants to memorise a 12-digit account ID.

IAM Users vs User Groups — attaching policies directly to users works, but using groups is the better practice. It's cleaner and much easier to manage at scale.

Tags aren't just for organisation — they can actually drive your security policies. That Env tag was the entire reason the permission logic worked. One tag value meant full access, another meant denied.

Testing is everything. Writing the policy is one thing; actually logging in as the user and seeing what they can and can't do is how you know it works.

If you're just getting started with AWS, IAM is one of the first things worth learning properly. Messing up permissions is one of the most common ways things go wrong in cloud environments, and understanding IAM gives you real control over who can do what in your account.

Give it a try, break things in a dev environment, and see what happens. That's honestly the best way to learn it.