AWS IAM Basics: Users, Groups, Roles, and Policies

Overview

AWS Identity and Access Management (IAM) revolves around four core building blocks:

1. Users — long-lived identities for humans or applications.
2. Groups — collections of users for shared policy attachment.
3. Roles — temporary identities anyone (or any service) can assume.
4. Policies — JSON documents that define permissions.

Understanding these and how they interact is the foundation of AWS access control.

---

1. IAM Users

An IAM User is a long-lived identity defined within an AWS account. Each user has:

• A name and unique ARN.
• (Optional) A console password for human sign-in.
• (Optional) Access keys for programmatic access.
• Attached policies (directly or via groups).
• (Optional) MFA device.
• Tags.

When to Use IAM Users

• Small AWS deployments (few accounts, few people).
• Specific automation that can't use roles or federation.
• Break-glass accounts.

Why You Should Limit IAM Users

• Long-lived credentials are riskier than temporary ones.
• Difficult to manage at scale (many accounts).
• IAM Identity Center / federation are stronger and easier to govern.

---

2. IAM Groups

A Group is a container for IAM Users. Policies attached to a group apply to all members.

• Groups cannot be principals (you can't assume a group).
• Groups cannot contain other groups.
• Use them to manage policies for sets of similar users (Developers, ReadOnlyAuditors, etc.).

Common Group Pattern

• Developers — attached DeveloperAccessPolicy.
• ReadOnlyAuditors — attached ReadOnlyAccess.
• Billing — attached billing-specific policy.

---

3. IAM Roles

A Role is a temporary identity that any allowed principal can assume.

Components

• Trust policy — defines who can assume the role.
• Permissions policies — define what the role can do.
• Session duration — how long credentials last after assumption (15 min – 12 h).
• External ID (optional) — extra trust restriction for cross-account.

Common Use Cases

• EC2 instance profile — an EC2 instance assumes a role and gets credentials via the instance metadata service.
• Lambda execution role — Lambda functions assume their execution role.
• Cross-account access — a principal in account A assumes a role in account B.
• Federated access — SAML / OIDC users assume a role on sign-in.
• AWS services — many services need a role to act on your behalf (e.g., CodePipeline, Backup).

Roles vs Users

Aspect	IAM User	IAM Role
Credentials	Long-lived	Temporary (STS)
Principal	Itself	Anyone with trust
Use case	Persistent identity	Temporary or service identity
Risk	Higher	Lower

---

4. IAM Policies

Policies are JSON documents describing permissions.

Policy Document Structure

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

Types of Policies

• AWS managed — created and maintained by AWS (e.g., ReadOnlyAccess, AdministratorAccess).
• Customer managed — your custom reusable policies.
• Inline — embedded in a specific user, group, or role.
• Resource-based — attached to resources (S3 bucket policies, KMS key policies).
• Permission boundaries — cap maximum permissions for a principal.
• Service Control Policies (SCPs) — at Organization level, deny-only.
• Session policies — passed during AssumeRole to further restrict.

Effect: Allow vs Deny

• Allow — grants permission (subject to other Denies).
• Deny — overrides any Allow.

---

Putting It All Together

Example 1: Developer Access

• Group: Developers.
• Group Policy: allows S3, EC2, Lambda actions in dev account.
• Members: human IAM users (or via Identity Center group mapping).

Example 2: EC2 Instance Reading from S3

• Role: WebApp-S3ReadRole.
• Trust policy: allows ec2.amazonaws.com to assume.
• Permissions: s3:GetObject on specific bucket only.
• Attached to instance via instance profile.

Example 3: Cross-Account Access

• Account A (corp): user auditor belongs to CrossAccountAuditors group.
• Account B (workload): role AuditorRole trusts account A.
• auditor assumes AuditorRole to read CloudTrail in account B.

---

Common Pitfalls

• Inline policies sprinkled across users — hard to audit. Prefer customer managed reusable policies.
• Wildcards in Action and Resource (s3:* on *) — over-broad.
• No MFA conditions on sensitive policies.
• Long-lived access keys for IAM Users.
• Trust policies allowing * as Principal.
• iam:PassRole without scope — privilege escalation vector.
• No naming conventions — chaos at scale.

---

Best Practices

1. Prefer roles over users for everything possible.
2. Use IAM Identity Center for human access; federate from Entra ID / Okta / Google.
3. Apply MFA conditions on sensitive policies.
4. Use customer managed policies with version control.
5. Use permission boundaries for delegated administration.
6. Use SCPs at Organization level for guardrails.
7. Tag-based access control where appropriate.
8. Periodic reviews with IAM Access Analyzer.
9. Eliminate unused users, keys, roles, policies quarterly.
10. CloudTrail + detection on IAM changes.

---

Quick Checklist

• IAM Users minimized; Identity Center used for humans?
• Roles used for services and cross-account?
• Customer managed policies preferred over inline?
• MFA enforced on sensitive actions?
• iam:PassRole scoped tightly?
• Permission boundaries for delegated admins?
• SCPs enforce guardrails?
• Quarterly cleanup of unused identities, keys, policies?
• CloudTrail + IAM Access Analyzer enabled?

---

How Forestall Helps

Forestall maps Users, Groups, Roles, and Policies across every account:

• Effective permissions per principal (incl. resource-based grants).
• Trust relationships visualized.
• Privilege escalation paths via dangerous IAM actions.
• Stale identities and unused permissions.
• Risk-ranked findings tied to remediation guidance.

---

Frequently Asked Questions

Should I create IAM Users for my engineers?

Probably not — use Identity Center with federated SSO and Permission Sets that materialize as roles in each account.

What's the difference between a service role and a service-linked role?

Service roles you create and manage. Service-linked roles are pre-defined by an AWS service for its specific operations.

Can a role assume another role?

Yes — chained role assumption is supported (with limits).

What is the policy evaluation order?

Explicit Deny > Allow (across all policy types). No allow = implicit deny.

What's iam:PassRole and why does it matter?

It controls who can pass a role to AWS services. Excessive iam:PassRole permissions enable privilege escalation (assigning a high-privilege role to a service the attacker controls).

---

Conclusion

Users, Groups, Roles, and Policies are the four pillars of AWS IAM. Understanding when to use each — and how to compose them safely — is foundational to AWS security. Prefer roles to users, federate humans through Identity Center, write least-privilege policies, layer SCPs and permission boundaries, and continuously audit. Done well, IAM becomes a strong, scalable, observable access plane across every AWS account.