IAM users, groups, and roles

IAM Users, Groups, and Roles - Complete Guide for AWS Solutions Architect Professional

Why IAM Users, Groups, and Roles Are Important

Identity and Access Management (IAM) forms the foundation of security in AWS. Understanding IAM users, groups, and roles is critical because:

• Every interaction with AWS requires authenticated and authorized identities
• Proper IAM design prevents security breaches and unauthorized access
• Organizations need scalable identity management for hundreds or thousands of users
• Cross-account access and federated identity scenarios are common in enterprise environments
• The AWS Solutions Architect Professional exam heavily tests organizational complexity scenarios involving IAM

What Are IAM Users, Groups, and Roles?

IAM Users
IAM users are identities that represent a person or application that interacts with AWS. Each user has:
• A unique name within the AWS account
• Security credentials (password for console access, access keys for programmatic access)
• Permissions defined through attached policies
• A hard limit of 5,000 users per AWS account

IAM Groups
IAM groups are collections of IAM users that share the same permissions. Key characteristics:
• Groups can only contain users, not other groups
• A user can belong to multiple groups (up to 10)
• Groups cannot be used as principals in resource-based policies
• There is a limit of 300 groups per account
• Groups simplify permission management at scale

IAM Roles
IAM roles are identities with specific permissions that can be assumed by trusted entities. Roles:
• Do not have long-term credentials (passwords or access keys)
• Provide temporary security credentials when assumed
• Can be assumed by IAM users, AWS services, applications, or federated users
• Are essential for cross-account access scenarios
• Support trust policies that define who can assume the role

How IAM Users, Groups, and Roles Work

Authentication and Authorization Flow

1. Authentication: The principal (user, role, or federated identity) proves their identity to AWS
2. Authorization: AWS evaluates all applicable policies to determine if the requested action is allowed
3. Policy Evaluation: AWS checks identity-based policies, resource-based policies, permissions boundaries, SCPs, and session policies

IAM Users in Practice

Users authenticate using:
• Username and password (console access)
• Access key ID and secret access key (CLI and API access)
• MFA tokens for additional security

Best practices include:
• Never use the root user for daily tasks
• Enable MFA for all users
• Rotate credentials regularly
• Follow the principle of least privilege

IAM Groups in Practice

Groups enable efficient permission management:
• Create groups based on job functions (Developers, DBAs, Admins)
• Attach policies to groups rather than individual users
• When employees change roles, move them between groups
• Use multiple groups to create layered permissions

IAM Roles in Practice

Roles consist of two key policies:
• Trust Policy: Defines which principals can assume the role
• Permissions Policy: Defines what actions the role can perform

Common role use cases:
• EC2 instance roles for applications running on EC2
• Cross-account access between AWS accounts
• Federation with external identity providers (SAML, OIDC)
• AWS service roles (Lambda execution roles, ECS task roles)
• Break-glass roles for emergency access

Assuming Roles

When a principal assumes a role:
1. The principal calls AWS STS AssumeRole API
2. STS validates the request against the trust policy
3. STS returns temporary credentials (access key, secret key, session token)
4. Credentials are valid for a configurable duration (15 minutes to 12 hours)
5. The principal uses these credentials to make AWS API calls

Cross-Account Access Patterns

Resource-Based Policies vs. Role-Based Access

For cross-account scenarios, you have two options:

1. Resource-Based Policies:
• Attach a policy to the resource granting access to the external account
• The principal retains their original permissions plus the granted permissions
• Supported by S3, SNS, SQS, Lambda, and some other services

2. Role-Based Access:
• Create a role in the target account with a trust policy allowing the source account
• The principal assumes the role and temporarily gives up their original permissions
• Works with all AWS services

When to Use Each Approach

Use resource-based policies when:
• You need to retain original permissions while accessing the resource
• The service supports resource-based policies
• You want simpler configuration for specific resources

