AWS Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) is a free, global service of Amazon Web Services used to define permissions and manage who can access which resources across a multi-account AWS environment. It manages IAM users, IAM groups, IAM roles, and federated users, and lets you enforce multi-factor authentication (MFA) to protect the account. Temporary credentials issued through IAM roles are backed by AWS Security Token Service (STS).

AI Practitioner focus

• Apply least-privilege roles and policies to models, endpoints, knowledge bases, S3 data, vector stores, KMS keys, logs, and agent tools. Prefer short-lived role credentials over embedded keys.
• Agent/model output must never determine its own authorization. Amazon Bedrock AgentCore Identity and Policy can add delegated credentials and deterministic tool-action boundaries.

Key points

• IAM Users: a user can be a person or a service; each accesses the AWS environment with its own set of credentials.
• IAM Groups: collections of users; policies are attached to groups to assign permissions to many users at once.
• IAM Roles: IAM users or AWS services can assume a role to obtain temporary security credentials for making AWS API calls; a role can also grant users in one AWS account access to resources in another AWS account that they do not already have permission to reach.
• IAM Policies: written as JSON documents (key-value pairs) that define what can and cannot be accessed.
• Policy evaluation logic: all access is denied by default; an explicit Allow in an attached policy is required to grant access, but a single explicit Deny in any applicable policy always overrides an allow for the same resource and action.
• Least privilege: the recommended approach for granting permissions is to give an identity only the permissions required to perform its specific task, not broad access “just in case.”
• IAM Federated Access: allows credentials external to AWS to be used as a means of authentication to AWS resources.
• Distinct from Amazon Cognito, which handles sign-up/sign-in and identity federation (including social and enterprise identity providers) for external end users of web and mobile applications, rather than access to AWS resources themselves.
• IAM Access Analyzer: identifies resources — including Amazon S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager secrets, SNS topics, EBS snapshots, RDS snapshots, ECR repositories, EFS file systems, and DynamoDB tables/streams — shared with an external entity, based on the resource-based policies that grant access; it checks access policies and offers actionable recommendations to help set secure and functional policies.
• Beyond external access, Access Analyzer now also has internal access analyzers (which principals inside your org/account can reach a chosen business-critical resource) and unused access analyzers (unused IAM roles, access keys, passwords, and unused permissions on active roles/users), plus custom policy checks and CloudTrail-activity-based policy generation. External access analysis and basic policy validation are free; unused access analysis and custom policy checks are billed.
• Access Analyzer for S3: reviews all S3 buckets with ACLs and bucket policies from within the S3 console.
• IAM Credential Report: audits password and access key rotation details for compliance purposes.
• Access keys: used for programmatic access to AWS resources through the AWS CLI or the AWS API.
• MFA (Multi-Factor Authentication): AWS now enforces MFA by default for the root user across all account types (standalone and AWS Organizations member accounts), a requirement rolled out through 2024–2025; the account owner still has to register a device the first time they sign in.
• Root user: only the root user can perform certain tasks. For a standalone account these include changing the root password/email/access keys, closing the account, viewing certain VAT tax invoices, restoring accidentally revoked IAM user permissions, activating IAM access to Billing and Cost Management, AWS GovCloud (US) sign-up, and a handful of other service-specific tasks (EC2 Reserved Instance Marketplace seller registration, recovering an unmanageable KMS key via Support, linking an Amazon Mechanical Turk account, enabling S3 MFA delete, and fixing an S3/SQS resource policy that denies all principals). Other account settings (name, contact info, alternate contacts, Regions) do not require root.
• Centralized root access management: within AWS Organizations, the management account or a delegated admin can now centrally remove root credentials from member accounts, disable root password recovery, and perform privileged root-only tasks on member accounts without ever signing in as their root user (older CLF-C02 material assumes root actions always require signing in as that account’s own root user).
• IAM account password policy: lets an account enforce custom complexity and rotation requirements for IAM user passwords; the default AWS password policy applies if none is set.
• Service Control Policies (SCPs) and Resource Control Policies (RCPs), managed through AWS Organizations, provide an additional layer of permission management across accounts alongside IAM policies; policy evaluation is a strict intersection — an action must be allowed by the identity-based policy, any applicable SCP, and any applicable RCP, and an explicit deny in any of the three overrides an allow.
• IAM itself is free to use; you are only charged for the AWS resources that IAM-governed identities access.

Sources

• AWS account root user and root-only tasks
• IAM now enforces MFA for root users across all account types
• Using IAM Access Analyzer
• IAM policy evaluation logic