About AWS Security Credentials

Topics

Quick Start
Introduction to AWS Security Credentials
Access Credentials
Sign-In Credentials
- E-mail Address and Password
- AWS Multi-Factor Authentication
Account Identifiers
Using Credentials with Amazon EC2

Quick Start

The following table helps you choose which credentials to use, based on the task you want to perform.

If You Want to...	Use This Credential...	Learn More
Make a REST or Query API request to an AWS product	Your Access Keys	Access Keys
Make a SOAP API request to an AWS product	Your X.509 Certificates (except for Amazon S3 and Amazon Mechanical Turk, which require your Access Keys)	X.509 Certificates Access Keys
Access secure pages on the AWS web site or AWS Management Console	Your Amazon E-mail Address and Password with optional AWS Multi-Factor Authentication	Sign-In Credentials
Use the Amazon EC2 command line tools	Your X.509 Certificates	X.509 Certificates
Launch or connect to an Amazon EC2 instance	Your Amazon EC2 Key Pairs	Amazon EC2 Key Pairs
Bundle an Amazon EC2 AMI	For Linux/UNIX AMIs: your X.509 Certificates and AWS Account ID to bundle the AMI, and your Access Keys to upload it to Amazon S3. For Windows AMIs: your Access Keys for both bundling and uploading the AMI.	X.509 Certificates Account Identifiers Access Keys
Share an Amazon EC2 AMI or Amazon EBS snapshot	The AWS Account ID of the account you want to share with (without the hyphens)	Account Identifiers
Create a signed URL to access Amazon CloudFront private content	Your Amazon CloudFront Key Pairs	Amazon CloudFront Key Pairs
Send email by using the Amazon SES SMTP endpoint	Your Amazon SES SMTP user name and password	Amazon SES SMTP User Name and Passwords
Access the AWS Discussion Forums or AWS Premium Support site	Your Amazon E-mail Address and Password	Sign-In Credentials

Introduction to AWS Security Credentials

Access to applications and services within the AWS cloud is secure and protected in multiple ways. Accessing those applications and services requires the use of special credentials that are associated with your account. The credentials give you access to different interfaces and resources you use with AWS, as illustrated in the following diagram.

Two of the main sites you might use are the AWS web site at http://aws.amazon.com and the AWS Management Console at http://aws.amazon.com/console.

You might use a third-party product (e.g., S3Fox) or library (e.g., Boto), which in turn uses an AWS product API.

If you're a developer writing your own library, then you'll use the APIs for different AWS products, (e.g., REST, Query, SOAP, or a command line interface).

You might also access resources such as Amazon Elastic Compute Cloud (Amazon EC2) instances or Amazon Simple Storage Service (Amazon S3) objects.

All of these interfaces and resources require you to use AWS credentials. The following sections give more details about which credentials you use where. For information about exactly how to use a credential, consult the documentation for the AWS product or tool you're using the credential with.

Access Credentials

One of the primary ways to use AWS products is through an API. You'll probably use an existing tool or library that in turn uses a product's API.

Each product has one or more APIs available (types: REST, Query, or SOAP). Some products (like Amazon EC2) also have a simple command line interface that uses one of the other APIs.

When you send a request to an AWS product API, you use a credential to authenticate yourself to AWS. In the basic process of authentication with AWS, you use your credential and part of the request itself to create a digital signature. You send the request and the signature to AWS. AWS then verifies the signature to confirm you're the sender of the request. You get access to the product only if the signature passes verification. Details about how authentication works for each AWS product are available from the product technical documentation at http://aws.amazon.com/documentation.

The credential you use depends on the type of API. The REST and Query APIs use your access keys as the credential. The SOAP APIs for most AWS products use your X.509 certificates as the credential (although Amazon S3 and Amazon Mechanical Turk use your access keys). If you're using a tool or library (as opposed to writing your own), consult its documentation to find out which type of credential it uses.

If you use Amazon EC2 or Amazon CloudFront, you'll probably also use key pairs. The Key Pairs tab on the Security Credentials page displays two types: Amazon EC2 key pairs, and Amazon CloudFront key pairs. Amazon EC2 key pairs enable you to access the instances you launch. Amazon CloudFront key pairs enable you to create signed URLs to access private CloudFront content.

Access Keys

Your access keys are based on the idea of symmetric key cryptography. We recommend you take a few minutes to familiarize yourself with it to help you understand how AWS uses your access keys to secure your requests. For more information about symmetric key cryptography, go to http://en.wikipedia.org/wiki/Symmetric-key_algorithm.

