Understanding and getting your Amazon credentials - Amazon General Reference
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.

Understanding and getting your Amazon credentials

Amazon requires different types of security credentials, depending on how you access Amazon. For example, you need a user name and password to sign in to the Amazon Web Services Management Console, and you need access keys to make programmatic calls to Amazon. You also need access keys to use the Amazon Command Line Interface or Amazon Tools for PowerShell.

Considerations

  • Be sure to save the following in a secure location: the email address associated with your Amazon Web Services account, the Amazon Web Services account ID, the root user password, and your account access keys. 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 access keys, you must sign into your account to create new ones.

  • We strongly recommend that you do not 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.

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

  • Never share your Amazon Web Services account root user password or access keys with anyone.

Accessing your Amazon account

The way you access your Amazon Web Services account depends on what type of Amazon user you are. There are a few different types of Amazon users. You can be an account root user, an Amazon Identity and Access Management (IAM) user, an Amazon IAM Identity Center (successor to Amazon Single Sign-On) user, or a federated identity.

You can access Amazon using the following methods:

  • Amazon Web Services Management Console sign-in page

  • Amazon access portal sign-in page

  • Federated identity

  • Programmatic methods like API, Amazon Command Line Interface, and SDK (Software Development Kit)

Amazon Web Services Management Console

Root and IAM users sign in through the Amazon Web Services Management Console. The Amazon Web Services Management Console provides a web-based user interface that you can use to create and manage your Amazon resources. For example, you can start and stop Amazon Elastic Compute Cloud (EC2) instances, create Amazon DynamoDB tables, and create Amazon Simple Storage Service (S3) buckets.

  • Root users sign in with:

    • Email address

    • Password

  • IAM users sign in with:

    • Account ID or alias

    • User name or email address

    • Password

      • Your account owner or IAM administrator should provide your account ID or alias and user name to you. They create the account and set your user name. Your user name might be your email address.

For step-by-step directions on how to sign in to the Amazon Web Services Management Console, see Signing in to the Amazon Web Services Management Console in the Amazon Sign-In User Guide.

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

Important

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 do not 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 General Reference.

Amazon access portal

IAM Identity Center users sign in through the Amazon access portal rather than the Amazon Web Services Management Console. After you sign in through the Amazon access portal, you can access your Amazon Web Services account and applications. You can access cloud applications such as Office 365, Concur, and Salesforce through the Amazon access portal. Your administrator or help desk employee should have provided you a specific sign-in URL like the following examples:

https://d-xxxxxxxxxx.awsapps.com/start

or

https://your_subdomain.awsapps.com/start

Alternatively, if you created an IAM Identity Center user for your Amazon Web Services account, you would have received an email invitation with the specific sign-in URL.

IAM Identity Center users sign in with:

  • Corporate user name

  • Corporate password

    • If prompted for a verification code, check your email and then copy and paste the code into the sign-in page.

      • Verification codes are typically sent through email, but the delivery method can vary. Your administrator establishes the security settings that requires users to provide a verification code. Check with your administrator for details.

For step-by-step directions on how to sign in to the Amazon access portal, see Signing in to the Amazon access portal in the Amazon Sign-In User Guide.

For more information about IAM Identity Center, see What is IAM Identity Center? in the Amazon IAM Identity Center (successor to Amazon Single Sign-On) User Guide.

Federated identity

Federated identities are users that can access secure Amazon Web Services account resources with external identities. 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. The type of external identity in use determines how federated identities sign in.

For more information about federated identities, see About web identity federation in the IAM User Guide.

Administrators 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 Web Services Management Console.

Note

Your administrator creates federated identities. Contact your administrator for more details on how to sign in as a federated identity.

Amazon Command Line Interface

Amazon users can also sign in with the Amazon Command Line Interface (Amazon CLI). For more information about the Amazon CLI, see What is the Amazon Command Line Interface.

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 in the IAM User Guide.

When you activate MFA and you sign in to your Amazon Web Services account, you are prompted for your user name and password, 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 in the IAM User Guide.

Access keys

When you use Amazon programmatically, you provide your Amazon access keys so that Amazon can verify your identity in programmatic calls. Access keys can be either temporary (short-term) credentials or long-term credentials, such as for an IAM user or the Amazon account root user. In many cases, there are alternatives to long-term access keys to consider.

About access keys

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 with 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. For more information, see Temporary access keys.

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.

Considerations and alternatives for 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 rotate them. Mechanisms include IAM roles or the authentication of an IAM Identity Center user. For more information, see Use temporary security credentials (IAM roles) and Temporary access keys.

  • 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 (successor to Amazon Single Sign-On) (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 (successor to Amazon Single Sign-On) 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 (successor to Amazon Single Sign-On), Connect to your external identity provider, and Permission sets in the Amazon IAM Identity Center (successor to Amazon Single Sign-On) 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.

For additional security best practices related to access keys, see Best practices for managing Amazon access keys.

Temporary access keys

You can create and use temporary access keys, known as temporary security credentials, for programmatic access requests. We recommend that you use temporary access keys over long term access keys, as mentioned in the previous section. For more information, see Using temporary credentials with Amazon resources in the IAM User Guide.

You can use temporary access keys in less secure environments, or distribute them, to grant users temporary access to resources in your Amazon Web Services account.

For example, you can grant entities from other Amazon Web Services accounts access to resources in your Amazon Web Services account (cross-account access). You can also grant users who don't have Amazon security credentials access to resources in your Amazon Web Services account (federation). For more information, see aws sts assume-role.

Long-term access keys

You can assign up to two long-term access keys per user. It is useful to have two access keys when you want to rotate them. When you disable an access key, you can't use it, but it counts toward your limit of two access keys. After you delete an access key, it's gone forever and can't be restored, but it can be replaced with a new access key.

Important

Unless there is no other option, we strongly recommend that you don't create long-term access keys for your root user. If a malicious user gains access to your root user access keys, they can completely take over your account.

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.

For more information about creating access keys for the root user, see Amazon Web Services account root user in the IAM User Guide.

For more information about creating access keys for IAM users, see Managing access keys for IAM users in the IAM User Guide.