Creating an Instance Store-Backed Linux AMI
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.
Overview of the Creation Process for Instance Store-Backed AMIs
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 find your AWS account ID number in the AWS Management Console, click on Support in the navigation bar in the upper-right, and then click Support Center. Your currently signed in account ID appears below the Support menu.
An X.509 certificate and private key. If you need to create an X.509 certificate, see Managing Signing Certificates in the Amazon EC2 Command Line Reference. The X.509 certificate and private key are used to encrypt and decrypt your AMI.
Your AWS account access key ID and secret access key. For more information, see Creating, Modifying, and Viewing Access Keys in the IAM User Guide.
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.
Creating an AMI from an Instance Store-Backed Linux Instance
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
In this example, the root device (indicated by a
MOUNTPOINTof /) is
/dev/xvda1. The root block device is its parent,
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
In the above example, the GRUB version is 0.94, which is GRUB Legacy. If your GRUB version is 0.9
xor less, you may move on to Step 3. If you do not see a GRUB version in this output, try the grub-install --version command.
grub-install --versiongrub-install (GRUB) 1.99-21ubuntu3.10
In this example, the GRUB version is greater than 0.9
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
Note the options following the kernel and root device parameters,
xen_emul_unplug=unnecessary. Your options may differ.
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
Note that the
consoleparameter is pointing to
ttyS0and that the
xen_emul_unplug=unnecessaryparameter is missing. Again, your options may differ.
/boot/grub/menu.lstfile with your favorite text editor (such as vim or nano) to change the console and add the parameters you identified earlier to the boot entries.
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 mounted at
/boot/efi. The ec2-bundle-vol command will not bundle this boot partition, so you need to comment out the
/etc/fstabentry for the EFI partition as shown in the example below.
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/certdirectory on your instance, using a secure copy tool such as scp. The
-ioption in the following scp command is the private key you use to connect to your instance with SSH, not the X.509 private key. For example:
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
-eoption to exclude the directory where your credentials are stored. By default, the bundle process excludes files that might contain sensitive information. These files include
*/.bash_history. To include all of these files, use the
--no-filteroption. To include some of these files, use the
By default, the AMI bundling process creates a compressed, encrypted collection of files in the
/tmpdirectory that represent your root volume. If you do not have enough free disk space in
/tmpto store the bundle, you need to specify a different location for the bundle to be stored with the
-doption. Some instances have ephemeral storage mounted at
/media/ephemeral0that you can use, or you can also create, attach, and mount a new Amazon EBS volume to store the bundle.
The ec2-bundle-vol command needs to run as
root. 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 variables.
sudo -E su
Run the ec2-bundle-vol command with the following arguments. If you do not have enough available disk space in
/tmpto store your bundle, specify a location that has available space with the
option. For HVM instances, be sure to add the
--partitionflag; 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
--partition mbrflag 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 completes, your
tmpdirectory 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
-moption 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
/tmpdirectory on the instance using the following rm command:
If you specified a path with the
option in Step 2.b, use that same path below, instead of
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
-Woptions 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.
Converting your Instance Store-Backed AMI to an Amazon EBS-Backed AMI
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/certdirectory on your instance, using a secure copy tool such as scp. The
my-private-keyparameter 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
/tmp/bundleusing 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.
lsblkNAME 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
/dev/sdb1, but your device name will likely be different. If your volume is not partitioned, then the device to mount will be similar to
/dev/sdb(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/fstabfile 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 mounted on
fstabfile is located at
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 step.
ami-8ef297beamazon/amzn-ami-pv-2013.09.2.x86_64-s3 amazon available public x86_64 machine aki-fc8f11cc instance-store paravirtual xen
In this example, the architecture is
x86_64and the kernel image ID is
aki-fc8f11cc. Use these values in the following step. If the output of the above command also lists an
ariID, 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
ariID, include that in the following command with
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.