Purpose	Making requests to AWS product REST or Query APIs. You might be using a third-party product such as S3Fox that requires your access keys (because the product itself makes AWS requests for you). Although access keys are primarily used for REST or Query APIs, Amazon S3 and Amazon Mechanical Turk also use access keys with their SOAP APIs.
Getting Them	AWS provides them on the Access Keys tab on the AWS Security Credentials page.
Replacing Them	For security purposes, we recommend you change your access keys every 90 days. For more information, see Access Credential Rotation.
Parts & Usage	Access Key ID—Your Access Key ID identifies you as the party responsible for service requests. You include it in each request, so it's not a secret. Secret Access Key—Each Access Key ID has a Secret Access Key associated with it. This key is just a long string of characters (and not a file) that you use to calculate the digital signature that you include in the request. Your Secret Access Key is a secret, and only you and AWS should have it. Don't e-mail it to anyone, include it any AWS requests, or post it on the AWS Discussion Forums. No authorized person from AWS will ever ask for your Secret Access Key. When you create a request, you create a digital signature with your secret key and include it in the request along with your Access Key ID. When we get the request, we use your Access Key ID to look up the corresponding Secret Access Key. We use the key to validate the signature and confirm that you're the request sender.

X.509 Certificates

X.509 certificates are based on the idea of public key cryptography. We recommend you take a few minutes to familiarize yourself with it to help you understand how AWS uses your X.509 certificates to secure your requests. For more information about public key cryptography, go to http://en.wikipedia.org/wiki/Public_Key_Cryptography.

