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 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.
|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|
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.
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.
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||
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 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).
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:
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).
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
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).
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:
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.
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
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:
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:
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
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.
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:
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.
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:
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
At this point, you have two active credentials.
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.
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.
AWS assigns two unique IDs to each AWS account:
You get both IDs from the Account Identifiers area of the AWS Security Credentials page. You can't change either ID.
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||
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)|
Copyright © 2013 Amazon Web Services, Inc. or its affiliates. All rights reserved.