When you access AWS programmatically, you verify your identity and the identity of your
applications by using an access key. An access key consists of an access key ID (something
AKIAIOSFODNN7EXAMPLE) and a secret access key (something like
Anyone who has your access key has the same level of access to your AWS resources that you do. Consequently, we go to significant lengths to protect your access keys, and in keeping with our shared-responsibility model, you should as well.
In this topic we describe a number of steps you should take to protect access keys. For general background, see AWS Security Credentials.
Your organization may have different security requirements and policies than those described in this topic. The suggestions provided here are intended to be general guidelines.
An access key is required in order to sign requests that you make using the command-line interface (CLI), using the AWS SDKs, or using direct API calls. Anyone who has the access key for your root account has unrestricted access to all the resources in your account, including billing information.
One of the best ways to protect your account is to not have an access key for your root account. We recommend that unless you must have a root access key (this is very rare), that you do not generate one. Instead, AWS best practice is to create one or more AWS Identity and Access Management (IAM) users, give them the necessary permissions, and use IAM users for everyday interaction with AWS.
If you already have an access key for your account, we recommend that you find places in your applications where you are currently using that key (if any), replace the root access key with an IAM user access key, and then disable and remove the root access key. For details about how to substitute one access key for another, see the post How to rotate access keys for IAM users on the AWS Security Blog.
By default, AWS does not generate an access key for new accounts.
For information about how to create IAM users with administrative permissions, see Getting Started in the Using IAM guide.
In many scenarios, you don't need a long-term access key that never expires (as you have with an IAM user) . Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials consist of an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire.
Use an IAM role and temporary security credentials in these scenarios:
You have an application or CLI scripts running on an Amazon EC2 instance. Do not pass an access key to the application, embed it in the application, or have the application read a key from a source such as an Amazon S3 bucket (even if the bucket is encrypted). Instead, define an IAM role that has appropriate permissions for your application and launch the Amazon EC2 instance with Roles for EC2. This associates an IAM role with the Amazon EC2 instance and lets the application get temporary security credentials that it can in turn use to make AWS calls. The AWS SDKs and the CLI can get temporary credentials from the role automatically.
You need to grant cross-account access. Use an IAM role to establish trust between accounts, and then grant users in one account limited permissions to access the trusted account. For more information, see Cross-Account API Access Using IAM Roles.
You have a mobile app. Do not embed an access key with the app, even in encrypted storage. Instead, use Amazon Cognito to manage user identity in your app. This service lets you authenticate users using Login with Amazon, Facebook, or Google. You can then use the Amazon Cognito credentials provider to manage credentials that your app uses to make requests to AWS. For more information, see Using the Amazon Cognito Credentials Provider on the AWS Mobile Development blog.
If your mobile app doesn't support authentication using Login with Amazon, Facebook, or Google, you can create a proxy server that can dispense temporary credentials to your app. For more information, see Creating a Mobile App with Custom Authentication.
You want to federate into AWS and your organization supports SAML 2.0. If you work with an organization that has an identity provider that supports SAML 2.0, configure the provider to use SAML to exchange authentication information with AWS and get back a set of temporary security credentials. For more information, see Using Your Organization's Authentication System and SAML to Grant Access to AWS Resources.
You want to federate into AWS and your organization has an on-premises identity store. If users can authenticate inside your organization, you can write an application that can issue them temporary security credentials for access to AWS resources. For more information, see Using Your Organization's Authentication System to Grant Access to AWS Resources.
If you do need to create access keys for programmatic access to AWS, create an IAM user and grant that user only the permissions he or she needs. Then generate an access key for that user. For details, see Administering Access Keys for IAM Users in the Using IAM guide.
Remember that if you are running an application on an Amazon EC2 instance and the application needs access to AWS resources, you should use an IAM role and Roles for EC2, as described in the previous section.
Don't embed access keys directly into code. The AWS SDKs and the AWS CLI allow you to put access keys in known locations so that you do not have to keep them in code.
Put access keys in one of the following locations:
Environment variables. On a multi-tenant system, choose user environment variables, not system environment variables.
A configuration file that is kept separately from the source code (that is, one that's not checked into a source code repository) and that uses access control to make it available only to authorized parties.
If the configuration file is part of a project in Eclipse, Visual Studio, or another IDE, remove the keys before distributing or sharing the project (for example, on a developer site).
We recommend specifically configuring your source-control software to ignore the access keys configuration file, for example using gitignore.
Use different access keys for different applications. Do this so that you can isolate the permissions and revoke the access keys for individual applications if an access key is exposed. Having separate access keys for different applications also generates distinct entries in AWS CloudTrail log files, which makes it easier for you to determine which application performed specific actions.
Rotate access keys periodically. Change access keys on a regular basis. For details, see How to rotate access keys for IAM users on the AWS Security Blog.
Remove unused access keys. If a user leaves your organization, remove the corresponding IAM user so that the user's access to your resources is removed.
Configure multi-factor authentication for your most sensitive operations. For details, see Using Multi-Factor Authentication (MFA) Devices with AWS in the Using IAM guide.
For more information about best practices for keeping your AWS account secure, see the following resources:
IAM Best Practices. This topic presents a list of suggestions for using the IAM service to help secure your AWS resources.
The following pages provide guidance for setting up the SDKs and the command-line interface (CLI) to use access keys.
Using IAM Roles for Amazon EC2 Instances with the AWS SDK for .NET. This topic discusses how programs written using the .NET SDK can automatically get temporary security credentials via a role in an Amazon EC2 instance. Similar topics are available for the AWS Java SDK and the AWS Ruby SDK.