Alestic.com - A Personal AWS Blog by Eric Hammond

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) and registers the snapshot as an AMI. New instances can be run of this AMI with their starting state almost identical to the original running instance.

For years, I’ve been propagating the belief that a create-image call against a running instance is equivalent to these steps:

1. stop
2. register-image
3. start

However, through experimentation I’ve found that though create-image is similar to the above, it doesn’t have all of the effects that a stop/start has on an instance.

Specifically, when you trigger create-image,

• the Elastic IP address is not disassociated, even if the instance is not in a VPC,

• the Internal IP address is preserved, and

• the ephemeral storage (often on /mnt) is not lost.

I have not tested it, but I suspect that a new billing hour is not started with create-image (as it would be with a stop/start).

So, I am now going to start saying that create-image is equivalent to:

1. shutdown of the OS without stopping the instance - there is no way to do this in EC2 as a standalone operation
2. register-image
3. boot of the OS inside the still running instance - also no way to do this yourself.

or:

create-image is a reboot of the instance, with a register-image API call at the point when the OS is shutdown

As far as I’ve been able to tell, the instance stays in the running state the entire time.

I’ve talked before about the difference between a reboot and a stop/start on EC2.

Note: If you want to create an image (AMI) from your running instance, but can’t afford to have it reboot and be out of service for a few minutes, you can specify the no-reboot option.

There is a small risk of the new AMI having a corrupt file system in the rare event that the snapshot was created while the file system on the boot volume was being modified in an unstable state, but I haven’t heard of anybody actually getting bit by this.

If it is important, test the new AMI before depending on it for future use.