IAM Users

• Individual identity: Each IAM User is a unique identity within AWS, created for specific people or applications needing direct access to AWS services.
• Access options: Users can log in to AWS via a password for the AWS Management Console, or use access keys for API or CLI access.
• Permissions: User permissions are managed by attaching IAM policies that define what actions they can perform on which resources.

IAM User Groups

• Collection of users: Groups allow organizing multiple IAM Users, like developers or admins, into manageable units.
• Inherited permissions: Users in a group automatically inherit the permissions assigned to that group, making it easier to standardize permissions for similar roles.
• Simplified management: User groups enable administrators to quickly add or remove permissions for multiple users by updating policies attached to the group, rather than each individual user.

Example

Scenario:

Your company has a small AWS team with Developers and Admins. Each group has specific permissions based on their roles.

IAM Users Example

1. Alice (Admin):
   • Identity: Alice is created as an IAM User.
   • Access: She can log in to the AWS Management Console with a password and access AWS services with access keys.
   • Permissions: Alice has full administrative permissions, allowing her to manage resources, create users, and configure security settings.
2. Bob (Developer):
   • Identity: Bob is also created as an IAM User.
   • Access: Bob can log in to the console and use access keys for API/CLI access.
   • Permissions: Bob has permissions specific to development tasks, like deploying applications, but he can’t manage users or configure account settings.

IAM User Groups Example

1. Admins Group:
   • Members: Alice and any other admin users.
   • Permissions: This group has an AdministratorAccess policy attached, granting full permissions across AWS.
   • Purpose: By adding Alice to the Admins Group, you ensure she has all necessary permissions without managing individual settings.
2. Developers Group:
   • Members: Bob and other developers.
   • Permissions: This group has a DeveloperAccess policy, granting permissions like managing EC2 instances and accessing S3 buckets but restricting access to sensitive operations.
   • Purpose: Adding Bob to the Developers Group makes sure all developers have the same permissions without individually assigning them.