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
Launch permissions determine who can use an AMI to launch instances. You can think oflaunch permissions assharing an AMI—whenyou grant launch permissions, you're sharing the AMI with other users. Only theowner of an AMI can determine 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 moreinformation, seeUnderstand shared AMI usage in Amazon EC2.Developers can charge for their AMIs. For more information, seePaid AMIs in the AWS Marketplace for Amazon EC2 instances.
Root volume type
All AMIs are categorized as eitherbacked by Amazon EBS orbackedby Amazon S3.
Amazon EBS-backed AMI – The root volume for an instance launched from the AMI is anAmazon Elastic Block Store (Amazon EBS) volume created from an Amazon EBS snapshot. Supported for bothLinux and Windows AMIs.
Amazon S3-backed AMI – The root volume for an instance launched from the AMI is aninstance store volume created from a template stored in Amazon S3. Supported forLinux AMIs only. Windows AMIs do not support instance store for the rootvolume.
For more information, seeRoot volumes for your Amazon EC2 instances.
Amazon S3-backed AMIs are considered end of life and are not recommended for new usage. Theyare only supported on the following older instance types:C1, C3, D2, I2, M1, M2, M3, R3, and X1.
The following table summarizes the important differences when using the two types ofAMIs.
| Characteristic | Amazon EBS-backed AMI | Amazon S3-backed AMI |
|---|---|---|
Root 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 anyother EBS volumes persists after instance termination bydefault. | Data on any instance store volumes persists only during the life of theinstance. |
Stopped state | Can be in a stopped state. Even when the instance is stopped and not running, the rootvolume 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 theinstance 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 EBSsnapshot. | 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 theDeleteOnTermination flag set totrue. For information about how to change this flag so that thevolume persists after termination, seeKeep an Amazon EBS root volume after an Amazon EC2 instance terminates.
** Supported withio2 EBS Block Express only. For more information, seeProvisioned IOPS SSD Block Express volumes in theAmazon 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 themenu.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, seeUser 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, seeEnhanced 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 tohvm, using the console or thedescribe-images command. | Verify that the virtualization type of the AMI is set toparavirtual, using the console or thedescribe-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.
