How to create an ebs image from an existing ec2 instance
Amazon recently announced a new feature which allows you to boot from an ebs volume. But it doesn’t provide any tools to convert your existing AMIs to this new type of image. There is no easy way to create an ebs image from scratch. There are some posts that explain how to convert your existing AMI into this new type of image using ec2-unbundle and dd (a linux utility). I am going to take a little different route and explain how we can create an ebs image from an existing instance. It’s fairly simple to create a new image using dd from an existing instance.
Make sure that you have the latest ec2 api tools before you start creating and ebs type of image. Support for some of the commands (such as to register a snapshot as an image) is only available in the version 46266 onwards.
1) Launch an ec2 instance from the image you want to convert to an ebs image. Make the changes (if any) you want to make to this instance. Let’s say that your instance id is i-xxxxxxxx
2) Launch an 10G ebs volume and attach it to this instance. You can create a bigger volume too. But currently the default size of Amazon’s ephemeral storage is 10G and hence a 10G volume should be sufficient for most of the people.
The following code will launch an ebs volume and attach it to your instance. The code assumes that us-east-1a is the availability zone of your instance.
ec2-create-volume --size 10 --availability-zone us-east-1a
The command should give you an volume id in the form of vol-yyyyyyyy. Note it down and use it in the next command to attach this volume to your instance.
ec2-attach-volume vol-yyyyyyyy --instance i-xxxxxxxx --device /dev/sdh
Create ext3 filesystem on this volume and mount the volume
yes | mkfs -t ext3 /dev/sdh
mkdir /mnt/ebsimage
echo '/dev/sdh /mnt/ebsimage ext3 defaults,noatime 0 0' >> /etc/fstab
mount /mnt/ebsimage
3) Now that the volume is ready and mounted at /mnt/ebsimage, we are going to copy your entire disk to this volume using dd (a linux disc imaging utility).
nohup dd if=/dev/sda1 of=/dev/sdh &
The command above will start copying the disc to the ebs volume in background. This could take really long time (e.g. 20 minutes) depending upon your data. To check status of copying you will first need to get pid of the dd process by executing
ps -aef | grep dd
And then use the pid obtained in the following command
kill -SIGUSR1 pid
The above command will clearly print a message similar to
531694080 bytes (532 MB) copied, 11.6338 seconds, 45.7 MB/s
Please note that the message is printed by the dd process and not by the kill process. This means if you have your output redirected to somewhere else, the message will be printed there instead of your screen.
3) Once dd finishes, do a spot check on the data copied in /mnt/ebsimage. If you find everything ok, unmount the volume and detach the volume from the ec2 instance. You can use the following commands to do so:
umount /mnt/ebsimage
ec2-detach-volume vol-yyyyyyyy --instance i-xxxxxxxx
4) Now take the snapshot of the ebs volume.
ec2-create-snapshot vol-yyyyyyyy
5) Register this snapshot as an image. Use the snapshot id obtained from the output of the above command.
ec2reg -s snap-zzzzzzzz -a x86_64 -d Description -n imagename
Make sure that you replace the snapshot id, image name, description and the image type (x86_86 or x86_64) in the command above.
That’s it! Your ebs image is ready. Simply launch your instance from this image exactly the same way you launch any other ec2 instance!

December 22nd, 2009 at 9:52 am
Thanks for the excellent explanation ! I just had to add the –kernel aki-####### and –ramdisk ari-####### parameters to the ec2reg command. Without them, the ami did start but was not accessible.
December 29th, 2009 at 4:00 am
thanks for the writeup, just tried it out and it worked sweetly. How important are the -kernel and -ramdisk options mentioned by Coert?
December 29th, 2009 at 4:13 am
This is great, thank you.
BTW I didn’t need to add -kernel and -ramdisk options to ec2reg, I created the EBS from a CentOS 5 i386 community contributed AMI.
And image type for i386 is x86_86 or i386, or you can leve this option out as i386 is the default.
December 29th, 2009 at 9:30 am
I don’t think the option -kernel and -ramdisk are required. I think they have default values. If you don’t want to use the default value, then you should specify it.
December 30th, 2009 at 9:12 pm
Why would you mkfs on the block device in order to just dd over it? That step makes no sense
December 30th, 2009 at 10:23 pm
You are right, mkfs is not necessary as dd is a block by block copy of the source disk.
January 11th, 2010 at 5:42 am
I needed to use the -kernel and -ramdisk parameters to get it working. Same problem as Coert, without I could not connect to the ami. I copied them from the source ami. My assumption is that the parameters must be the same, so default works for most cases but not for every case.
Thanks for the blog post. It saved me a lot of time.
January 11th, 2010 at 5:27 pm
Just wanted to point you guys here:
http://developer.amazonwebservices.com/connect/thread.jspa?threadID=39358&start=15&tstart=0
If you combine both these instructions, it results in a cleaner setup. Ie. use rsync instead of dd. This also allows you to potentially use another FS instead of ext3. I’m tryng it out with XFS right now, as I need that FS. I don’t know why Amazon is so fixated in ext3. It snapshots like crap.