2.1.1.1. IAM: Users, Groups, Roles, and Policies

💡 First Principle: AWS IAM provides granular control over who accesses which AWS resources and what actions they perform, ensuring secure, compliant operations via least privilege.

AWS Identity and Access Management (IAM) allows you to manage access to AWS services and resources securely. It's the core service for defining, granting, and managing permissions for your AWS environment.

Key IAM Components:

• "Users": Individual entities (people or applications) with long-term credentials (password, access keys) for direct AWS interaction.
• "Groups": Collections of IAM users. Attaching policies to a group grants the same permissions to all users within it, simplifying permission management.
• "Roles": Secure IAM identities that grant temporary permissions to AWS services (e.g., an EC2 instance accessing S3) or trusted external entities without needing permanent credentials.
• "Policies": JSON documents that define specific permissions (allowed or denied actions on resources). They are attached to users, groups, or roles to enforce access control.

Scenario: Instead of hardcoding S3 bucket credentials directly into an application running on an EC2 instance, an IAM role is assigned to the instance, granting it temporary, secure access to S3.

Visual: IAM Users, Groups, Roles, and Policies

Loading diagram...

⚠️ Common Pitfall: Attaching policies directly to individual IAM users rather than using groups or roles. This makes permissions difficult to manage and audit at scale.

Key Trade-Offs:

• Users/Access Keys vs. Roles: Users with long-term access keys are simpler for initial setup but carry higher risk if compromised. Roles provide temporary, short-lived credentials, which are more secure for applications and cross-account access but require a bit more setup.

Reflection Question: How does IAM's centralized control and the use of IAM roles enhance security and operational efficiency compared to managing individual, long-term credentials for applications?