What is an EBS volume vs an instance store

An EBS volume is a separate, durable disk that lives on AWS's network and keeps your data even if the instance attached to it is stopped or replaced. An instance store is free local disk space bolted straight onto the physical server your instance happens to be running on, and it forgets everything the moment that instance stops, hibernates, or terminates. Here's the part almost nobody tells you first: picking the wrong one isn't a performance mistake, it's a data-loss mistake, and by the time you notice, the data is already gone.

Jake found this out the expensive way. A customer dropped off a laptop for a data recovery job, and Jake — trying to save a few dollars on his side project, a little inventory tracker he runs on a single EC2 instance — had put the whole SQLite database file on what he thought was "just the hard drive." He stopped the instance overnight to save money, the way you'd turn off a light. In the morning, the instance started fine. The database file was gone. Not corrupted. Not moved. Gone, like it never existed.

The one question that tells you which one you need

Before we get into the technical differences, there's a single diagnostic question that settles 90% of "which one should I use" arguments: if this instance stopped right now, would I be upset about losing what's on this particular disk?

If the answer is yes — a customer database, a website's uploaded files, application logs you need for a compliance audit, anything you'd have to explain to a boss or a customer if it vanished — the answer is EBS. Full stop. No exceptions, no "but it's cheaper," no "I'll just be careful." An EBS volume is a durable, block-level storage device that you can attach to your instances, and it keeps working the way a normal external hard drive would: you can detach it, move it, and it doesn't care what happens to the computer it was plugged into.

If the answer is no — a cache that rebuilds itself from a database in five minutes, a scratch directory for a video transcoding job, temp files a load balancer is going to regenerate anyway — instance store is not just acceptable, it's usually the smarter and cheaper choice, because it's local physical disk sitting right next to the CPU instead of traveling over the network.

What an EBS volume actually is

EBS stands for Elastic Block Store. "Block storage" just means it behaves like a raw hard drive — you format it with a file system and use it the way you'd use any disk — as opposed to "object storage" (like Amazon S3), where you upload and download whole files through an API instead of writing to sectors on a disk.

The important word in Elastic Block Store isn't "elastic," it's "network." An EBS volume is off-instance, network-attached storage that persists independently from the running life of a single EC2 instance. It doesn't physically sit inside the server your instance is running on. It lives elsewhere in the same Availability Zone (AWS's term for one physical data center location within a region — think of a region as a city and an Availability Zone as one specific building in it), and your instance talks to it over a network connection, the same conceptual idea as a network-attached storage box sitting in a closet down the hall from your desk instead of a drive bolted inside your PC.

That separation is the whole point. Because the volume isn't physically part of the instance, you can detach it and reattach it to a different instance in the same zone. You can stop your instance, and the volume just sits there, unaffected, still charging you for its storage but doing nothing else. You can take a snapshot — a point-in-time backup copied to Amazon S3 — and use that snapshot to create a brand-new volume later, even in a different Availability Zone. None of that is possible with disk space that's physically welded to one server.

What instance store actually is

Instance store is the opposite design decision. It's temporary block-level storage that comes from disks that are physically attached to the host computer your instance is running on. There's no network hop, no separate service, no independent lifecycle — it's a chunk of the literal physical SSD sitting inside the same rack unit as your virtual server. That physical closeness is exactly why it's fast: reads and writes don't have to leave the box.

It's also exactly why it's temporary. Amazon explains it plainly: instance store is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content, or data you're deliberately replicating across a whole fleet of servers, like a pool of identical web servers that could each rebuild their own copy of the same content. The volumes are exposed to your operating system as devices with names like ephemeral0 through ephemeral23 — "ephemeral" being the technical word for "temporary, here-and-gone," which is the whole personality of this storage type in one word.

Ethan's take: think of it like a hotel room, not an apartment

"An EBS volume is your apartment," Ethan told Jake once, after the customer database disaster. "You can leave, come back next week, and your stuff is still there, because the apartment isn't tied to whether you're currently standing in it. Instance store is a hotel room. Housekeeping comes in and resets it the second you check out — and 'checking out,' for an EC2 instance, means stopping it, hibernating it, or terminating it. It's not that the hotel is unreliable. It was never designed to remember you."

