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.

IAM Identities (users, user groups, and roles)

Important

The IAM best practices have been updated. As a best practice, require human users to use federation with an identity provider to access Amazon using temporary credentials. An additional best practice recommendation is to require workloads to use temporary credentials with IAM roles to access Amazon. IAM users are to be used only in very limited scenarios where an IAM role cannot be assumed. To learn about using Amazon IAM Identity Center (successor to Amazon Single Sign-On) to create users with temporary credentials, see Getting started in the Amazon IAM Identity Center (successor to Amazon Single Sign-On) User Guide.

Tip

Having trouble signing in to Amazon? Make sure that you're on the correct Amazon sign-in page for your type of user:

  • 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.

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 in the Amazon Account Management Reference Guide.

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, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see Rotate access keys regularly 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.

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 is similar to an IAM user, but is not 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 How IAM roles differ from resource-based policies.

  • 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. Policies grant permissions to a principal. When you use some services, you might perform an action that then triggers another action in a different service. In this case, you must have permissions to perform both actions. To see whether an action requires additional dependent actions in a policy, see Actions, resources, and condition keys for Identity And Access Management; in the Service Authorization Reference.

    • 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 IAM 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 are not 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 (successor to Amazon Single Sign-On) 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 are not 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.

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: