IAM Identities (users, user groups, and roles) - Amazon Identity and Access Management
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

IAM Identities (users, user groups, and roles)

Tip

Having trouble signing in to Amazon? Make sure that you're on the correct sign-in page.

  • To sign in as the Amazon Web Services account root user (account owner), use the credentials that you set up when you created the Amazon Web Services account.

  • To sign in as an IAM user, use the credentials your account administrator gave you to sign in to Amazon.

  • To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user.

    For help signing in using an IAM Identity Center user, see Signing in to the Amazon access portal in the Amazon Sign-In User Guide.

For sign-in tutorials, see How to sign in to Amazon in the Amazon Sign-In User Guide.

Note

If you need to request support, do not use the Feedback link on this page. Feedback you enter is received by the Amazon Documentation team, not Amazon Support. Instead, choose the Contact Us link at the top of this page. There, you'll find links to resources to help you get the support that you need.

The Amazon Web Services account root user or an administrative user for the account can create IAM identities. An IAM identity provides access to an Amazon Web Services account. An IAM user group is a collection of IAM users managed as a unit. An IAM identity represents a human user or programmatic workload, and can be authenticated and then authorized to perform actions in Amazon. Each IAM identity can be associated with one or more policies. Policies determine what actions a user, role, or member of a user group can perform, on which Amazon resources, and under what conditions.

Amazon Web Services account root user

When you first create an Amazon Web Services account, you begin with one sign-in identity that has complete access to all Amazon Web Services and resources in the account. This identity is called the Amazon Web Services account root user and is accessed by signing in with the email address and password that you used to create the account.

Important

We strongly recommend that you don't use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform the tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see Tasks that require root user credentials.

IAM users

An IAM user is an identity within your Amazon Web Services account that has specific permissions for a single person or application. Where possible, best practices recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. Before creating access keys, review the alternatives to long-term access keys. If you have specific use cases that require access keys, we recommend that you update access keys when needed. For more information, see Update access keys when needed for use cases that require long-term credentials. To add IAM users to your Amazon Web Services account, see Creating an IAM user in your Amazon Web Services account.

Note

As a security best practice, we recommend that you provide access to your resources through identity federation instead of creating IAM users. For information about specific situations where an IAM user is required, see When to create an IAM user (instead of a role).

IAM user groups

An IAM group is an identity that specifies a collection of IAM users. You can't use a group to sign-in. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named IAMPublishers and give that group the types of permissions that publishing workloads typically need.

IAM roles

An IAM role is an identity within your Amazon Web Services account that has specific permissions. It's similar to an IAM user, but isn't associated with a specific person. You can temporarily assume an IAM role in the Amazon Web Services Management Console by switching roles. You can assume a role by calling an Amazon CLI or Amazon API operation or by using a custom URL. For more information about methods for using roles, see Using IAM roles.

IAM roles with temporary credentials are used in the following situations:

  • Federated user access – To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see Creating a role for a third-party Identity Provider in the IAM User Guide.

  • Temporary IAM user permissions – An IAM user or role can assume an IAM role to temporarily take on different permissions for a specific task.

  • Cross-account access – You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some Amazon Web Services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see Cross account resource access in IAM.

  • Cross-service access – Some Amazon Web Services use features in other Amazon Web Services. For example, when you make a call in a service, it's common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal's permissions, using a service role, or using a service-linked role.

    • Principal permissions – When you use an IAM user or role to perform actions in Amazon, you are considered a principal. When you use some services, you might perform an action that then initiates another action in a different service. FAS uses the permissions of the principal calling an Amazon Web Service, combined with the requesting Amazon Web Service to make requests to downstream services. FAS requests are only made when a service receives a request that requires interactions with other Amazon Web Services or resources to complete. In this case, you must have permissions to perform both actions. For policy details when making FAS requests, see Forward access sessions.

    • Service role – A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see Creating a role to delegate permissions to an Amazon Web Service in the IAM User Guide.

    • Service-linked role – A service-linked role is a type of service role that is linked to an Amazon Web Service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your Amazon Web Services account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.

  • Applications running on Amazon EC2 – You can use an IAM role to manage temporary credentials for applications that are running on an EC2 instance and making Amazon CLI or Amazon API requests. This is preferable to storing access keys within the EC2 instance. To assign an Amazon role to an EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the EC2 instance to get temporary credentials. For more information, see Using an IAM role to grant permissions to applications running on Amazon EC2 instances in the IAM User Guide.

Temporary credentials in IAM

As a best practice, use temporary credentials with both human users and workloads. Temporary credentials are primarily used with IAM roles, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This prevents you from accidentally performing tasks that aren't permitted by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.

When to use IAM Identity Center users?

We recommend that all human users use IAM Identity Center to access Amazon resources. IAM Identity Center enables significant improvements over accessing Amazon resources as an IAM user. IAM Identity Center provides:

  • A central set of identities and assignments

  • Access to accounts across an entire Amazon Organization

  • Connection to your existing identity provider

  • Temporary credentials

  • Multi-factor authentication (MFA)

  • Self-service MFA configuration for end-users

  • Administrative enforcement of MFA usage

  • Single sign-on to all Amazon Web Services account entitlements

For more information, see What is IAM Identity Center in the Amazon IAM Identity Center User Guide.

When to create an IAM user (instead of a role)

