Creating a New Image for EC2 by Rebundling a Running Instance


NOTE: This is an article from 2009, back before EBS boot instances were available on Amazon EC2. I recommend you use EBS boot instances which make it trivial to create new AMIs (single command/API call). Please stop reading this article now and convert to EBS boot AMIs!

When you start up an instance (server) on Amazon EC2, you need to pick the image or AMI (Amazon Machine Image) to run. This determines the Linux distribution and version as well as the initial software installed and how it is configured.

There are a number of public images to choose from with EC2 including the Ubuntu and Debian image published on but sometimes it is appropriate to create your own private or public images. There are two primary ways to create an image for EC2:

  1. Create an EC2 image from scratch. This process lets you control every detail of what goes into the image and is the easiest way to automate image creation.

  2. Rebundle a running EC2 instance into a new image. This approach is the topic of the rest of this article.

After you rebundle a running instance to create a new image, you can then run new EC2 instances of that image. Each instance starts off looking exactly like the original instance as far as the files on the disk go (with a few exceptions).

This guide is primarily written in the context of running Ubuntu on EC2, but the concepts should apply without too much changing on Debian and other Linux distributions.

To use this rebundling approach, you start by running an instance of an image that (1) is as close as possible to the image you want to create, and (2) is published by a source you trust. You then proceed to install software and configure that instance so that it contains exactly what you want to be available on new instances right down to the startup scripts.

The next step is to bundle the instance’s disk image into a new AMI, but before we get to that, it is important to understand a few things about security.


If you are creating a new EC2 image, you need to be very careful what pieces of information you inadvertently leave on the image, especially if you have the goal of publishing it as a public AMI. Anybody who runs an instance of that AMI will have access to the files you included in the bundle, and there is no way to modify an AMI after it has been created (though you can delete it).

For example, you don’t want to leave your AWS certificate or private key on the disk. You’ll even want to clear out the shell history file in case you had typed secret information in commands or in setting environment variables.

You also want to consider the security concerns from the perspective of the people who run the new image. For example, you don’t want to leave any passwords active on accounts. You should also make sure you don’t include your public ssh key in authorized_keys files. Leaving a back door into other people’s servers is in poor taste even if you have no intention of ever using it.

Here are some sample commands, but only you can decide if this wipes out too much or what other files you need to exclude depending on how you set up and used the instance you are bundling:

