IAM Explained Simply: Users, Roles, Policies and Why It Confuses Everyone

IAM is the thing every AWS beginner bounces off. It is also the thing you cannot avoid, because nothing in AWS works until IAM lets it. The confusion is not your fault: IAM has a few pieces that sound similar (users, roles, policies, groups) and the relationships between them are not obvious. Let me explain it the way I wish someone had explained it to me, with no jargon until it earns its place.

The one sentence version

IAM answers a single question for every request in your account: is this identity allowed to perform this action on this resource? Everything else is detail about how you express "this identity," "this action," and "this resource." Hold that sentence and the pieces fall into place.

The pieces, in plain terms

Identities (who is asking):

• User: a person or a long-lived thing with its own credentials. You, logging in. A user is meant for a human or a fixed program.
• Group: just a bucket of users so you can attach permissions to many people at once. "The Developers group." A group is a convenience, not an identity that acts.
• Role: the one that confuses everyone, and the most important to understand. A role is a set of permissions that anything can temporarily assume. It has no permanent credentials. An EC2 instance, a Lambda function, or a user from another account can "put on" a role and get its permissions for a short time, then take it off. Think of a role as a costume anyone approved can wear, not a person.

Permissions (what they can do):

• Policy: a JSON document that says Allow or Deny for specific actions on specific resources. Policies are where the actual permissions live. You attach policies to users, groups, or roles.

So the shape is: policies define permissions, and you attach them to identities (users, groups, roles).

Why roles are the part that clicks last

Beginners get users immediately and roles slowly, because "permissions nobody owns permanently, that things temporarily assume" is unusual. But roles are how AWS wants you to work, for a good reason: no long-lived credentials to leak.

Instead of giving your EC2 instance a stored access key (which can be stolen), you attach a role to the instance. The instance assumes the role and gets temporary credentials that rotate automatically. Same for Lambda, for cross-account access, for CI pipelines. If you find yourself creating a user and storing its keys somewhere for a machine to use, that is almost always a sign you should have used a role instead.

A tiny policy, decoded

Policies look scary and are actually simple once you see the structure:

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

Read it as a sentence: Allow the action get an S3 object on the resource any object in my-bucket. That is it. Effect (Allow/Deny), Action (what), Resource (on what). Most policies are just longer lists of these.

The two rules that resolve most confusion

1. Explicit Deny always wins. If any policy that applies to you says Deny, you are denied, no matter how many Allows exist. This is why "I have admin but still get access denied" happens, some Deny higher up (an SCP, a boundary) overrode your Allow.

2. Deny by default. If nothing explicitly Allows an action, it is denied. You do not start with everything and remove; you start with nothing and grant. This is why a brand-new user can do almost nothing until you attach a policy.

How to not shoot yourself in the foot

• Least privilege. Grant the specific actions needed, not *. It is annoying now and a relief forever. Broad permissions are how accounts become un-auditable.
• Roles for machines, users for humans (and prefer SSO even for humans). Do not store access keys for services. Attach a role.
• Use the policy simulator. Before you swear a permission is right, simulate it. AWS has a tool that tells you whether a given identity can do a given action, no guessing.
• Groups for people, not roles. Put humans in groups and attach policies to the group, so onboarding is "add to group," not "copy someone's permissions."

The take

IAM is confusing because the words overlap, not because the idea is hard. It answers one question, is this identity allowed to do this action on this resource, using policies (the permissions) attached to identities (users for humans, roles for machines and temporary access, groups for convenience). Remember that explicit Deny wins and everything is denied by default, prefer roles over stored keys, and grant least privilege, and IAM stops being the wall you bounce off.

What part of IAM took longest to click for you? For most people it is roles, the "permissions nobody owns that things temporarily wear" idea that is unlike anything else until it suddenly makes sense.