Jake pushed back, the way he usually does. "Then why would anyone use the hotel room?" Ethan's answer: "Because sometimes you don't want to own the furniture. If all you need is somewhere fast to work for a few hours, a hotel room that gets refreshed for free every time beats paying rent on an apartment you don't need."

The instance type you already picked might not even have one

Here's the fact that surprises the most people who've been using EC2 for years without thinking hard about storage: most current-generation instance types have no instance store at all. There's no dial you can turn on for it after the fact — it's baked into the specific instance type you chose at launch.

AWS's own instance-type documentation spells this out with real examples: instance types such as C8i, M8i, and R8i do not support instance store volumes, while their close cousins C8id, M8id, and R8id — same processor family, same memory ratio, just with a "d" tacked onto the name — do. That single letter is the entire difference between "this server has zero local disk beyond its EBS root volume" and "this server has a chunk of fast NVMe SSD physically bolted in." If you've been assuming every EC2 instance quietly has some spare local disk sitting around, check the instance type name for that "d" — it's the tell.

For the instance families that do include it, the amount and type of instance store varies by the specific size within that family — a larger size in the same family generally gets more and bigger instance store volumes, not just more CPU and RAM. And for the NVMe-based flavors, all supported instance store volumes are automatically attached the moment the instance launches — you don't request them separately the way you'd order an EBS volume.

EBS isn't one thing — it's a menu of volume types

This is the part where a lot of "EBS vs instance store" explainers stop short, and it's a mistake, because "EBS" isn't a single product with one speed and one price. AWS splits EBS into solid-state drive (SSD) volumes, built for lots of small, frequent read and write operations, and hard-disk drive (HDD) volumes, built for large, steady streams of data like log processing. Picking the wrong EBS type can leave just as much performance on the table as picking EBS when you should have used instance store in the first place.

Two of the SSD types are worth calling out by their annual failure rate, because it's a real, documented number and it explains why databases lean on the pricier option: general-purpose SSD volumes (gp3/gp2) are built for 99.8%–99.9% durability, meaning roughly 0.1%–0.2% could fail in a given year, while the Provisioned IOPS io2 family is built for 99.999% durability — a failure rate about a hundred times lower. Neither number means "don't use gp3" — it's the default for a reason, and it's what most boot volumes and everyday application disks use — but it's why a bank doesn't run its ledger database on the cheapest tier.

What instance store gives you automatically — and what it doesn't

Unlike EBS, instance store doesn't come with a menu of types to choose between. On instance types that support it, you get whatever NVMe SSD or, on a shrinking number of older types, SATA-based hard disk the specific instance size ships with — you can't swap it for a different flavor the way you can pick gp3 versus io2. What you control is whether you use it at all, and how you configure it once it's there.

One thing people trip over: an instance store volume can only be added at launch time — you can't attach one after launch, and you can't detach one from an instance and move it to a different instance the way you can with EBS. If you didn't plan for it in the launch configuration, and your instance type supports adding it, you typically have to relaunch to get it, or rely on the ones your instance size auto-attaches by default. Plan ahead here — it's not a "come back to this later" setting.

Mounting an instance store volume so you can actually use it

An instance store volume showing up doesn't mean it's ready to write files to — same as plugging in a brand-new external drive that hasn't been formatted yet. You have to format it with a file system and mount it to a folder before your applications can touch it. Here's the documented sequence for a Linux instance:

1. Connect to the instance over SSH, the same way you'd connect to check on anything else running on it.
2. Find the device name for the instance store volume — commonly something like /dev/nvme1n1 on newer NVMe-based instance types.
3. Format it with a file system: sudo mkfs -t xfs /dev/nvme1n1 — this is the step that turns raw, unusable disk space into something an operating system can organize files on.
4. Create a folder to act as the mount point: sudo mkdir /data.
5. Mount the volume to that folder: sudo mount /dev/nvme1n1 /data — from this point on, anything written into /data is physically landing on that local disk.

