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:
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
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:
shutdownof the OS without stopping the instance - there is no way to do this in EC2 as a standalone operation
bootof the OS inside the still running instance - also no way to do this yourself.
rebootof the instance, with a
register-imageAPI 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
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.