AWS Identity and Access Management (IAM) is a global service used to securely manage access to AWS resources across all regions. The primary identities used to control this access are IAM Users, IAM Groups, and IAM Roles, each serving a distinct purpose in a secure architecture.

IAM Users

An IAM User is an identity created within your AWS account that represents a specific person or application needing long-term, persistent access to AWS.

• Key Characteristics: When a new IAM user is created, it starts with no permissions by default; permissions must be explicitly granted through policies. Users typically have permanent credentials, such as a password for the AWS Management Console or access keys for the CLI.
• Example: If a developer named "Alice" joins your team, you would create an IAM User specifically for her so she can log in and perform her daily tasks.

IAM Groups

An IAM Group is a collection of IAM Users that allows you to manage permissions for multiple people simultaneously.

• Key Characteristics: Instead of attaching policies to each individual user, you attach them to the group, and any user added to that group automatically inherits those permissions. This simplifies management and ensures consistency across a team.
• Example: You can create an IAM Group called "SysAdmins" and attach a policy that grants full administrative access. By adding "Alice" and "Bob" to this group, they both receive those permissions without you having to configure them separately.

IAM Roles

An IAM Role is an identity that is not associated with a specific person but is instead intended to be assumed by anyone or anything that needs temporary access.

• Key Characteristics: Roles do not have permanent long-term credentials; instead, they provide temporary (ephemeral) security credentials via the AWS Security Token Service (STS). Roles are commonly used for service-to-service access, cross-account access, or for users federated from an external corporate directory (like Active Directory).
• Example: If you have an application running on an EC2 instance that needs to read data from an Amazon S3 bucket, you should not hardcode credentials into the app. Instead, you create an IAM Role with the necessary S3 permissions and assign that role to the EC2 instance, allowing the service to securely access the data.

Summary Comparison Table

Feature	IAM User	IAM Group	IAM Role
Primary Use	Single person or application.	Managing permissions for a set of users.	Temporary access for services or federated users.
Credentials	Long-term (Passwords/Access Keys).	None (inherited by members).	Short-term/Ephemeral (via AWS STS).
Best Practice	Use for individual human access.	Use to organize users by job function.	Use for services and third-party access.
Permissions	Identity-based policies.	Identity-based policies.	Identity and trust-based policies.