AWS IAM

Definition

AWS Identity and Access Management (IAM) is the service that controls authentication (who can sign in) and authorization (what they can do) across your AWS account. Every API call, CLI command, or console action in AWS is evaluated against IAM — it is the security foundation of the entire platform.

Core IAM Concepts

IAM Users

• Long-term credentials (username + password, access keys)
• Represent a person or application that needs persistent AWS access
• Best practice: Avoid IAM users for human access; use IAM Identity Center with federated identity instead

IAM Groups

• Collection of IAM users sharing the same permissions
• Assign policies to groups; users inherit permissions

IAM Roles

• Temporary credentials assumed by AWS services, applications, or users
• No long-term access keys — credentials rotate automatically
• Use cases: EC2 instance role, Lambda execution role, cross-account access, federated identity

IAM Policies

• JSON documents defining permissions (Allow/Deny + Actions + Resources + Conditions)
• Attached to users, groups, or roles
• Types: AWS managed policies, customer managed policies, inline policies, resource-based policies

Policy Evaluation Logic

AWS evaluates permissions in this order:

1. Explicit Deny — always wins, regardless of any Allow
2. SCPs (AWS Organizations) — define maximum permissions for the account
3. Permission Boundaries — define maximum permissions for a role/user
4. Identity-Based Policies — policies attached to the principal
5. Resource-Based Policies — policies attached to the resource (S3 bucket, KMS key, etc.)

Final permission = the intersection of all applicable policies with no explicit denies.

IAM Identity Center (formerly AWS SSO)

IAM Identity Center is the recommended approach for human access to AWS accounts:

• Connect to your existing identity provider (Azure AD, Okta, Google Workspace, Active Directory)
• Assign permission sets (predefined policies) to users/groups per AWS account
• Single sign-on — users log in once via your IdP; access assigned accounts
• No long-term IAM users needed; credentials are session-based (default 8 hours)
• Scales across 1–1,000+ AWS accounts in an organization

Least Privilege Principle

Grant only the permissions needed to perform a specific task:

• Start with the most restrictive policy; add permissions as needed
• Use IAM Access Analyzer to identify unused permissions and generate least-privilege policies from CloudTrail activity logs
• Use condition keys (aws:RequestedRegion, aws:PrincipalTag) to scope permissions further
• Rotate access keys regularly; delete unused keys

Common Mistakes

Mistake 1: Giving *:* (full access) to applications or Lambda functions. Always use task-specific roles with only the permissions the application actually needs.

Mistake 2: Using long-term IAM user access keys for applications. Use IAM roles (for EC2, Lambda, ECS) or OIDC federation (for GitHub Actions, Kubernetes) — no static credentials in code or environment variables.

Mistake 3: Not enabling MFA for the root account and privileged users. The AWS root account has unrestricted access; protect it with hardware MFA and never use it for day-to-day operations.

Related AWS Services

• IAM Identity Center: Centralized human access management across multiple accounts
• AWS Organizations + SCPs: Organization-wide permission boundaries
• IAM Access Analyzer: Identify over-privileged permissions and external access
• AWS CloudTrail: Audit log of every IAM action and API call

Related FactualMinds Content

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