Overview of Amazon identity management: Users - 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).

Overview of Amazon identity management: Users

You can give access to your Amazon Web Services account to specific users and provide them specific permissions to access resources in your Amazon Web Services account. You can use both IAM and Amazon IAM Identity Center to create new users or federate existing users into Amazon. The main difference between the two is that IAM users are granted long-term credentials to your Amazon resources while users in IAM Identity Center have temporary credentials that are established each time the user signs-in to Amazon. As a best practice, require human users to use federation with an identity provider to access Amazon using temporary credentials instead of as an IAM user. A primary use for IAM users is to give workloads that cannot use IAM roles the ability to make programmatic requests to Amazon services using the API or CLI.

First-time access only: Your root user credentials

When you 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. 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 IAM User Guide. Only service control policies (SCPs) in organizations can restrict the permissions that are granted to the root user.

IAM users and users in IAM Identity Center

IAM users are not separate accounts; they are users within your account. Each user can have its own password for access to the Amazon Web Services Management Console. You can also create an individual access key for each user so that the user can make programmatic requests to work with resources in your account.

IAM users are granted long-term credentials to your Amazon resources. As a best practice, do not create IAM users with long-term credentials for your human users. Instead, require your human users to use temporary credentials when accessing Amazon.

Note

For scenarios in which you need IAM users with programmatic access and long-term credentials, we recommend that you update access keys when needed. For more information, see Updating access keys.

In contrast, users in Amazon IAM Identity Center are granted short-term credentials to your Amazon resources. For centralized access management, we recommend that you use Amazon IAM Identity Center (IAM Identity Center) to manage access to your accounts and permissions within those accounts. IAM Identity Center is automatically configured with an Identity Center directory as your default identity source where you can create users and groups, and assign their level of access to your Amazon resources. For more information, see What is Amazon IAM Identity Center in the Amazon IAM Identity Center User Guide.

Federating existing users

If the users in your organization already have a way to be authenticated, such as by signing in to your corporate network, you don't have to create separate IAM users or users in IAM Identity Center for them. Instead, you can federate those user identities into Amazon using either IAM or Amazon IAM Identity Center.

The following diagram shows how a user can get temporary Amazon security credentials to access resources in your Amazon Web Services account.


        Users who are already authenticated elsewhere can be federated into Amazon and assume
          an IAM role that gives them permissions to access specific resources.For more
          information about roles, see Roles terms and concepts.

Federation is particularly useful in these cases:

  • Your users already exist in a corporate directory.

    If your corporate directory is compatible with Security Assertion Markup Language 2.0 (SAML 2.0), you can configure your corporate directory to provide single-sign on (SSO) access to the Amazon Web Services Management Console for your users. For more information, see Common scenarios for temporary credentials.

    If your corporate directory is not compatible with SAML 2.0, you can create an identity broker application to provide single-sign on (SSO) access to the Amazon Web Services Management Console for your users. For more information, see Enabling custom identity broker access to the Amazon console.

    If your corporate directory is Microsoft Active Directory, you can use Amazon IAM Identity Center to connect a self-managed directory in Active Directory or a directory in Amazon Directory Service to establish trust between your corporate directory and your Amazon Web Services account.

    If you are using an external identity provider (IdP) such as Okta or Microsoft Entra to manage users, you can use Amazon IAM Identity Center to establish trust between your IdP and your Amazon Web Services account. For more information, see Connect to an external identity provider in the Amazon IAM Identity Center User Guide.

  • Your users already have Internet identities.

    If you are creating a mobile app or web-based app that can let users identify themselves through an Internet identity provider like Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC) compatible identity provider, the app can use federation to access Amazon. For more information, see OIDC federation.

    Tip

    To use identity federation with Internet identity providers, we recommend you use Amazon Cognito.

Access control methods

Here are the ways you can control access to your Amazon resources.

Type of user access Why would I use it? Where can I get more information?

Single sign-on access for human users, such as your workforce users, to Amazon resources using IAM Identity Center

IAM Identity Center provides a central place that brings together administration of users and their access to Amazon Web Services accounts and cloud applications.

You can set up an identity store within IAM Identity Center or you can configure federation with an existing identity provider (IdP). Granting your human users limited credentials to Amazon resources as needed is recommended as a security best practice.

Users have an easier sign-in experience and you maintain control over their access to resources from a single system. IAM Identity Center supports multi-factor authentication (MFA) for additional account security.

For more information about setting up IAM Identity Center, see Getting Started in the Amazon IAM Identity Center User Guide

For more information about using MFA in IAM Identity Center, see Multi-factor authentication in the Amazon IAM Identity Center User Guide

Federated access for human users, such as your workforce users, to Amazon services using IAM identity providers

IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0). After you create an IAM identity provider, you must create one or more IAM roles that can be dynamically assigned to a federated user.

For more information about IAM identity providers and federation, see Identity providers and federation.

Cross-account access between Amazon Web Services accounts

You want to share access to certain Amazon resources with users in other Amazon Web Services accounts.

Roles are the primary way to grant cross-account access. However, some Amazon services allow you to attach a policy directly to a resource (instead of using a role as a proxy). These are called resource-based policies.

For more information about IAM roles, see IAM roles.

For more information about service-linked roles, see Using service-linked roles.

For information about which services support using service-linked roles, see Amazon services that work with IAM. Look for the services that have Yes in the Service-Linked Role column. To view the service-linked role documentation for that service select the link associated with the Yes in that column.

Long-term credentials for designated IAM users in your Amazon Web Services account

You might have specific use cases that require long-term credentials with IAM users in Amazon. You can use IAM to create these IAM users in your Amazon Web Services account, and use IAM to manage their permissions. Some of the use cases include the following:

  • Workloads that cannot use IAM roles

  • Third-party Amazon clients that require programmatic access through access keys

  • Service-specific credentials for Amazon CodeCommit or Amazon Keyspaces

  • Amazon IAM Identity Center is not available for your account and you have no other identity provider

As a best practice in scenarios in which you need IAM users with programmatic access and long-term credentials, we recommend that you update access keys when needed. For more information, see Updating access keys.

For more information about setting up an IAM user, see Creating an IAM user in your Amazon Web Services account.

For more information about IAM user access keys, see Managing access keys for IAM users.

For more information about service-specific credentials for Amazon CodeCommit or Amazon Keyspaces, see Using IAM with CodeCommit: Git credentials, SSH keys, and Amazon access keys and Using IAM with Amazon Keyspaces (for Apache Cassandra).