AMI types and characteristics in Amazon EC2
When you launch an instance, the AMI that you choose must be compatible with the instance type that you choose. You can select an AMI to use based on the following characteristics:
Operating system
Processor architecture
Launch permissions
The owner of an AMI determines its availability by specifying launch permissions. Launch permissions fall into the following categories.
| Launch permission | Description |
|---|---|
| public | The owner grants launch permissions to all AWS accounts. |
| explicit | The owner grants launch permissions to specific AWS accounts, organizations, or organizational units (OUs). |
| implicit | The owner has implicit launch permissions for an AMI. |
Amazon and the Amazon EC2 community provide a large selection of public AMIs. For more information, see Understand shared AMI usage in Amazon EC2. Developers can charge for their AMIs. For more information, see Paid AMIs in the AWS Marketplace for Amazon EC2 instances.
Root device type
All AMIs are categorized as either backed by Amazon EBS or backed by instance store.
-
Amazon EBS-backed AMI – The root device for an instance launched from the AMI is an Amazon Elastic Block Store (Amazon EBS) volume created from an Amazon EBS snapshot. Supported for both Linux and Windows AMIs.
-
Amazon instance store-backed AMI – The root device for an instance launched from the AMI is an instance store volume created from a template stored in Amazon S3. Supported for Linux AMIs only. Windows AMIs do not support instance store for the root device.
For more information, see Root volumes for your Amazon EC2 instances.
The following table summarizes the important differences when using the two types of AMIs.
| Characteristic | Amazon EBS-backed AMI | Amazon instance store-backed AMI |
|---|---|---|
Root device volume |
EBS volume |
Instance store volume |
Boot time for an instance |
Usually less than 1 minute |
Usually less than 5 minutes |
Data persistence |
By default, the root volume is deleted when the instance terminates.* Data on any other EBS volumes persists after instance termination by default. |
Data on any instance store volumes persists only during the life of the instance. |
Stopped state |
Can be in a stopped state. Even when the instance is stopped and not running, the root volume is persisted in Amazon EBS |
Cannot be in a stopped state; instances are running or terminated |
Modifications |
The instance type, kernel, RAM disk, and user data can be changed while the instance is stopped. |
Instance attributes are fixed for the life of an instance. |
Charges |
You're charged for instance usage, EBS volume usage, and storing your AMI as an EBS snapshot. |
You're charged for instance usage and storing your AMI in Amazon S3. |
AMI creation/bundling |
Uses a single command/call |
Requires installation and use of AMI tools |
* By default, EBS root volumes have the DeleteOnTermination flag set to
true. For information about how to change this flag so that the
volume persists after termination, see Keep an Amazon EBS root volume after an Amazon EC2 instance terminates.
** Supported with io2 EBS Block Express only. For more information, see
Provisioned IOPS SSD Block Express volumes in the Amazon EBS User Guide.
Virtualization types
Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main differences between PV and HVM AMIs are the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance. Windows AMIs are HVM AMIs.
The following table compares HVM and PV AMIs.
| Characteristic | HVM | PV |
|---|---|---|
| Description | HVM AMIs are presented with a fully virtualized set of hardware and boot by executing the master boot record of the root block device of your image. This virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware. The Amazon EC2 host system emulates some or all of the underlying hardware that is presented to the guest. | PV AMIs boot with a special boot loader called PV-GRUB, which starts
the boot cycle and then chain loads the kernel specified in the
menu.lst file on your image. Paravirtual guests can
run on host hardware that does not have explicit support for virtualization.
For more information about PV-GRUB and its use in Amazon EC2, see User provided kernels. |
| Supported instance types | All current generation instance types support HVM AMIs. | The following previous generation instance types support PV AMIs: C1, C3, M1, M3, M2, and T1. Current generation instance types do not support PV AMIs. |
| Support for hardware extensions | HVM guests can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system. They are required to use enhanced networking and GPU processing. To pass through instructions to specialized network and GPU devices, the OS must have access to the native hardware platform, and HVM virtualization provides this access. For more information, see Enhanced networking on Amazon EC2 instances. |
No, they can't take advantage of special hardware extensions such as enhanced networking or GPU processing. |
| How to find | Verify that the virtualization type of the AMI is set to
hvm, using the console or the describe-images
command. |
Verify that the virtualization type of the AMI is set to
paravirtual, using the console or the describe-images
command. |
PV on HVM
Paravirtual guests traditionally performed better with storage and network operations than HVM guests because they could leverage special drivers for I/O that avoided the overhead of emulating network and disk hardware, whereas HVM guests had to translate these instructions to emulated hardware. Now PV drivers are available for HVM guests, so operating systems that cannot be ported to run in a paravirtualized environment can still see performance advantages in storage and network I/O by using them. With these PV on HVM drivers, HVM guests can get the same, or better, performance than paravirtual guests.
