The first thing you will need to do to use Amazon Web Services is sign up for an account. Go to http://aws.amazon.com/ and click on the Sign Up Now button. If you already have an account with Amazon.com and want to associate your AWS activity with that account, you can simply log in with those credentials. If you prefer, you can create a new account just for your AWS activity.
For detailed instructions on signing up for AWS, you can check out this tutorial, provided by RightScale.
Make sure your account has been enabled for at least the EC2 service and the S3 service. The tutorial linked to above provides detailed instructions on signing up for services.
Once your account has been created, a variety of credentials will be associated with it:
- AWS Account Credentials
These are the credentials you use to log into the AWS web portal and the AWS Management Console and consist of an email address and a password. Since these credentials control access to all of the other credentials discussed below, it is very important to choose a strong password for this account and to age the password aggressively.
- AWS Account Number
This is the unique 12-digit number associated with your AWS account. Unlike the other credentials we will discuss, this one is not a secret. The easiest way to find your account number is to look in the upper-right corner of the web page after you have logged into the AWS portal. You should see something like Figure 1-2.
The Account Number is a public identifier and is used mainly for sharing resources within AWS. For example, if I create an AMI in EC2 and I want to share that AMI with a specific user without making the AMI public, I would need to add that user’s Account Number to the list of user IDs associated with the AMI. One potential source of confusion here: even though the Account Number is displayed with hyphens separating the three groups of four digits, when it is used via the API, the hyphens must be removed.
- AccessKeyID and SecretAccessKey
These Access Identifiers are at the heart of all API access in AWS. Every REST or Query API request made to every AWS service requires you to pass your AccessKeyID to identify who you are. The APIs also require you to compute and include a signature in the request.
The signature is calculated by concatenating a number of elements of the request (e.g., timestamp, request name, parameters, etc.) into a StringToSign and then creating a signature by computing an HMAC of the StringToSign using your SecretAccessKey as the key.
When the request is received by AWS, the service concatenates the same StringToSign and then computes the signature based on the SecretAccessKey AWS has associated with the AccessKeyID sent in the request. If they match, the request is authenticated. If not, it is rejected.
The AccessKeyID associated with an account cannot be changed, but the SecretAccessKey can be regenerated at any time using the AWS portal. Because the SecretAccessKey is the shared secret upon which the entire authentication mechanism is based, if there is any risk that your SecretAccessKey has been compromised, you should regenerate it.
- X.509 Certificate
The other Access Identifier associated with your account is the X.509 Certificate. You can provide your own certificate or you can have AWS generate a certificate for you. This certificate can be used for authenticating requests when using the SOAP versions of the AWS APIs, and it is also used when creating your own S3-based AMIs in EC2. Essentially, the files that are created when bundling an AMI are cryptographically signed using the X.509 cert associated with your account, so if anyone were to try to tamper with the bundled AMI, the signature would be broken and easily detected.
When using the SOAP APIs, the X.509 certificate is as critically important from a security point of view as the SecretAccessKey discussed above, and it should be managed just as carefully. Remember, even if you don’t use SOAP, a hacker could!
- SSH Keys
The final credential we need to discuss is the public/private keypair used for SSH access to an EC2 instance. By default, an EC2 instance will allow SSH access only by PublicKey authentication. I strongly recommend that you stick to this policy in any AMIs you create for your own use. SSH keypairs can be generated via the AWS Console and API, or you can import existing keypairs. You should create keypairs for each individual in your organization that will need access to running instances and guard those SSH keys carefully.
Once you have signed up for your AWS account and obtained your
credentials, you need to make boto aware of them. There are
several ways to do this:
- Explicitly pass credentials to
boto Each time you want to access some AWS service, you need to create a connection to that service with
boto. At that time, you can pass in your access key ID and secret access key explicitly andbotowill use those credentials when communicating with the service:% python Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import boto >>> ec2 = boto.connect_ec2(aws_access_key_id='my_access_key', aws_secret_access_key='my_secret_key')
Most people find that this gets tedious pretty quickly.
- Store credentials in environment variables
If no explicit credentials are passed to
botowhen making a connection (as shown above),botowill look to see if the environment variablesAWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYare defined in the user’s environment. If they are,botowill use the values of these environment variables as the access key and secret key.- Store credentials in the boto config file
If
botodoesn’t get credentials passed to it explicitly and it doesn’t find them in the user’s environment, it will try to find them in thebotoconfiguration files. By default,botowill look for configuration information in /etc/boto.cfg and in ~/.boto. If you want to store your config info elsewhere, you can set the environment variableBOTO_CONFIGto the path to the config file andbotowill read it from there. To add your credentials to thebotoconfig file, you would add a section like this:[Credentials] aws_access_key_id = your_access_key aws_secret_access_key = your_secret_key
Once the credentials are stored in the
botoconfig file,botowill use them automatically each time you use it. This is the most convenient way to deal with your AWS credentials. However, if you store your AWS credentials in yourbotoconfig file, you should set the file protections such that the file is readable only by you.
Hopefully, at this point you have boto installed and
you have your AWS account created and your credentials stored in
environment variables or the boto config file. Before
moving on, let’s just do a quick test to verify that things are
working:
% python Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import boto >>> ec2 = boto.connect_ec2() >>> ec2.get_all_zones() [Zone:us-east-1a, Zone:us-east-1b, Zone:us-east-1c, Zone:us-east-1d] >>>
If you get roughly the same output when you run this little test, you should be all set to proceed with the recipes. If not, double-check the previous steps. If you are still stuck, try posting a question on the boto users group.