Users, Groups, Roles
Within AWS IAM, Users, Groups, and Roles represent distinct identities used to manage who or what can interact with your resources. Managing them properly is critical for maintaining an organized and secure infrastructure.
1. IAM Users
An IAM User is a permanent identity created within your AWS account that represents a single specific person or an isolated background application.
Credentials: Users possess long-term, permanent security credentials. This includes a password for accessing the web management console, or a static pair of Access Keys (Access Key ID and Secret Access Key) used to authenticate local CLI or SDK scripts.
Default State: When you create a new IAM User, it has absolutely zero permissions by default. It cannot view, create, or modify any AWS resource until a permission policy is attached to it.
Best Practice Use Case: You create individual IAM Users for the actual human members of your engineering team so they can log in and perform daily operations.
2. IAM Groups
An IAM Group is simply a collection of multiple IAM Users. It is not an identity itself, meaning an application cannot log in "as a group".
The Purpose: Groups exist purely to simplify permission management. Instead of manually attaching identical permission documents to 15 different developer accounts one by one, you attach the policy to a single Group.
Inheritance: Any IAM User added to a Group instantly inherits all the permissions attached to that Group. If you remove the user from the Group, those permissions are instantly revoked.
Constraints: Groups cannot be nested (a Group cannot contain another Group). A Group can only contain individual Users. However, an individual User can belong to multiple different Groups simultaneously.
3. IAM Roles
An IAM Role is a distinct identity that has specific permission policies, but it is not uniquely associated with a single permanent person or service.
No Permanent Credentials: Unlike a User, a Role does not have a permanent password or static access keys.
Temporary Security Tokens: When a User, an external identity, or an AWS service assumes a Role, the AWS Security Token Service (STS) dynamically generates short-lived, temporary security credentials that automatically expire after a set time window (typically 1 to 12 hours).
The Costume Analogy: Think of a User as a permanent employee badge, while a Role is a specialized uniform hanging in a closet. Anyone who is allowed to put on that uniform temporarily gains the specific tools and access rights that come with it. When they take the uniform off, those permissions are completely gone.
Primary Use Case: Roles are the standard tool used to grant cross-account access, integrate external single-sign-on systems, or allow server hardware (like an EC2 instance running a server) to securely access other AWS resources without storing hardcoded API credentials in the application files.