sudo rm -f /root/.*hist* $HOME/.*hist*
sudo rm -f /var/log/*.gz
sudo find /var/log -name mysql -prune -o -type f -print | 
  while read i; do sudo cp /dev/null $i; done

Whole directories can be excluded from the image using the --exclude option of the ec2-bundle-vol command (see below).


Now we’re ready to bundle the actual EC2 image (AMI). To start, you need to copy your certificate and key to the instance ephemeral storage. Adjust the sample command to use the appropriate keypair file for authentication and the appropriate location of your certification and private key files. If you are not running a modern Ubuntu image, then change remoteuser to “root”.


rsync   --rsh="ssh -i KEYPAIR.pem"   --rsync-path="sudo rsync"   PATHTOKEYS/{cert,pk}-*.pem   $remoteuser@$remotehost:/mnt/

Set up some environment variables for convenience in the following commands. A single S3 bucket can be used for multiple AMIs. The manifest prefix should be descriptive, especially if you plan to publish the AMI publicly, as it is the only piece of documentation many users will see when they look through AMI lists. At a minimum, I recommend including the Linux distribution (e.g, “ubuntu”), the architecture (e.g., “i386” or “32”), and the date (e.g., “20090621”), as well as some tag that indicates the special nature of the image (e.g., “desktop” or “lamp”).


On the EC2 instance itself, you also set up some environment variables to help the bundle and upload commands. You can find these values in your EC2 account.

export AWS_USER_ID=<your-value>
export AWS_ACCESS_KEY_ID=<your-value>
export AWS_SECRET_ACCESS_KEY=<your-value>

if [ $(uname -m) = 'x86_64' ]; then

Bundle the files on the current instance into a copy of the image under /mnt:

sudo -E ec2-bundle-vol   -r $arch   -d /mnt   -p $prefix   -u $AWS_USER_ID   -k /mnt/pk-*.pem   -c /mnt/cert-*.pem   -s 10240   -e /mnt,/root/.ssh,/home/ubuntu/.ssh

Upload the bundle to a bucket on S3:

ec2-upload-bundle    -b $bucket    -m /mnt/$prefix.manifest.xml    -a $AWS_ACCESS_KEY_ID    -s $AWS_SECRET_ACCESS_KEY

Now that the AMI files have been uploaded to S3, you register the image as a new AMI. This is done back on your local system (with the API tools installed):

ec2-register   --name "$bucket/$prefix"   $bucket/$prefix.manifest.xml

The output of this command is the new AMI id which is used to run new instances of that image.

It is important to use the same account access information for the ec2-bundle-vol and ec2-register commands even though they are run on different systems. If you don’t you’ll get an error indicating you don’t have the rights to register the image.

Public Images

By default, the new EC2 image is private, which means it can only be seen and run by the user who created it. You can share access with another individual account or with the public.

To let another EC2 user run the image without giving access to the world:

ec2-modify-image-attribute -l -a <other-user-id> <ami-id>

To let all other EC2 users run instances of your image:

ec2-modify-image-attribute -l -a all <ami-id>


AWS will charge you standard S3 charges for the stored AMI files which comes out to $0.15 per GB per month. Note, however, that the bundling process uses sparse files and compression, so the final storage size is generally very small and your resulting cost may only be pennies per month.

The AMI owner incurs no charge when users run the image in new instances. The users who run the AMI are responsible for the standard hourly instance charges.


Before removing any public image, please consider the impact this might have on people who depend on that image to run their business. Once you publish an AMI, there is no way to tell how many users are regularly creating instances of that AMI and expecting it to stay available. There is also no way to communicate with these users to let them know that the image is going away.

If you decide you want to remove an image anyway, here are the steps to take.

Deregister the AMI

ec2-deregister ami-XXX

Delete the AMI bundle in S3:

ec2-delete-bundle   --access-key $AWS_ACCESS_KEY_ID   --secret-key $AWS_SECRET_ACCESS_KEY   --bucket $bucket   --prefix $prefix

[Update 2009-09-12: Security tweak for running under non-root.] [Update 2010-02-01: Update to use latest API/AMI tools and work for Ubuntu 9.10 Karmic.]


Excellent information. I'm preparing to release several AMIs based on my work with Chapter Three in developing ready-to-go installations of the Drupal CMS (and associated stack) for clients. Will keep this on file before I send anything out.

Now that AWS is offering reserved instances at extremely competitive prices, with the right backup and restore structure it's possible to deliver really great value for clients who are ready to take the leap into the cloud.

One question, given that there's no way to update an AMI, what's your recommended process for versioning releases? Most alestic AMI's come with a datestamp, which is great, but how do you keep track of all this internally?

Anyway, I have to tip my hat to you, sir. Without this kind of trailblazing work (and all the free AMIs from alestic) none of my contributions would be possible.

My problem with learning how to bundle or rebundle is that there are no docs *anywhere* I can find that provide enough details about what to include and not include. It's a nightmare trying to figure out how the basics of bundling work, let alone trying to hammer out how to deal with the Alestic layer applied on top of it in order to accomplish a rebundle.

1. For bundling, the default list of directories excluded by ec2-bundle-vol includes /dev. Does one really not need to include this? Will Amazon automatically create a /dev directory and fill it with all necessary devices (/dev/null, /dev/random, /dev/zero)? If /dev needs to be bundled, does bundling actually manage to correctly "copy" special devices like /dev/random, and won't bundling /dev include all the harddrive mount sources (/dev/sda1, etc), which would conflict with the separate block device config given to ec2-bundle-vol?

2. From the point of view of Alestic rebundling: how to make sure that the bundled image will start over "fresh", including Alestic startup script(s)? Specific example is that after rebundling, my rebundled AMI must be capable of using the Alestic functionality for executing the userdata script on first boot of all instances.

3. Finally, what about the creation/population of /root/authorized_keys? Is that something that an Alestic-included script does, or is that something Amazon does in the underlying instance launching? And if it's Amazon, is it done via a first-boot script I can locate on the filesystem, or does Amazon create that file from outside the OS (perhaps by the VM layer manually mounting the drive to create it).

Add on the fact that the kernel is somehow magically located external to the actual filesystem via the VM layer, and the confusion just continues. :|

frickenate: I'm confused about why you have so many questions about rebundling after reading an article which describes exactly how to rebundle. Why not try the steps listed, review the results, and then post questions you have? The best forum for general EC2 questions is the Amazon EC2 forum.


First off, thanks for all your hard work...I use a few different AMI's that you have put together and I really appreciate it.

I have been rebundling your AMI's following the steps you've outlined above, but I've run into an issue I'm hoping you can shed some light on for me..

when I rebundle an AMI and launch a new instance from it, none of the user-data scripts are run....I can confirm this by checking in the syslog...I went a step further and setup a script to be run at startup in init.d/ as outlined here:

But again, this script doesnt run when i rebundle the AMI and launch a new instance from it.

Do you have any pointers?


robbucci: The fact that your init.d script is not running implies that the problem is deeper than the user-data script itself.

@Eric, Nice article!
@Robbucci, I'm also facing the same problem while re-bundling eucalyptus images (Ubuntu). Whenever I'm running my user-scripts with originally bundled images, it worked but re-bundling as mentioned with this article as well as scripts given by UEC [ ], never worked for me. I think it is access-permission-issue for user-script to run in super-user mode. Not sure though!

Dipak Chirmade


First, your website is *awesome*. The is sooo much good concise perfectly-working information here. Lots of signal. Very little noise. Except for this paragraph you're reading right now perhaps :-P

My question: the new Canonical Karmic amis come with euca2ools instead of ami tools. The euca2ools are muuuch faster than Amazon's ec2 tools, though they feel a little beta, but: have you tried rebundling karmic using them? Could you get an instance to start from the resulting image afterwards? I found I could bundle easily enough, register the image, but starting the image using ec2-run-instances, the image looked like it was starting, and then immediately terminated. Ideas?

hughperkins: euca2ools is faster than the API tools, but not the AMI tools given the different type of work they are doing. That aside, I haven't been able to use euca2ools to bundle/upload/register successfully yet due to a bug. You can install the ec2-ami-tools package on Karmic (multiverse) and use them instead.

Above you suggest running the EXPORT for the secret access key right before bundling

But - that will leave it in the ubuntu user history I think. So, clearing the shell history should be the last step before bundling.

In the latest version of the ec2 API tolls (ec2-api-tools-1.3-46266), at least, the ec2-register command also seems to require the name (-n) parameter to be passed in.

Following these instruction I hit a minor snag with the new instance, the /tmp dir is only writable by root, so commands like "crontab -e" fail.

on the original instance:

drwxrwxrwt 6 root root 4096 2010-02-01 18:20 tmp

on the instance booted from the bundled AMI:

drwxr-xr-x 4 root root 4096 2010-02-01 18:21 tmp

obviously this is easy to fix manually, but is there something missing from the bundling process or the firstboot script?

pwolanin: As I point out under "SECURITY", you have to be careful not to leave any private information on an AMI if you are going to make it public and clearing the history is one part of that. Each publisher will need to evaluate their own case and take the necessary steps.

If you are going to make an AMI public, for security and general image freshness I recommend building it from scratch instead of rebundling a running instance. Here are a couple articles about that:

Thanks also for pointing out the -n parameter. I'll take another run through the tutorial and update it.

pwolanin: The AMIs I built and published under the "alestic" name included a startup trigger which set up /tmp with the correct permissions. The Canonical (e.g., Karmic) AMIs do not have this, so you may not want to exclude (-e) the /tmp directory when bundling. I'll take it out of the example commands.

interestingly - on 9.10 at least, I had to use "history -c
" to clear my history (not sure where it's being stored). The commands above cleared what's in my home directory, but various private keys were still visible.

Also, the .pem uploads should go to /mnt not /tmp if that's no longer in the -e list.

scp -i KEYPAIR.pem \
/{cert,pk}-*.pem \

and then:

/tmp/cert-*.pem --> /mnt/cert-*.pem

pwolanin: History is stored in $HOME/.bash_history (eventually). I've updated the commands to work with the latest Ubuntu 9.10 Karmic AMI as a base, and the latest API/AMI tools. Thanks again for your testing and feedback.

Trying to launch an instance rebundled this way - I'm seeing what looks like the Ubuntu "can't ssh" bug re-appearing.

If I rebundle an instance does the original first boot script get restored and used, or is there another step needed to make that happen, or is some generic one from AWS used?

pwolanin: For support, please use and provide enough information for somebody else to reproduce it (e.g., AMI id, rebundle instructions, ssh error).

first, it has been said before but I add myself to those offering kudos and appreciation for this resource.

I am quite new to this and have encountered something I havn't seen mentioned.

My colleague has an instance in the U.S. and one that I am working on in the eu-west-1 region.
When I installed the EC2 commandline tools on the server and said ec2-describe-instances I saw the US instance.
I did
export EC2_URL=
and the Europe instance was then shown instead. In the same shell session I ran the ec2-bundle-vol successfully. When I went on to ec2-upload-bundle I was told

You are bundling in one region, but uploading to another. If the kernel
or ramdisk associated with this AMI are not in the target region, AMI
registration will fail.
You can use the ec2-migrate-manifest tool to update your manifest file
with a kernel and ramdisk that exist in the target region.
Are you sure you want to continue? [y/N]

I ran
ec2-migrate-manifest \
-c /root/.ec2/cert-xxxxxxxxxxxxxxxxxx.pem \
-k /root/.ec2/pk-xxxxxxxxxxxxxxx.pem \
-m /mnt/image1/local_mysql.manifest.xml \
--region eu-west-1

Successfully migrated /mnt/image1/local_mysql.manifest.xml
It is now suitable for use in eu-west-1.

But still get the warning. The bundle command is
root@ip-10-224-99-999:~# ec2-upload-bundle \
> -b someName \
> -m /mnt/image1/local_mysql.manifest.xml \
> -s secret-squirrel

I am thinking maybe the account identifier is associated with the US instance - is there a way I can find that out?
Presumably for a proof-of-concept we could go ahead and upload+register the image anyway, it's "just" that it would have to hop over the Atlantic if we tried to launch an instance of it in the EU?

victor: I use ec2-migrate-bundle to migrate an image already registered in S3. For more in depth help, you might try the EC2 forum or ec2ubuntu Google group.

googling around, it's not an unknown problem. Re-running the ec2-upload-bundle command specifying the parameter "--location EU" seems to fix the issue.

It was a very good post and quite extensive, except one thing that the init file on already running instance needs to be touched.

If file "/var/ec2/firstrun" exists on an instance, setup script "/etc/init.d/ec2-setup" is executed when instance is started for the first time. This script will remove the firstrun file, so script is not executed every time, instance is rebooted.

So, before creating AMI, we need to touch the file, and after the process is complete remove it. Else the instance will not be setup making it inaccessible.

thanks man for this great tutorial. saved me probably a few days of frustration.

Thank you for this great tutorial.

ec2-register asked me for my key and certificate:

ec2-register --name "$bucket/$prefix" $bucket/$prefix.manifest.xml -K /mnt/pk-*.pem -C /mnt/cert-*.pem

When I run:
$ sudo ec2-bundle-vol -d /mnt/amis -k /mnt/ids/pk-*.pem -c /mnt/ids/cert-*.pem -u 123456789123 -r i386

I get the error:
ERROR: execution failed: "mkfs.ext3 -F /mnt/amis/image -U 2c567c84-20a1-44b9-a353-dbdcc7ae863b -L "

Here's the entire output:

Copying / into the image file /mnt/amis/image...
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00273375 s, 384 MB/s
mkfs.ext3: option requires an argument -- 'L'
Usage: mkfs.ext3 [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
ERROR: execution failed: "mkfs.ext3 -F /mnt/amis/image -U 2c567c84-20a1-44b9-a353-dbdcc7ae863b -L "


Looks like ec2-bundle-vol is not passing a label to mkfs.ext3.

Now that we have EBS boot instances, I no longer use the rebundling method described in this article. I recommend using and creating EBS boot AMIs instead as they offer a lot of advantages including making it much easier to create new images from running instances.


Thanks so much for the response, and I totally agree with your ideaology.

I'm using an AMI that is instance store, and the maker of the AMI hasn't released a EBS boot version...YET.

We have, however, created an EBS volume, attached and formatted it as /vol and moved our /var/www and MySQL data there.

This has worked for the past few months while we have been in development.

Last week our instance stopped responding. We contacted Amazon via the discussion forum, and found that there was an underlying hardware problem.

So we had to spin up a new instance with the aforementioned AMI, make our customizations to it and then re-attach the volume.

No big deal, and only a few hours lost re-customizing the AMI.

Now we want to minimize that "few hours" down to 5 or 10 minutes by re-bundling the AMI after we have made our customizations to it.

How would you recommend we get to where we want to be with the following:

AMI - instance store with most of the software/customization.

Running instance built on AMI with our own customization.

Desired result: EBS boot AMI of aforementioned AMI.

Any response would be appreciated. I realize that the answer may be too complicated to answer in a blog comment.

We have been reading alot about Amazon EC2 over the last 9 months and your name has come up significantly more than others. We solidly appreciate your work and advice.

The basic approach to creating an EBS boot AMI is to create an EBS boot volume, copy your file system to it (rsync -PaSHAX), snapshot it, and register the EBS snapshot as a new AMI with the appropriate AKI and ARI. You can start with a downloaded image from Ubuntu, or the file system of a running EC2 instance. Further questions about this approach are suitable for more populated forums where others can pitch in with answers.

Thanks for the helpful instructions. Just a quick question--should an AMI upload to S3 take several hours? We've got a 193 part AMI uploading (10GB image of a 40GB EBS splits into 193 10 meg parts for some reason...) and it's taking far longer than a normal S3 transaction.


This is a very old article which talks about S3-based AMIs. I recommend using EBS boot AMIs instead as they make it trivial to create a new AMI from an instance and there are many other good reasons for using EBS boot instances.

Thanks for the response. We're moving some AMIs to S3 in hopes of registering them on several different regions (and accounts). Is this possible with EBS boot AMIs? I haven't been able to find a simple way to do this yet...

Scratch that on my last comment. We've just discovered that our S3 images won't work in the other region anyway. Wish we'd realized that yesterday :)

Thanks again for all the helpful articles!

Leave a comment

Ubuntu AMIs

Ubuntu AMIs for EC2:

More Entries

When Are Your SSL Certificates Expiring on AWS?
If you uploaded SSL certificates to Amazon Web Services for ELB (Elastic Load Balancing) or CloudFront (CDN), then you will want to keep an eye on the expiration dates and…
Throw Away The Password To Your AWS Account
reduce the risk of losing control of your AWS account by not knowing the root account password As Amazon states, one of the best practices for using AWS is Don’t…
AWS Community Heroes Program
Amazon Web Services recently announced an AWS Community Heroes Program where they are starting to recognize publicly some of the many individuals around the world who contribute in so many…
EBS-SSD Boot AMIs For Ubuntu On Amazon EC2
With Amazon’s announcement that SSD is now available for EBS volumes, they have also declared this the recommended EBS volume type. The good folks at Canonical are now building Ubuntu…
EC2 create-image Does Not Fully "Stop" The Instance
The EC2 create-image API/command/console action is a convenient trigger to create an AMI from a running (or stopped) EBS boot instance. It takes a snapshot of the instance’s EBS volume(s)…
Finding the Region for an AWS Resource ID
use concurrent AWS command line requests to search the world for your instance, image, volume, snapshot, … Background Amazon EC2 and many other AWS services are divided up into various…
Changing The Default "ubuntu" Username On New EC2 Instances
configure your own ssh username in user-data The official Ubuntu AMIs create a default user with the username ubuntu which is used for the initial ssh access, i.e.: ssh ubuntu@<HOST>…
Default ssh Usernames For Connecting To EC2 Instances
Each AMI publisher on EC2 decides what user (or users) should have ssh access enabled by default and what ssh credentials should allow you to gain access as that user.…
New c3.* Instance Types on Amazon EC2 - Nice!
Worth switching. Amazon shared that the new c3.* instance types have been in high demand on EC2 since they were released. I finally had a minute to take a look…
Query EC2 Account Limits with AWS API
Here’s a useful tip mentioned in one of the sessions at AWS re:Invent this year. There is a little known API call that lets you query some of the EC2…
Using aws-cli --query Option To Simplify Output
My favorite session at AWS re:Invent was James Saryerwinnie’s clear, concise, and informative tour of the aws-cli (command line interface), which according to GitHub logs he is enhancing like crazy.…
Reset S3 Object Timestamp for Bucket Lifecycle Expiration
use aws-cli to extend expiration and restart the delete or archive countdown on objects in an S3 bucket Background S3 buckets allow you to specify lifecycle rules that tell AWS…
Installing aws-cli, the New AWS Command Line Tool
consistent control over more AWS services with aws-cli, a single, powerful command line tool from Amazon Readers of this tech blog know that I am a fan of the power…
Using An AWS CloudFormation Stack To Allow "-" Instead Of "+" In Gmail Email Addresses
Launch a CloudFormation template to set up a stack of AWS resources to fill a simple need: Supporting Gmail addresses with “-” instead of “+” separating the user name from…
New Options In ec2-expire-snapshots v0.11
The ec2-expire-snapshots program can be used to expire EBS snapshots in Amazon EC2 on a regular schedule that you define. It can be used as a companion to ec2-consistent-snapshot or…
Replacing a CloudFront Distribution to "Invalidate" All Objects
I was chatting with Kevin Boyd (aka Beryllium) on the ##aws Freenode IRC channel about the challenge of invalidating a large number of CloudFront objects (35,000) due to a problem…
Email Alerts for AWS Billing Alarms
using CloudWatch and SNS to send yourself email messages when AWS costs accrue past limits you define The Amazon documentation describes how to use the AWS console to monitor your…
Cost of Transitioning S3 Objects to Glacier
how I was surprised by a large AWS charge and how to calculate the break-even point Glacier Archival of S3 Objects Amazon recently introduced a fantastic new feature where S3…
Running Ubuntu on Amazon EC2 in Sydney, Australia
Amazon has announced a new AWS region in Sydney, Australia with the name ap-southeast-2. The official Ubuntu AMI lookup pages (1, 2) don’t seem to be showing the new location…
Save Money by Giving Away Unused Heavy Utilization Reserved Instances
You may be able to save on future EC2 expenses by selling an unused Reserved Instance for less than its true value or even $0.01, provided it is in the…
Installing AWS Command Line Tools from Amazon Downloads
This article describes how to install the old generation of AWS command line tools. For the most part, these have been replaced with the new AWS cli that is…
Convert Running EC2 Instance to EBS-Optimized Instance with Provisioned IOPS EBS Volumes
Amazon just announced two related features for getting super-fast, consistent performance with EBS volumes: (1) Provisioned IOPS EBS volumes, and (2) EBS-Optimized Instances. Starting new instances and EBS volumes with…
Which EC2 Availability Zone is Affected by an Outage?
Did you know that Amazon includes status messages about the health of availability zones in the output of the ec2-describe-availability-zones command, the associated API call, and the AWS console? Right…
Installing AWS Command Line Tools Using Ubuntu Packages
See also: Installing AWS Command Line Tools from Amazon Downloads Here are the steps for installing the AWS command line tools that are currently available as Ubuntu packages. These include:…
Ubuntu Developer Summit, May 2012 (Oakland)
I will be attending the Ubuntu Developer Summit (UDS) next week in Oakland, CA. ┬áThis event brings people from around the world together in one place every six months to…
Uploading Known ssh Host Key in EC2 user-data Script
The ssh protocol uses two different keys to keep you secure: The user ssh key is the one we normally think of. This authenticates us to the remote host, proving…
Seeding Torrents with Amazon S3 and s3cmd on Ubuntu
Amazon Web Services is such a huge, complex service with so many products and features that sometimes very simple but powerful features fall through the cracks when you’re reading the…
There are a number of CloudCamp events coming up in cities around the world. These are free events, organized around the various concepts, technologies, and services that fall under the…
Use the Same Architecture (64-bit) on All EC2 Instance Types
A few hours ago, Amazon AWS announced that all EC2 instance types can now run 64-bit AMIs. Though t1.micro, m1.small, and c1.medium will continue to also support 32-bit AMIs, it…
ec2-consistent-snapshot on GitHub and v0.43 Released
The source for ec2-conssitent-snapshot has historically been available here: ec2-consistent-snapshot on using Bazaar For your convenience, it is now also available here: ec2-consistent-snapshot on GitHub using Git You are…