IAM User: What It Is and When to Use It

Definition

An AWS Identity and Access Management (IAM) User is an identity within an AWS account that has specific, long-term credentials and permissions to interact with AWS services. It represents a person or an application and is a fundamental building block for controlling access to your AWS resources, solving the problem of how to grant granular access without sharing the all-powerful account root user credentials.

How It Works

An IAM User is a distinct entity within your AWS account, identified by a unique name (e.g., dev-user-jane) and an Amazon Resource Name (ARN). When you create an IAM User, it has no permissions by default, adhering to the principle of least privilege.

Permissions are granted explicitly by attaching identity-based policies. These are JSON documents that define what actions the user is allowed or denied to perform on which AWS resources. Policies can be attached in two ways:

Directly to the user: Known as an inline policy (for single-use cases) or by attaching a managed policy (reusable policies managed by AWS or by you).
Via an IAM Group: The recommended approach for managing permissions for multiple users with similar job functions is to place them in an IAM Group and attach policies to the group. The user then inherits all permissions from all groups it belongs to.

An IAM User can have two types of credentials:

Password: For access to the AWS Management Console. You can enforce a custom password policy and require Multi-Factor Authentication (MFA) for enhanced security.
Access Keys: A pair consisting of an Access Key ID and a Secret Access Key. These are used for programmatic access via the AWS Command Line Interface (CLI), Software Development Kits (SDKs), and direct API calls. An IAM user can have a maximum of two active access keys at a time to allow for safe rotation.

When an IAM User makes a request to an AWS service, AWS evaluates all applicable policies to determine authorization. This includes identity-based policies on the user/group, resource-based policies on the target resource (e.g., an S3 bucket policy), and broader organizational controls like Service Control Policies (SCPs). An explicit Deny in any of these policies will always override an Allow.

Key Features and Limits

Permanent Credentials: IAM Users are associated with long-term credentials (passwords and access keys) that are valid until manually revoked.
Granular Permissions: Access is defined by attaching fine-grained IAM policies.
Multi-Factor Authentication (MFA): Can be enabled for console access and API calls, providing a critical layer of security.
Programmatic Access: Users can be configured with access keys for using the AWS CLI, SDKs, and other development tools.
Permissions Boundaries: An advanced feature that sets the maximum permissions an IAM user can ever have, even if their identity-based policies grant more.

Service Quotas (as of 2026):

IAM Users per AWS Account: 5,000 (can be increased).
IAM Groups per AWS Account: 300 (can be increased).
IAM Groups a User can be in: 10 (can be increased).
Managed Policies attached to a User: 10 (can be increased).
Access Keys per User: 2.
Inline Policy Size per User: 2,048 characters.

Common Use Cases

While the best practice for human access has shifted to AWS IAM Identity Center, and for workloads to IAM Roles, there are still specific, valid use cases for IAM Users.

Initial Administrative User: After creating an AWS account, the first step is to create an administrative IAM User with MFA, and then secure the root user credentials. This user is for initial setup and account management.
Workloads Running Outside of AWS: An application or script running on an on-premises server or a developer's local machine needs long-term credentials (access keys) to interact with AWS APIs. IAM Roles Anywhere is a modern alternative for this scenario.
Specific AWS Services: Some services, like AWS CodeCommit, can use SSH keys associated with an IAM user for Git authentication.
Break-Glass or Emergency Access: A dedicated, highly secured IAM user with administrative privileges (and mandatory MFA) can be created for emergency situations where other access methods might fail.
Legacy Systems: Older applications that were not designed to assume IAM Roles may still rely on static IAM user credentials.

Pricing Model

AWS Identity and Access Management (IAM), including the creation and management of IAM Users, Groups, and Policies, is a feature of your AWS account offered at no additional charge. You are only billed for the usage of other AWS services that your IAM users access (e.g., the Amazon EC2 instances they launch or the data they store in Amazon S3).

Some advanced features within the IAM ecosystem, such as certain types of analysis in IAM Access Analyzer, may incur costs.

Pros and Cons

Pros

