You can check out the release notes for more information about new features.

If you are running the command line tools for accessing EC2, you can find the AMI IDs in your region by running:

$ euca-describe-images -o amazon | grep amzn-ami | grep 2012.03.1

Change euca- to ec2- if you are using the Amazon EC2 API Tools.

If you like what you see and want to help us build future versions of the Amazon Linux AMI, you should submit your resume!

As of October 1, I am pleased to report that I have the extremely coveted Big Radish status, which is currently my favorite frequent-buyer-program name.

Big Radish status: giving renewed (and voluntary!) meaning to the old phrase, “I owe my soul to the company store”.

I’ve created ~/terminate-all-instances-in-region with permissions of 700.

$ cat terminate-all-instances-in-region
euca-describe-instances | grep INSTANCE | sed 's/INSTANCE[[:space:]]*\(i-[[:alnum:]]*\).*/\1/' | xargs euca-terminate-instances

Change euca- to ec2- if you are using the Amazon EC2 API Tools.

This assumes that your EC2 region is set via the EC2_URL environment variable. See this post for more details.

The command line tools that you’ll want are either the Amazon EC2 API Tools or the euca2ools package, depending on your language, license, and distro preferences.

In the examples below, change euca- to ec2- if you are using the Amazon EC2 API Tools.

Note that everything in this blog post is something that you should only have to do once, and then you’ll be off and running with EC2 for a long time to come.

Setting environment variables

The first thing to do is to configure your system’s environment variables to handle AWS account credentials. Create ~/set-ec2-environment as follows:

$ cat ~/set-ec2-environment
EC2_ACCESS_KEY=TEXT_FROM_WEBSITE_SEE_BELOW
EC2_SECRET_KEY=TEXT_FROM_WEBSITE_SEE_BELOW
EC2_CERT=~/amazon-cert-pub.pem
EC2_PRIVATE_KEY=~/amazon-cert-priv.pem
export EC2_ACCESS_KEY EC2_SECRET_KEY EC2_CERT EC2_PRIVATE_KEY

The values for these variables are all found or generated via this link. Some really useful docs are here.

Setting your region

EC2 is split into distinct regions. Typically you’ll choose a region based on your geographic location, and you will launch Amazon Machine Images (AMIs) in that region. For the most part, you should be able to do all of your work in one region, unless you make a conscious choice to spread your workload across regions, or if an AMI that you want to run is only available in a specific region.

$ euca-describe-regions
REGION eu-west-1 ec2.eu-west-1.amazonaws.com
REGION us-east-1 ec2.us-east-1.amazonaws.com
REGION ap-northeast-1 ec2.ap-northeast-1.amazonaws.com
REGION us-west-1 ec2.us-west-1.amazonaws.com
REGION ap-southeast-1 ec2.ap-southeast-1.amazonaws.com

Create one or more ~/set-region-REGION-NAME as follows:

$ cat ~/set-region-us-east-1
EC2_URL=https://ec2.us-east-1.amazonaws.com:443
export EC2_URL

Tying credential and regional settings together

Edit ~/.bashrc to source the two configuration files on login, or just source the two files from the command line. Also, if you have multiple set-region-REGION-NAME files, it makes it very easy to change your region, simply by running source on the new region file.

source ~/set-ec2-environment
source ~/set-region-us-east-1

The reason why we’re going to all this trouble is because everything in EC2 is divided by regions, and the idea is to separate the global AWS configuration from the region currently in use, and to make it trivial to change that region from the command line.

Setting your EC2 ssh key

Now that you have your region set, it’s time to create your ssh key and upload it to the region to which your environment is pointing.

$ euca-add-keypair amazon-ssh > amazon-ssh
$ chmod 600 amazon-ssh


The default AWS security group in each region doesn’t allow inbound ssh access. It is a very simple command to enable this for all of your instances in that region.

$ euca-authorize -p 22 default

Finally, edit ~/.ssh/config to set the proper identify file for EC2 logins:

$ cat ~/.ssh/config
Host *.amazonaws.com
    User ec2-user
    IdentityFile ~/amazon-ssh

NOTE: It is possible to use a single SSH key for multiple regions, but euca2ools 1.3.1 doesn’t currently support this. You have to generate your own ssh public/private keypair, and then use ec2-import-keypair or the EC2 console in order to upload that public key to multiple regions.

Congrats! You’ve now finished all the one-time setup that is necessary to use EC2.

Launching your AMI

Launch your instance by running: $ euca-run-instances -k amazon-ssh AMI_ID

I have added alias euca-run-instances="euca-run-instances -k amazon-ssh" to my ~/.bashrc which allows me to simply run $ euca-run-instances AMI_ID with no additional command line arguments needed, unless I choose to specify a particular instance type, etc.

Connecting to your AMI

Run $ euca-describe-intances to get a list of all instances you have running in the region. You’ll see the hostname of the instance that you just started, and you can now run $ ssh HOSTNAME to connect. If everything is configured properly, you won’t need any other command line options.

Summary

Your home directory should contain:

amazon-cert-priv.pem
amazon-cert-pub.pem
amazon-ssh
set-ec2-environment
set-region-us-east-1

Your ~/.bashrc should contain:

alias euca-run-instances="euca-run-instances -k amazon-ssh"
source ~/set-ec2-environment
source ~/set-region-us-east-1

Your ~/.ssh/config should contain:

Host *.amazonaws.com
    User ec2-user
    IdentityFile ~/amazon-ssh

The AMI IDs are listed near the bottom of the detail page, along with the release notes.

If you are running the command line tools for accessing EC2, you can find the AMI IDs in your region by running:

$ euca-describe-images -o amazon | grep 2011.09.1 | grep amzn.*ami

Change euca- to ec2- if you are using the Amazon EC2 API Tools.

On August 22nd, I begin with Amazon Web Services as a manager in their Kernel & Operating Systems group. My team’s focus is on the overall customer experience of using Amazon Machine Images (AMIs). This includes accountability for the Amazon Linux AMI, working with external AMI vendors, and handling premium support for customers running AMIs.

Thus, one of the places where my new job will continue to intersect (at least a little bit) with the Fedora community is in the Cloud SIG, where the building, testing, and deployment of Fedora on EC2 is a key goal of that group of contributors.

I’ve subscribed to the cloud mailing list and sent a few notes, but things will probably be a bit quiet from me until I actually start with Amazon.  The next few weeks are devoted to seeing some family on the east coast followed by the logistics around leaving Raleigh and relocating to Seattle.