AWS IAM
Manage user access and encryption keys securely
IAM is like the security system for your AWS account; it controls who can do what. Think of it as a building with many rooms (AWS services). IAM lets you create badges (users) with specific permissions: some people can enter all rooms, others only specific ones, and some can only look but not touch. You can also create group badges (IAM groups) for teams, and temporary visitor passes (IAM roles) for applications. It's free, and it follows the principle of least privilege: give people only the permissions they absolutely need, nothing more. IAM is the foundation of AWS security.
IAM manages authentication (who you are) and authorization (what you can do) in AWS.
Key Capabilities
- Supports three identity types: users (long-lived credentials for humans), groups (collections of users), and roles (temporary credentials assumed by services, Lambda functions, or federated users)
- Policies are JSON documents attached to identities or resources; they define allowed and denied actions on specific AWS resources
- Permission boundaries cap the maximum permissions a role can ever have, regardless of what broader policies allow
- Service Control Policies (SCPs) applied via AWS Organizations act as organization-level guardrails across all member accounts
- IAM Access Analyzer identifies overly permissive policies by analyzing resource access from outside your account or organization
- Supports identity federation via SAML 2.0 and OIDC, enabling SSO from external identity providers without creating IAM users
Gotchas & Constraints
Gotcha #1: IAM is eventually consistent; policy changes can take seconds to propagate. Gotcha #2: Explicit Deny always wins; if one policy denies and another allows, the deny takes precedence. Constraints: IAM is global (not region-specific), maximum 5,000 users per account (use federation for more), and policies have size limits (6,144 bytes for managed policies).
A company has 200 employees across development, operations, and finance teams. Instead of sharing root account credentials (which is dangerous), they create IAM users for each employee. Developers get policies allowing EC2, RDS, and S3 access in the dev account. Operations get full access to production resources. Finance gets read-only access for cost analysis. They create IAM roles for applications: EC2 instances assume roles to access S3 without embedding access keys in code. For contractors, they use IAM roles with temporary credentials that expire after 12 hours. They enable MFA for all users with admin privileges and set up CloudTrail to log all IAM actions for compliance. When an employee leaves, they delete the IAM user, immediately revoking all access.
The Result
granular access control, no shared credentials, and full audit trail of who did what.