Maybe you already joined the cool kids out there and utilize Cloud Computing to scale your application to infinity while reducing IT-budget? Just kidding.

As using the (increasingly hyped) cloud infrastructure indeed does make sense for some applications out there, some of our customers use it. A common task when working on Amazon EC2 is to launch instances (virtual machines for the old-fashioned) in order to get increased computing power, to add another slave for whatever, etc.. Of course you need some kind of image to boot your virtual machine - and you can't just drive past the Amazon datacenter in Dublin to insert your Ubuntu CD somewhere.

Ideally this image already includes the basic stuff you usually need. As we work with Ruby on Rails most of the time we need a Ruby interpreter, a bunch of gems we usually use, maybe a database server, Java run-time-environment for using Solr or Memcached. Additionally you might have some basic configuration like security-stuff, monitoring or SSH keys for your team.

In order to create such an instance that includes your individual stuff, boot one of the offered basic AMIs at Amazon, do your configuration homework and follow the next steps to create your own private individual AMI:

First of all you need the X.509 keys. Go to the AWS Management Console, click "Account" in the very upper menu line, "Security credentials", enter your login data and click on "X.509 Certificates" located in "Access Credentials". Copy these certificates to your instance:

$ scp -i your_keyfile_for_the_instance.pem directory_where_both_x509_certs_are/*.pem root@$hostname.compute.amazonaws.com:

Log into the instance and move the keys to a separate directory, as you want to exclude those keys from the image to be created:

$ ssh into instance
$ mkdir x509_certs
$ mv *.pem x509_certs
$ cd x509_certs

Hints:

• ec2-bundle-image is very likely not what you want if you intend to create an AMI from a running instance, use ec2-bundle-vol (as described in the following) instead!
• To ensure you get a clean state of your machine, try to disable as much services (read: database, application server, etc.) as possible.
• Keep in mind that if you connect to an instance through an elastic IP, your SSH-connection will die if you disassociate the IP.

You need your Amazon account number for the next step. To find out, click Account -> Personal Information within the AWS MC. Your Account number is on the upper right side, separated by dashes: 2342-4242-1234

Remove the slashes from your account number and run ec2-bundle-vol with the following (necessary) parameters:

$ ec2-bundle-vol -k ./pk-$pk-keyfile.pem  -c ./cert-$cert.pem -u 234242421234
$ ec2-bundle-vol -k ./pk-$pk-keyfile.pem  -c ./cert-$cert.pem -u 234242421234 -e /root/x_509_certificates/ -d /mnt/

I ran into trouble with Ruby Enterprise Edition installed on the machine while running ec2-bundle-vol:

root@hostname:~# ec2-bundle-vol
/usr/lib/site_ruby/ec2/amitools/bundlevol.rb:11:in `require': no such file to load -- ec2/amitools/bundle (LoadError)
        from /usr/lib/site_ruby/ec2/amitools/bundlevol.rb:11

Setting a new path does the trick:

root@hostname:~# PATH=/usr/bin:$PATH

Take two more minutes to think about whether you want to use the optional parameters:

• -s size in MB (have a look at `df -h` what your instances consumes at the moment)
• -e directory exclude directories from your image. AT LEAST exclude the directory your keys are copied to! (-e ~/x509_certs/ in our example)

ec2-bundle-vol asks for the architecture you are running. Have a look at uname -a if in doubt. Just hit enter if you're running an i386-instance.

To keep the image persistent, upload it to S3:

ec2-upload-bundle -b $some_name -m /tmp/image.manifest.xml -a $AWS_access_ID -s $AWS_secret_key --location EU

Replace $some_name with something that identifies and describes the image. It will be used as the bucket (newfangled "directory") on S3. Replace $AWS_access_ID and $AWS_secret_key accordingly.

To make the image accessible from within the Management Console, click "Register new AMI" and enter the path to the manifest on S3, which should be $some_name/image.manifest.xml.

That was easy, wasn't it?