IAM Users, Groups, and Roles: Who Can Do What on AWS

The problem this concept solves

Imagine a group project where everyone shares one login. Someone deletes a file and nobody knows who. A teammate graduates and still has access. A new member needs to get in, so you text the password around again.

Now imagine that instead of a shared document, it is a company's AWS account holding customer data and running the systems that generate revenue. AWS Identity and Access Management (IAM) is the service that prevents that situation. It answers one question continuously: is this specific request, from this specific identity, allowed?

What it means in plain English

IAM controls authentication (who are you?) and authorization (what are you allowed to do?). It is free to use and available globally rather than per Region.

Nothing in IAM has permissions on its own. Access comes from policies — JSON documents that specify:

• Actions: what may be done, such as reading an object or terminating an instance.
• Resources: what it may be done to, such as one specific S3 bucket.
• Effect: allow or deny.
• Conditions: optional constraints, such as requiring MFA or a particular source network.

The default is deny. If no policy grants an action, it is not permitted, and an explicit deny always overrides an allow.

The three identity types

IAM users

An IAM user represents one person or one long-lived application. Users have long-term credentials: a password for console sign-in, and optionally access keys for programmatic use. Because those credentials persist until you rotate or delete them, they carry ongoing risk and should be protected with MFA.

IAM groups

A group is a collection of users that exists purely to simplify permission management. You attach a policy to the group, and every member inherits it. Add someone to "Developers" and they receive developer access; remove them and it goes away.

Two details the exam likes: a group is not an identity — you cannot make a group the actor in a policy — and groups cannot be nested inside other groups.

IAM roles

A role is a set of permissions that can be assumed temporarily. A role has no password and no permanent credentials. When an identity assumes a role, AWS issues temporary security credentials that expire automatically.

This is the safer pattern, and it is the answer to a large share of exam questions. Common uses:

• AWS services acting on your behalf. An EC2 instance or Lambda function assumes a role to reach S3 or write logs — no keys stored in your code.
• Cross-account access. Account B defines a role that trusts identities from Account A, so no one has to create duplicate users.
• Federation. People sign in with an existing corporate or university identity provider and assume a role in AWS. No second password to manage.

IAM Identity Center

AWS IAM Identity Center (formerly AWS Single Sign-On) is the recommended way to manage human access at scale, particularly across multiple AWS accounts. People sign in once through a central directory and receive temporary credentials for the accounts and permission sets they are entitled to.

Least privilege

The principle of least privilege means granting only the permissions required to do a job, and nothing more. The direction matters: you start from nothing and add what is needed, rather than starting with administrator access and trimming later.

Hypothetical scenario: A campus web team runs a class project on AWS. Each student gets an IAM user with MFA enabled, placed in a "Students" group that allows managing only the project's S3 bucket. The application itself runs on EC2 and uses an IAM role to write uploads to that bucket, so no access keys are ever pasted into the source code. When a student finishes the course, removing them from the group revokes their access instantly.

Do not confuse these concepts

• User: A permanent identity with long-term credentials, meant for a specific person or application.
• Group: A container for users that simplifies assigning permissions. Not an identity itself.
• Role: A temporary identity that is assumed, granting short-lived credentials. Best for AWS services, cross-account access, and federation.
• Policy: The document that defines permissions. It is attached to users, groups, or roles — it is not an identity.

Quick recall

	IAM user	IAM group	IAM role
Is it an identity?	Yes	No — a container	Yes, when assumed
Credentials	Long-term password and/or access keys	None	Temporary, auto-expiring
Typical holder	A person, or a long-lived app	N/A	An AWS service, another account, a federated user
Best for	Individual human access	Managing permissions in bulk	Anything short-lived or automated

Term	One-line meaning
Policy	JSON defining allowed actions, resources, and conditions
Managed policy	Reusable policy, AWS-provided or customer-created
Inline policy	Policy embedded in a single identity, not reusable
Least privilege	Grant only what is needed, starting from nothing
MFA	A second authentication factor beyond the password
Federation	Using an external identity provider to access AWS
IAM Identity Center	Central single sign-on across multiple AWS accounts

Key takeaways

• Permissions in AWS come from policies; users, groups, and roles are just what those policies attach to, and the default is always deny.
• Users carry long-term credentials, groups exist to manage permissions in bulk, and roles provide temporary credentials for services, cross-account access, and federation.
• Least privilege means starting from no access and adding only what is necessary — and roles are preferred over long-lived access keys wherever possible.

Check your understanding

1. An application on an EC2 instance needs to read files from an S3 bucket. What is the recommended way to grant that access, and why?
2. What is the practical difference between an IAM user and an IAM role?
3. Why would an organization use IAM Identity Center instead of creating IAM users in every account?

Suggested answers

1. Attach an IAM role to the EC2 instance. The instance receives temporary credentials that rotate automatically, so no long-term access keys need to be stored on the server or in the application's code, where they could be leaked.
2. An IAM user is a permanent identity with long-term credentials, intended for a specific person or application. A role has no permanent credentials and is assumed temporarily, granting short-lived credentials that expire — which makes it the safer choice for services, cross-account access, and federated sign-in.
3. IAM Identity Center provides central single sign-on across many AWS accounts, so people authenticate once through one directory and receive temporary credentials. Creating separate IAM users in every account multiplies long-term credentials and makes removing someone's access slow and error-prone.

Continue learning

• IAM security best practices – AWS
• What is AWS IAM Identity Center? – AWS