What Are the Differences Between EBS and Instance Store AMIs?

Amazon Elastic Compute Cloud instances rely on Amazon Machine Images to define the initial software and root storage configuration required to launch a virtual server. The primary distinction between Elastic Block Store backed images and instance store backed images lies in where the root volume resides and how data persistence, instance lifecycle states, and launch speeds are handled. While Elastic Block Store backed images use persistent network-attached block storage that survives instance reboots and stops, instance store backed images utilize ephemeral local storage physically attached to the host computer, offering temporary storage that is wiped when the instance terminates.

Understanding EBS-Backed AMIs

An Amazon EBS-backed AMI launches an EC2 instance whose root device is an Amazon Elastic Block Store volume created from an Amazon EBS snapshot. Because EBS volumes are network-attached storage independent of the physical host running the compute instance, they provide long-term durability and flexibility.

Key Characteristics of EBS-Backed Instances

• Boot Speed: Instances launched from an EBS-backed AMI typically boot much faster (usually under a minute) because the root volume does not need to be downloaded from Amazon S3 in its entirety before booting begins.
• Instance Lifecycle: EBS-backed instances support the Running, Stopped, Hibernate, and Terminated states. When you stop an EBS-backed instance, the virtual machine shuts down and you stop incurring compute charges, but the root EBS volume remains intact so you can restart the instance later.
• Upgradability: Because the instance can be stopped without losing root volume data, you can easily change the instance type, update kernel parameters, or modify volume attributes while the instance is in the Stopped state.
• Data Persistence: By default, the root EBS volume is deleted when the instance is terminated, though you can configure the DeleteOnTermination attribute to false to preserve the root volume even after termination. Any secondary EBS volumes attached to the instance persist by default upon termination.

Understanding Instance Store-Backed AMIs

An instance store-backed AMI launches an EC2 instance whose root device is an ephemeral storage volume created from a template stored in Amazon Simple Storage Service (Amazon S3). Instance store volumes reside on disks that are physically attached to the underlying host computer (such as NVMe SSDs or SATA HDDs).

Key Characteristics of Instance Store-Backed Instances

• Boot Speed: Booting an instance store-backed AMI takes longer than an EBS-backed AMI because the entire root volume image bundle must be copied from Amazon S3 to the local storage on the host server before the instance can finish booting.
• Instance Lifecycle: Instance store-backed instances only support Running and Terminated states (along with rebooting). They cannot be placed in a Stopped state. If the instance were stopped and started again, it would likely be placed on a different physical host, leaving the local disk behind.
• Data Persistence: Data on an instance store volume persists only during the lifetime of the associated instance. While data survives guest operating system reboots, it is permanently lost if the underlying disk drive fails, the instance stops (in scenarios of host hardware degradation), or the instance terminates.
• Volume Size Limit: The root volume of an instance store-backed AMI has a strict maximum size limit of \(10\text{ GiB}\).

Side-by-Side Comparison

Differences in AMI Creation and Management

Creating an EBS-backed AMI is straightforward. You can generate a new AMI from a running or stopped instance using a single command or console action. AWS automatically takes a point-in-time snapshot of the root volume and registers the image.

Creating an instance store-backed AMI requires significantly more effort. You must use specific AMI tools on the running instance to bundle the root volume into compressed, encrypted parts, upload those parts to an Amazon S3 bucket, and then register the manifest file (image.manifest.xml) with EC2 to create the AMI.

When to Use Each AMI Type

Use EBS-Backed AMIs For:

• Almost All Standard Workloads: AWS recommends EBS-backed AMIs for the vast majority of use cases due to their reliability, ease of management, and fast boot times.
• Cost Optimization via Stopping: Environments such as development, testing, or staging servers that need to be stopped outside of business hours to save on EC2 compute costs while retaining their state.
• Vertical Scaling: Applications where you anticipate needing to resize the instance type (CPU/RAM) or scale the storage size and IOPS dynamically.

Use Instance Store-Backed AMIs For:

• Stateless Distributed Architectures: Workloads where every node is completely disposable and replicates data across a cluster, or pulls configuration dynamically on startup.
• Strict Ephemeral Security Requirements: Scenarios where regulations dictate that no persistent root storage snapshots or residual network block volumes remain after an instance shuts down.

Note that if you require the high I/O performance of local NVMe instance store disks, you do not need to use an instance store-backed AMI. You can launch an EBS-backed AMI on an instance type that includes local instance store volumes (such as the i3, i4i, or c6id families), using EBS for the persistent \(8\text{ GiB}\) to \(100\text{ GiB}\) root OS drive while mounting the local instance store volumes for high-speed scratch data, caches, and temporary buffers.