Stop 07 · Identity & SecurityTopics · 4/10

Roles vs Users vs Groups

In short

Users, groups and roles all "have permissions", which is why people mix them up. The difference is who they belong to and how long the access lasts.

A User is a long-lived identity for a person, a Group bundles permissions for multiple users, and a Role is a temporary, assumable identity — often used by services or for cross-account access, without long-lived credentials.

A teacher clips a temporary badge onto the blob character, who already wears an ID card.

Think of it like this

ID card, section and duty badge

Your college ID card is you, always. Your section groups you with forty classmates who share a timetable. During exams, a teacher hands you an invigilator badge for three hours, then takes it back. User, group, role.

Watch it happen

Who gets permissions, and how

AWS account

Group: devs

User: priya

User: arjun

Role: app-server

EC2 instance

Role: deploy

CI pipeline

1/4Everything lives inside one account. Identities here are users and roles; groups just organise users.

The big ideas

What you need to know

User

A long-lived identity, usually one person. Can have a password and access keys. Fewer of these is better.

Group

A bag of users sharing policies. Not an identity itself: you can't log in as a group.

Role

An identity anyone trusted can put on for a while. Gives temporary credentials, usually for an hour by default.

Modern setups

Many teams skip IAM users for people and log in through SSO (IAM Identity Center), which hands out roles.

See it in code

Walk through the code

bash

1# Let an EC2 instance use a role instead of stored keys2aws iam create-role --role-name app-server \3  --assume-role-policy-document file://trust-ec2.json4 5aws iam attach-role-policy --role-name app-server \6  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess7 8# On the instance, check which identity you are9aws sts get-caller-identity

1/3Create the role. The trust policy file lists who is allowed to wear it.

trust-ec2.json says who may assume the role (here, the EC2 service). The attached policy says what the role can do.

Save yourself the pain

Common mistakes

Oops

Creating an IAM user for an app and pasting its access keys into the server.

Do this instead

Attach a role to the server. The SDK picks up short-lived credentials automatically.

Oops

Attaching policies to each user one by one.

Do this instead

Put policies on groups (or SSO permission sets). Then access changes in one place.

Your mission

Swap keys for a role

~35 min

Quick check

Your Lambda function needs to read from DynamoDB. What should it use?

Go deeper

1Create an IAM group, add a user to it, and attach a policy to the group instead of the user directly.
2Create a role and practice assuming it to perform an action.
3Learn why roles are generally preferred over long-lived access keys for service-to-service access.