Simplicity for Basic Setups: For a single account with a few users or applications, creating IAM Users is straightforward.
Persistent Access for External Workloads: Provides necessary long-lived credentials for applications running outside the AWS environment.
Direct and Explicit Permissions: Permissions are clearly tied to a specific identity, making it easy to understand who has access to what in simple scenarios.

Cons

Major Security Risk: Long-lived access keys are a primary target for attackers. If leaked, they provide persistent access until they are manually discovered and revoked. This is the most significant drawback.
Management Overhead: Managing credentials, permissions, and key rotation for many individual users is complex, error-prone, and does not scale well across multiple accounts.
Modern Alternatives are Superior: For nearly every common use case, a more secure and scalable alternative exists:
- Human Users: AWS IAM Identity Center provides temporary, role-based access that can be integrated with external identity providers (IdPs) for Single Sign-On (SSO).
- AWS Workloads (EC2, Lambda, etc.): IAM Roles provide temporary, automatically rotated credentials and are the definitive best practice.

Comparison with Alternatives

IAM User vs. IAM Role

This is the most fundamental comparison in IAM.

Identity: An IAM User is a permanent identity tied to one person or application. An IAM Role is not tied to a specific identity; it is a set of permissions that trusted identities (users, services, applications) can assume temporarily.
Credentials: An IAM User has permanent credentials (password, access keys). An IAM Role provides temporary security credentials that expire after a defined period.
Use Case: Use IAM Users for workloads outside AWS that require static keys. Use IAM Roles for everything running inside AWS (e.g., EC2 instance profiles), for cross-account access, and for identity federation.

IAM User vs. AWS IAM Identity Center

This comparison is about managing human access.

Scope: IAM Users are created and managed within a single AWS account. IAM Identity Center is designed to manage user access centrally across an entire AWS Organization with many accounts.
Authentication: IAM Users authenticate with their IAM password. IAM Identity Center users authenticate through a central user portal, often federated with a corporate identity provider like Okta or Azure AD, enabling SSO.
Permissions: With IAM Users, you attach policies directly. With IAM Identity Center, you create reusable "Permission Sets" (which are essentially IAM Roles) and assign them to users or groups for access to specific accounts.
Recommendation: For all human access, AWS IAM Identity Center is the modern, recommended best practice.

Exam Relevance

IAM is a foundational topic on nearly all AWS certification exams, from Associate to Professional and Specialty levels.

Applicable Certifications: AWS Certified Solutions Architect (Associate & Professional), AWS Certified SysOps Administrator - Associate, AWS Certified Developer - Associate, AWS Certified Security - Specialty.
Key Knowledge Areas:
- The principle of least privilege.
- The fundamental differences between an IAM User, Group, Role, and Policy.
- When to use an IAM User (specific, limited cases) versus an IAM Role (most cases).
- The critical security importance of enabling MFA and rotating access keys.
- Understanding that the AWS account root user is distinct from an IAM user and should be secured.
- The policy evaluation logic, especially that an explicit Deny always wins.

Frequently Asked Questions

Q: What is the difference between the AWS account root user and an IAM user?

A: The root user is the identity created when you first open an AWS account. It has complete and unrestricted access to all services and resources, including billing and the ability to close the account. An IAM user is an identity you create within the account, which has only the specific permissions you grant it. Best practice is to never use the root user for daily tasks; instead, lock away its credentials with MFA and use an administrative IAM user.

Q: Should I use an IAM user for my application running on an Amazon EC2 instance?

A: No. The definitive best practice is to use an IAM Role. You can associate an IAM Role with an EC2 instance via an "instance profile." This provides the application with temporary, automatically rotated credentials through the instance metadata service, which is far more secure than storing a permanent IAM user's access keys on the instance.

Q: How many access keys can an IAM user have, and why would I need more than one?

A: An IAM user can have a maximum of two active access keys at one time. The primary purpose of allowing two keys is to enable seamless credential rotation without downtime. The process is: 1) Create a new, second access key. 2) Update all your applications and tools to use the new key. 3) Verify the old key is no longer being used (by checking its last used date in IAM). 4) Deactivate and then delete the old key.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.