Cloud Parts

AWS IAM

AWS’s identity and access management: JSON policies decide which users, roles and services may call which AWS APIs on which resources.

What it is
Identity & access (IAM)
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026
Website

What it is

AWS Identity and Access Management checks every AWS API call. The caller is a principal: an IAM user with long-lived access keys, or, far more often, a role. A role has no password; EC2 instances, Lambda functions, containers or a CI job assume it through AWS STS and get temporary credentials that last from 15 minutes to 12 hours (one hour by default). What a principal may do is written in JSON policies, each statement naming an Effect, the Actions, the Resource ARNs and optional Conditions on tags, source IP, MFA and more.

Evaluation starts from deny. Within one account, a request is allowed if an identity-based or a resource-based policy (such as an S3 bucket policy) allows it, and any explicit Deny anywhere wins. Permissions boundaries, and AWS Organizations’ service control policies (SCPs) and resource control policies (RCPs), can only narrow that: the action has to be allowed by each of them. IAM, IAM Identity Center (single sign-on for people) and STS cost nothing extra.

Why teams pick it

  • Fine-grained control over every API action and resource ARN, with conditions on tags, network, MFA and time
  • Roles hand workloads short-lived credentials that rotate on their own, so there are no keys to store; OIDC federation does the same for CI systems
  • One model that every AWS service uses, and no additional charge
  • Organization-wide guardrails (SCPs and RCPs) that no account admin can override

Watch out for

  • Many policy types interact, and it can be hard to work out why a call gets AccessDenied
  • Size limits bite on large setups: 6,144 characters per managed policy and 20 managed policies per role by default (25 at most)
  • Eventually consistent: a new role or policy change may not take effect everywhere straight away, so it doesn’t belong in a hot code path
  • It controls access to AWS only; for your own app’s sign-ups and logins AWS offers Amazon Cognito instead

How it fits with other technologies

A trust policy that lets one GitHub repository assume a role over OIDC · json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
      "StringLike": { "token.actions.githubusercontent.com:sub": "repo:acme/infra:*" }
    }
  }]
}

See it in a real stack

No architecture uses AWS IAM yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Article· March 2023The Great Lambda Migration to Kubernetes Jobs: a Journey in Three PartsLiav Yona, InfoQA first-person account of how Firefly moved event-driven work off Lambda (after hitting the 15-minute timeout), briefly onto ECS, and finally onto Kubernetes Jobs on EKS, with practical notes on reusing container images, swapping an IAM trust policy for EKS OIDC, moving environment variables into ConfigMaps and a blue/green cutover. It is one company’s story with few numbers, and the author’s employer sells infrastructure-as-code tooling, which colours the emphasis on IaC.
Article· August 2022Deploying AWS Lambda functions using AWS Controllers for Kubernetes (ACK)Rajdeep Saha, AWS Compute BlogAWS’s step-by-step tutorial for managing Lambda functions as Kubernetes custom resources: install the ACK Lambda controller in EKS, give it IAM permissions through IRSA, then kubectl apply a Function manifest that points at code in S3. It explains why you might (one GitOps and RBAC model for pods and functions) but, being AWS’s own post, not the drawbacks.
Article· May 2021Spice up Your Kubernetes Environment with AWS LambdaLiav Yona, MediumShows how a Lambda function triggered by SQS or SNS can forward events to an internal (ClusterIP) service in EKS through the Kubernetes API server’s service proxy, using IAM-to-RBAC mapping instead of exposing an endpoint, with code on GitHub. A clever pattern, but written for 2021-era EKS: it maps the IAM role through the aws-auth ConfigMap, and it routes application traffic through the cluster’s control plane.
All resources →
Where it came from2010–2024

An AWS account starts with a single identity, the root user, which has complete access to every service and resource in it. Before IAM, that was effectively the only identity an account had, so a company with many engineers and programs had to share the same all-powerful credentials, with no way to give each person or program only the permissions it needed.

AWS previewed Identity and Access Management in September 2010 and launched it in May 2011. It let customers create users and groups and attach policy documents to them, covering fifteen AWS services, and set the model AWS still uses: fine-grained permissions on actions and resources, with conditions on when a policy applies. Federation with existing corporate identities and short-lived credentials followed in August 2011, and in June 2012 IAM roles for EC2 took over what AWS called “the muck” of getting access keys onto servers.

As customers spread across many accounts, guardrails moved up a level: service control policies arrived with AWS Organizations in 2017 and resource control policies in 2024. By 2021 IAM was evaluating more than 400 million API calls per second, up from a couple of thousand per second in 2011.

Why it’s built this way

Deny by default; an explicit deny always wins
A request succeeds only if some policy allows it and none denies it. That makes the safe outcome the default and lets an administrator block something with certainty, however many other policies allow it.
Policies as JSON over actions, resources and conditions
One grammar covers every AWS service, and because policies are data, tools can generate and check them. AWS later built Zelkova (2018), which translates policies into logic so automated reasoning can find misconfigurations.
Roles with temporary credentials
Copying long-lived access keys onto servers meant distributing and guarding secrets by hand. Roles make credentials available automatically and let them expire, first for EC2 instances in 2012 and now for Lambda, containers and outside systems over OIDC.

Timeline

  1. 2010

    IAM previewed in September

  2. 2011

    Launches in May; identity federation and temporary credentials in August

  3. 2012

    IAM roles for EC2 instances

  4. 2017

    AWS Organizations brings service control policies

  5. 2019

    IAM Access Analyzer launches

  6. 2024

    Resource control policies set an organization-wide data perimeter

Sources12 · facts checked 5 October 2026

Improve this page on GitHub