AWS EBS vs Instance Store – Persistence & Speed

AWS EBS vs Instance Store

🆕 Major Updates (2024-2026)

  • EBS gp3 Performance Boost (Sep 2025) – Up to 64 TiB size, 80,000 IOPS, and 2,000 MiB/s throughput (4X/5X/2X previous limits)
  • EBS Multi-Attach – io1/io2 volumes can attach to up to 16 Nitro-based instances simultaneously
  • EBS Elastic Volumes – Up to 4 volume modifications per 24-hour window (Jan 2026)
  • io2 Block Express – 256,000 IOPS, 4,000 MB/s, 64 TiB capacity, 99.999% durability
  • EBS Recycle Bin – Recover deleted snapshots, AMIs, and volumes (volumes support added Nov 2025)
  • EBS Snapshots Archive – Low-cost archive tier for infrequently accessed snapshots
  • New Instance Store Types – I7i (45 TB NVMe, 50% better performance), C8id/M8id/R8id (22.8 TB), M9gd (Graviton5)
  • EC2 instances support two types for block level storage
  • EC2 Instances can be launched using either Elastic Block Store (EBS) or Instance Store volume as root volumes and additional volumes.
  • EC2 instances can be launched by choosing between AMIs backed by EC2 instance store and AMIs backed by EBS. However, AWS recommends using EBS backed AMIs because they launch faster and use persistent storage.
  • Instance store backed AMIs (S3-backed) are supported for Linux instances only. Windows instances can only use EBS-backed AMIs.

Instance Store (Ephemeral storage)

  • An Instance store backed instance is an EC2 instance using an Instance store as root device volume created from a template stored in S3.
  • Instance store volumes access storage from disks that are physically attached to the host computer.
  • When an Instance stored instance is launched, the image that is used to boot the instance is copied to the root volume (typically sda1).
  • Instance store provides temporary block-level storage for instances.
  • Data on an instance store volume persists only during the life of the associated instance; if an instance is stopped or terminated, any data on instance store volumes is lost.
  • Modern instance store volumes use NVMe-based SSDs (Nitro SSDs) that provide high I/O performance, low latency, and always-on hardware encryption.

Key points for Instance store backed Instance

  1. Boot time is slower than EBS backed volumes and usually less than 5 min
  2. Can be selected as Root Volume and attached as additional volumes
  3. Instance store backed Instances can be of a maximum 10GiB volume size for root volumes
  4. Instance store volume can be attached as additional volumes only when the instance is being launched and cannot be attached once the Instance is up and running.
  5. Instance store backed Instances cannot be stopped, as when stopped and started AWS does not guarantee the instance would be launched in the same host, and hence the data is lost.
  6. Data on Instance store volume is LOST in the following scenarios:-
    • Failure of an underlying drive
    • Stopping an EBS-backed instance where instance stores are attached as additional volumes
    • Termination of the Instance
  7. Data on Instance store volume is NOT LOST when the instance is rebooted
  8. For EC2 instance store-backed instances AWS recommends to
    1. distribute the data on the instance stores across multiple AZs
    2. back up critical data from the instance store volumes to persistent storage on a regular basis.
  9. AMI creation requires the usage of AMI tools and needs to be executed from within the running instance.
  10. Instance store backed Instances cannot be upgraded

Instance Store Instance Types (2024-2026)

  • Storage Optimized:
    • I7i instances (Apr 2025) – Up to 45 TB NVMe storage with 3rd gen Nitro SSDs, 50% better real-time storage performance, 50% lower I/O latency, and 60% lower latency variability vs I4i
    • I4i instances – Up to 30 TB local Nitro SSD storage with always-on encryption
    • I3en instances – Up to 60 TB NVMe SSD with 100 Gbps networking
  • General Purpose with local storage:
    • M9gd (Jun 2026) – Graviton5-based with NVMe SSD, up to 30% faster compute than M8g
    • C8id/M8id/R8id (Feb 2026) – Intel Xeon 6 with up to 22.8 TB NVMe storage, 3X more local storage than 6th-gen
    • C8gd/M8gd/R8gd (Apr 2025) – Graviton4-based with NVMe SSD storage
  • Instance store volumes can deliver over 100,000+ IOPS on certain instance types (much faster than network-attached EBS storage)

