Amazon security credentials - Amazon Identity and Access Management
Security considerationsFederated identityMulti-factor authentication (MFA)Programmatic accessAlternatives to long-term access keysAccessing Amazon using your Amazon credentials
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).

Amazon security credentials

When you interact with Amazon, you specify your Amazon security credentials to verify who you are and whether you have permission to access the resources that you are requesting. Amazon uses the security credentials to authenticate and authorize your requests.

For example, if you want to download a protected file from an Amazon Simple Storage Service (Amazon S3) bucket, your credentials must allow that access. If your credentials don't show you are authorized to download the file, Amazon denies your request. However, your Amazon security credentials aren't required for you to download a file in an Amazon S3 bucket that is publicly shared.

There are different types of users in Amazon. All Amazon users have security credentials. There is the account owner (root user), users in Amazon IAM Identity Center, federated users, and IAM users.

Users have either long-term or temporary security credentials. Root user, IAM user, and access keys have long-term security credentials that do not expire. To protect long-term credentials have processes in place to manage access keys, change passwords, and enable MFA.

IAM roles, users in Amazon IAM Identity Center, and federated users have temporary security credentials. Temporary security credentials expire after a defined period of time or when the user ends their session. Temporary credentials work almost identically to long-term credentials, with the following differences:

  • Temporary security credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, Amazon no longer recognizes them or allows any kind of access from API requests made with them.

  • Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested. When (or even before) the temporary security credentials expire, the user can request new credentials, as long as the user requesting them still has permissions to do so.

As a result, temporary credentials have the following advantages over long-term credentials:

  • You do not have to distribute or embed long-term Amazon security credentials with an application.

  • You can provide access to your Amazon resources to users without having to define an Amazon identity for them. Temporary credentials are the basis for roles and identity federation.

  • The temporary security credentials have a limited lifetime, so you do not have to update them or explicitly revoke them when they're no longer needed. After temporary security credentials expire, they cannot be reused. You can specify how long the credentials are valid, up to a maximum limit.

Security considerations

We recommend that you consider the following information when determining the security provisions for your Amazon Web Services account:

  • When you create an Amazon Web Services account, we create the account root user. The credentials of the root user (account owner) allow full access to all resources in the account. The first task you perform with the root user is to grant another user administrative permissions to your Amazon Web Services account so that you minimize the usage of the root user.

  • You can't use IAM policies to deny the root user access to resources explicitly. You can only use an Amazon Organizations service control policy (SCP) to limit the permissions of the root user.

  • If you forget or lose your root user password, you must have access to the email address associated with your account in order to reset it.

  • If you lose your root user access keys, you must be able to sign in to your account as the root user to create new ones.

  • Do not use the root user for your everyday tasks. Use it 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.

  • Security credentials are account-specific. If you have access to multiple Amazon Web Services accounts, you have separate credentials for each account.

  • Policies determine what actions a user, role, or member of a user group can perform, on which Amazon resources, and under what conditions. Using policies you can securely control access to Amazon Web Services and resources in your Amazon Web Services account. If you must modify or revoke permissions in response to a security event, you delete or modify the policies instead of making changes directly to the identity.

  • Be sure to save the sign-in credentials for your Emergency Access IAM user and any access keys you created for programmatic access in a secure location. If you lose your access keys, you must sign in to your account to create new ones.

  • We strongly recommend that you use temporary credentials provided by IAM roles and federated users instead of the long-term credentials provided by IAM users and access keys.

Federated identity

Federated identities are users with external identities that are granted temporary Amazon credentials that they can use to access secure Amazon Web Services account resources. External identities can come from a corporate identity store (such as LDAP or Windows Active Directory) or from a third party (such as Login in with Amazon, Facebook, or Google). Federated identities do not sign in with the Amazon Web Services Management Console or Amazon access portal.

To enable federated identities to sign in to AWS, you must create a custom URL that includes https://signin.aws.amazon.com/federation. For more information, see Enabling custom identity broker access to the Amazon console.

For more information about federated identities, see Identity providers and federation.

Multi-factor authentication (MFA)

Multi-factor authentication (MFA) provides an extra level of security for users who can access your Amazon Web Services account. For additional security, we recommend that you require MFA on the Amazon Web Services account root user credentials and all IAM users. For more information, see Using multi-factor authentication (MFA) in Amazon.

When you activate MFA and you sign in to your Amazon Web Services account, you are prompted for your sign-in credentials, plus a response generated by an MFA device, such as a code, a touch or tap, or a biometric scan. When you add MFA, your Amazon Web Services account settings and resources are more secure.

By default, MFA isn't activated. You can activate and manage MFA devices for the Amazon Web Services account root user by going to the Security credentials page or the IAM dashboard in the Amazon Web Services Management Console. For more information about activating MFA for IAM users, see Enabling MFA devices for users in Amazon.

For more information about signing in with multi-factor authentication (MFA) devices, see Using MFA devices with your IAM sign-in page.

Programmatic access

