AWS Glossary
AWS IAM
AWS Identity and Access Management — controls who can authenticate and what actions they are authorized to perform in your AWS account.
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
Related FactualMinds content
Related Services
AWS Security Consulting
AWS security consulting from an AWS Select Tier Partner. 2-week assessment, 4–6 week remediation, zero disruption. IAM hardening, public exposure, compliance gaps, and continuous monitoring.
Cloud Compliance Services — HIPAA, SOC 2, PCI DSS on AWS
Cloud compliance services — HIPAA, SOC 2, PCI DSS, ISO 27001, GDPR. Expert consulting from FactualMinds.
Need help with this topic?
Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.