AWS IAM: What It Is and When to Use It

Definition

AWS Identity and Access Management (IAM) is the service that controls who can do what in your AWS account. It lets you create identities (users, groups, roles), attach permission policies to them, and federate external identity providers — all so that every API call to an AWS service can be authenticated and then authorized against explicit rules. IAM is offered at no additional charge.

How It Works

Every request to AWS has three inputs: the principal making the request (an IAM user, a role session, or an AWS service), the action being performed (e.g., s3:GetObject), and the resource being acted on (e.g., a specific S3 bucket). IAM evaluates a stack of policies to decide whether to allow or deny the request.

Core Entities

• Root user — the email-and-password identity that created the AWS account. Has unrestricted access; should be locked down with MFA and used only for a handful of tasks (account closure, billing contacts, changing support plans).
• IAM users — long-lived identities with a sign-in password and/or access keys. Best practice is to minimize their use and rely on IAM Identity Center for humans and IAM roles for workloads.
• IAM groups — collections of users for policy management. Policies attached to a group apply to all members.
• IAM roles — identities that no one logs into directly. Instead, principals assume the role and receive temporary credentials (via AWS Security Token Service, or STS). Used by AWS services (EC2 instance profiles, Lambda execution roles), cross-account access, and federated users.
• Policies — JSON documents that describe permissions. Each statement has Effect, Action, Resource, and optional Condition.
• IAM Identity Center (formerly AWS SSO) — the recommended way for humans to sign into AWS. Federates an identity provider (Okta, Azure AD, Google, or its own directory) and lets users assume roles across many AWS accounts from a single portal.

Policy Types

1. Identity-based policies — attached to users, groups, or roles. Define what the identity is allowed to do.
2. Resource-based policies — attached to resources that support them (S3 buckets, KMS keys, SQS queues, SNS topics, Lambda functions). Define who can access the resource.
3. Permissions boundaries — set the maximum permissions an identity-based policy can grant. They do not grant permissions on their own but cap the effective set.
4. Service Control Policies (SCPs) — applied at the Organizations level. Act as a guardrail across one or more accounts — nothing below can exceed what the SCP allows, regardless of identity-based policies.
5. Session policies — passed when a role is assumed. Further restrict the resulting session's permissions.

Evaluation Logic (simplified)

1. Explicit Deny anywhere → request denied.
2. Organizations SCPs → must allow.
3. Resource-based policy or identity-based policy → must allow.
4. Permission boundary → must allow (if one is attached).
5. Session policy → must allow (if one is set).
6. Default is implicit deny.

Key Features and Limits

