Easy way to convert custom 32-bit AMI into 64-bit one?

I have customised (EBS-backed) AMI for running a demo version of an application of ours. (The AMI contains Ubuntu 11.04 with a Tomcat & MySQL setup for the app itself, and Jenkins for easy one-click update of the demo).

This is a 32-bit AMI, which means I have the following instance type options:

  • Micro (t1.micro)
  • Small (m1.small)
  • High-CPU medium (c1.medium)

We've noticed that we'd like some more performance for the demo server than what c1.medium can offer. (Specifically, I suspect "I/O Performance: Moderate" might be a bottleneck, although I'm not sure if improving that would help given that we use EBS for everything.)

Anyway, in order to use the more powerful instance types (e.g. "m1.large" or "c1.xlarge"), I would need a 64-bit AMI.

One way to do this is to create a new instance from clean 64-bit Ubuntu AMI, then re-setup my system there, and finally save that as a new AMI. I could mount a volume with the current setup, and then cp -a some stuff over to the new instance's root disk, which would help somewhat. But even so, this approach can be somewhat tedious and time-consuming.

So, my question is, is there any easier, automated way of converting a 32-bit AMI to a 64-bit one?


No, there is no automated way. You will have to create a new AMI starting with the Ubuntu-plain one.

It's possible to convert an Unbuntu installation but it's really messy. It's best you make a fresh AMI.


Best practices:

  1. Whenever you build an AMI (or even set up an instance) always document the exact steps you took to install and configure the software and what data you put on it and where. This has many benefits including making it easy to rebuild the same AMI for a different architecture.

    Even better, I recommend scripting most or all of the install, configure steps so that you can automate the building of the AMIs. This makes it easy to tweak the setup and test new versions.

    Here's a sample of how I build an Ubuntu AMI with Git and gitolite installed for private Git repository servers:

    https://github.com/alestic/alestic-git/blob/master/bin/alestic-git-build-ami

  2. The first recommendation above is for setting up the software which generally goes on the root volume. Your data should be placed on separate EBS volume(s) that you attach to your instance after running the AMI. This has many benefits including the ability to move the data between instances, like when you want to switch to running a new AMI. It also lets you make copies of your data volumes to attach to development instances.

You may think that this advice is too late for you, but you are about to build another AMI, so...


You'll need to start with a new AMI I believe, but you can generate a package list on the old image using dpkg:

dpkg --get-selections | awk '{print $1}' > pkgs.old

Then use this on the new image to figure out what packages you might need to install:

dpkg --get-selections | awk '{print $1}' | fgrep -v -f - pkgs.old

Then probably copying files out of /etc should get you most of the way there.

And +1 for scripting it -- you hardly every set these things up once or twice -- it's usually many many times. Having all this automated and in source control is crucial.