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:
stop
register-image
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:
shutdown
of the OS without stopping the instance - there is no way to do this in EC2 as a standalone operationregister-image
boot
of the OS inside the still running instance - also no way to do this yourself.
or:
create-image
is areboot
of the instance, with aregister-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.