IAM users, groups and roles: what’s the difference?

Every request to AWS answers two questions: who is asking, and are they allowed? IAM, AWS Identity and Access Management, handles both. Its building blocks are users, groups and roles, with policies saying what each may do. They’re easy to mix up, and exam questions are built on the differences. One idea sorts most of them out:

• A user is someone, with credentials that last until you remove them.
• A group is a list of users that share permissions. It can’t sign in.
• A role is a set of permissions that someone or something takes on for a while: whoever assumes it can do what the role allows, using credentials that expire.

Users: one person or app, long-term credentials

An IAM user is an identity inside your AWS account with its own long-term credentials:

• a password to sign in to the AWS Management Console, and/or
• access keys (an access key ID and secret) for the AWS CLI, SDKs and API.

Those credentials keep working until someone rotates or deletes them, which is exactly the risk: an access key pasted into code or a laptop’s config file can leak and stay valid for years.

That’s why AWS’s current advice is to use IAM users sparingly. People should sign in through federation, ideally AWS IAM Identity Center, and workloads should use roles. Keep IAM users for the few cases that truly need long-term credentials, and turn on MFA for any that can sign in.

The root user is different

The root user is the email address that created the account. It can do everything, including closing the account, and IAM policies can’t restrict it (only an SCP can, in an AWS Organizations member account). Protect it with MFA, give it no access keys, and use it only for the handful of tasks that require it.

Groups: permissions for many users at once

An IAM group is a collection of users. Attach a policy to the group and every member gets it; move someone to another team by changing their groups, not their policies.

• A user can belong to several groups, and gets the permissions of all of them.
• Groups can’t be nested: a group can’t contain another group.
• A group is not an identity. It can’t sign in, can’t make requests, and can’t be named as the principal in a resource policy or a role’s trust policy.

Groups only hold IAM users. People who sign in through IAM Identity Center get their permissions from permission sets there instead.

Roles: temporary credentials for whoever needs them

An IAM role has permissions but no password and no access keys. Instead, a trusted user, service or account assumes the role and gets temporary credentials from AWS STS that expire on their own, typically after an hour.

A role has two policies:

• a trust policy: who may assume it (an AWS service such as EC2 or Lambda, a user, another AWS account, or a federated identity), and
• a permissions policy: what it may do once assumed.

Roles are the answer to most “how should this get access?” questions:

• An application on EC2 gets a role through an instance profile. The SDK picks up the temporary credentials automatically, and they rotate by themselves.
• A Lambda function runs with its execution role.
• Another AWS account gets access by assuming a role you trust it to use: cross-account access without sharing keys.
• People signing in through your identity provider (SAML or OIDC) land in a role, which is how federation and IAM Identity Center work under the hood.

Policies: what anyone may actually do

Users, groups and roles start with no permissions. Policies, JSON documents of allowed or denied actions on resources, add them.

• Identity-based policies attach to a user, group or role. Resource-based policies attach to a resource, such as an S3 bucket policy, and name who may use it.
• Everything is denied by default. An allow grants access, and an explicit deny always wins over any allow.
• Service control policies (SCPs) in AWS Organizations and permissions boundaries set the maximum permissions. They never grant anything on their own.

Whatever you attach, follow least privilege: grant only what the job needs, and tighten it as you learn what’s actually used.

Side by side

Exam traps

• “An application on EC2 needs to read from S3. What’s the most secure way?” An IAM role attached through an instance profile. Never access keys in code, environment variables or the AMI.
• “Give 50 developers the same permissions and keep them in sync.” An IAM group (or a permission set in IAM Identity Center).
• “Let another AWS account access resources in this one.” A role in this account whose trust policy names the other account.
• “Employees should sign in with their existing corporate credentials.” Federation, ideally IAM Identity Center, not an IAM user per employee.
• “Prevent everyone in member accounts, administrators included, from using a Region.” A service control policy. SCPs limit; they don’t grant.
• “A user has an allow and a deny for the same action.” The explicit deny wins.
• “Secure the root user.” MFA, no access keys, and day-to-day work done as something else.

For the full details, see the IAM User Guide on IAM users, IAM groups, IAM roles, roles for applications on EC2, how policies are evaluated, the root user and security best practices.