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:


  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...

  • 1
    Scripting? I dunno about you, but I build mine out with Puppet. Dec 18 '11 at 9:15
  • 1
    Tom: I consider writing Puppet or Chef configurations to be a form of scripting. All I mean is that you should automate the process so that it requires as little manual work as possible. Dec 19 '11 at 21:32
  • Fair enough. I suppose the line between a DSL and a script is pretty slim. Dec 19 '11 at 22:35
  • Thanks, great advice. Intuitively this feels right, and I sort of knew it, but so far I've been too lazy to automate everything, or it always felt like a one-off case... :)
    – Jonik
    Jan 15 '12 at 9:12
  • 1
    Jonik: Full automation isn't always necessary. Get in the habit of opening a text file and copying the commands you run and files you edit when you set up a new system. This documentation makes things much easier the next time and is a good start towards automation. Jan 15 '12 at 21:24

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.


Try reverse engineering the 32bit AMI with blueprint:


Save the output as a bash script and use the user data hook when firing up the 64 bit version.

  • I came in here to suggest blueprint. +1 for you!
    – ceejayoz
    Sep 20 '11 at 21:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.