IAM

AWS Identity and Access Management (IAM) — Overview & Core Components

What is AWS IAM?

AWS Identity and Access Management (IAM) is the service that lets you securely control who can access what in your AWS account and how they can use it. IAM provides authentication (who you are) and authorization (what you can do) for users, applications, and services across AWS.

Core Components

Identities

Users — long‑lived identities (human or programmatic) with credentials like passwords and access keys. Best for people logging in to the console and for CI only when federation isn’t possible.

Groups — collections of users. You attach policies to groups to manage permissions for many users at once.

Roles — identities that do not have long‑term credentials. They are assumed by users, applications, or AWS services via sts:AssumeRole to obtain temporary credentials.

Policies

Identity‑based policies — JSON documents attached to users, groups, or roles that grant permissions (Action, Resource, Condition).

Resource‑based policies — attached to resources like S3 buckets, SQS queues, or KMS keys; they specify who (principals) can access that resource.

Permissions boundaries — a maximum permissions guardrail for an identity; the effective permissions are the intersection of the identity policy and the boundary.

Service Control Policies (SCPs) — organization‑level guardrails applied to AWS accounts in AWS Organizations (do not grant permissions; they limit what principals in those accounts can be granted).

Session policies — inline policies passed when assuming a role to further restrict the resulting session.

Authentication Methods

Console sign‑in — username/password + MFA for humans.

Access keys — for programmatic access (CLI/SDK). Prefer roles + temporary creds.

Federation/SAML/OIDC — use your corporate identity provider (Azure AD/Okta/Cognito) to obtain temporary AWS credentials via roles.

Evaluation Logic

IAM uses an implicit deny by default. An explicit Allow grants access unless there is an explicit Deny, which always wins. Effective permissions come from combining identity policies, resource policies, boundaries, SCPs, and session policies.

Example: Minimal S3 Read‑Only Policy

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

Best Practices (Quick)

Least privilege — grant only what is required; prefer scoped resources and conditions (e.g., aws:PrincipalTag, s3:prefix).

Use roles + temporary credentials — avoid long‑lived access keys; rotate automatically via STS.

Enable MFA for human users and on the root account; lock away root keys.

Use permissions boundaries / SCPs for guardrails in multi‑team and multi‑account setups.

Monitor & audit with CloudTrail, Access Analyzer, and IAM last accessed information.

Common Real‑Time Workflow

A user authenticates via your IdP (SAML/OIDC) → assumes an IAM role → receives temporary credentials via STS → calls AWS services (e.g., upload to S3 or invoke a Lambda). Policies on the role and resources control exactly what is allowed.

Remember: Policies do not run code; they describe permissions. Services (like S3, Lambda, EventBridge) enforce them at request time based on the caller's identity and context keys.

AWS IAM Theory and Practical / of AWS IAM Introduction