Why can you not create an EBS-style snapshot of an EC2 instance store volume, and how do you protect data that lives on one?
answer
- no volume ID, no API to call
- host hardware, not an AWS resource
- capacity is a property of the instance type
- AMIs capture EBS volumes only
- durability moves up into the application
basics
~20 sAn EC2 instance store volume is a raw disk in the host, not an AWS resource with a volume ID, so no snapshot, detach, or resize API applies to it. Protection has to happen above it: copy to S3 or EBS, or replicate at the application level.
solid answer
~50 sEBS snapshots operate on an EBS volume resource identified by a `vol-` ID; the EBS service reads the volume's blocks and stores them incrementally. An instance store volume is not a resource at all — it is local hardware presented to the instance as an NVMe device, so there is nothing for `CreateSnapshot` to address, and equally nothing to detach, re-attach, or resize. Its size and count are fixed by the instance type and it is attached automatically at launch; you cannot add one later. That means every durability decision moves up a layer: periodically copy the data you care about to S3 or to an attached EBS volume, or run a datastore that keeps replicas on other nodes so a lost disk is a rebuild rather than a loss. Also note that `CreateImage` does not help — an AMI captures EBS volumes only.
go deeper
Know that instance store cannot be snapshotted or backed up by AWS, and that anything valuable has to be copied to S3 or an EBS volume yourself.
Explain the structural reason — no volume resource means no snapshot, detach, or resize API — and name the three protection patterns: regenerable data, application replication, scheduled copy-out.
Demonstrate that you size the risk: how much data sits in the window between copies, what a node rebuild costs, and whether the local data is genuinely reproducible from a real source of truth.
Own the policy that decides which data classes may touch ephemeral storage at all, and make the recovery path — rebuild from replicas or re-derive from S3 — an explicit, tested part of the platform rather than tribal knowledge.
## What an EBS snapshot actually operates on An EBS volume is a first-class AWS resource. It has an ID (`vol-…`), an ARN, tags, and an API surface: `CreateVolume`, `AttachVolume`, `DetachVolume`, `ModifyVolume`, `CreateSnapshot`. A snapshot is the EBS service reading the volume's blocks from its own storage layer and writing them, incrementally, to S3-backed snapshot storage — all of it happening on the AWS side, not inside your instance. Instance store has none of that. The NVMe devices on the host are wired straight through to the instance. There is no service in between that could read your blocks on your behalf, and there is no resource identifier to pass to an API call. `aws ec2 describe-volumes` will never list one, and `create-snapshot` has no argument that could name one. ```bash # Instance store devices never appear here; only EBS volumes have IDs aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \ --query 'Reservations[].Instances[].BlockDeviceMappings[].{dev:DeviceName,vol:Ebs.VolumeId}' ``` ## Everything else you cannot do either The missing snapshot API is one symptom of a broader constraint: - **You cannot attach one after launch.** On current Nitro instance types the included local volumes are attached automatically when the instance launches. If you launch without realising you needed local storage, the fix is a new instance of a type that has it. - **You cannot detach or move one.** The disk belongs to the host, not to your instance. - **You cannot resize one.** Capacity and disk count are properties of the instance type, so "more local storage" means "a bigger or different instance type". - **You cannot pick its durability.** There is no replication and no RAID unless you build it yourself inside the guest across the local devices — which protects against a single failed disk, not against losing the host. The capacity that comes with a type is discoverable from the API: ```bash aws ec2 describe-instance-types --instance-types i4i.large \ --query 'InstanceTypes[0].InstanceStorageInfo' ``` That returns the total local capacity, the number and type of disks, and whether NVMe and encryption are supported. Types with no local storage return null — a useful pre-flight check before you design around instance store. ## So where does durability come from? Three patterns, in rough order of how often they are the right answer: **1. The data does not need protecting.** Scratch space, spill files, temp output, a local cache whose source of truth is S3, a database, or another service. If losing it costs a cold start and nothing else, you are done. Most legitimate instance-store use falls here. **2. The application replicates it.** A distributed datastore that keeps copies of each shard on multiple nodes turns a lost local disk into a node rebuild: you replace the instance and the cluster re-streams that node's data from its peers. The durability lives in the replication factor, not in the disk. **3. You copy it out on a schedule.** If the local disk holds something genuinely valuable and irreproducible, push it to S3 (or to an attached EBS volume you can snapshot) at whatever interval matches the loss you can tolerate. Be honest that the window between copies is data you have chosen to lose — a stop or a host retirement in that window takes it. ## The AMI misconception A common wrong answer is "I'll just bake an AMI". `CreateImage` snapshots the instance's EBS volumes and records the block device mapping; the contents of local NVMe are not in the image. Instances launched from it come up with empty local devices that still need to be formatted and populated — usually from user data at boot or by the application warming its own cache. ## Encryption, since it usually comes up next On Nitro-based instance types, instance store volumes are encrypted at rest by the Nitro hardware using a key the customer never handles, and that key is discarded when the instance stops or terminates. That is a nice property — no wiped-disk data-remanence worry — but it is not durability, and it is not something you configure with KMS the way you would an EBS volume or an S3 object. ## How to answer this in an interview State the structural reason first ("it is not an AWS resource, so there is no API surface"), then move immediately to what you do instead. Interviewers are checking whether you understand that ephemeral storage pushes durability up into the architecture, rather than expecting you to recite an API limitation.
- Can you add more instance store capacity to a running instance if it fills up?No. The number and size of local disks are fixed by the instance type and attached at launch, so "more local storage" means launching a different type. Your options in the moment are to free space, attach an EBS volume as overflow, or replace the node with a larger type — which, being a new instance, starts with empty local disks.
- Does RAID across the local NVMe devices give you durability?It gives you redundancy against a single failed disk inside the host, and striping can raise throughput, but it does nothing about the failure that actually matters: losing the host. A stop, a terminate, or a retirement takes every local device with it regardless of how they are arranged.
- How is instance store encryption different from EBS encryption?On Nitro instance types, local volumes are encrypted at rest by the hardware with a key you never see or manage, destroyed when the instance stops. EBS encryption is a KMS-integrated, per-volume choice with a key you own, which is what lets snapshots and cross-account or cross-region copies stay encrypted under keys you control.
saying these in an interview costs you the question
- Claiming you can snapshot instance store like EBS
- Thinking an AMI backs up local NVMe contents
- Believing you can attach instance store after launch
- Treating in-host RAID as a durability guarantee
- Assuming local disks can be resized like a volume