You provide your Amazon access keys to make programmatic calls to Amazon or to use the Amazon Command Line Interface or Amazon Tools for PowerShell. We recommend using short-term access keys when possible.

When you create a long-term access key, you create the access key ID (for example, AKIAIOSFODNN7EXAMPLE) and secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) as a set. The secret access key is available for download only when you create it. If you don't download your secret access key or if you lose it, you must create a new one.

In many scenarios, you don't need long-term access keys that never expire (as you have when you create access keys for an IAM user). Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials include an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire. After they expire, they're no longer valid.

Access key IDs beginning with AKIA are long-term access keys for an IAM user or an Amazon Web Services account root user. Access key IDs beginning with ASIA are temporary credentials access keys that you create using Amazon STS operations.

Users need programmatic access if they want to interact with Amazon outside of the Amazon Web Services Management Console. The Amazon APIs and the Amazon Command Line Interface require access keys. Whenever possible, create temporary credentials that consist of an access key ID, a secret access key, and a security token that indicates when the credentials expire.

To grant users programmatic access, choose one of the following options.

Which user needs programmatic access? To By
IAM Use short-term credentials to sign programmatic requests to the Amazon CLI or Amazon APIs (directly or by using the Amazon SDKs). Following the instructions in Using temporary credentials with Amazon resources in the IAM User Guide.
IAM

(Not recommended)

Use long-term credentials to sign programmatic requests to the Amazon CLI or Amazon APIs (directly or by using the Amazon SDKs).		 Following the instructions in Managing access keys for IAM users in the IAM User Guide.

Alternatives to long-term access keys

For many common use cases, there are alternatives to long-term access keys. To improve your account security, consider the following.

  • Don't embed long-term access keys and secret access keys in your application code or in a code repository – Instead, use Amazon Secrets Manager, or other secrets management solution, so you don't have to hardcode keys in plaintext. The application or client can then retrieve secrets when needed. For more information, see What is Amazon Secrets Manager? in the Amazon Secrets Manager User Guide.

  • Use IAM roles to generate temporary security credentials whenever possible – Always use mechanisms to issue temporary security credentials when possible, rather than long-term access keys. Temporary security credentials are more secure because they are not stored with the user but are generated dynamically and provided to the user when requested. Temporary security credentials have a limited lifetime so you don't have to manage or update them. Mechanisms that provide temporary access keys include IAM roles or the authentication of an IAM Identity Center user. For machines that run outside of Amazon you can use Amazon Identity and Access Management Roles Anywhere.

  • Use alternatives to long-term access keys for the Amazon Command Line Interface (Amazon CLI) or the aws-shell – Alternatives include the following.

    • Amazon CloudShell is a browser-based, pre-authenticated shell that you can launch directly from the Amazon Web Services Management Console. You can run Amazon CLI commands against Amazon Web Services through your preferred shell (Bash, Powershell, or Z shell). When you do this, you don't need to download or install command line tools. For more information, see What is Amazon CloudShell? in the Amazon CloudShell User Guide.

    • Amazon CLI Version 2 integration with Amazon IAM Identity Center (IAM Identity Center). You can authenticate users and provide short-term credentials to run Amazon CLI commands. To learn more, see Integrating Amazon CLI with IAM Identity Center in the Amazon IAM Identity Center User Guide and Configuring the Amazon CLI to use IAM Identity Center in the Amazon Command Line Interface User Guide.

  • Don't create long-term access keys for human users who need access to applications or Amazon Web Services – IAM Identity Center can generate temporary access credentials for your external IdP users to access Amazon Web Services. This eliminates the need to create and manage long-term credentials in IAM. In IAM Identity Center, create an IAM Identity Center permission set that grants the external IdP users access. Then assign a group from IAM Identity Center to the permission set in the selected Amazon Web Services accounts. For more information, see What is Amazon IAM Identity Center, Connect to your external identity provider, and Permission sets in the Amazon IAM Identity Center User Guide.

  • Don't store long-term access keys within an Amazon compute service – Instead, assign an IAM role to compute resources. This automatically supplies temporary credentials to grant access. For example, when you create an instance profile that is attached to an Amazon EC2 instance, you can assign an Amazon role to the instance and make it available to all of its applications. An instance profile contains the role and enables programs that are running on the Amazon EC2 instance to get temporary credentials. To learn more, see Using an IAM role to grant permissions to applications running on Amazon EC2 instances.

Accessing Amazon using your Amazon credentials

Amazon requires different types of security credentials, depending on how you access Amazon and what type of Amazon user you are. For example, you use sign-in credentials for the Amazon Web Services Management Console while you use access keys to make programmatic calls to Amazon. Also, each identity you use, whether it be the account root user, an Amazon Identity and Access Management (IAM) user, an Amazon IAM Identity Center user, or a federated identity, has unique credentials within Amazon.

For step-by-step instructions on how to sign in to Amazon according to your user type, see How to sign in to Amazon in the Amazon Sign-In User Guide.