AWS Identity & Access Management (IAM): Users
In the AWS ecosystem, an IAM User is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. Unlike a Role, which is intended to be assumed by anyone who needs it, a User is a permanent identity with long-term credentials.
The “Office Building” Analogy
Think of AWS as a secure office building. The Root User is the building owner with the master key. An IAM User is an employee with their own personalized ID badge (Username/Password). Their Permissions are the specific floors and rooms their badge is programmed to open.
Topics covered :
Summary of key subtopics covered in this guide:
- IAM User Fundamentals & Credential Types
- IAM Groups vs. Individual Permissions
- The Principle of Least Privilege
- Multi-Factor Authentication (MFA) Requirements
- Programmatic Access vs. Console Access
- Comparison: Users vs. Roles vs. Root
Core Concepts & Configuration
1. Identity Types
IAM Users are Global objects. They are not region-specific. When you create a user, it exists across all AWS regions simultaneously. By default, a newly created user has No Permissions (Implicit Deny).
2. Credentials
- Console Password: Used for logging into the AWS Management Console (GUI).
- Access Keys (ID & Secret): Used for programmatic access via the AWS CLI, SDKs, or APIs. These should never be embedded in code.
- Signing Certificates: Used for some specific AWS services (mostly legacy).
Comparison: Identity Entities
| Feature | IAM User | IAM Role | Root User |
|---|---|---|---|
| Credentials | Long-term (Password/Keys) | Short-term (Temporary) | Email/Password (Master) |
| Use Case | Humans/Static Apps | EC2, Lambda, Federation | Account setup only |
| Best Practice | Use Groups for policy | Preferred for services | Lock away/MFA |
| MFA | Highly Recommended | N/A (Inherited) | Mandatory (Critical) |
Exam Tips and Gotchas
- The Root Rule: Never use the Root user for daily tasks. If an exam question asks how to perform a task securely, and “Root User” is an option, it is almost always the wrong answer.
- Access Key Safety: If Access Keys are compromised, the first step is to Deactivate/Rotate them, not necessarily delete the user immediately.
- Groups vs. Users: Always assign permissions to Groups, then add Users to those Groups. Do not attach policies directly to individual users (harder to manage).
- EC2 Best Practice: Never store IAM User Access Keys on an EC2 instance. Instead, attach an IAM Role to the instance.
Decision Matrix / If–Then Guide
| If the requirement is… | Then Choose… |
|---|---|
| A person needs to log in to the AWS Dashboard | IAM User + Console Access + MFA |
| An application on EC2 needs to upload files to S3 | IAM Role (not User) | IAM Group + Attached Policy |
| A third-party auditor needs access for 2 hours | IAM Role with External ID |
IAM User Architecture & Ecosystem
Credential Rotation
IAM Users do not automatically rotate passwords or access keys. Use IAM Access Analyzer or AWS Config to monitor key age and enforce rotation policies.
Service Ecosystem
- CloudTrail: Logs all User API calls.
- CloudWatch: Alarms on failed logins.
- KMS: Users use keys to encrypt data.
Limits & Limits
Default limit: 5,000 IAM Users per account. If you need more, consider Identity Federation (SAML/OIDC) instead of creating more users.
Production Use Case: Developer Onboarding
When a new developer joins, create an IAM User, add them to a “Developer” Group (which has an attached Managed Policy for PowerUser access), and enforce MFA activation before they can access any resources. For CLI work, issue Access Keys and store them in the local ~/.aws/credentials file, never in the code repository.