IAM users and groups in AWS - Deep Dive

Overview - IAM users and groups

What is it?

IAM users and groups are ways to manage who can access your AWS resources. A user represents a person or service that needs access. Groups are collections of users that share the same permissions. This helps organize and control access easily.

Why it matters

Without users and groups, managing access to cloud resources would be chaotic and risky. Anyone could access anything, leading to security breaches or accidental damage. Users and groups let you give the right people the right access, keeping your cloud safe and organized.

Where it fits

Before learning IAM users and groups, you should understand basic cloud concepts and AWS accounts. After this, you can learn about IAM roles, policies, and permissions to control access more finely.

Mental Model

Core Idea

IAM users are individual identities, and groups are collections of these identities to share permissions easily.

Think of it like...

Think of a company where each employee has an ID card (user), and departments (groups) have shared access to certain rooms. Instead of giving each employee a separate key, the department key opens all needed rooms for everyone in that group.

┌─────────────┐       ┌─────────────┐
│   IAM User 1│──────▶│   Group A   │
├─────────────┤       ├─────────────┤
│   IAM User 2│──────▶│             │
├─────────────┤       │ Permissions │
│   IAM User 3│──────▶│  (Access)   │
└─────────────┘       └─────────────┘

Build-Up - 7 Steps

1

Foundation

What is an IAM User

Concept: IAM user represents a single identity that can access AWS resources.

An IAM user is like a person’s account in AWS. It has a name and credentials like a password or access keys. This user can be given permissions to do things like start servers or read files.

Result

You can create a user and give it a password or keys to log in and use AWS services.

Understanding that users are individual identities helps you control who exactly can do what in your cloud.

2

Foundation

What is an IAM Group

Concept: IAM group is a collection of users that share the same permissions.

Instead of assigning permissions to each user one by one, you put users into groups. Then you assign permissions to the group. All users in that group get those permissions automatically.

Result

You can manage permissions for many users at once by changing the group’s permissions.

Knowing groups simplify permission management saves time and reduces errors.

3

Intermediate

Assigning Permissions to Groups

🤔Before reading on: do you think permissions assigned to a group apply to all users in that group? Commit to your answer.

Concept: Permissions attached to groups automatically apply to all users in those groups.

When you attach a policy (a set of permissions) to a group, every user in that group inherits those permissions. For example, if Group A can read files, all users in Group A can read files.

Result

Users gain permissions through their group memberships without needing individual policies.

Understanding inheritance of permissions through groups is key to scalable access control.

4

Intermediate

Users Can Belong to Multiple Groups

🤔Before reading on: do you think a user in two groups gets combined permissions from both? Commit to your answer.

Concept: A user can be in many groups and gets all permissions from all those groups combined.

If User1 is in Group A (read access) and Group B (write access), User1 can both read and write. AWS combines all permissions from all groups a user belongs to.

Result

Users can have flexible access by joining multiple groups.

Knowing permissions combine helps design flexible and precise access setups.

5

Intermediate

Users Can Have Individual Permissions

🤔Before reading on: do you think users can have permissions separate from their groups? Commit to your answer.

Concept: Users can have their own permissions in addition to group permissions.

Besides group permissions, you can attach policies directly to users. This lets you customize access for special cases without changing groups.

Result

Users get permissions from both groups and their own policies.

Understanding this lets you handle exceptions without complicating group structures.

6

Advanced

Best Practices for Users and Groups

🤔Before reading on: do you think giving users direct permissions is better than using groups? Commit to your answer.

Concept: Using groups for permissions is safer and easier to manage than assigning permissions directly to users.

Experts recommend assigning permissions mainly to groups, not individual users. This reduces mistakes and makes audits simpler. Direct user permissions should be rare and well documented.

Result

Your access control is easier to maintain and less error-prone.

Knowing this prevents common security mistakes and simplifies long-term management.

7

Expert

How IAM Users and Groups Work Internally

🤔Before reading on: do you think AWS stores permissions only on users or also on groups? Commit to your answer.

Concept: AWS stores policies separately and evaluates combined permissions at request time.

When a user tries to do something, AWS checks all policies attached to the user and their groups. It merges these permissions and decides if the action is allowed. This evaluation happens every time, ensuring up-to-date access control.

Result

Permissions are dynamic and reflect current policies without needing manual updates.

Understanding this evaluation process explains why changes to groups affect users immediately.

Under the Hood