• Global service — IAM is not Region-scoped. Users, roles, policies, and account-level settings are the same in every Region. Changes are eventually consistent and can take seconds to propagate.
• MFA — Multi-Factor Authentication via virtual authenticator apps, FIDO2 security keys, or (legacy) hardware TOTP tokens.
• Federation — SAML 2.0, OIDC, AssumeRoleWithWebIdentity (for mobile/web apps), and AssumeRoleWithSAML.
• IAM Access Analyzer — finds resources shared with external principals, checks custom policies for errors, and reports unused access (users, roles, permissions) to help clean up over time.
• Access keys — at most 2 active per user (so you can rotate). Consider AWS CLI aws configure sso or instance profiles instead of long-lived keys.
• Policy size limits — managed policy: 6,144 characters; inline policy on a user: 2,048; on a group: 5,120; on a role: 10,240.
• Policy versioning — managed policies keep up to 5 versions.
• Conditions — powerful condition keys like aws:SourceIp, aws:SourceVpc, aws:MultiFactorAuthPresent, aws:RequestTag/*, aws:PrincipalOrgID, aws:CurrentTime enable fine-grained control.
• Role trust policy — separate from the permission policy; defines who may assume the role.
• External ID — a condition used when a third-party role is assumed on your behalf, preventing the "confused deputy" vulnerability.

Common Use Cases

1. Workload access control — grant an EC2 instance, ECS task, or Lambda function an IAM role so it can call AWS APIs without embedded credentials.
2. Cross-account access — let a build account's CI pipeline deploy into a production account by assuming a role with a tightly scoped trust policy.
3. Human access via IAM Identity Center — federate employees from a corporate IdP and give them scoped, time-bounded sessions in each AWS account.
4. Least-privilege enforcement — start from AWS-managed policies, then tighten with custom policies using IAM Access Analyzer to find unused permissions.
5. Organizational guardrails — use SCPs to disallow disabling CloudTrail, deny resource creation in unapproved Regions, or require specific tags.
6. Temporary credentials for mobile apps — use Cognito Identity Pools or AssumeRoleWithWebIdentity to exchange a Google/Apple/Facebook token for short-lived AWS credentials.

Pricing Model

IAM, IAM Identity Center, and AWS STS are free. You pay only for the underlying AWS services that IAM authorizes calls to.

IAM Access Analyzer's basic external-access findings are free; unused access analysis and custom policy checks are priced per resource and per evaluation, respectively — still inexpensive, but worth noting in the bill.

Pros and Cons

Pros

• Extremely expressive policy language with conditions, tags, and resource-level controls.
• Covers both humans (users, SSO) and workloads (roles) with consistent semantics.
• Tight integration with every AWS service; resource-based policies enable easy cross-account sharing.
• Access Analyzer automates much of the audit burden.

Cons

• JSON policies are notoriously easy to over-scope; first-time writers often end up with "Action": "*", "Resource": "*".
• Evaluation logic has many layers (SCP, boundary, session, identity, resource) that are hard to reason about without tooling.
• Eventual consistency means policy changes can take a few seconds to take effect, which can trip up CI/CD pipelines.
• Legacy IAM users with long-lived access keys remain a persistent source of leaked-credential incidents.

Comparison with Alternatives

| Concept | IAM User | IAM Role | | --- | --- | --- | | Credentials | Long-lived password and/or access keys | Temporary credentials obtained via STS | | Intended for | Direct human or service sign-in | Services, cross-account workflows, federated humans | | Rotation | Manual | Automatic (each session has a fresh token) | | Best practice | Avoid where possible | Preferred for workloads and humans (via IAM Identity Center) |

Compared with Google Cloud IAM and Azure AD/RBAC, AWS IAM is more resource-focused (many services have their own resource policies), its policy language is more expressive with conditions, and Organizations SCPs give strong org-level guardrails that don't have exact counterparts in other clouds.

Exam Relevance

IAM is one of the most heavily tested topics on AWS certification exams:

• Cloud Practitioner (CLF-C02) — basics of users, groups, roles, MFA, and the principle of least privilege.
• Solutions Architect Associate (SAA-C03) — cross-account access patterns, federation, role trust policies, permission boundaries, resource-based policies (S3 bucket policies, KMS key policies).
• Developer Associate (DVA-C02) — IAM roles for Lambda/EC2/ECS, Cognito identity pools, SigV4 signing, STS AssumeRole patterns.
• SysOps Administrator (SOA-C02) — policy evaluation troubleshooting, IAM Access Analyzer, Organizations + SCPs.
• Security Specialty (SCS-C02) — deep dive into condition keys, policy evaluation, cross-account access, and detecting/remediating over-privileged identities.

Classic exam pattern: given a scenario where an allow-policy seems to permit access but the request is still denied — the answer is usually an explicit deny somewhere (SCP, resource policy, permission boundary). Memorize the "explicit deny always wins" rule.

Frequently Asked Questions

Q: What is the difference between an IAM user and an IAM role?

A: An IAM user is a long-lived identity with a password and/or access keys, intended for a specific person or application. An IAM role is an identity with no long-lived credentials; principals assume the role and receive temporary credentials from AWS Security Token Service. Best practice is to use IAM roles for workloads (EC2 instance profiles, Lambda execution roles) and IAM Identity Center for humans, instead of long-lived IAM user credentials.

Q: How does IAM policy evaluation work when multiple policies apply?

A: IAM evaluates all applicable policies together. An explicit Deny in any policy (identity-based, resource-based, SCP, permission boundary, session policy) beats any Allow. Otherwise, at least one policy must explicitly Allow the action and resource, and no higher-level control (SCP or permission boundary) may prohibit it. The default for everything else is an implicit deny.

Q: What is an IAM permission boundary and how is it different from an SCP?

A: A permission boundary is an advanced feature attached to a single IAM user or role that caps the maximum permissions that identity can have — useful when you delegate role creation to developers but want to limit what they can grant. A Service Control Policy (SCP) is an AWS Organizations feature that applies to entire accounts or organizational units — a guardrail across many identities. Both work subtractively (they limit, not grant), but boundaries are per-identity while SCPs are per-account.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS IAM documentation before making production decisions.