EBS vs EFS Latency and Throughput Trade-Offs

Most engineers assume the gap between EBS and EFS performance comes down to settings: pick the right volume type, tune a few parameters, and the numbers should even out. That assumption is wrong. The gap is structural, built into how each service physically gets data from storage to a compute instance, and no amount of tuning changes that.

EBS acts like a hard drive bolted straight onto your server. It presents raw block storage that attaches directly at the instance level, and behaves like a local NVMe drive would. The data path never crosses a network file system layer at all. When an EC2 instance asks for a block of data, it's a local conversation, the kind of quick back-and-forth you'd get from a drive sitting inside the machine itself.

EFS works on a completely different principle. It's a fully managed NFS service, running NFSv4.0 and NFSv4.1, and every single read or write has to travel across the network to reach the distributed file system behind it. That network hop, baked into what NFS-over-network means as an architecture, is the latency floor that no config change fixes.

Sources describing this split call it "the fundamental difference," and that phrase earns its place. Direct block access versus network file access is the one distinction that determines performance, scalability, and cost outcomes across both services. A performance comparison published in May 2026 frames the mechanics simply: EBS connects at the instance level for minimal latency, while EFS has to traverse the network for every file operation, adding latency that block storage never sees. That single architectural fork is what the rest of this piece traces all the way out to AI training clusters and multi-cloud data platforms.

The concrete performance gap in IOPS, throughput, and latency

Architecture on paper is one thing. Translate it into numbers and the gap gets very concrete, very fast.

EBS, at the top end, is fast in a way that's hard to argue with. The io2 Block Express tier delivers up to 256,000 IOPS with multi-gigabyte-per-second throughput, and gp3 and io2 volumes both hit sub-millisecond latency on database workloads. gp3 volumes let operators dial IOPS and throughput up or down independently, across a wide range, without resizing anything. io2 Block Express scales to very large volume sizes while holding onto the same peak IOPS and throughput ceiling as the rest of the io2 family. For a single instance doing single-instance work, EBS is built to behave like the fastest drive in the building.

EFS runs a different play. General Purpose mode gives a strong IOPS baseline with bursting on top of it, and latency for file operations typically runs in the low millisecond range. Max I/O mode trades some of that latency for sequential read speeds that, while well below EBS io2's throughput ceiling, get delivered across many concurrent clients at once rather than one. EFS latency isn't a fixed, provisioned number. It shifts with file size and the number of concurrent connections hitting the system.

None of this makes EFS's numbers a failure. They're a direct reflection of a concurrency-first design, the same design the next section defends on its own terms. Tunability is the real asymmetry. EBS gives operators granular control: provision the IOPS, provision the throughput, adjust as needed. EFS gives fewer dials to turn, and because it's a network file system, it adds round-trip time that makes throughput harder to predict under bursty, uneven workloads. That's the asymmetry that explains why EBS fits workloads needing fine-grained, predictable control, and why EFS is built for something else entirely.

The concurrency inversion: where EFS's latency cost becomes a deliberate trade for shared access

The apparent EBS advantage flips when many instances need to read and write to the same files at the same time. EFS's higher per-operation latency is the price of a capability EBS cannot offer by design: many instances reading and writing to the same files at the same time.

EBS volumes live in a single Availability Zone and, in the ordinary case, attach to exactly one EC2 instance. A comparison from Zesty lays the arithmetic out: mounting one EFS volume across multiple EC2 instances costs the same as mounting it to a single instance, while duplicating EBS volumes across nodes adds up fast. EBS Multi-Attach does exist, but it only applies to io1/io2 volumes inside a single Availability Zone. It's a narrow special case, not a general answer to shared access.

That network hop that adds latency to every EFS operation is the same mechanism that lets throughput aggregate across many concurrent readers and writers at once. General Purpose mode's 7,000 IOPS baseline isn't a number one client pulls in isolation, it's a number spread across every connection hitting the system simultaneously. EFS also scales storage automatically from gigabytes to petabytes with no manual provisioning step, while EBS requires operators to set capacity and performance up front and wait for changes to take effect. Thousands of machines can connect to one EFS file system at the same time. EBS has no equivalent to that at all.

This is the concurrency inversion: the exact thing that makes EFS look slower on a single operation is the thing that makes it stronger at scale. Trading per-operation speed for simultaneous, shared access isn't a compromise forced on EFS, it's the design goal.

EFS's own internal trade-off: General Purpose versus Max I/O mode

The same tension appears one layer down, inside EFS itself. AWS built two modes into the service because latency and high-concurrency throughput pull against each other even within a single product, and operators have to pick a side.

General Purpose mode is the default for most EFS use cases, built for applications that need lower latency on individual operations. Max I/O mode is built for the opposite priority: highly parallelized workloads that can tolerate higher latency in exchange for scale. Max I/O reaches sequential read speeds up to 1,750 MB/s across concurrent clients, at the cost of the latency floor rising further above General Purpose's already-higher baseline.

AWS didn't stumble into this design. The same tension resurfaces, at a much bigger scale and with much higher stakes, once AI training enters the picture.

The EBS/EFS trade-off at AI training scale

