To create an instance store-backed Linux AMI, start from an instance that you've launched from an existing instance store-backed Linux AMI. After you've customized the instance to suit your needs, bundle the volume and register a new AMI, which you can use to launch new instances with these customizations.
If you need to create an instance store-backed Windows AMI, see Creating an Instance Store-Backed Windows AMI in the Amazon EC2 User Guide for Microsoft Windows Instances.
The AMI creation process is different for instance store-backed AMIs. For more information about the differences between Amazon EBS-backed and instance store-backed instances, and how to determine the root device type for your instance, see Storage for the Root Device. If you need to create an Amazon EBS-backed Linux AMI, see Creating an Amazon EBS-Backed Linux AMI.
The following diagram summarizes the process of creating an AMI from an instance store-backed instance.
First, launch an instance from an AMI that's similar to the AMI that you'd like to create.
You can connect to your instance and customize it. When the instance is set up the way
you want it, you can bundle it. It takes several minutes for the bundling
process to complete. After the process completes, you have a bundle, which consists of
an image manifest (
image.part.xx) that contain a template for the root volume.
Next you upload the bundle to your Amazon S3 bucket and then register your AMI.
When you launch an instance using the new AMI, we create the root volume for the instance using the bundle that you uploaded to Amazon S3. The storage space used by the bundle in Amazon S3 incurs charges to your account until you delete it. For more information, see Deregistering Your AMI.
If you add instance store volumes to your instance in addition to the root device volume, the block device mapping for the new AMI contains information for these volumes, and the block device mappings for instances that you launch from the new AMI automatically contain information for these volumes. For more information, see Block Device Mapping.
Before you can create the AMI, you must complete the following tasks:
Install the AMI tools. For more information, see Set Up the AMI Tools.
Install the API tools. For more information, see Setting Up the Amazon EC2 Command Line Interface Tools on Linux.
Ensure that you have an Amazon S3 bucket for the bundle. To create an Amazon S3 bucket, open the Amazon S3 console and click Create Bucket.
Ensure that you have the following credentials:
Your AWS account ID. To retrieve your account ID, go to Your Security Credentials and expand Account Identifiers.
An X.509 certificate and private key. If you need to create an X.509 certificate, go to Your Security Credentials, expand X.509 Certificates, and click Create New Certificate. The X.509 certificate and private key are used to encrypt and decrypt your AMI.
Your access key ID. If you need to retrieve or create an access key ID, go to Your Security Credentials, and expand Access Keys.
Your secret access key. You can't retrieve your secret access key. Therefore, if you can't find your secret access key, you'll need to create a new one. To create a secret access key, go to Your Security Credentials, expand Access Keys, and click Create New Access Key.
Connect to your instance and customize it. For example, you can install software and applications, copy data, delete temporary files, and modify the Linux configuration.
To prepare to use the Amazon EC2 AMI Tools (HVM instances only)
The Amazon EC2 AMI tools require GRUB Legacy to boot properly. Some AMIs (most notably, Ubuntu) are configured to use GRUB 2. You must check to see that your instance uses GRUB Legacy, and if not, you need to install and configure it.
HVM instances also require partitioning tools to be installed for the AMI tools to work properly.
Check to see if your instance uses GRUB Legacy.
List the block devices to find the root block device.
lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part / xvdb 202:16 0 30G 0 disk /media/ephemeral0
this example, the root device (indicated by a
MOUNTPOINT of /) is
/dev/xvda1. The root block device is its
Determine the GRUB version on the root block device.
sudo file -s /dev/xvda/dev/xvda: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, stage2 address 0x2000, 1st sector stage2 0x800, stage2 segment 0x200, GRUB version 0.94; partition 1: ID=0xee, starthead 254, startsector 1, 16777215 sectors, extended partition table (last)\011, code offset 0x48
the above example, the GRUB version is 0.94, which is GRUB Legacy. If
your GRUB version is 0.9
x or less, you may
move on to Step 3. If you do
not see a GRUB version in this output, try the grub-install
grub-install --versiongrub-install (GRUB) 1.99-21ubuntu3.10
this example, the GRUB version is greater than
x, so GRUB Legacy must be installed.
Proceed to Step 2.
sudo apt-get install -y grub
You can verify that your instance is using GRUB Legacy with the grub --version command.
grub --versiongrub (GNU GRUB 0.97)
gdisk (some distributions may call this package
For Ubuntu instances, use the following command.
sudo apt-get install -y gdisk kpartx
Check the kernel parameters for your instance.
cat /proc/cmdlineBOOT_IMAGE=/boot/vmlinuz-3.2.0-54-virtual root=UUID=4f392932-ed93-4f8f-aee7-72bc5bb6ca9d ro console=ttyS0 xen_emul_unplug=unnecessary
the options following the kernel and root device parameters,
xen_emul_unplug=unnecessary. Your options may
Check the kernel entries in
grep ^kernel /boot/grub/menu.lstkernel /boot/vmlinuz-3.2.0-54-virtual root=LABEL=cloudimg-rootfs ro console=hvc0 kernel /boot/vmlinuz-3.2.0-54-virtual root=LABEL=cloudimg-rootfs ro single kernel /boot/memtest86+.bin
console parameter is pointing to
hvc0 instead of
ttyS0 and that the
xen_emul_unplug=unnecessary parameter is missing. Again,
your options may differ.
/boot/grub/menu.lst file with your favorite text
editor (such as vim or nano) to change the
console and add the parameters you identified earlier to the boot
title Ubuntu 12.04.3 LTS, kernel 3.2.0-54-virtual root (hd0) kernel /boot/vmlinuz-3.2.0-54-virtual root=LABEL=cloudimg-rootfs ro
console=ttyS0 xen_emul_unplug=unnecessaryinitrd /boot/initrd.img-3.2.0-54-virtual title Ubuntu 12.04.3 LTS, kernel 3.2.0-54-virtual (recovery mode) root (hd0) kernel /boot/vmlinuz-3.2.0-54-virtual root=LABEL=cloudimg-rootfs ro single
console=ttyS0 xen_emul_unplug=unnecessaryinitrd /boot/initrd.img-3.2.0-54-virtual title Ubuntu 12.04.3 LTS, memtest86+ root (hd0) kernel /boot/memtest86+.bin
Verify that your kernel entries now contain the correct parameters.
grep ^kernel /boot/grub/menu.lstkernel /boot/vmlinuz-3.2.0-54-virtual root=LABEL=cloudimg-rootfs ro console=ttyS0 xen_emul_unplug=unnecessary kernel /boot/vmlinuz-3.2.0-54-virtual root=LABEL=cloudimg-rootfs ro single console=ttyS0 xen_emul_unplug=unnecessary kernel /boot/memtest86+.bin
(For Ubuntu 14.04 and later only) Starting with Ubuntu 14.04, instance store
backed Ubuntu AMIs use a GPT partition table and a separate EFI partition
/boot/efi. The ec2-bundle-vol
command will not bundle this boot partition, so you need to comment out the
/etc/fstab entry for the EFI partition as shown in the
LABEL=cloudimg-rootfs / ext4 defaults 0 0
#LABEL=UEFI /boot/efi vfat defaults 0 0 /dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
To create an AMI from an instance store-backed Linux instance
This procedure assumes that you have satisfied the prerequisites in Prerequisites.
Upload your credentials to your instance. We use these credentials to ensure that only you and Amazon EC2 can access your AMI.
Create a temporary directory on your instance for your credentials as follows:
This enables you to exclude your credentials from the created image.
Copy your X.509 certificate and private key from your computer to the
/tmp/cert directory on your instance, using a
secure copy tool such as scp. The
the following scp command is the private key you use
to connect to your instance with SSH, not the X.509 private key. For
scp -ipk-HKZYKTAIG2ECMXYIBH3HXV4ZBEXAMPLE.pem 100% 717 0.7KB/s 00:00 cert-HKZYKTAIG2ECMXYIBH3HXV4ZBEXAMPLE.pem 100% 685 0.7KB/s 00:00
Prepare the bundle to upload to Amazon S3 using the ec2-bundle-vol command.
Be sure to specify the
-e option to exclude the directory where your credentials are stored.
By default, the bundle process excludes files that might contain sensitive information.
These files include
To include all of these files, use the
To include some of these files, use the
By default, the AMI bundling process creates a compressed, encrypted
collection of files in the
/tmp directory that
represent your root volume. If you do not have enough free disk space in
/tmp to store the bundle, you need to specify a
different location for the bundle to be stored with the
Some instances have ephemeral storage mounted at
/media/ephemeral0 that you can use, or you can also
create, attach, and mount a new Amazon EBS volume to store the
The ec2-bundle-vol command needs to run as
For most commands, you can use sudo to gain elevated
permissions, but in this case, you should run sudo -E
su to keep your environment
sudo -E su
Run the ec2-bundle-vol
command with the following arguments. If you do not have enough
available disk space in
/tmp to store your bundle,
specify a location that has available space with the
option. For HVM instances, be sure to add the
--partition flag; otherwise, your AMI will not
boot. For more information on this command and its available options,
see ec2-bundle-vol in the Amazon EC2 Command Line Reference.
For Ubuntu 14.04 and later HVM instances, add the
flag to bundle the boot instructions properly ; otherwise, your
newly-created AMI will not boot.
$EC2_AMITOOL_HOME/bin/ec2-bundle-vol -k /tmp/cert/
your_aws_account_id-r x86_64 -e /tmp/cert
It can take a few minutes to create the image. When this command
tmp directory contains the bundle
image.manifest.xml, plus multiple
Exit from the
Upload your bundle to Amazon S3 using the ec2-upload-bundle command. Note that if the bundle prefixes (directories) don't exist in the bucket, this command creates them.
If you specified a path with the
option in Step 2.b, use that same path in the
-m option below, instead of
bundle_name-m /tmp/image.manifest.xml -a
(Optional) After the bundle is uploaded to Amazon S3, you can remove the bundle from the
/tmp directory on the instance using the following
If you specified a path with the
option in Step 2.b, use that same path below,
sudo rm /tmp/image.manifest.xml /tmp/image.part.* /tmp/image
Register your AMI using the ec2-register command. Note that you don't need to specify the
-W options if you've set the
For HVM AMIs, add the
(For Ubuntu 14.04 and later only) Uncomment the EFI entry in
/etc/fstab; otherwise, your running instance will not
be able to reboot.
You can convert an instance store-backed Linux AMI that you own to an Amazon EBS-backed Linux AMI.
You can't convert an instance store-backed Windows AMI to an Amazon EBS-backed Windows AMI and you cannot convert an AMI that you do not own.
To convert an instance store-backed AMI to an Amazon EBS-backed AMI
Launch an Amazon Linux instance from an Amazon EBS-backed AMI. For more information, see Launching an Instance. Amazon Linux instances have the Amazon EC2 command line and AMI tools pre-installed.
Upload the X.509 private key that you used to bundle your instance store-backed AMI to your instance. We use this key to ensure that only you and Amazon EC2 can access your AMI.
Create a temporary directory on your instance for your X.509 private key as follows:
Copy your X.509 private key from your computer to the
/tmp/cert directory on your instance, using a
secure copy tool such as scp. The
in the following command is the private key you use to connect to your
instance with SSH. For example:
scp -ipk-HKZYKTAIG2ECMXYIBH3HXV4ZBEXAMPLE.pem 100% 717 0.7KB/s 00:00
Set environment variables for your AWS access key and secret key.
export AWS_ACCESS_KEY=[ec2-user ~]$
Prepare an Amazon EBS volume for your new AMI.
Create an empty Amazon EBS volume in the same Availability Zone as your instance using the ec2-create-volume command. Note the volume ID in the command output.
This Amazon EBS volume must be the same size or larger than the original instance store root volume.
ec2-create-volume --size 10 --regionVOLUME
volume_id10 us-west-2b creating 2014-01-24T23:11:45+0000 standard
Attach the volume to your Amazon EBS-backed instance using the ec2-attach-volume command.
instance_id--device /dev/sdb --region
instance_id/dev/sdb attaching 2014-01-24T23:15:34+0000
Create a folder for your bundle.
Download the bundle for your instance store-based AMI to
using the ec2-download-bundle command.
bundle_name-m image.manifest.xml -a $AWS_ACCESS_KEY -s $AWS_SECRET_KEY --privatekey
Reconstitute the image file from the bundle using the ec2-unbundle command.
Change directories to the bundle folder.
Run the ec2-unbundle command.
ec2-unbundle -m image.manifest.xml --privatekey
Copy the files from the unbundled image to the new Amazon EBS volume.
sudo dd if=/tmp/bundle/image of=/dev/sdb bs=1M
Probe the volume for any new partitions that were unbundled.
sudo partprobe /dev/sdb
List the block devices to find the device name to mount.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT /dev/sda 202:0 0 8G 0 disk └─/dev/sda1 202:1 0 8G 0 part / /dev/sdb 202:80 0 10G 0 disk └─/dev/sdb1 202:81 0 10G 0 part
In this example, the partition to mount is
your device name will likely be different. If your volume is not partitioned,
then the device to mount will be similar to
(without a device partition trailing digit).
Create a mount point for the new Amazon EBS volume and mount the volume.
sudo mkdir /mnt/ebs[ec2-user bundle]$
sudo mount /dev/sdb1 /mnt/ebs
/etc/fstab file on the EBS volume with your favorite text
editor (such as vim or nano) and remove
any entries for instance store (ephemeral) volumes. Because the Amazon EBS volume is
fstab file is
sudo nano /mnt/ebs/etc/fstab# LABEL=/ / ext4 defaults,noatime 1 1 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0
/dev/sdb /media/ephemeral0 auto defaults,comment=cloudconfig 0 2
In the above example, the last line should be removed.
Unmount the volume and detach it from the instance.
sudo umount /mnt/ebs[ec2-user bundle]$
instance_id/dev/sdb detaching 2014-01-24T23:15:34+0000
Create an AMI from the new Amazon EBS volume as follows.
Create a snapshot of the new Amazon EBS volume.
your_snapshot_description" -O $AWS_ACCESS_KEY -W $AWS_SECRET_KEY
volume_idpending 2014-01-25T00:18:48+000 1234567891011 10
Check to see that your snapshot is complete.
volume_idcompleted 2014-01-25T00:18:48+0000 100% 1234567891011 10
Identify the processor architecture, virtualization type, and the kernel image
aki) used on the original AMI with the
ec2-describe-images command. You need the AMI
ID of the original instance store-backed AMI for this
ami-8ef297beamazon/amzn-ami-pv-2013.09.2.x86_64-s3 amazon available public x86_64 machine aki-fc8f11cc instance-store paravirtual xen
this example, the architecture is
x86_64 and the
kernel image ID is
aki-fc8f11cc. Use these values in
the following step. If the output of the above command also lists an
ari ID, take note of that as well.
Register your new AMI with the snapshot ID of your new Amazon EBS volume and the values from the
previous step. If the previous command output listed an
ari ID, include that in the following command
snapshot_id-a x86_64 --kernel
(Optional) After you have tested that you can launch an instance from your new AMI, you can delete the Amazon EBS volume that you created for this procedure.