Which of the following can be used as an additional layer of security to using a user name and password when logging into the AWS console?

AWS requires different types of security credentials, depending on how you access AWS and what type of AWS user you are. 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. Also, 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.

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.

You can access AWS using the following methods.

AWS Management Console sign-in page

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.

To sign in as a root user

You need the email address used to create the AWS account and the password for the root user. For more information see Signing in as the root user in the AWS Sign-In User Guide.

To sign in as an IAM user

The account owner provides you with the account ID or alias, your user name, and your password. For more information, see Signing in as an IAM user in the AWS Sign-In User Guide.

For troubleshooting information, see Troubleshooting sign-in issues in the AWS Sign-In User Guide.

AWS access portal sign-in page

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. For more information, see the AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide.

To sign in, you need a sign-in URL, user name, and password. Your administrator or help desk employee provides you with this information. Alternatively, if you created an IAM Identity Center user for your AWS account, you received an email invitation with the specific sign-in URL.

To sign in using the AWS access portal

For step-by-step directions, see Signing in to the AWS access portal in the AWS Sign-In 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.

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

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.

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

Programmatic access

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.

Access keys

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.

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.

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 and Use temporary security credentials in the AWS Account Management Reference 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.

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.

Create long-term access keys

The procedures to create long-term access keys depend on whether you are the AWS account root user or an IAM user.

To create access keys for the AWS account root user

Follow the step-by-step directions in Creating and deleting access keys for the AWS account root user in the AWS Account Management Reference Guide.

To create access keys for IAM users

Follow the step-by-step directions in Managing access keys for IAM users in the IAM User Guide.

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