KBY Technologies Logo
cd ../lexicon
sys/docs/lexicon/aws-iam.md
Lexicon
AWS IAM

AWS IAM

AWS Identity and Access Management (IAM) is the AWS service that authenticates identities and authorises the actions they may take on AWS resources, using users, roles, groups and JSON policy documents.
Difficulty: Intermediate
6 min read
Updated 2026-08-17

In plain English

Plain definition

AWS Identity and Access Management (IAM) is the AWS service that authenticates identities and authorises the actions they may take on AWS resources, using users, roles, groups and JSON policy documents.

Technical Definition

IAM is built around four core constructs: principals (the IAM user, role or federated identity making a request), policies (JSON documents containing one or more statements with an Effect, Action, Resource and optional Condition), permissions (the net effect of all policies that apply to a request) and authentication mechanisms (long-term credentials for IAM users, or short-term credentials issued by AWS Security Token Service, AWS STS, when a role is assumed).

Policy evaluation in IAM follows a consistent logic: access is denied by default; an explicit Allow in an applicable identity-based, resource-based, permissions-boundary or service-control policy is required to grant access; and any explicit Deny in any applicable policy overrides all Allows. This "explicit deny wins" rule is central to reasoning about IAM behaviour and is frequently the source of unexpected access outcomes.

  • IAM users — named identities with long-term credentials, intended for a small number of human or break-glass use cases.
  • IAM roles — identities with no long-term credentials, assumed temporarily by users, applications or AWS services via AWS STS.
  • IAM groups — collections of users that share attached policies for easier administration.
  • IAM policies — JSON documents that can be attached to users, groups or roles (identity-based) or to certain resources such as S3 buckets and KMS keys (resource-based).

Operational Relevance

IAM configuration is one of the most consequential surfaces in an AWS environment: it directly determines the blast radius of a compromised credential, a misconfigured pipeline or a permissive automation script. Practical operational concerns include avoiding routine use of the account root user, preferring roles over long-lived access keys for workloads running on EC2, Lambda or containers, enforcing multi-factor authentication for human users, and periodically reviewing unused permissions with tools such as IAM Access Analyzer.

Because IAM permissions compose across multiple policy types — identity-based policies, resource-based policies, permissions boundaries and, where AWS Organizations is in use, service control policies — a change that appears correct in isolation can still be blocked or unexpectedly widened by a policy attached elsewhere. Reasoning about what an identity can actually do therefore requires checking every applicable policy layer, not just the one most recently edited.

Architecture Relationship

IAM sits underneath almost every other AWS service rather than beside them. Compute services (EC2, Lambda, ECS, EKS) assume IAM roles to obtain temporary credentials for calling other AWS APIs. Storage and data services (S3, KMS, SQS, SNS) can carry their own resource-based policies that must agree with the calling identity’s permissions before access is granted. AWS Organizations layers service control policies on top of IAM to set an outer boundary on what any identity in a member account can ever be allowed to do, regardless of what identity-based policies say. IAM Identity Center centralises human federation into this model, issuing temporary IAM role sessions rather than long-lived IAM user credentials.

Example

A bounded, representative use of IAM: an application running on an EC2 instance needs to read objects from one specific S3 bucket. The recommended pattern is to create an IAM role with an identity-based policy scoped to s3:GetObject on that bucket’s Amazon Resource Name (ARN) only, attach an instance profile containing that role to the EC2 instance, and avoid issuing any IAM user access keys to the application at all. The instance retrieves temporary credentials automatically via AWS STS, and those credentials expire and rotate without manual intervention.

Misunderstanding

A common misunderstanding is that attaching a permissive identity-based policy is sufficient to guarantee access. In practice, IAM authorisation is the intersection of every applicable policy layer: an identity-based Allow can still be blocked by a missing or conflicting resource-based policy on the target service, by a permissions boundary that caps the role’s maximum permissions, or by a service control policy at the AWS Organizations level. Treating IAM as a single flat allow-list, rather than as several policy layers that must all agree, is a frequent source of both unexpected access denials and unexpected over-permissioning.

  • AWS Security Token Service (STS)
  • IAM role
  • IAM policy (identity-based and resource-based)
  • Permissions boundary
  • Service control policy (AWS Organizations)
  • Principle of least privilege
  • IAM Identity Center

Further Reading

IAM Identity Center and several IAM federation flows rely on OpenID Connect and OAuth 2.0, protocols documented through the RFC process; the RFC Editor’s published series is the authoritative record for those underlying specifications. Readers who need current, version-specific detail on IAM console workflows, service quotas or newly released policy features should confirm those details directly against current official AWS product documentation, since that detail was outside the scope of the verified evidence used for this entry.