AWS IAM
An authentication and authorization service for securely controlling access to AWS resources, providing fine-grained access management through users, groups, roles, and policies
Overview
AWS Identity and Access Management (IAM) is a service for securely managing access to AWS resources. By creating IAM users, groups, and roles and defining access permissions with JSON-based policies, you can precisely control who can perform what actions on which resources. IAM is built into every AWS account by default, and AWS states that IAM itself is offered at no additional charge (as of September 2026); see the official AWS pricing pages for details. It includes security features such as multi-factor authentication (MFA) enforcement, password policy configuration, and access key rotation. IAM roles let you grant temporary credentials to EC2 instances and Lambda functions, eliminating the need to manage long-lived access keys. IAM Access Analyzer automatically detects resources accessible from outside your account and identifies unintended access permissions.
Policy Evaluation Logic and Practicing Least Privilege
The central principle in IAM policy design is least privilege. As of September 2026, the AWS security best practices for IAM describe this as granting only the permissions required to perform a task, and note that you might start with broader permissions while you explore what a workload requires and then work to reduce those permissions as the use case matures. IAM evaluates policies through a specific logic: an explicit Deny always wins, followed by explicit Allow, and the default is implicit Deny. There are two types of policies: identity-based policies (attached to users, groups, and roles) and resource-based policies (such as S3 bucket policies and SQS queue policies). AWS managed policies are a practical starting point, and AWS documentation notes that they might not grant least-privilege permissions for a specific use case because they are available to all AWS customers; AWS therefore recommends reducing permissions further by defining customer managed policies for your own use cases. The Condition element lets you restrict access based on criteria such as source IP address, MFA authentication status, and request time. Use IAM last accessed information - surfaced in the console on the Access Advisor tab - to review which services each user or role has actually accessed, and remove the permissions that are not being used; AWS recommends regularly reviewing and removing unused users, roles, permissions, policies, and credentials.
IAM Roles and Temporary Credentials
IAM roles provide temporary credentials through the Security Token Service (STS), eliminating the need to manage long-lived access keys. When an EC2 instance or Lambda function uses a role, AWS delivers temporary credentials to that compute resource and the AWS SDKs discover and refresh them automatically; the maximum session duration depends on how the credentials are requested and on the role configuration. This avoids embedding long-lived access keys in application code or configuration files; as of September 2026, AWS recommends relying on temporary credentials instead of creating long-term credentials such as access keys wherever possible. Cross-account roles enable secure resource sharing between AWS accounts without creating IAM users in each account. For workloads running outside AWS, IAM Roles Anywhere extends the same temporary credential model to on-premises servers and other cloud environments using X.509 certificates. In contrast, Azure RBAC takes a different approach by assigning role definitions to scopes (management groups, subscriptions, resource groups), with permissions inheriting from higher scopes to lower ones - IAM does not have this hierarchical inheritance and instead requires each policy to explicitly specify its target resources.
Large-Scale Management with Organizations and IAM Identity Center
As your organization scales beyond a handful of accounts, IAM Identity Center - the current name as of September 2026, formerly AWS SSO - provides centralized access management across multiple AWS accounts, and AWS documentation recommends it for managing access to your accounts centrally. Users authenticate once through IAM Identity Center and can access any permitted account without maintaining separate IAM users in each account. Permission sets define what actions users can perform in each account, and these can be assigned to groups synced from external identity providers like Okta or Microsoft Entra ID. Service Control Policies (SCPs) combined with AWS Organizations set upper bounds on allowed actions at the account or organizational unit level - even if individual IAM policies grant excessive permissions, SCPs enforce guardrails. For example, an SCP can prevent any account from disabling CloudTrail or creating resources outside approved regions. Combining IAM Access Analyzer with CloudTrail logs helps identify permissions that are not being used, enabling systematic permission cleanup across the entire organization.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.