Elastic Block Store (EBS)

  • An “EBS-backed” instance means that the root device for an instance launched from the AMI is an EBS volume created from an EBS snapshot
  • An EBS volume behaves like a raw, unformatted, external block device that can be attached to an instance and is not physically attached to the Instance host computer (more like network-attached storage).
  • Volume persists independently from the running life of an instance.
  • After an EBS volume is attached to an instance, you can use it like any other physical hard drive.
  • EBS volume can be detached from one instance and attached to another instance
  • EBS volumes can be created as encrypted volumes using the EBS encryption feature
  • EBS Multi-Attach: io1 and io2 Provisioned IOPS volumes can be attached to up to 16 Nitro-based instances simultaneously within the same AZ
  • EBS Elastic Volumes: Allows modification of volume size, type, and IOPS without detaching the volume or stopping the instance

Key points for EBS backed Instance

  1. Boot time is very fast usually less than a min
  2. Can be selected as Root Volume and attached as additional volumes
  3. EBS backed Instances can be of maximum 64 TiB volume size depending upon the volume type and OS (gp3 and io2 Block Express both support up to 64 TiB)
  4. EBS volume can be attached as additional volumes when the Instance is launched and even when the Instance is up and running
  5. Data on the EBS volume is LOST for
    1. EBS Root volume, if Delete On Termination flag is enabled, which is the default.
    2. Attached EBS volumes, if the Delete On Termination flag is enabled. It’s disabled, by default.
  6. Data on EBS volume is NOT LOST in the following scenarios:-
    • Reboot on the Instance
    • Stopping an EBS-backed instance
    • Termination of the Instance for the additional EBS volumes. Additional EBS volumes are detached with their data intact
  7. When an EBS-backed instance is in a stopped state, various instance– and volume-related tasks can be done for e.g. you can modify the properties of the instance, you can change the size of your instance or update the kernel it is using, or you can attach your root volume to a different running instance for debugging or any other purpose
  8. EBS volumes are AZ scoped and tied to a single AZ where created.
  9. EBS volumes are automatically replicated within that zone to prevent data loss due to the failure of any single hardware component
  10. AMI creation is easy using a Single command
  11. EBS backed Instances can be upgraded for instance type, Kernel, RAM disk, and user data
  12. EBS volumes support Elastic Volumes modifications – change size, type, and IOPS/throughput without detaching (up to 4 modifications per 24-hour window as of Jan 2026)

EBS Volume Types (Current)

  • EBS provides six volume types:
    • General Purpose SSD (gp3) – Up to 64 TiB, 80,000 IOPS, 2,000 MiB/s (enhanced Sep 2025). Baseline: 3,000 IOPS, 125 MiB/s. Recommended for most workloads.
    • General Purpose SSD (gp2) – Up to 16 TiB, 16,000 IOPS. Burstable performance. Migration to gp3 recommended for cost savings (up to 20% less).
    • Provisioned IOPS SSD (io2 Block Express) – Up to 64 TiB, 256,000 IOPS, 4,000 MB/s, 99.999% durability, sub-millisecond latency. Supports Multi-Attach.
    • Provisioned IOPS SSD (io1) – Up to 16 TiB, 64,000 IOPS. Migration to io2 recommended for better durability at same cost.
    • Throughput Optimized HDD (st1) – Up to 16 TiB, 500 MiB/s. For frequently accessed, throughput-intensive workloads.
    • Cold HDD (sc1) – Up to 16 TiB, 250 MiB/s. Lowest cost for infrequently accessed data.

