What is AWS IAM and how does access management in AWS work?

What is AWS IAM?

AWS Identity and Access Management (IAM) is a service that, as Amazon puts it in the IAM documentation, "helps you securely control access to AWS resources." On every request sent to the cloud, IAM answers two questions: who is making it (authentication) and are they allowed to make it (authorization).

It is worth stating what IAM is not: it is not an AI model or a firewall, but a foundational layer for managing identities and permissions — built into every AWS account and evaluated on every API, console, and CLI call. The service is global and free of charge; you pay only for the resources it grants access to.

IAM's model is restrictive by default: every request is denied until an explicit rule allows it (default deny). This is the opposite of "open by default" — and the source of both IAM's security and its complexity.

How does it work?

At the heart of IAM is its policy evaluation logic. A principal is any identity performing an action in AWS — a user, a role, an application, or a service. When a principal sends a request, AWS first authenticates it, then builds the request context (the requested action, resource, principal, tags, IP address, time, MFA status, and other data — this is where Condition keys come from), and finally runs that context through all applicable policies to reach a verdict — allow or deny.

The rules for combining policies are precise, and worth memorizing, because they most often trip up newcomers:

• Everything is denied by default. Without an explicit allow, the request fails.
• An explicit deny always wins. If any policy contains an explicit deny, it overrides every allow — no exceptions.
• Identity-based and resource-based policies are additive (union). If an action is allowed by a policy on the user, on the resource, or both, it is allowed.
• Permission boundaries and organization policies narrow (intersection). They grant nothing — they can only restrict; an action must be allowed by both the identity-based policy and the boundary/SCP^?SCP: Service Control Policies (SCPs) — AWS Organizations policies that cap the maximum permissions for entire accounts.

The key distinction: policies that grant access add together; policies that restrict it (boundaries, SCPs, RCPs, sessions) act as successive gates. A single deny sinks the request. In short, effective permissions are the set:

The same mechanism, traced step by step:

What are its key components?

IAM is built on a handful of object types. On the identity side:

• Users — typically intended for individual people. Applications can use IAM users with long-term keys, but AWS recommends roles and temporary credentials instead.
• Groups — collections of users to which policies are attached in bulk.
• Roles — identities with no permanent credentials, designed to be assumed by any principal that needs them.
• Root user — the account owner with full access; AWS advises against everyday use and reserves it for a handful of account-level administrative tasks.

Roles and AWS STS

Roles are the heart of modern IAM: they have no permanent credentials, and once a role is assumed the principal receives temporary credentials from STS^?STS: AWS Security Token Service — the AWS service that issues short-lived, automatically expiring access credentials — short-lived, generated dynamically, valid from a few minutes to several hours. Once they expire they stop working and never need manual revocation, per the temporary credentials documentation.

Every IAM role combines two separate policies:

Policies

On the permissions side are policies. AWS defines nine policy types in total; the ones that matter most in practice are:

• Identity-based policies — JSON documents attached to users, groups, and roles; they define what an identity can do.
• Resource-based policies — attached directly to a resource; they name which principal has access. Contrary to common belief, these are not limited to S3 buckets — KMS keys, SQS queues, SNS topics, and roles (as trust policies) support them too.
• Permission boundaries — the ceiling of permissions that identity-based policies can grant to an entity.
• Service Control Policies (SCPs) and Resource Control Policies (RCPs) — AWS Organizations policies that set the maximum permissions for whole accounts.
• Session policies — passed when creating a temporary session, narrowing the permissions of that specific session.

Managed vs inline policies

Permissions can be attached as managed (standalone, reusable) or inline (embedded permanently in a single entity). Managed policies split further into AWS Managed and Customer Managed:

In practice, managed policies are recommended — easier to reuse and audit; inline policies are reserved for permissions that should exist only alongside one specific identity.

A policy itself is a JSON document of version 2012-10-17, made of statements with an effect (Allow/Deny), an action, a resource, and optional Condition clauses — for example, requiring MFA^?MFA: multi-factor authentication — a second factor beyond the password, e.g. a one-time code from a phone. Here is a minimal example — read access to one bucket, allowed only when MFA is active:

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

What can it be used for?

