AMI

An Amazon Machine Image (AMI) supplies everything needed to launch an instance. An AMI is defined by:

1. The Region it exists in — AMIs are regional, and must be copied to be used elsewhere
2. The operating system and any software baked into the root volume
3. The processor architecture (x86-64 or ARM64)
4. Launch permissions, which control who may launch from it
5. A block device mapping describing the root volume and any additional volumes

EBS-backed and instance-store-backed

An AMI is backed by one of two root device types.

Amazon EBS. The root device is an EBS volume created from an EBS snapshot. The instance can be stopped and started without losing data, the root volume can be resized and re-attached, and on termination you can choose to retain the volumes. This is what current-generation instances use.

Instance store. The root device is an instance store volume created from a template held in Amazon S3. This storage is ephemeral: the instance cannot be stopped, only rebooted or terminated, and if the underlying host fails the data is gone. Terminating the instance destroys the volume. Very few workloads have a reason to use this today.

AMIs and launch templates

An AMI and a launch template do different jobs, and they are often confused:

• An AMI is the server image and nothing else.
• A launch template is the complete launch configuration — which AMI, which instance type, which subnet, which security groups, which IAM instance profile, which user data.
• You need an AMI to write a launch template, and one AMI can be referenced by many launch templates.
• Launch templates are required for newer Auto Scaling features such as mixed instance types and multiple purchase options in a single group. See Auto Scaling groups.

How to create an AMI

There are two routes.

From a running instance. This takes a point-in-time snapshot of every EBS volume attached to the instance and preserves the installed software, configuration and data. It can be done while the instance is running, but anything mid-write may be captured inconsistently — stop the instance first if the data matters.

From an existing EBS snapshot. Useful when the original instance is gone. The snapshot must be of a root volume. You can adjust some settings during creation, such as architecture and virtualisation type, and attach snapshots of additional volumes at the same time.

In both cases the resulting AMI inherits the permissions and encryption settings of the source snapshots. An AMI whose root snapshot is unencrypted cannot be used to launch an instance with hibernation enabled — see EC2 Hibernation.

For anything that ships repeatedly, build AMIs from a versioned definition rather than by hand: EC2 Image Builder or Packer, driven from a pipeline, so the image is reproducible and its provenance is recorded.