EBS Data Protection Features

  • EBS Snapshots: Point-in-time backups stored in S3, incremental in nature
    • Snapshots Archive: Low-cost tier for infrequently accessed snapshots (75% cheaper). Minimum 90-day retention. Restore takes 24-72 hours.
    • Snapshots Lock: Prevent snapshot deletion for a specified period (governance or compliance mode)
  • Recycle Bin: Recover accidentally deleted EBS snapshots, AMIs, and EBS volumes
    • Retention rules specify how long deleted resources are retained (1 day to 1 year)
    • Rule Lock: Prevent retention rules from being modified or deleted
    • EBS Volumes support added in Nov 2025
  • Encryption by Default: Enable at account/region level to encrypt all new EBS volumes and snapshots using AWS KMS

EBS vs Instance Store Comparison

Feature EBS Instance Store
Persistence Persists independently of instance lifecycle Ephemeral – lost on stop/terminate/hardware failure
Boot Time Fast (less than 1 minute) Slower (up to 5 minutes, retrieved from S3)
Max Volume Size Up to 64 TiB (gp3, io2 Block Express) Up to 10 GiB (root); varies by instance type for additional
Performance Up to 256,000 IOPS (io2), 80,000 IOPS (gp3) 100,000+ IOPS (SSD); lowest latency (physically attached)
Attachment Can attach/detach while running; Multi-Attach for io1/io2 Only at launch; cannot be added later
Stop/Start Supported; data persists Cannot stop instance-store backed instances
Encryption EBS encryption with KMS; encryption by default option Hardware encryption on Nitro SSD instance types
Snapshots Supported (incremental, archive tier, Recycle Bin) Not supported
AMI Creation Single command Requires AMI tools from within instance
Instance Upgrade Can change instance type while stopped Cannot upgrade instance type
Cost Pay for provisioned storage (per GB-month + IOPS/throughput) Included in instance price
Use Cases Databases, boot volumes, persistent storage, most workloads Temporary data, caches, buffers, scratch data, high-IOPS workloads
Replication Automatically replicated within AZ No replication

Boot Times

  • EBS-backed AMIs launch faster than EC2 instance store-backed AMIs.
  • When an EC2 instance store-backed AMI is launched, all the parts have to be retrieved from S3 before the instance is available.
  • When an EBS-backed AMI is launched, parts are lazily loaded and only the parts required to boot the instance need to be retrieved from the snapshot before the instance is available.
  • However, the performance of an instance that uses an EBS volume for its root device is slower for a short time while the remaining parts are retrieved from the snapshot and loaded into the volume.
  • When you stop and restart the instance, it launches quickly, because the state is stored in an EBS volume.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. EC2 EBS-backed (EBS root) instance is stopped, what happens to the data on any ephemeral store volumes?
    1. Data is automatically saved in an EBS volume.
    2. Data is unavailable until the instance is restarted.
    3. Data will be deleted and will no longer be accessible.
    4. Data is automatically saved as an EBS snapshot.
  2. When an EC2 instance that is backed by an S3-based AMI is terminated, what happens to the data on the root volume?
    1. Data is automatically saved as an EBS snapshot.
    2. Data is automatically saved as an EBS volume.
    3. Data is unavailable until the instance is restarted.
    4. Data is automatically deleted.
  3. Which of the following will occur when an EC2 instance in a VPC (Virtual Private Cloud) with an associated Elastic IP is stopped and started? (Choose 2 answers)
    1. The Elastic IP will be dissociated from the instance
    2. All data on instance-store devices will be lost
    3. All data on EBS (Elastic Block Store) devices will be lost
    4. The ENI (Elastic Network Interface) is detached
    5. The underlying host for the instance is changed
  4. Which of the following provides the fastest storage medium?
    1. Amazon S3
    2. Amazon EBS using Provisioned IOPS (PIOPS)
    3. SSD Instance (ephemeral) store (SSD Instance Storage provides 100,000+ IOPS on some instance types, much faster than any network-attached storage)
    4. AWS Storage Gateway
  5. A company needs to store database files that require very high IOPS with the lowest possible latency. The data does not need to persist if the instance is terminated. Which storage option is MOST appropriate?
    1. Amazon EBS io2 Block Express volume
    2. Amazon EBS gp3 volume
    3. Instance store volume (Instance store provides the lowest latency as it’s physically attached. Data persistence is not required, making ephemeral storage appropriate.)
    4. Amazon S3
  6. An EBS volume is attached to a running EC2 instance. The team needs to increase the volume size and change the volume type without downtime. Which EBS feature enables this?
    1. EBS Snapshots
    2. EBS Multi-Attach
    3. EBS Elastic Volumes (Elastic Volumes allows modification of size, type, and IOPS without detaching the volume or stopping the instance.)
    4. EBS Encryption
  7. A company requires a single EBS volume to be shared across multiple EC2 instances for a clustered application in the same AZ. Which EBS feature and volume type should be used?
    1. gp3 with EBS Elastic Volumes
    2. io1 or io2 with Multi-Attach (Multi-Attach is available only for io1 and io2 Provisioned IOPS volumes and supports up to 16 Nitro-based instances in the same AZ.)
    3. st1 with EBS Snapshots
    4. gp2 with Multi-Attach
  8. An administrator accidentally deleted several EBS snapshots. Which AWS feature can help recover these deleted snapshots?
    1. EBS Snapshot Archive
    2. AWS Backup
    3. Recycle Bin (Recycle Bin retains deleted EBS snapshots, AMIs, and EBS volumes based on configured retention rules, allowing recovery within the retention period.)
    4. EBS Snapshot Lock

