- A global (not region-specific) AWS service that centralizes management of authentication and authorization: users, groups, roles, policies.
- Fundamental to nearly all AWS services, governing who can do what on which AWS resources.
- Every AWS service relies on IAM to authorize API calls by users, roles, or services.
- EC2 instances use roles (via STS temporary credentials) to access S3, DynamoDB, etc., without embedding keys.
- Cross-account access: IAM roles can be assumed by principals in different AWS accounts for controlled multi-account access.
- Supports federated access with SAML/OIDC identity providers (e.g., Google, ADFS), enabling SSO for AWS IAM roles.
- IAM is used with AWS Organizations and SCPs, where IAM entities operate under broader organizational guardrails.
- IAM features like permissions boundaries, IAM Access Analyzer, Credential Report, and Access Advisor help enforce least privilege and audit permissions.
- Least-Privilege Access Control: Assign minimal needed permissions via identity-based policies.
- Service-to-Service Access: EC2 or Lambda use roles to fetch secrets (e.g., from Secrets Manager) or interact with S3 without hard-coded credentials.
- Cross-Account Role Access: Securely grant external accounts or your own secondary accounts access via roles with trust policies.
- Federated SSO: Map external identities to temporary roles in AWS with fine-grained permission control.
- Delegated Administration: Use permissions boundaries so that developers can create users/policies but cannot elevate privileges.
- Business Scenarios: Example: Provide “describe-only” EC2 access to support users, or restrict partnered external users to “write-only” access to an S3 bucket.
- IAM Identity Center (formerly AWS SSO): Offers centralized user sign-on across AWS accounts and business applications. Works with permission sets, not direct IAM users.
- AWS Cognito: Used for managing app users (hundreds to millions), often for mobile/web app authentication and federated identity. Differs from IAM, which is for AWS control plane.
- AWS Organizations + SCPs: Apply higher-level permission guardrails across accounts that complement IAM policies and boundaries.
- 5,000 IAM users per account; use roles or federation if exceeding.
- Groups: Up to 300 groups per account; each user can belong to up to 10 groups; groups don’t nest; no limit to users in a group.
- IAM Roles: Default attachments are two policy types—trust and permission policies.
- Managed policies per role: 10 by default; can be increased via Service Quotas.
- IAM Identity Center (permission set) quotas: e.g., number of permission sets (2,000), inline policies limit (1), policies per set (20), etc.
- Using the root account for routine operations—never recommended.
- Distributing access keys for EC2 or Lambda—use roles instead to avoid credential exposure.
- Letting developers grant themselves elevated permissions—use permission boundaries to prevent privilege escalation.
- Using IAM users for app-end users—AWS recommends Cognito or Identity Center for scalable user pools.
- Relying purely on resource-based policies for cross-account access when IAM roles with trust policies are simpler and more flexible. Resource-based policies are limited in supported services.
-
Understand Principal-Policy-Resource evaluation logic: Explicit Deny > Allow > Default Deny.
-
Root vs user vs role distinctions—use MFA, avoid root.
-
Role-based access control: Use roles for services, cross-account, and temporary access.
-
Policy types:
- Identity-based (attach to users, groups, roles)
- Resource-based (attach to some resources like S3)
- Permissions boundaries (limit maximum permissions)
- Session policies (further restrict assumed roles)
- SCPs (at organization level)
-
Federation & IdP integration: SAML/OIDC integration, Identity Center, Cognito differences.
-
Monitoring & auditing tools: IAM Access Analyzer, Credential Reports, Access Advisor.
-
Exam weight: IAM is under “Design Secure Architectures” (30%)—focus on least-privilege, secure delegation, multi-account strategy.
| Topic | Core Takeaways |
|---|---|
| Purpose | Centralized authentication & authorization across AWS |
| Key Entities | Users (long-term), Groups, Roles (temporary), Policies |
| Use Cases | EC2 roles, cross-account, federation, delegated admin |
| Limits | 5k users, 300 groups, 10 groups/user, 10 policies/role |
| Bad Practices | Root usage, embedded keys, self-permissions, user anchoring |
| Exam Focus | Least privilege, role-based access, policy types, federation |
| Tools | Access Analyzer, Credential Report, policy simulator |