We recommend you only use IAM users for use cases not supported by federated users. Some of the use cases include the following:

  • Workloads that cannot use IAM roles – You might run a workload from a location that needs to access Amazon. In some situations, you can't use IAM roles to provide temporary credentials, such as for WordPress plugins. In these situations, use IAM user long-term access keys for that workload to authenticate to Amazon.

  • Third-party Amazon clients – If you are using tools that don’t support access with IAM Identity Center, such as third-party Amazon clients or vendors that aren't hosted on Amazon, use IAM user long-term access keys.

  • Amazon CodeCommit access – If you are using CodeCommit to store your code, you can use an IAM user with either SSH keys or service-specific credentials for CodeCommit to authenticate to your repositories. We recommend that you do this in addition to using a user in IAM Identity Center for normal authentication. Users in IAM Identity Center are the people in your workforce who need access to your Amazon Web Services accounts or to your cloud applications. To give users access to your CodeCommit repositories without configuring IAM users, you can configure the git-remote-codecommit utility. For more information about IAM and CodeCommit, see Using IAM with CodeCommit: Git credentials, SSH keys, and Amazon access keys. For more information about configuring the git-remote-codecommit utility, see Connecting to Amazon CodeCommit repositories with rotating credentials in the Amazon CodeCommit User Guide.

  • Amazon Keyspaces (for Apache Cassandra) access – In a situation where you are unable to use users in IAM Identity Center, such as for testing purposes for Cassandra compatibility, you can use an IAM user with service-specific credentials to authenticate with Amazon Keyspaces. Users in IAM Identity Center are the people in your workforce who need access to your Amazon Web Services accounts or to your cloud applications. You can also connect to Amazon Keyspaces using temporary credentials. For more information, see Using temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin in the Amazon Keyspaces (for Apache Cassandra) Developer Guide.

  • Emergency access – In a situation where you can't access your identity provider and you must take action in your Amazon Web Services account. Establishing emergency access IAM users can be part of your resiliency plan. We recommend that the emergency user credentials be tightly controlled and secured using multi-factor authentication (MFA).

When to create an IAM role (instead of a user)

Create an IAM role in the following situations:

You're creating an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and that application makes requests to Amazon.

Don't create an IAM user and pass the user's credentials to the application or embed the credentials in the application. Instead, create an IAM role that you attach to the EC2 instance to give temporary security credentials to applications running on the instance. When an application uses these credentials in Amazon, it can perform all of the operations that are allowed by the policies attached to the role. For details, see Using an IAM role to grant permissions to applications running on Amazon EC2 instances.

You're creating an app that runs on a mobile phone and that makes requests to Amazon.

Don't create an IAM user and distribute the user's access key with the app. Instead, use an identity provider like Login with Amazon, Amazon Cognito, Facebook, or Google to authenticate users and map the users to an IAM role. The app can use the role to get temporary security credentials that have the permissions specified by the policies attached to the role. For more information, see the following:

Users in your company are authenticated in your corporate network and want to be able to use Amazon without having to sign in again—that is, you want to allow users to federate into Amazon.

Don't create IAM users. Configure a federation relationship between your enterprise identity system and Amazon. You can do this in two ways:

  • If your company's identity system is compatible with SAML 2.0, you can establish trust between your company's identity system and Amazon. For more information, see SAML 2.0 federation.

  • Create and use a custom proxy server that translates user identities from the enterprise into IAM roles that provide temporary Amazon security credentials. For more information, see Enabling custom identity broker access to the Amazon console.

Compare Amazon Web Services account root user credentials and IAM user credentials

The root user is the account owner and is created when the Amazon Web Services account is created. Other types of users, including IAM users, and Amazon IAM Identity Center users are created by the root user or an administrator for the account. All Amazon users have security credentials.

Root user credentials

The credentials of the account owner allow full access to all resources in the account. You can't use IAM policies to explicitly deny the root user access to resources. You can only use an Amazon Organizations service control policy (SCP) to limit the permissions of the root user of a member account. Because of this, we recommend that you create an administrative user in IAM Identity Center to use for everyday Amazon tasks. Then, safeguard the root user credentials and use them to perform only those few account and service management tasks that require you to sign in as the root user. For the list of those tasks, see Tasks that require root user credentials. To learn how to set up an administrator for daily use in IAM Identity Center, see Getting started in the IAM Identity Center User Guide.

IAM credentials

An IAM user is an entity you create in Amazon that represents the person or service that uses the IAM user to interact with Amazon resources. These users are identities within your Amazon Web Services account that have specific custom permissions. For example, you can create IAM users and give them permissions to create a directory in IAM Identity Center. IAM users have long-term credentials that they can use to access Amazon using the Amazon Web Services Management Console, or programmatically using the Amazon CLI or Amazon APIs. For step-by-step instructions for how IAM users sign in to the Amazon Web Services Management Console, see Sign in to the Amazon Web Services Management Console as an IAM user in the Amazon Sign-In User Guide.

In general, we recommend that you avoid creating IAM users because they have long-term credentials such as a username and password. Instead, require human users to use temporary credentials when accessing Amazon. You can use an identity provider for your human users to provide federated access to Amazon Web Services accounts by assuming IAM roles, which provide temporary credentials. For centralized access management, we recommend that you use IAM Identity Center to manage access to your accounts and permissions within those accounts. You can manage your user identities with IAM Identity Center, or manage access permissions for user identities in IAM Identity Center from an external identity provider. For more information, see What is IAM Identity Center in the IAM Identity Center User Guide.