Purpose	Making requests to AWS product SOAP APIs (except for Amazon S3 and Amazon Mechanical Turk, which use access keys for their SOAP APIs). They're also used for some specific Amazon EC2 tasks (see Using Credentials with Amazon EC2).
Getting Them	You can have AWS generate the certificate and private key files for you, or you can provide your own certificate file. In both cases, you need to go to the X.509 Certificates tab on the AWS Security Credentials page. For creating certificates for IAM users, see Creating and Uploading a User Signing Certificate in the Using IAM guide.
Replacing Them	For security purposes, we recommend you change your X.509 certificates every 90 days. For more information, see Access Credential Rotation.
Parts & Usage	Your X.509 certificates consist of a certificate file and a private key file: X.509 Certificate—The certificate holds the public key and related metadata. You include it in each service request, so it's not a secret. Private Key—Each certificate has a private key associated with it. Use the private key to calculate the digital signature to include in the request. Your private key is a secret, and only you should have it. AWS doesn't keep a copy of it. Don't e-mail it to anyone, include it any AWS requests, or post it on the AWS Discussion Forums. No authorized person from AWS will ever ask for your private key. When you create a request, you create a digital signature with your private key and include it in the request, along with your certificate. When we get the request, we use the public key in the certificate to decrypt the signature and confirm that you're the request sender. We also verify the certificate you provide matches the one we have on file. If you have us generate your X.509 certificates, we give you a PEM-encoded certificate file, and a PEM-encoded private key (unencrypted, which means you don't get a password for it). You'll need to convert the files to whatever format your toolkit uses (see the toolkit's documentation for help). Even though we provide you the private key, we don't store it anywhere. If you lose it, you must switch to using a different X.509 certificate. If you provide your own keys, you must upload only your certificate to AWS (you keep the private key). The certificate must be in PEM format. AWS accepts any syntactically and cryptographically valid, unexpired X.509 certificates. They don't need to be from a formal Certificate Authority (CA).

Amazon EC2 Key Pairs

You use an Amazon EC2 key pair each time you launch an EC2 Linux/UNIX or Windows instance. The key pair ensures that only you have access to the instance.

Purpose	Launching and connecting to Amazon EC2 instances
Getting Them	You can create EC2 key pairs with the Amazon EC2 API, or any interface or tool that uses the API (such as the AWS Management Console).
Replacing Them	You can't replace a particular EC2 key pair. However, you can have as many as you like. You can use one EC2 key pair for all your instances, or one pair for a particular type of instance—how you organize them is up to you. However, it's important that you don't lose the private key for a Linux/UNIX instance. If you do, you can no longer access the instance through SSH.
Parts & Usage	Each EC2 key pair includes a key pair name, a private key, and a public key: Key pair name—When you create an EC2 key pair, you give it a friendly name. Make sure to record the name, because you must provide it when launching an instance with the associated key pair. Private key—When you create the EC2 key pair, you download the private key and give the downloaded file a name. We recommend you use the same name you used for the key pair itself. You store the private key locally on the system you're using to access the instance. Your private key is a secret, and should be readable only by you. AWS doesn't have a copy of it. Don't e-mail it to anyone, include it any AWS requests, or post it on the AWS Discussion Forums. No authorized person from AWS will ever ask for your private key. Public key—When you create the EC2 key pair, AWS keeps the public key (it's not available for you to download). When you launch an instance, you specify a particular EC2 key pair name, and AWS puts a copy of the public key from that pair on the instance. Only the holder of the private key (you) should therefore be able to access the instance. For root access to a Linux/UNIX instance via SSH, you provide the name of the private key as part of the SSH command. AWS uses that key to authenticate your access to the instance. For administrator access to a Windows instance via a Remote Desktop Client, you use the private key in an API call to retrieve and decrypt the initial administrator password. You then use that administrator password to access the instance.

Amazon CloudFront Key Pairs

You use Amazon CloudFront key pairs to create signed URLs, which you can use to control access to files that you are distributing with CloudFront. To learn more about using signed URLs to restrict access to your content, see Using Signed URLs to Serve Private Content in the Amazon CloudFront Developer Guide.

Note: CloudFront key pairs are unrelated to AWS access keys, which you use to authenticate requests to REST or query APIs for CloudFront and other AWS services. CloudFront key pairs are also unrelated to Amazon EC2 key pairs. You cannot use an Amazon EC2 key pair instead of a CloudFront key pair because Amazon EC2 doesn't make the key pair ID available.

Purpose	Creating signed URLs to allow access to CloudFront private content
Getting Them	AWS can generate a CloudFront key pair for you, or you can provide your own. Both options are available on the Key Pairs tab on the AWS Security Credentials page. Note: A CloudFront key pair is associated with your AWS account, and you can create key pairs only for AWS accounts. You cannot create key pairs for IAM users.
Replacing Them	For security purposes, we recommend you change your Amazon CloudFront key pairs every 90 days. For more information, see Access Credential Rotation.
Parts & Usage	Your Amazon CloudFront key pair includes a public key, a private key, and an ID for the key pair: Public key—CloudFront uses the public key to decrypt the signature portion of a signed URL. AWS stores the public key from a key pair. Private key—You use the private key to encrypt the signature portion of a CloudFront-signed URL. You keep the private key from a key pair. Your private key is a secret, and only you should have it. AWS doesn't have a copy of it. Don't e-mail it to anyone, include it in any AWS requests, or post it on the AWS Discussion Forums. No authorized person from AWS will ever ask for your private key. Key pair ID—You include the key pair ID as a parameter in a CloudFront signed URL. CloudFront uses the key pair ID to determine which public key to use to decrypt the signature portion of the signed URL. When you create a signed URL, you use your private key to create a digital signature, and you include the digital signature and the key pair ID in the URL When CloudFront receives a request for an object in the form of a signed URL, CloudFront decrypts the signature using the public key that is associated with the key pair ID. CloudFront then confirms that the signed URL is valid and that access should be granted to the requested content. You can have AWS generate a CloudFront key pair or provide your own key pair: If you have AWS generate a CloudFront key pair: We give you an RSA private key in PEM format, along with a key pair ID. We don't give you the public key, but it's available to download from the AWS Security Credentials page. Even though we generate and give you the private key, we don't store it anywhere. If you lose the private key, you must switch to using a different key pair. If you provide your own key pair: You upload only your public key to AWS. You keep the private key. The public key must be an RSA key in PEM format. When you upload the public key, we give you a key pair ID to use in your CloudFront-signed URLs.

Amazon SES SMTP User Names and Passwords

You use Amazon SES SMTP User Names and Passwords to send email by using the Amazon SES SMTP interface. This interface lets you configure a wide variety of SMTP-enabled programming languages and software packages to send email through Amazon SES.

Note: Amazon SES also uses access keys (to authenticate requests you make to the Amazon SES API).

Purpose	Connecting to the Amazon SES SMTP endpoint
Getting Them	You can use the AWS Management Console to create your SMTP user name and password. To create an SMTP user name and password, go to the Amazon SES dashboard and click SMTP Settings.
Replacing Them	Amazon SES uses AWS Identity and Access Management (IAM) for managing your SMTP credentials. If you want to change your SMTP password, go to the IAM console and delete your existing IAM user, and then go to the Amazon SES console to regenerate your SMTP credentials.
Parts & Usage	Your Amazon SES SMTP credentials consist of an IAM user name, SMPT user name, and SMTP password: IAM User Name—A friendly name that you assign to your SMTP credentials. The IAM user name is not the same thing as your SMTP user name. The Amazon SES SMTP endpoint will not recognize the IAM user name as a valid SMTP user name. SMTP User Name—The IAM access key that's associated with your IAM user name. It is also the user name that you provide when you connect to the Amazon SES SMTP endpoint. SMTP Password—The IAM secret key that's associated with your IAM user name. It is also the password that you provide when you connect to the Amazon SES SMTP endpoint. You can only view your SMTP password when you create it. If you forget your SMTP password, you must delete and then regenerate your SMTP credentials. When you create your SMTP credentials, you can use them to connect to the Amazon SES SMTP endpoint. For more information about sending email by using the Amazon SES SMTP endpoint, go to the Amazon SES Developer Guide.

Access Credential Rotation

To help secure your applications and AWS resources, you should change (i.e., rotate) your access credentials on a regular basis (we recommend every 90 days). If a malicious user gets one of your credentials, then you should replace it immediately to minimize harm.

For each of the access credentials discussed in the preceding sections (except Amazon EC2 key pairs), you can have two credentials in an Active state at any point in time so you can rotate them without impact to your application's availability. The AWS Security Credentials page displays the current state of each of the credentials you can rotate. The possible states:

Active—Can be used to secure requests to AWS.

Inactive—Can't be used, but can be moved back to the Active state.

Deleted—Can never be used again.

Let's say you start with one access key and use it with your applications for three months. For security purposes, you want to switch to a different access key. The following procedure lets you rotate your access keys without interruption to your applications.

To rotate a credential

While still using the first credential, create a second credential, which will be in an Active state by default.

At this point, you have two active credentials.

Update your applications to use the new credential.

Change the first credential's state to Inactive.

Confirm, using only the new credential, that your applications are working well. If you need to, you can revert to using the original credential by switching its state back to Active.

Delete the first credential.

Sign-In Credentials

As an AWS user, you need to access secure pages on the AWS web site, and you might want to use the AWS Management Console. To sign in to these sites, you need your email address login and password.

Email Address and Password

The locations where you use your email address and password include:

Note that your AWS account is just an Amazon.com account that has been enabled for AWS products. Therefore, the email address login and password also work with the Amazon.com site.

You should not write down your password or give it to anyone. Anyone you give it to will have access to your credit card information and your credentials. We recommend your password be at least 8 characters long and include uppercase and lowercase letters, at least one number, and at least one special character. We also recommend you use AWS Multi-Factor Authentication to further protect your account.

You can change both your login and password on the Sign-In Credentials area of the AWS Security Credentials page.

AWS Multi-Factor Authentication

Your sign-in credentials provide one level of security when you access secure AWS web sites and the AWS Management Console. To add an extra layer of security, we recommend you use AWS Multi-Factor Authentication (AWS MFA), an optional account feature.

Once you enable AWS MFA, you must provide a six-digit single-use code in addition to your sign-in credentials whenever you access secure AWS web site pages or the AWS Management Console. You get this single-use code from an authentication device that you keep in your physical possession. This is called Multi-Factor Authentication because two factors are checked before access is granted to your account: You must provide both your Amazon email login and password (the first factor: something you know), and the precise code from your authentication device (the second factor: something you have).

It's easy to obtain an authentication device from a participating third-party provider and set it up for use. For more information, go to http://aws.amazon.com/mfa.

Account Identifiers

AWS assigns two unique IDs to each AWS account:

AWS Account ID—If you want to let someone else use one of your AWS resources (for example, an Amazon EC2 AMI, Amazon EBS snapshot, or Amazon SQS queue), you use the AWS Account ID to specify the account. Example ID: 1234-5678-9012. Typically, the AWS product requires you to remove the hyphens from the ID.

Canonical User ID—If you want to share Amazon S3 resources (objects and buckets) with another AWS account, you use this ID to specify the account. The ID is a long string.

You get both IDs from the Account Identifiers area of the AWS Security Credentials page. You can't change either ID.

Using Credentials with Amazon EC2

Like other AWS products, Amazon EC2 requires you to use access keys and X.509 certificates when accessing its APIs. However, there's more to using Amazon EC2 than just using an API. You can use the command line tools, bundle AMIs, connect to instances, etc. The following table lists which credential you use when.

For more information about using your credentials with Amazon EC2, refer to the Amazon Elastic Compute Cloud User Guide or the Amazon Elastic Compute Cloud Developer Guide.

If You Want to...	Use This Credential...
Bundle a Linux/UNIX AMI	For bundling: X.509 Certificates AWS Account ID as your user name (without the hyphens) For uploading the AMI to Amazon S3: Access Keys Note: If you rotate your X.509 certificates, you're still able to launch an AMI that was bundled using an old certificate.
Bundle a Windows AMI	Access Keys Used for both bundling and uploading the AMI to Amazon S3
Use the command line tools	X.509 Certificates
Use the REST API	Access Keys
Use the SOAP API	X.509 Certificates
Launch and connect to an instance	Amazon EC2 Key Pairs (commonly called an "SSH key pair") Administrator password (Windows instances only)
Have your instance talk to other AWS products (e.g., Amazon S3, etc.)	Access Keys or X.509 Certificates You put the credentials on the instance itself; which set of credentials depends on what the service in question requires.
Share an AMI or Amazon EBS snapshot	AWS Account ID of the account to share with (without the hyphens)

----------------------