AWS IAM stores users, groups, and policies as separate entities. Policies are JSON documents defining allowed or denied actions. When a user makes a request, AWS collects all policies attached to the user and their groups, merges them, and evaluates if the request is allowed. This happens in real-time, ensuring permissions are always current.

Why designed this way?

Separating users, groups, and policies allows flexible and scalable permission management. It avoids duplicating policies for each user and supports complex permission combinations. This design balances security, ease of management, and performance.

┌─────────────┐       ┌─────────────┐       ┌───────────────┐
│   IAM User  │──────▶│   Group(s)  │──────▶│   Policies    │
│             │       │             │       │ (JSON rules)  │
└─────────────┘       └─────────────┘       └───────────────┘
        │                    │                    ▲
        │                    └────────────────────┘
        └─────────────────────────────────────────────▶
                      Permission Evaluation Engine

Myth Busters - 4 Common Misconceptions

Quick: Do users automatically get permissions from groups they are not part of? Commit to yes or no.

Common Belief: Users get permissions from all groups in the account.

Reality: Users only get permissions from groups they belong to, not from all groups.

Why it matters: Assuming users get all group permissions can lead to overestimating access and creating security holes.

Quick: Can a user’s direct permissions override a group’s deny policy? Commit to yes or no.

Common Belief: User permissions always override group permissions.

Reality: Explicit deny in any policy (user or group) always blocks access, overriding allows.

Why it matters: Misunderstanding deny rules can cause unexpected access denials or security risks.

Quick: Do groups have passwords or login credentials? Commit to yes or no.

Common Belief: Groups can log in like users because they have credentials.

Reality: Groups are only containers for users and do not have credentials or login ability.

Why it matters: Thinking groups can log in leads to confusion about access control and user management.

Quick: Does assigning permissions directly to users always make management easier? Commit to yes or no.

Common Belief: Direct user permissions are simpler than using groups.

Reality: Direct permissions to users increase complexity and risk of errors compared to group-based management.

Why it matters: Ignoring group-based management can cause permission sprawl and harder audits.

Expert Zone

1

Group membership changes take effect immediately because permissions are evaluated at request time, not cached.

2

Policies attached to groups and users are merged, but explicit deny always overrides allow, which can cause subtle permission conflicts.

3

Users without any permissions (no policies attached and no group membership) cannot access anything, even if the AWS account owner.

When NOT to use

Avoid assigning permissions directly to users except for rare exceptions. Instead, use IAM roles for temporary access or service accounts for automated processes. For large organizations, consider AWS Organizations and SCPs for broader control.

Production Patterns

In production, teams create groups by job function (e.g., Developers, Admins) and assign policies accordingly. Users are added or removed from groups as roles change. Direct user policies are minimized. Automation scripts manage group memberships and policies to ensure consistency.

Connections

Role-Based Access Control (RBAC)

IAM users and groups implement RBAC principles in cloud security.

Understanding IAM groups as roles helps grasp how access control models work across IT systems.

Unix User and Group Permissions

Similar concept of users and groups controlling access to files and resources.

Knowing Unix permissions clarifies how grouping users simplifies permission management in AWS.

Organizational Hierarchies in Management

Groups reflect organizational units, mirroring how companies assign responsibilities.

Seeing IAM groups as departments helps design access aligned with real-world team structures.

Common Pitfalls

#1 Assigning permissions directly to many users instead of using groups.

Wrong approach:

Attach policies individually to each user for similar access needs.

Correct approach:

Create a group with the needed permissions and add users to that group.

Root cause:

Misunderstanding that groups simplify permission management leads to duplicated effort and errors.

#2 Assuming removing a user from a group does not immediately revoke permissions.

Wrong approach:

Wait hours or restart services expecting permissions to update.

Correct approach:

Know that permission changes apply instantly upon group membership change.

Root cause:

Not knowing AWS evaluates permissions in real-time causes confusion about access delays.

#3 Believing groups can log in or have credentials.

Wrong approach:

Trying to create login credentials for a group.

Correct approach:

Only users have credentials; groups are just permission containers.

Root cause:

Confusing groups with users leads to incorrect access management.

Key Takeaways

IAM users represent individual identities that need access to AWS resources.

IAM groups are collections of users that share permissions, simplifying access management.

Permissions assigned to groups automatically apply to all their users, enabling scalable control.

Users can belong to multiple groups and also have individual permissions, which combine to define their access.

Best practice is to assign permissions mainly to groups, not directly to users, to reduce errors and ease management.