AI training workloads expose the EBS/EFS trade-off at its sharpest, revealing that EFS's concurrency advantage is insufficient for the most demanding training configurations.

Training workloads consume data at enormous volumes, and they need dozens of GPU processes running on different servers to read the same files at the exact same moment. That's a workload EBS simply cannot serve without duplicating a volume onto every single node, which defeats the point of fast, simple infrastructure. EFS's shared access model looks like the natural fix: every GPU node reads the same training dataset at once, with no need to copy files onto each machine first. That's exactly why EFS shows up so often as the shared-dataset layer in multi-GPU clusters, and it's listed as suitable for machine learning training workflows where large datasets need parallel reads across a cluster.

For the most latency-sensitive, high-bandwidth workloads, things like distributed training and model serving across multiple GPU instances, AWS's own guidance points toward FSx for Lustre instead of EFS. FSx for Lustre is a fully managed, high-performance parallel file system built specifically for HPC and ML work. AWS positions it as the preferred architecture for these workloads, not EFS. AWS's recommended pattern for large language model training goes further still: stage datasets in S3, use Mountpoint for S3 to handle high-throughput training I/O, and design checkpoint storage to keep GPU idle time to a minimum. EFS becomes one option among several in that framing for shared storage.

Concurrency wins the argument against EBS. But concurrency plus throughput at the scale modern training clusters demand needs something beyond EFS. The constraint on AI performance now is network infrastructure, meaning how well data moves between compute nodes, across regions, and between cloud and edge. That constraint pushes the conversation toward a third option sitting above object storage.

S3 caching layers as a third architectural option that changes the comparison

The EBS-versus-EFS frame assumes those two are the only paths to shared, low-latency storage. That assumption is getting out of date. Low-latency object storage tiers and transparent caching layers built on top of them have opened up a third path, one that competes with EFS on concurrency while beating it on latency.

S3 Express One Zone is built for exactly this. It's a storage class purpose-built to deliver consistent, single-digit millisecond data access for latency-sensitive applications, and it improves data access speeds while cutting request costs compared to S3 Standard. Caching layers sitting above object storage push further still: transparent layers between AI workloads and cloud storage can deliver sub-millisecond time-to-first-byte latency while holding throughput steady, with latency well below both S3 Standard and S3 Express One Zone in benchmark comparisons.

Training, in practice, is a throughput problem more than a latency problem: the storage layer has to keep pace at sustained scale, not just hit a fast number once. Retrieval-augmented generation flips that profile on its head. A RAG query touches a handful of objects in milliseconds, the total throughput involved is modest, but concurrency and tail latency matter enormously, because a retrieval endpoint that hesitates half a second per query stops feeling conversational.

Cloud-agnostic filesystem layers that mount directly over existing S3, GCS, R2, or Azure Blob buckets serve this same role, without requiring migration, ETL pipelines, or code changes. Archil, a serverless filesystem that mounts S3 and GCS buckets as a native POSIX filesystem so AI workloads can read data zero-copy without moving it, is one concrete example of this approach. They bring NVMe-cached, sub-millisecond reads to data that stays exactly where it already lives, with the bucket remaining the single source of truth and no duplicate copies created. For AI agents specifically, a persistent shared workspace that survives across sessions and mounts across many servers at once solves the same concurrency problem that originally justified choosing EFS, while staying cloud-agnostic and billed on actual use rather than provisioned capacity sitting idle. Framed on its merits, this class of architecture requires no migration and no ETL step, keeps the bucket as source of truth, tracks billing to actual usage, and offers POSIX semantics so existing code runs unmodified.

Multi-cloud and cross-region data movement

EBS and EFS share one assumption neither service ever questions: that data lives in one cloud, in one region. Once AI workloads start spanning regulatory boundaries and multiple cloud providers, the real question is no longer EBS-versus-EFS but whether the data needs to move at all.

EBS volumes are locked to a single Availability Zone, full stop. EFS Multi-AZ replication helps with resilience, but it doesn't solve access across regions or across clouds at the speed inference workloads demand. The response taking shape across enterprises is data layers that stay cloud-agnostic and keep data stationary, bringing compute to the data instead of dragging data into a centralized, proprietary warehouse before it can be useful for AI.

Dell and Starburst co-engineered a platform announced at Dell Technologies World 2026 built on that exact principle: a GPU-accelerated data foundation for agentic AI where data never has to move to be useful, delivering governed, federated access at inference speed, right where the data already sits. Google's infrastructure roadmap, shown at a recent Next event, points the same direction. Managed Lustre uses TPUDirect and RDMA so data bypasses the host and goes straight to the accelerator, while Rapid Buckets on Google Cloud Storage targets sub-millisecond latency and 20 million operations per second, both built toward training and inference without forcing data to migrate first.

A multi-cloud context layer extends the same logic to metadata rather than raw data: cloud-agnostic infrastructure that gives AI agents consistent definitions, relationships, policies, and lineage no matter which cloud they're running on. Because that context gets queried where it already lives, cross-cloud data movement and its egress costs never enter the picture. EBS and EFS were built to solve storage inside one cloud, inside one cluster. Multi-cloud AI infrastructure is a different problem, and it's being solved by keeping data put rather than picking a faster way to move it around.