Amazon Machine Image (AMI)

What is Amazon Machine Image (AMI)?

An Amazon Machine Image (AMI) is a master image for the creation of virtual servers -- known as EC2 instances -- in the Amazon Web Services (AWS) environment.

The machine images are like templates that are configured with an operating system and other software that determine the user's operating environment. AMI types are categorized according to region, operating system, system architecture -- 32- or 64-bit -- launch permissions and whether they are backed by Amazon Elastic Block Store (EBS) or backed by the instance store.

Each AMI includes a template for the root volume required for a particular type of instance. A typical example might contain an operating system, an application server and applications. Permissions are also controlled to ensure that AMI launches are restricted to the appropriate AWS accounts. block device mapping ensures that the correct volumes are attached to the launched instance.

How to create an AMI from an Amazon EC2 instance

Using an Amazon EC2 instance, AMIs can be created from running or stopped instances.

1. To create an AMI from a running instance, users open the Amazon EC2 instances view and right-click on the instance's file to select Create Image from the drop-down menu.
   
   
2. After selecting Create Image from the drop-down menu, a pop-up window appears with fields requiring information, such as a name and description. After filling in the field information, select Create Image at the bottom of the window. Amazon EC2 automatically shuts down the instance, takes a snapshot of any volumes attached, creates and registers the AMI, and then reboots the instance. Optionally, No reboot can be selected to prevent the instance from shutting down.
   
   
3. The AMI may take a few minutes to be created. When the creation process is complete, the AMI will appear in the AMIs view in the AWS Explorer. To access the AWS Explorer view, double-click on Amazon EC2 | AMIs node. View AMIs by selecting Owned by Me from the Viewing drop-down list. There is a Refresh button to see if the AMI has appeared; if it appears in a pending state, it will eventually become available.

Searching for an AMI

Once an AMI is created and registered, it can be used to launch new instances. It's also possible to launch instances from AMIs not belonging to a user if launch permissions are granted by the AMI owners. An AMI can be copied into the same or a different AWS region, which are the locations where AWS is available. Users can find an AMI suitable to their instance, either provided by AWS, the user community or through the AWS CLI.

AMIs can be selected based on the following factors:

• Region. Users can specify which region they want to search for an AMI among the EC2 locations around the world. Locations fall into the categories of Regions (geographic area), Availability Zones (isolated locations within a Region), Local Zones, AWS Outposts and Wavelength Zones. Resources can be placed in Local Zones to be closer to the end user. AWS Outposts bring any AWS service to data centers or on-premises facilities. Lastly, Wavelength Zones can host applications that provide low latencies required for communicating with 5G devices.
  
  
• Operating system. Users can select an AMI image by specifying an operating system, such as Linux.
  
  
• Architecture. The AMI architecture will either be 32-bit or 64-bit depending on the underlying operating system.
  
  
• Launch permissions. An owner decides the launch permission for an AMI, which can be public (any AWS account can get access), explicit (the owner of the AMI provides specific permission to AWS accounts) or implicit (only the owner has permission to launch the AMI).
  
  
• Storage for the root device. Storage for AMIs is either provided by Amazon Elastic Block Store (EBS) or by an instance store volume created from a template stored in Amazon S3.

Amazon Linux AMI virtualization types

AWS uses both paravirtualization (PV) and hardware virtual machines (HVM).

• Paravirtualization. This is a virtualization technique that can improve the performance of guest operating systems by eliminating the overhead of emulating hardware and by using knowledge of the guest operating system (OS). It is an approach to virtualization that is effective for high-performance computing (HPC) applications, such as those used in scientific computing, transactional databases and other enterprise computing that require rapid processing. PV requires close cooperation between the virtual machine monitor and the guest operating system, as well as a modified operating system kernel.
  
  
• Hardware virtual machines. HVM guests are fully virtualized, and the underlying hardware has to be emulated for the guests to use. With PV, the guest OS is modified to run without requiring that emulation. HVM requires that the host machine have a specific feature available on its hardware, whereas PV requires that the guest OS have a specific feature present in the software.

While both HVM and PV machines are virtual machines (VMs), the main difference is that PV virtual machines are lightweight compared to their HVM counterparts. This means a PV VM boots faster and uses less computer hardware but is limited to a smaller number of operating systems.

Buying, selling and deregistering AMIs

After an AMI is created, it can be kept private so that only the owner can use it, or it can be

shared with specific AWS accounts. AMIs can also be made public to share with the community. Using a shared AMI is at the user's risk as Amazon cannot guarantee the integrity or security of publicly shared AMIs by Amazon EC2 users. Shared AMIs should be regarded as any other foreign code being deployed, meaning that the user is expected to perform their own due diligence before using a publicly available AMI.

AMIs can also be purchased from a third party, including those that come with service contracts from organizations such as Red Hat -- a Linux distribution based on the source code of the Linux kernel. Created AMIs can also be sold to other Amazon EC2 users.

If an AMI is deregistered, current instances will not be affected, but it cannot be used to launch new instances. Existing instances already using the AMI will not be impacted and will continue to incur instances charges. This means that when a user is finished with an instance, it should be terminated.