Note what's missing from that list: anything that survives a stop. That mount doesn't persist across a reboot on its own unless you also configure it in your file system table, and none of it matters at all the moment the instance stops, hibernates, or is terminated — the data underneath that mount point is wiped regardless of how carefully you set up the folder.

Automating the mount so you're not doing this by hand every time

If instance store is part of your setup, don't treat the formatting and mounting steps as a one-time chore you do after every manual launch. Because that data disappears on every stop or replacement, and because Auto Scaling groups and spot fleets can replace an instance at any moment, the mount needs to happen automatically, every single time a fresh instance boots — not just the first time you happened to SSH in and set it up.

The common pattern is to fold the format-and-mount commands into the instance's launch configuration, either as EC2 user data (a script that runs automatically the first time an instance boots) or as part of the AMI itself if you're baking a custom image. That way, a brand-new instance launched from an Auto Scaling group ends up with its scratch disk ready before your application even starts, instead of failing on startup because a folder it expected to exist isn't there yet. It's a small piece of automation, but it's the difference between instance store being a convenience and it being a page at 2 a.m. because a replacement instance came up with no /data directory.

Stop, reboot, hibernate, terminate — they are not the same event

This is the section that would have saved Jake his customer database, and it's the part of the "EBS vs instance store" question that trips up even people who've read the marketing pages. The four things you can do to a running instance don't behave the same way, and the difference is entirely about what happens to each storage type.

Notice the row that doesn't have an instance-store column entry for "Stop" the way you'd expect a symmetrical table to have — that's not an oversight. You genuinely cannot stop or hibernate an instance whose root volume is instance store. You can only reboot it or terminate it. If your instance's root device is instance store rather than EBS, trying to stop it through the AWS CLI returns an outright error, because the operation doesn't apply to that kind of instance at all. This is one of the more counterintuitive facts in this entire topic — most people assume "stop" is a universal button that works on any running server, and for one whole category of EC2 instance, it simply isn't offered.

It's also worth knowing the full list of what does and doesn't preserve instance store data, because it's more specific than a simple "restart good, stop bad" rule. Documented events that preserve it: an intentional restart from within the operating system, a reboot triggered through the console or API, an AWS-scheduled system reboot, and a brief power failure followed by a reboot. Documented events that wipe it: an operating-system-initiated shutdown, an instance stop, hibernation, termination, AWS's automatic recovery actions, and instance retirement. The pattern underneath all of it is the same: anything that keeps the instance on the same physical host preserves the data, and anything that could move it, or shut it down entirely, does not.

What actually happens the moment you hit "Terminate"

Termination is permanent and irreversible — once it's done, you can't reconnect to the instance and it can't be recovered. Every byte on any instance store volume that instance had is permanently and cryptographically erased, no exceptions and no setting to turn that off. EBS volumes get a choice, though: any volume marked "delete on termination" goes away with the instance, and anything not marked that way keeps existing as an independent volume you can reattach elsewhere, sitting in your account racking up storage charges until you either reattach it or delete it yourself.

That "delete on termination" flag is worth checking manually before you ever terminate anything you care about, because the default for the root volume is to delete it, and the default for extra volumes you attached yourself is generally to keep them — which is the opposite of what a lot of people assume going in.

There's one more wrinkle worth knowing if AWS ever has to retire the physical host under your instance because of a hardware fault: what happens next depends on your root volume type. An instance with an EBS root volume gets scheduled to stop, giving you a chance to start it again on healthy hardware with your EBS data intact. An instance with an instance store root volume gets scheduled to terminate instead, because there's no way to preserve instance store data across a host change in the first place, so AWS doesn't pretend otherwise.

Why instance store is fast, and why "fast" isn't the only question

