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.

Practice

1. What is the main purpose of an IAM group in AWS?

easy

A. To organize multiple IAM users and assign permissions collectively

B. To store data securely in the cloud

C. To create virtual servers for applications

D. To monitor network traffic in AWS

Solution

1. Step 1: Understand IAM user and group roles

   IAM users represent individuals or services, while groups organize these users.

2. Step 2: Identify the purpose of groups

   Groups allow assigning permissions to many users at once, simplifying management.

3. Final Answer:

   To organize multiple IAM users and assign permissions collectively -> Option A

4. Quick Check:

   IAM groups = organize users + assign permissions [OK]

Hint: Groups bundle users for easy permission management [OK]

Common Mistakes:

• Confusing groups with storage or servers
• Thinking groups monitor network traffic
• Believing groups are individual user accounts

2. Which of the following is the correct way to add an IAM user named alice to a group named Developers using AWS CLI?

easy

A. aws iam add-group-to-user --group-name Developers --user-name alice

B. aws iam attach-user-policy --user-name alice --policy-name Developers

C. aws iam add-user-to-group --user-name alice --group-name Developers

D. aws iam create-group --group-name Developers --user alice

Solution

1. Step 1: Recall AWS CLI command for adding user to group

   The correct command is aws iam add-user-to-group with parameters --user-name and --group-name.

2. Step 2: Match command syntax with options

   aws iam add-user-to-group --user-name alice --group-name Developers matches the correct syntax exactly.

3. Final Answer:

   aws iam add-user-to-group --user-name alice --group-name Developers -> Option C

4. Quick Check:

   Correct CLI command = aws iam add-user-to-group --user-name alice --group-name Developers [OK]

Hint: Use 'add-user-to-group' command with user and group names [OK]

Common Mistakes:

• Using 'attach-user-policy' instead of adding to group
• Confusing 'create-group' with adding users
• Reversing user and group parameters

3. Given the following IAM group policy attached to group Admins:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}

If user bob is added to the Admins group, what permissions does bob have on S3?

medium

A. Full access to all S3 actions and resources

B. Read-only access to S3 buckets

C. No access to S3 unless user policy allows it

D. Access only to S3 buckets created by bob

Solution

1. Step 1: Analyze the group policy permissions

   The policy allows all S3 actions (s3:*) on all resources (*), meaning full access.

2. Step 2: Understand group membership effect

   User bob inherits all permissions from the Admins group.

3. Final Answer:

   Full access to all S3 actions and resources -> Option A

4. Quick Check:

   Group policy allows s3:* on * = full access [OK]

Hint: s3:* on * means full S3 access [OK]

Common Mistakes:

• Assuming user needs separate policy for access
• Thinking group policies restrict to created buckets
• Confusing read-only with full access

4. You tried to add user carol to group Managers using this command:

aws iam add-user-to-group --group-name Managers --user carol

But it failed. What is the error in this command?

medium

A. The command should be 'aws iam add-group-to-user' instead

B. The parameter should be --user-name, not --user

C. The group name should be specified after --user-name

D. The user name must be in quotes

Solution

1. Step 1: Check AWS CLI command syntax

   The correct parameter for specifying the user is --user-name, not --user.

2. Step 2: Identify the error in the command

   Using --user causes the command to fail because it is invalid.

3. Final Answer:

   The parameter should be --user-name, not --user -> Option B

4. Quick Check:

   Correct parameter = --user-name [OK]

Hint: Use --user-name, not --user, for specifying IAM user [OK]

Common Mistakes:

• Using incorrect parameter names
• Swapping user and group parameters
• Adding unnecessary quotes around names

5. You want to create a secure setup where users in the Developers group can only start and stop EC2 instances, but not terminate them. Which IAM policy snippet attached to the group achieves this?

hard

A. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances"],
"Resource": "*"
}]
}

B. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
}]
}

C. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "ec2:TerminateInstances",
"Resource": "*"
}]
}

D. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ec2:StartInstances", "ec2:StopInstances"],
"Resource": "*"
}]
}

Solution

1. Step 1: Understand required permissions

   Users should only start and stop instances, so allow only those actions.

2. Step 2: Evaluate policy options

   { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:StartInstances", "ec2:StopInstances"], "Resource": "*" }] } allows only StartInstances and StopInstances. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }] } allows all EC2 actions, including terminate. { "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "Action": "ec2:TerminateInstances", "Resource": "*" }] } denies terminate but does not allow start/stop explicitly. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances"], "Resource": "*" }] } allows terminate, which is not desired.

3. Final Answer:

   Policy allowing only start and stop EC2 instances -> Option D

4. Quick Check:

   Allow only start/stop, no terminate = { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:StartInstances", "ec2:StopInstances"], "Resource": "*" }] } [OK]

Hint: Allow only needed actions, avoid wildcard ec2:* [OK]

Common Mistakes:

• Using ec2:* allows unwanted terminate action
• Only denying terminate without allowing start/stop
• Including terminate in allowed actions