In AWS, what happens to data on an EC2 instance store volume, compared with data on an attached EBS volume, when the instance is rebooted, stopped and started again, or terminated?
answer
- storage inside the host, not beside it
- reboot is not the same as stop
- start means a new physical host
- no volume ID means no snapshot
- root EBS has DeleteOnTermination true
basics
~20 sEC2 instance store data survives a reboot but is lost on stop, hibernate, or terminate, because it lives on disks physically inside the host. EBS volumes are network-attached and persist independently of the instance lifecycle.
solid answer
~50 sAn instance store volume is local NVMe (or older local SSD/HDD) hardware inside the physical host the instance runs on, so its lifetime is tied to that placement. A reboot keeps the instance on the same host, so the data is still there. A stop-then-start, a hibernate, a terminate, or a failure of the underlying host all mean the instance leaves that host — and the local disks are wiped and the data is gone with no way to recover it. EBS is different: it is network-attached block storage that lives outside the host and is replicated within one Availability Zone, so it survives stop/start and can be re-attached to a different instance. The one EBS gotcha is `DeleteOnTermination`, which defaults to true for the root volume, so terminating an instance does delete its root EBS volume unless you changed that flag.
go deeper
Be ready to say plainly that instance store is local, temporary disk and EBS is network storage that persists. Naming stop, terminate and host failure as the events that wipe local data is enough at this level.
Explain why the lifetime differs: a start places the instance on a new physical host, so the old host's disks are irrelevant. Mention hibernate as a stop in disguise and the DeleteOnTermination default on root volumes.
Show that you design around it — nothing on instance store that cannot be regenerated, and node replacement rather than stop/start as the operational pattern. Mention scheduled retirement events as the failure nobody schedules.
Own the fleet-level rule: which classes of data are allowed on ephemeral storage at all, how that is enforced in launch templates and platform standards, and what the blast radius is when the rule is broken.
## Two different kinds of block storage on EC2 An EC2 instance can see two very different things that both look like ordinary block devices to the operating system: - **Instance store** — physical disks (on current instance types, NVMe SSDs) attached to the *host server* your instance happens to be running on. They are included in the price of the instance and only exist on instance types that ship with them: the storage-optimised `i` and `d` families and the `d`-suffixed variants of general-purpose and compute types such as `m6id` or `c6gd`. - **EBS (Elastic Block Store)** — a separate, network-attached service. An EBS volume is its own AWS resource with its own ID, its own lifecycle, and its own bill; the instance talks to it over the network fabric. Everything about the durability difference follows from that one structural fact: instance store is *in* the host, EBS is *beside* it. ## What each lifecycle event does **Reboot.** A reboot — from the console, the API, or `reboot` inside the guest — keeps the instance on the same physical host. The instance store volumes are the same disks, still there, still holding your data. This is the only lifecycle event instance store survives. **Stop and start.** Stopping an instance releases the host. When you start it again, EC2 places the instance on whatever host has capacity, which is almost never the same one. The old host's local disks are wiped for the next tenant. Your data is gone, and there is no recovery path — no snapshot, no support ticket, nothing. **Hibernate and resume.** Hibernation writes the instance's RAM to its root EBS volume and then stops the instance. Because it is a stop underneath, instance store contents are lost exactly as with a normal stop. **Terminate.** The instance is destroyed and its local disks are wiped. **Host failure or retirement.** If the underlying hardware degrades, AWS schedules the instance for retirement (visible as a scheduled event) and it will be stopped or terminated. Same outcome: local data gone. This is the one that surprises people, because it is not a human choosing to stop anything. ## Why EBS behaves differently An EBS volume is a durable resource inside one Availability Zone, replicated across multiple devices within that AZ. When you stop an instance, its EBS volumes stay attached in a detached-but-preserved state and come back on start; you can also detach a volume from one instance and attach it to another, and you can snapshot it to S3-backed storage for cross-AZ and cross-region recovery. None of that is possible with instance store: there is no volume ID to snapshot, detach, or re-attach. ```bash # Only EBS volumes appear here — instance store devices have no volume ID aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \ --query 'Reservations[].Instances[].BlockDeviceMappings[]' ``` ## The EBS asterisk: DeleteOnTermination EBS persistence is about the *stop/start* boundary, not an unconditional promise. Each EBS mapping carries a `DeleteOnTermination` flag. For the **root** volume it defaults to `true`, so terminating an instance does destroy its root volume. For volumes you attach later it defaults to `false`. If you want a data volume to outlive the instance, either attach it separately or set the flag explicitly in the launch template. ## What this means in practice Treat instance store as a fast scratch pad, never as the only copy of anything. Legitimate contents are things you can regenerate or that exist elsewhere: temporary files, spill/shuffle space, a local cache with a remote source of truth, or a shard of a datastore that keeps replicas on other nodes. Anything that is a system of record belongs on EBS, on S3, or in a managed database. A second practical consequence: because instance store lives on the host, its I/O does not consume the instance's EBS bandwidth allocation and its latency is not a network round trip. That is the entire reason it exists — you trade all durability for the lowest latency EC2 can offer. ## The trap to watch for A fleet can run happily for months and then lose data the first time somebody stops an instance to change its type, or the first time AWS retires a degraded host. If a node's local disk holds anything you cannot rebuild, that fleet has a bug — it just has not fired yet.
- You need to change an instance's type from m6id.large to m6id.xlarge. What does that do to the instance store data?Changing an instance type requires a stop and a start, so the instance is placed on a different host and all instance store data is lost. If the data matters, copy it to S3 or an EBS volume first, or replace the node and let the application rebuild its local state from its real source of truth.
- Does an AMI created from a running instance capture the instance store volumes?No. `CreateImage` snapshots the instance's EBS volumes only; local NVMe contents are not part of the image. A newly launched instance from that AMI gets empty instance store devices, which you have to format and populate yourself — typically from user data or an application-level warm-up.
- How do you tell whether a given instance type even has instance store?Query the instance type. `aws ec2 describe-instance-types --instance-types m6id.large --query 'InstanceTypes[0].InstanceStorageInfo'` returns the total local capacity, the disk count and type, and whether NVMe and encryption are supported; types without local disks return null. The `d` suffix and the storage-optimised `i` and `d` families are the usual carriers.
saying these in an interview costs you the question
- Thinking a stop and start keeps local disk data
- Believing instance store is replicated like EBS
- Assuming an AMI backs up the local NVMe volumes
- Treating reboot and stop as interchangeable operations
- Assuming EBS root volumes always survive termination