L5. AWS IAM: Users, Groups, Roles, and Policies

What Is AWS IAM?

AWS Identity and Access Management (IAM) is a global service that controls authentication (who you are) and authorization (what you can do) in AWS. IAM is free.

IAM Components

IAM Users: individual identities for people or applications that need access to AWS. A user can have a console password, access keys for API/CLI access, both, or neither. Prefer federation through IAM Identity Center for workforce access rather than creating long-term IAM user credentials. IAM Groups: collections of IAM users. Permissions assigned to a group apply to all members. Groups make managing permissions at scale easier. IAM Roles: identities that can be assumed by AWS services, users, or applications. Roles use temporary credentials (no long-term password or access key). Roles are the recommended way to grant permissions to AWS services. IAM Policies: JSON documents that define allowed or denied actions. Identity-based policies are attached to users, groups, or roles. Resource-based policies, such as S3 bucket policies, are attached to resources.

Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Key policy elements: Effect (Allow/Deny), Action (API operation), Resource (ARN).

IAM Best Practices

1. Reserve the root user for tasks that require it; use federated workforce access through IAM Identity Center for everyday tasks
2. Enable MFA on the root account and privileged users
3. Grant least privilege: give only the minimum permissions needed
4. Use roles for applications on EC2, Lambda, and other services (not access keys)
5. Prefer temporary credentials; review and remove unused access keys and update required long-term keys when needed
6. Use IAM Access Analyzer to identify external access and unused permissions

IAM Policy Evaluation Logic

When multiple policies apply, AWS evaluates them as follows:

1. Explicit Deny: if any policy denies the action, it is denied
2. Applicable Allow: the required policies must allow the action within permissions boundaries, session policies, and organization guardrails. A single Allow is not sufficient in every context
3. Implicit Deny: without the required Allow, the action is denied

For cross-account S3 access, both the resource policy in the bucket account and the identity policy in the requester account must allow the action. A bucket policy alone is not a cross-account exception. SCPs and permissions boundaries limit permissions; they do not grant them.

Root Account vs. IAM Users

Exam tip: Explicit Deny always wins. IAM roles use temporary credentials and are preferred over long-term access keys for applications. MFA should always be enabled on the root account.

Continue Learning

Apply these rules in S3 data protection, including cross-account bucket access.

References

• IAM security best practices
• Cross-account policy evaluation
• Service control policies and member-account root