Instance store's speed advantage comes down to physics, not marketing. Data traveling to an EBS volume has to leave your instance, cross AWS's internal network, reach the storage system, and come back — every one of those hops, however fast, adds a sliver of delay compared to data that never leaves the box. Modern instance store on Nitro-based instance types (Nitro is AWS's name for its current-generation virtualization hardware) uses NVMe SSDs, a fast storage interface designed specifically to minimize the overhead between the CPU and the drive.

Where this matters in practice: workloads that hammer a disk with constant small reads and writes — a database's temporary sort files, a video encoder's scratch space, a build server's compilation cache — feel that network round-trip on every single operation. Move that workload to local instance store and the difference is noticeable, not marginal.

But "fast" only wins the argument when durability isn't also on the table. A cache that's fast but empties itself every time you restart the server that runs it isn't actually fast for your users — it's fast until the moment it matters, and then it's a cold start that feels slow. This is why "instance store is faster, so use it everywhere" is popular, wrong advice: the speed is real, but it's a trade you're making against durability, and plenty of workloads can't afford that trade.

There's one more performance lever worth knowing about on the EBS side: EBS-optimized instances. To fully use the IOPS you've provisioned on an EBS volume, AWS recommends using an EBS-optimized instance, which dedicates network bandwidth specifically to EBS traffic instead of making it compete with your regular network traffic. The good news for anyone running a recent instance type: EBS-optimization is enabled by default at no additional cost on current-generation instance types, so you're already getting it without configuring anything. It only becomes something to actively check on older, previous-generation instance types, where it was a separate, chargeable option.

How each one actually shows up on your bill

This is a genuinely simple part of an otherwise nuanced topic: instance store costs you nothing extra. AWS states it directly — there's no additional charge to use the instance store volumes provided for your instance, because they're already baked into the hourly or per-second price of that instance type. Whether you use it or leave it empty, you're paying the same amount either way, which is a decent argument for using it for scratch data when your instance type happens to include it — you're leaving free performance on the table otherwise.

EBS is the opposite: it bills separately and continuously, based on how much storage you've provisioned, regardless of whether the instance attached to it is running. AWS charges for EC2 instance usage in one-second increments with a 60-second minimum, and the same per-second billing model applies to provisioned EBS storage. This is exactly why a "stopped" instance still shows up on your bill: you're not paying for the compute anymore, but you're still paying for every EBS volume attached to it, sitting there ready the moment you start it back up.

There's a second EBS cost most people don't budget for until their first bill: snapshots. Every snapshot you keep is stored in Amazon S3 and billed for as long as it exists, separately from the volume it came from — deleting the original volume doesn't delete snapshots you made of it. If you've set up automated daily snapshots for a database volume and never clean up old ones, that line item quietly grows every month even after the volume itself has long since been resized or replaced. It's also worth knowing that you can change an EBS volume's type, size, or provisioned performance on a live, running instance without detaching the volume or stopping it — a useful fact when a gp3 volume turns out to be too slow for a workload that grew, since you can move it to Provisioned IOPS without scheduling downtime.

When to reach for EBS, in plain terms

Use EBS as your default, unquestioned choice for:

1. Your operating system's boot volume. This is nearly always EBS on any current-generation setup, and it's what shows up automatically when you launch an instance from a normal AMI.
2. Any database's actual data files. A database that loses its data on every restart isn't a database, it's a very elaborate calculator.
3. Anything you'd need to restore from a backup if it disappeared. Uploaded customer files, application configuration, logs you're required to retain.
4. Anything you want to move between instances. EBS volumes can detach from one instance and attach to another in the same Availability Zone — useful for recovering a server that won't boot, or upgrading to a bigger instance type without rebuilding the disk.
5. Anything you want to encrypt at rest with a setting you control directly.

When instance store genuinely earns its place

Instance store is the right call, not just a cheap-out, for:

Buffers and scratch space during processing. A video transcoding job that reads a source file, writes intermediate frames somewhere, and produces a final output doesn't need those intermediate frames to survive a reboot — it needs them fast, and then it needs them gone.

Jake's shop has its own version of this: the point-of-sale terminal that only glitches on Saturday afternoons, right when the weekend rush hits, because that's the only time thumbnail images for a hundred different phone cases get regenerated at once. Moving that thumbnail cache onto instance store didn't fix the terminal glitching, but it stopped the glitch from also costing him the whole cache every time he restarted the terminal to clear it — which, until then, had been happening most Saturdays too.

Caches that rebuild themselves. If your cache is a copy of data that lives durably somewhere else — a database, an S3 bucket — losing the cache costs you a rebuild, not your data. That's a fine trade for the speed.

Data replicated across a fleet. A pool of identical, load-balanced web servers each holding the same static content doesn't need any one server's copy to be durable, because losing one server just means traffic routes to the others.

Database engines specifically designed for it, with replication. This is the nuanced one, and AWS's own best-practices guidance addresses it directly: if you use instance store for database storage, make sure you have a cluster with a replication factor that gives you fault tolerance — meaning multiple copies of the data spread across multiple instances, so losing any single instance's local disk doesn't mean losing the data. Distributed systems like this treat instance store as fast, disposable local disk that the cluster as a whole compensates for.

Some teams reach for third-party clustered or replicated file systems on top of instance store to give it durability it doesn't have natively. That's worth knowing exists, but it's overkill unless you're already running the kind of clustered workload that needs that complexity. For a single EC2 instance running one application, that setup usually isn't worth the operational overhead; move the data to EBS instead and call it done.

The pattern most production setups actually use: both, together

This is the answer that "EBS vs instance store" framing tends to obscure: it's rarely an either/or choice on a real instance. AWS's own EC2 best-practices guidance recommends using separate EBS volumes for the operating system versus your actual data, and separately, using whatever instance store is available for temporary data — two different roles, two different storage types, on the same box.

Jake's inventory tracker, rebuilt after the disaster, now looks like this: a small EBS root volume for the operating system and application code, a second EBS volume that holds the actual database file — the thing that can never be allowed to disappear — and, because he moved to an instance type that happens to include instance store, a local disk that holds nothing but temporary export files while a report is being generated. If the instance ever needs a hard reboot mid-export, the customer just re-runs the export. If it needed a hard reboot mid-database-write with the old setup, the whole database was gone.

One habit worth adopting alongside the two-volume pattern: name your mount points so the storage type is obvious without having to check. A folder called /data-ebs versus /scratch-local costs nothing to set up and removes an entire category of mistakes made at odd hours, because nobody has to remember which device number mapped to which volume type six months after they configured it.

The one habit that prevents the disaster entirely

Ethan's rule, which he says out loud to every new hire he trains: "Before you write a single file to a disk on EC2, ask what device that disk is. Not what folder — what device. /data tells you nothing. Whether /data is mounted from an EBS volume or an instance store volume tells you everything about whether that folder is going to exist tomorrow."

What it looks like when you've gotten this wrong

A few symptoms, and what they usually mean:

An application's data reappears empty after every deploy that restarts the instance. Almost always means the data directory is mounted on instance store, and whatever process manages your deploys is stopping the instance (not just rebooting the app) as part of the pipeline.

You can't stop an instance from the CLI and get an error you don't recognize. That's the tell for an instance-store-backed root volume — the operation genuinely isn't supported for that instance, and it isn't a permissions problem or a bug.

A cache stays surprisingly cold right after a deploy, with response times that don't recover for several minutes. If your cache lives on instance store and every instance in a fleet restarts around the same time — a rolling deploy that isn't rolling slowly enough — every instance's cache goes empty at once, and your backend database absorbs the full, un-cached traffic all at the same moment instead of a gradual trickle. The fix usually isn't moving the cache to EBS, it's slowing down the deploy so instances refill their caches at staggered times instead of together.

Your EBS bill keeps climbing even though you "shut everything down." Check for stopped instances with attached EBS volumes, and orphaned volumes with no instance attached at all — both keep billing for storage indefinitely until deleted.

A database on instance store loses data after what should have been a routine restart. If it's a single-node setup with no replication, this isn't a bug in AWS — it's the documented, expected behavior of instance store working exactly as designed. The fix isn't a setting; it's moving the data files to EBS, or adding real replication if the workload genuinely needs instance store's speed.

Edge cases: multiple volumes, snapshots, and moving between zones

A handful of situations that come up once you're past the basics:

Multiple EBS volumes on one instance: perfectly normal and common — attach as many as your instance type's device limits allow, each doing a different job (OS, database, logs, backups staging).

Moving an EBS volume to a different Availability Zone: you can't attach a volume directly across zones, but you can take a snapshot and create a new volume from that snapshot in a different zone — the snapshot itself lives in Amazon S3, which isn't zone-bound the way the live volume is.

Instance store and Availability Zones: not portable at all, in any direction. It's tied to one specific physical host inside one specific zone, and there's no snapshot mechanism for it the way there is for EBS.

Resizing: EBS volumes can be grown while attached and the instance stays running, using AWS's Elastic Volumes capability. Instance store has no resize option — its size is fixed by the instance type you picked, and the only way to get more is to move to a bigger instance size or a different family.

Backups: EBS snapshots are the standard, documented backup mechanism, stored in S3 and usable to recreate a volume later. Instance store has no equivalent — if you need a backup of data sitting on instance store, you're responsible for copying it somewhere durable yourself, on whatever schedule your application demands, before anything happens to the instance.

A couple of other hardware-adjacent situations worth knowing about: instances running inside a virtual machine you manage yourself, and remote desktop or VDI-style workloads, both interact with storage the same way any other EC2 instance does — the EBS-versus-instance-store rules don't change just because the workload on top is unusual. What does change is how forgiving the workload is of a storage hiccup: a remote desktop session with unsaved work in progress is a much worse candidate for instance store than a batch job that checkpoints its own progress to S3 every few minutes.

Can one EBS volume be attached to more than one instance?

Normally, no — a standard EBS volume can only be attached to a single instance at a time, the same way you can't plug one external hard drive into two computers simultaneously and expect it to work cleanly. There is a documented exception, though: EBS Multi-Attach.

Multi-Attach lets you attach a single Provisioned IOPS SSD volume — io1 or io2 only, not the general-purpose gp3/gp2 types — to as many as 16 instances at once, as long as every one of those instances is built on the Nitro System and sitting in the same Availability Zone as the volume. Each attached instance gets full read and write permission to the same underlying disk. There's no additional charge for the feature itself; you pay the standard io1 or io2 rate for the volume.

Encryption and the privacy angle

Amazon's own best-practices guidance is direct about this one: encrypt your EBS volumes and snapshots. EBS supports encryption as a setting you turn on when creating a volume — or can even set as an account-wide default so every new volume is encrypted automatically — and it carries through to any snapshot made from that volume, and to any new volume created from that snapshot — the encryption travels with the data through its whole lifecycle.

Instance store's story is different, and more specific than most explanations give it credit for. Instance types with an NVMe instance store encrypt data at rest by default, using an XTS-AES-256 block cipher, so this isn't a setting you have to remember to turn on for those types — it's already happening underneath you. It's still worth being deliberate about which storage type holds sensitive data in the first place, though, because EBS gives you an explicit, account-wide encryption setting you control and can prove compliance against, while instance store's protection is a property of the instance type rather than a configuration you set and document yourself.

There's also a security-relevant detail buried in how instance store gets wiped: when an instance stops, hibernates, or terminates, every block of its instance store volumes is cryptographically erased, not just marked as deleted the way a quick file delete would on a normal disk. That's part of why the data is genuinely unrecoverable afterward, and it's a reasonable thing to mention if a compliance requirement asks how temporary data gets destroyed.

Frequently asked questions

What's the single biggest difference between an EBS volume and instance store?

Persistence. EBS lives independently of any one instance and survives stops, reboots, and instance replacement. Instance store is physically tied to one server and is wiped the moment that instance stops, hibernates, or terminates.

Does stopping an EC2 instance delete data on instance store?

Yes, every time, with no exceptions. Stopping an instance may move it to a different physical host when you start it again, and the instance store on the new host has no connection to the one your data was sitting on.

Does rebooting an instance delete instance store data?

No. A reboot is a software restart on the same physical host, so both EBS and instance store are unaffected. Data loss on instance store happens specifically on stop, hibernate, or terminate — not a plain reboot.

Can I resize an instance store volume?

No. Its size is fixed by the instance type and size you chose at launch. If you need more local disk, you need a larger size within the same instance family or a different family entirely — there's no in-place resize the way there is with EBS.

Can I take a snapshot of an instance store volume?

Not directly, the way you'd snapshot an EBS volume. Instance store has no built-in backup mechanism. If you need to preserve data sitting on it, you have to copy that data yourself to EBS, S3, or another durable location before anything happens to the instance.

How do I know if my instance type has instance store?

Check the instance type name and its details in the EC2 console or documentation. As a rule of thumb, families with a "d" in the name (like M8id, C8id, or R8id) include local instance store; their non-"d" counterparts (M8i, C8i, R8i) generally don't. Always confirm against the specific instance type, since this varies by family and generation.

Is instance store actually faster than EBS?

For raw local read/write speed, generally yes, because the data never has to travel over a network to reach it. Whether that speed matters depends entirely on the workload — a workload doing constant small reads and writes will feel the difference far more than one doing occasional large transfers.

Can instance store be used as the root volume?

On certain instance types, yes — this is called an instance-store-backed (or Amazon S3-backed) instance, and it's an older pattern that boots from a template stored in S3. It's now a corner case rather than the norm; nearly all current AMIs boot from EBS instead, with faster typical boot times.

What happens to my EBS volumes when I terminate an instance?

The root volume is deleted by default unless you've changed that setting. Any additional EBS volumes you attached after launch are generally not deleted by default — they keep existing independently and will keep billing you for storage until you reattach or delete them yourself.

Am I charged extra for instance store?

No. Instance store is included in the usage cost of the instance type itself — you pay the same whether you use it or leave it empty. EBS, by contrast, bills separately based on the storage you've provisioned, whether or not the instance is running.

Which EBS volume type should I use for a production database?

General Purpose SSD (gp3) is a reasonable default for small-to-medium single-instance databases. For workloads that need consistent, high, and predictable performance — larger production databases, especially ones running software like SAP HANA or SQL Server — Provisioned IOPS SSD (io2 or io1) is the documented choice, because you set the exact performance level rather than relying on a shared baseline.

Can I add an instance store volume to an instance that's already running?

No. Instance store volumes can only be attached at launch, and you can't detach one from an instance and move it to a different instance afterward. If you need one and didn't configure it at launch, you need to launch a new instance with it included from the start.

Is data on instance store encrypted?

On instance types with an NVMe instance store, yes, by default, using an XTS-AES-256 block cipher, with no setting to turn on. It isn't the same kind of account-wide, documented setting EBS encryption is, so treat it as a property of the instance type rather than something you configure and audit the same way.

Can I use RAID across multiple instance store volumes?

On instance types that provide more than one instance store volume, combining them with software RAID for extra throughput or redundancy is a documented pattern some workloads use. It doesn't change the fundamental rule, though — RAID across instance store volumes still loses everything on a stop, hibernate, or terminate, since every volume in the array is equally temporary.

Can an EBS volume be attached to more than one EC2 instance at once?

Not by default. The exception is EBS Multi-Attach, which lets a single Provisioned IOPS SSD (io1 or io2) volume attach to up to 16 Nitro-based instances in the same Availability Zone, though your application has to handle write coordination itself since Multi-Attach doesn't provide I/O fencing.

What happens if the physical host running my instance store fails?

You lose the data on that instance store, the same as any other loss scenario — a hardware failure on the underlying disk is one of the documented ways instance store data disappears, alongside stopping, hibernating, or terminating the instance. It's another reason distributed systems that use instance store lean on cluster-level replication rather than trusting any single host's local disk.

Revision note. Written September 2026. This will need a revisit whenever AWS reshuffles which instance families carry instance store, or introduces a new EBS volume type. If you've already lost data the way Jake did, you're not the first person this has happened to, and you won't be the last — the fix from here forward is just knowing which disk is which before you write to it again.