The most basic use is giving people and applications exactly the permissions they need. But IAM's real power lies in roles: they let you delegate access without handing out permanent keys (an app on EC2 uses resources with no credentials stored on the server) and share resources across accounts (cross-account).

Another scenario is identity federation — it authenticates users outside AWS and exchanges that identity for temporary AWS credentials. So users signing in through a corporate directory (SAML 2.0) or an external provider (OpenID Connect, e.g. Google) use resources without any separate IAM accounts.

What does a typical request look like?

Theory meets practice in a simple example: an application running on EC2 wants to read a file from S3.

At no point is a static key stored on the server — the credentials live only for the session, and the access decision is made by IAM's logic against the policies attached to the role.

Best practices: least privilege

The most important principle AWS repeats almost everywhere is least privilege — grant only the permissions genuinely required for a task. AWS recommends starting from a minimum and adding as needed rather than the reverse, because tightening overly broad permissions after the fact is far harder and rarely done.

Concrete tooling helps: IAM Access Analyzer (over 100 policy checks and warnings about overly permissive access), policy generation from CloudTrail logs, and "last accessed" information showing which permissions were actually used. It is also worth knowing that IAM combines two models: RBAC (through roles) and ABAC (through tags and policy conditions) — the latter lets you build attribute-driven permissions (e.g. department, project) without multiplying separate policies.

How does it differ from other approaches?

Compared with traditional permission models in operating systems or databases, IAM stands out on three counts: it is closed by default, driven by declarative JSON policies, and an explicit deny has absolute priority.

Against other clouds the differences are mainly conceptual (a simplification of each model, not a feature-by-feature comparison). In Microsoft Azure, the identity layer (Microsoft Entra ID, formerly Azure AD) is a separate directory, and permissions are granted through RBAC role assignments over scopes. Google Cloud IAM typically works by binding "member → role → resource" across a hierarchy of projects and folders. AWS IAM, by contrast, is strongly resource- and policy-centric: you express permissions as policy documents attached to identities or resources, not only as pre-built roles. Remember too that IAM operates within a single account — managing many accounts requires AWS Organizations and SCPs.

Key limitations and challenges

IAM's biggest challenge is its complexity. Nine policy types, the union-and-intersection rules, and the absolute priority of deny make computing "effective permissions" non-obvious even for experienced engineers.

That feeds directly into misconfiguration: an overly broad policy with a "*" wildcard in the action or resource can silently grant far more access than intended — and such mistakes are among the most common causes of cloud incidents.

A third constraint is the set of hard quotas you need to be aware of already at the architecture stage:

Most can be raised through Service Quotas, but some (such as the role-name length or the maximum session duration) are fixed. Details are in the IAM and STS quotas documentation.

Who is behind it?

IAM is built and operated by Amazon Web Services; it has been generally available since 2011 and is one of the platform's foundations. A set of related services surrounds it — STS (temporary credentials), IAM Identity Center (workforce access), and IAM Access Analyzer (policy validation).

Why does it matter?

IAM is the quiet foundation of security across all of AWS. Every API call, every server launch, and every database read is evaluated by IAM's logic — so the quality of your policies is, in practice, the quality of your deployment's security.

Well-designed permissions confine the blast radius of a breach to a narrow slice of infrastructure; poorly designed ones turn a single leaked key into a full account compromise. That is why the shift from long-term keys toward temporary credentials (roles and STS) is one of the most important changes in cloud security of the past decade — a key that never touches disk and expires within the hour is far harder to steal.

For a junior, IAM is not "one more service" but the language in which all of AWS security is expressed. Whoever masters the policy evaluation logic, the difference between union and intersection, and why roles beat static keys holds the key to using the entire platform securely.

Sources

• AWS — "What is IAM?" (IAM User Guide) — link
• AWS — "Policy evaluation logic" (IAM User Guide) — link
• AWS — "Policies and permissions in IAM" (IAM User Guide) — link
• AWS — "IAM roles" (IAM User Guide) — link
• AWS — "Temporary security credentials in IAM" (IAM User Guide) — link
• AWS — "IAM and AWS STS quotas" (IAM User Guide) — link
• AWS — IAM product page — link