References

24 thoughts on “AWS EBS vs Instance Store – Persistence & Speed

  1. Hi Jayendra
    >>Data on the EBS volume is LOST only if the Root Volume is EBS backed and the Delete On Termination flag is *** disabled *** (enabled by default)

    I think the statement should read “Delete On Termination flag is *** enabled ***”.

    Cheers,
    Satish

    1. Thanks Satish, its different for Root EBS volumes and Attached EBS volumes. Simplified the description.

  2. Hi Jayendra,
    Data on the EBS volume is LOST
    for EBS Root volume, if Delete On Termination flag is disabled (enabled, by default)
    for attached EBS volumes, if the Delete On Termination flag is disabled, which is the default.

    I understand the default behavior is different. Still data will be lost IFF the flag is enabled in both the cases correct ? if flag is “disabled” then data will not be “lost”. Correct ?

    1. Thats right, the default selection of the flag differs. However, if the flag is disabled, meaning – Do Not Delete On Termination, the EBS volumes will not loss the data for Root or for Attach Volumes.

  3. >> Data on the EBS volume is LOST
    for attached EBS volumes, if the Delete On Termination flag is disabled, which is the default.

    >> Data on EBS volume is NOT LOST in following scenarios :-
    Termination of the Instance for the additional EBS volumes. Additional EBS volumes are detached with their data intact.

    What’s the difference is both scenarios?
    If the EBS backed instance has an additional EBS volume, on the termination of the actual instance, by default will the additional EBS vol data will be lost or kept intact?

    1. The Delete on Termination flag value is different for the Root EBS Volume and the Attached EBS Volume. By default, the Root volume is deleted and the attached EBS volumes are just detached.

  4. Data on the EBS volume is LOST

    for EBS Root volume, if Delete On Termination flag is disabled (enabled, by default)
    for attached EBS volumes, if the Delete On Termination flag is disabled, which is the default.

    Data will not be LOST in both the cases.
    – On EBS root volume, if the “Delete on Termination flag” is disabled – Data will not be lost.
    – On EBS as attached volumes, “Delete on Termination flag” is disabled by default – Data will not be lost.

    If the flag is disabled data will not be lost in either case.
    – Flag is enabled by default on “EBS as root volume” and disabled on “EBS as attached volume” by default. If you want the data to persist, flag should be unchecked (disabled).

    Your blog is awesome!!

    1. For Root Volumes, the flag is enabled by default – meaning when the instance is terminated the volume is deleted on termination
      However for Attached volumes, the flag is disable by default, so the volumes are not deleted on instance termination.

      Default Behavior is different.

      1. I believe that we are on the same page, but the wording is so confusing that it is meaning different and incorrect.
        If possible can you please change point 5 and 6 (Ashish explanation seems to be more easy to read and understand).

  5. In “Key points for EBS backed Instance”
    5. Data on the EBS volume is LOST
    a) for EBS Root volume, if Delete On Termination flag is disabled (enabled, by default)
    b) for attached EBS volumes, if the Delete On Termination flag is disabled, which is the default.

    Why will the data be lost on either root or attached volumes if “DeleteOnTermination” is disabled. As per my understanding the data is lost(the volume is deleted) only if the flag is enabled and the instance gets terminated.
    Please correct me if I’m wrong.

  6. Which of the following will occur when an EC2 instance in a VPC (Virtual Private Cloud) with an associated Elastic IP is stopped and started? (Choose 2 answers)
    a. The Elastic IP will be dissociated from the instance
    b. All data on instance-store devices will be lost
    c. All data on EBS (Elastic Block Store) devices will be lost
    d. The ENI (Elastic Network Interface) is detached
    e. The underlying host for the instance is changed

    According to you the answer is b and e

    A user has launched an EBS backed EC2 instance. The user has rebooted the instance. Which of the below mentioned statements is not true with respect to the reboot action?
    a. The private and public address remains the same
    b. The Elastic IP remains associated with the instance
    c. The volume is preserved
    d. The instance runs on a new host computer

    According to you the answer is d(why???)
    Isn’t it contradicting with the above question???
    I think the answer will be (A) because the public address will change as this question is not talking about VPC.
    Instances launched outside a VPC, will get a new IP address.

    1. the latter question asks for statement not being true. Hence the answer is D as the instance does not run a new host computer.
      Stop and Start changes the underlying host.

      1. But the public address will be changed after a restart… right?
        Public address will not remain the same.

  7. But the public address will be changed after a restart… right?
    Public address will not remain the same.

  8. Q1, EC2 EBS-backed (EBS root) instance is stopped, what happens to the data on any ephemeral store volumes?

    First part says root volume is EBS. So how come an “ephemeral store volumes” will be attached that instance??

    1. You can have instance store attached to the EBS backed instances. These are data disks and not the root disks.

  9. Statement from you:
    An Instance store backed instance is an EC2 instance using an Instance store as root device volume created from a template stored in Amazon S3.

    Answer for Q4 is
    SSD Instance (ephemeral) store – which is ideally stored S3. !!??. So why the not the option 1?

    I assume Option 3 provides more precision. !!

    1. Instance store instance is created from S3 image. Once the instance is created it has actual SSD disks to work on it attached to the machine and hence they are the fastest.

  10. as many people already noticed,

    Data on the EBS volume is LOST
    for EBS Root volume, if Delete On Termination flag is disabled (enabled, by default)
    for attached EBS volumes, if the Delete On Termination flag is disabled, which is the default.

    is incorrect. if the Delete On Termination flag is disabled, data will NOT be lost.
    Please fix that.

    1. the Delete on Termination flag has different defaults based on the root and attached volumes.

  11. 4. Which of the following provides the fastest storage medium?
    a) Amazon S3
    b) Amazon EBS using Provisioned IOPS (PIOPS)
    c) SSD Instance (ephemeral) store (SSD Instance Storage provides 100,000 IOPS on some instance types, much faster than any network-attached storage)
    d) AWS Storage Gateway

    you marked answer C for this question, but there is not single reference to this in the article, can you provide relevant notes or links to that? putting a question that related to information you have not placed in the article doesn’t take much sense imo – of course you one google for details regarding that, but you could then separate such questions so people that are learning from your articles are aware, that they need external knowledge to answer questions in a dedicated section.

    1. Instance store is Ephemeral store and the fastest storage medium. Will check on the missing pieces to make sure it is covered for better reference.

Comments are closed.