Understanding and getting your AWS credentials - AWS General Reference

Understanding and getting your AWS credentials

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

Considerations

  • Be sure to save the following in a secure location: the email address associated with your AWS account, the AWS 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 AWS accounts, you have separate credentials for each account.

  • Never share your AWS account root user password or access keys with anyone.

Accessing your AWS account

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

You can access AWS using the following methods:

  • AWS Management Console sign-in page

  • AWS access portal sign-in page

  • Federated identity

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

AWS Management Console

Root and IAM users sign in through the AWS Management Console. The AWS Management Console provides a web-based user interface that you can use to create and manage your AWS 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 AWS Management Console, see Signing in to the AWS Management Console in the AWS 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 AWS account, you begin with one sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS 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 AWS General Reference.

AWS access portal

IAM Identity Center users sign in through the AWS access portal rather than the AWS Management Console. After you sign in through the AWS access portal, you can access your AWS account and applications. You can access cloud applications such as Office 365, Concur, and Salesforce through the AWS 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 AWS 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 AWS access portal, see Signing in to the AWS access portal in the AWS Sign-In User Guide.

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

Federated identity

Federated identities are users that can access secure AWS 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 AWS Management Console or AWS 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 AWS Management Console.

Note

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

AWS Command Line Interface

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

Multi-factor authentication (MFA)

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

When you activate MFA and you sign in to your AWS 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 AWS account settings and resources are more secure.

By default, MFA isn't activated. You can activate and manage MFA devices for the AWS account root user by going to the Security credentials page or the IAM dashboard in the AWS 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 AWS programmatically, you provide your AWS access keys so that AWS 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 AWS 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 AWS account root user. Access key IDs beginning with ASIA are temporary credentials access keys that you create using AWS 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 AWS 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 AWS Secrets Manager? in the AWS 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 AWS Command Line Interface (AWS CLI) or the aws-shell Alternatives include the following.

    • AWS CloudShell is a browser-based, pre-authenticated shell that you can launch directly from the AWS Management Console. You can run AWS CLI commands against AWS 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 AWS CloudShell? in the AWS CloudShell User Guide.

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

  • Don't create long-term access keys for human users who need access to applications or AWS services – IAM Identity Center can generate temporary access credentials for your external IdP users to access AWS 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 AWS accounts. For more information, see What is AWS IAM Identity Center (successor to AWS Single Sign-On), Connect to your external identity provider, and Permission sets in the AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide.

  • Don't store long-term access keys within an AWS 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 AWS 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 AWS 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 AWS 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 AWS account.

For example, you can grant entities from other AWS accounts access to resources in your AWS account (cross-account access). You can also grant users who don't have AWS security credentials access to resources in your AWS 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 AWS access keys to make programmatic calls to AWS or to use the AWS Command Line Interface or AWS Tools for PowerShell.

For more information about creating access keys for the root user, see AWS 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.