Use role-based access when:
• You need access to multiple services in another account
• The service does not support resource-based policies
• You want centralized permission management in the target account

Federation Scenarios

SAML 2.0 Federation
• Integrates with enterprise identity providers (Active Directory, Okta)
• Users authenticate with the IdP and receive SAML assertion
• SAML assertion is exchanged for temporary AWS credentials
• Commonly used for console access via SSO

Web Identity Federation
• For applications authenticating users via social identity providers
• Users authenticate with providers like Amazon, Google, or Facebook
• Application exchanges tokens for AWS credentials via STS
• Amazon Cognito simplifies this process and is recommended

AWS IAM Identity Center (formerly AWS SSO)
• Centralized access management for multiple AWS accounts
• Integrates with AWS Organizations
• Supports external identity providers or built-in directory
• Recommended approach for enterprise SSO to AWS

Permission Boundaries

Permission boundaries set the maximum permissions an IAM entity can have:
• They do not grant permissions themselves
• Effective permissions are the intersection of identity-based policies and permission boundaries
• Useful for delegating user creation while limiting the permissions those users can have
• Applied to users and roles, not groups

Exam Tips: Answering Questions on IAM Users, Groups, and Roles

Key Concepts to Remember

1. Users vs. Roles: If the question mentions applications on EC2 needing AWS access, always choose instance roles over access keys stored on the instance

2. Cross-Account Access: When asked about cross-account scenarios, determine if the user needs to retain their original permissions. If yes, use resource-based policies. If not, or if the service does not support them, use roles

3. Scalability Limits: Remember the 5,000 user limit per account. For scenarios with more users, federation is required

4. Groups Cannot Be Principals: If an answer option suggests using a group as a principal in a resource-based policy, it is incorrect

5. Temporary Credentials Are Preferred: AWS best practices favor temporary credentials (roles) over long-term credentials (access keys)

Common Exam Scenarios

Scenario 1: Large Enterprise with Existing Active Directory
• Solution: SAML 2.0 federation or AWS IAM Identity Center
• Key point: Users do not need IAM user accounts created

Scenario 2: Application on EC2 Accessing S3
• Solution: IAM role attached to EC2 instance
• Key point: Never embed access keys in application code or on instances

Scenario 3: Lambda Function in Account A Accessing DynamoDB in Account B
• Solution: Create a role in Account B that trusts Account A, Lambda assumes this role
• Alternative: Resource-based policy on DynamoDB table (if supported)

Scenario 4: Contractor Needs Temporary Access
• Solution: Create IAM user with MFA, set password expiration, or use federation
• Key point: Follow principle of least privilege

Scenario 5: Delegating IAM Administration
• Solution: Use permission boundaries to limit what administrators can grant
• Key point: Permission boundaries prevent privilege escalation

Red Flags in Answer Options

• Storing access keys in environment variables on EC2 - use instance roles instead
• Creating IAM users for applications - use roles for service accounts
• Using root user credentials - never correct except for specific root-only tasks
• Sharing IAM user credentials between people - create individual users
• Embedding credentials in code - use roles or secrets management

Best Practices to Know

• Enable MFA for all human users, especially privileged accounts
• Use IAM roles for all machine identities
• Implement least privilege access
• Use AWS Organizations SCPs for preventive guardrails
• Prefer AWS IAM Identity Center for enterprise SSO
• Use permission boundaries when delegating IAM administration
• Regularly review and rotate credentials
• Use IAM Access Analyzer to identify unintended access

Policy Evaluation Logic

Remember the policy evaluation order for complex scenarios:
1. Explicit Deny - always wins
2. Organizations SCPs - must allow the action
3. Resource-based policies - can allow cross-account access
4. Permission boundaries - must allow the action
5. Session policies - for assumed roles with further restrictions
6. Identity-based policies - must allow the action

The effective permission is the intersection of all applicable allow statements, minus any explicit denies.