AWS IAM

Definition

AWS Identity and Access Management (IAM) is the authorization layer for every AWS API call. It answers two questions: who is the principal (human, role, service), and what actions are they allowed on which resources under which conditions. IAM policies are JSON documents with Allow and Deny statements; an explicit Deny always wins. For human access at scale, AWS recommends IAM Identity Center (federated SSO) instead of long-lived IAM users. For workloads, IAM roles with temporary credentials replace static access keys.

When to use it

• Every AWS account — IAM is not optional; even root-only accounts still evaluate policies on API calls.
• Workload credentials via IAM roles for EC2, ECS, EKS, Lambda, and any service that assumes a role at runtime.
• Cross-account access with role trust policies and external ID for third-party SaaS integrations.
• Human access through IAM Identity Center permission sets mapped to IdP groups (Okta, Entra ID, Google Workspace).
• Permission boundaries and session policies to cap what a role can grant even if an admin attaches a broad policy.

When not to use it

• Application-level authorization (“Can user X edit document Y?”) — that belongs in your app layer or Amazon Verified Permissions, not IAM.
• Long-lived IAM users with access keys for applications — use roles, OIDC federation (GitHub Actions, Kubernetes), or IAM Roles Anywhere instead.
• Root account for daily operations — root has unrestricted access; use it only for account-level tasks that require it, with hardware MFA.

Tips

• Evaluate effective permissions with IAM Access Analyzer and policy simulation before production deploys.
• Prefer customer managed policies over inline policies — reusable, versioned, and auditable.
• Use condition keys (aws:RequestedRegion, aws:PrincipalTag, aws:SourceVpc) to narrow scope without multiplying policies.
• Attach permission boundaries to high-privilege roles so delegated admins cannot escalate beyond the boundary.
• In Organizations, remember SCPs intersect with IAM — an IAM Allow blocked by an SCP Deny still fails.

Gotchas

Serious

• *:* on production roles — one overly broad Lambda or CI role becomes lateral movement infrastructure after a single compromise.
• Root access keys — if they exist, delete them; attackers scan for them in leaked repos and public AMIs.
• Misunderstanding policy evaluation order — SCP Deny, permission boundary, session policy, identity policy, and resource policy all interact; “I attached AdministratorAccess” does not help if an SCP denies the action.

Regular

• Confusing IAM users with Identity Center users — SSO users do not appear in the IAM users list; auditing only IAM users misses your workforce.
• Forgetting resource-based policies — S3 bucket policies, KMS key policies, and Lambda permissions can grant access independently of identity policies.
• Not enabling MFA on privileged humans — password-only admin accounts fail basic compliance controls.

Official references

• What is IAM?
• Policy evaluation logic
• IAM Identity Center
• IAM Access Analyzer

Related FactualMinds content

• AWS Cloud Security Services
• Cloud Compliance Services
• Service Control Policies: AWS Governance Guide