AWS EBS vs EFS for Shared ML Storage

Walking through performance characteristics, cost structure, and the concrete ML scenarios each handles well gives practitioners a clear framework for matching storage architecture to workload shape.

The growing difficulty of ML storage decisions

Global AI infrastructure spending blew past $250 billion in 2025, with storage and networking growing almost as fast as compute itself. That's the headline number. The quieter number is worse: more than half of organizations say data and storage bottlenecks are actively limiting what their AI systems can do, and 57% of enterprises admit their data isn't even AI-ready yet, despite everyone racing to experiment anyway.

Put those two facts side by side and a pattern falls out. Compute gets the budget, the headlines, and the org chart. That question is the problem. EBS and EFS encode different assumptions about who accesses data, how many nodes need it simultaneously, and how predictable the load is.

So the real question was never which service is "better." It's which architectural bet actually matches how the training and inference jobs are structured. Get that wrong, and no amount of GPU horsepower fixes it. The result: teams reach for whichever AWS storage primitive is familiar, rather than matching architecture to workload shape.

What EBS is, and the architectural assumption it makes

EBS behaves like a dedicated virtual hard drive: it attaches to one EC2 instance in the same Availability Zone, moves data at the block level, and behaves like a local disk to the OS. That single-instance limit is a deliberate design choice, not an oversight someone forgot to patch. It's the design.

sc1, Cold HDD, is priced at $0.015 per GB-month, useful for archival tails and not much else, since it has no business anywhere near an active training job S3 vs EBS vs EFS vs Glacier: 2026 Comparison | SquareOps.

A detail that quietly costs teams real money: gp3 includes 3,000 IOPS and 125 MB/s at no extra charge as the current default. That change alone saves 20 to 30% for most workloads. Anyone still running gp2 volumes in 2026 is paying a self-imposed tax for no reason S3 vs EBS vs EFS vs Glacier: 2026 Comparison | SquareOps.

On durability, io2 volumes hit up to 99.999%, but that number comes with fine print: replication happens within the Availability Zone, not across zones by default. Snapshots, which live in S3 and update incrementally, are the actual backup and disaster-recovery mechanism here S3 vs EBS vs EFS vs Glacier: 2026 Comparison | SquareOps. They're not some built-in durability feature of the volume itself, and treating them as the same thing is how people get burned. On raw speed, a December 2024 Bonnie++ benchmark on an m5d.xlarge clocked EBS at 65.4 MB/s for large-block rewrite, fast for network-attached storage, though still short of the local instance store's 126 MB/s ceiling. Volume types for ML practitioners:. io2 Block Express costs $0.125/GB-month plus $0.065/IOPS-month, with a ceiling of 256,000 IOPS and 4,000 MB/s throughput EBS vs EFS Performance and Scalability Comparison.

What EFS is, and the architectural assumption it makes

EFS starts from the opposite premise. It's a fully managed NFS file system (NFSv4, specifically), built so that multiple EC2 instances, ECS tasks, EKS pods, and Lambda functions can all mount it and read or write at the same time. Shared access is the entire reason EFS exists. It's the entire reason the service exists.

Pricing runs in tiers that map to how often data actually gets touched. Standard, the multi-AZ option, runs $0.30 per GB-month and includes cross-AZ durability as part of the deal⟧c21⟧ Sedai. Standard-IA drops to $0.025 per GB-month for files nobody's opening much, with lifecycle policies moving data there automatically. Archive bottoms out at $0.0036 per GB-month for long-term retention and compliance needs.

Then there's the part of the bill that sneaks up on people: throughput. AWS is explicit that this includes metadata operations, so a simple ls, rm, or mkdir counts against the meter. Run a nightly scan across millions of small files and that "free" storage graph suddenly has a very real dollar figure attached to it that nobody budgeted for.

Speed-wise, EFS isn't far off EBS in the same December 2024 Bonnie++ test: EFS reached 60.6 MB/s for large sequential writes, close to EBS. Where it diverges is durability. "Standard" here is a storage class name, not a separate file system type, since multi-AZ replication is a property of the Regional file system itself Sedai S3 vs EBS vs EFS vs Glacier: 2026 Comparison | SquareOps.

The consistency problem that makes EFS indispensable for multi-node ML

This failure mode appears in almost every multi-node ML shop eventually. A scheduler on the master node reads version 2 of a DAG or config file. Meanwhile a worker node, sitting on its own local EBS volume, still has version 1 sitting there. The scheduler dispatches a task. The worker runs it using stale logic, either silently doing the wrong thing or blowing up with an import error that takes an afternoon to trace back to its actual cause.

Nobody wrote a bug here. This is what happens when block storage that's fundamentally single-instance gets pressed into a job that requires shared state, and no clever sync script bolted on top eliminates that race condition reliably once the cluster gets big enough.

EFS erases the problem by design. Every node mounts the identical volume at the identical path, so a file update becomes visible everywhere within NFS cache propagation time, typically under a second.

What doesn't belong there is just as important. Databases like PostgreSQL or Redis, container runtimes, OS volumes, anything that needs fast transactional I/O tied to one machine: that's EBS territory, full stop. And an asymmetry sits here. Losing an EFS mount is annoying but recoverable in minutes, since DAG files and code live in version control anyway. Losing the master node's EBS volume is a much worse day: task history, metadata, cluster state, all of it gone unless a snapshot happens to exist. What lives on EFS in a well-structured ML cluster:.

How performance characteristics diverge under ML-specific load patterns

On paper, EBS wins the single-instance throughput race by a wide margin. io2 Block Express reaches 4,000 MB/s and 256,000 IOPS, while EFS's Max I/O mode tops out at 1,750 MB/s EBS vs EFS Performance and Scalability Comparison. That's a real gap, and it matters for any workload pinned to one beefy node.

Most ML data loading involves a different workload. It's large-block sequential reads, and there the spec-sheet gap shrinks fast: the same December 2024 benchmark put EBS at 65.4 MB/s against EFS's 60.6 MB/s on comparable hardware. Close enough that the choice usually shouldn't be decided on raw speed.

Latency tells a more useful story. EBS stays low and predictable under heavy load. EFS latency moves around depending on how many connections are hitting it and how big the files are, which matters a lot for inference serving where tail latency is what actually breaks an SLA. So single-node, latency-sensitive work still favors EBS on that basis alone.

EFS earns its keep once the picture zooms out. Put dozens of GPU nodes in a training job, all needing the same dataset at once, and EBS forces a choice between one oversized instance or copying the dataset onto every single node. EFS just serves everyone from one mount, no copying, no coordination logic required. Within EFS itself there's a further choice: General Purpose mode, lower latency, suitable for most ML training pipelines.

One cost wrinkle belongs here too, because it's really a performance-per-dollar issue. Matching gp3's free 125 MB/s baseline through EFS Bursting requires provisioning 2,500 GB of Standard storage, which runs about $750 a month. EBS hands out that same throughput for free at any volume size. Pick EFS for a workload that actually wanted EBS's throughput profile, and the bill quietly punishes that choice every month.

Cost math for representative ML storage configurations

EFS One Zone is roughly half the Standard Multi-AZ price, which makes sense for dev and test environments, or training data that doesn't actually need cross-AZ redundancy. Standard-IA drops to $0.025 per GB-month once lifecycle tiering kicks in, close to S3 Standard pricing.

None of that premium is EFS overcharging for nothing. It's paying for multi-AZ durability that EBS only reaches by bolting snapshots on top. The problem is teams that don't need multi-AZ redundancy and pay for it anyway, out of habit rather than requirement.

EBS has its own trap, and it's a sneaky one: snapshots. Take a 500 GB gp3 volume running $40 a month, add daily snapshots with a 5% daily change rate, and that's roughly 25 GB of new snapshot data every single day. Teams that never set a retention policy find this out the hard way, usually via a finance team forwarding a suspicious invoice.

S3 paired with FSx for Lustre is often cheaper still for pure training data at 2 TB scale, compared to EFS Standard Multi-AZ at $600/month or EFS One Zone at $320/month. Lifecycle automation, moving files from Standard to IA to Archive as they age out of active use, can cut EFS storage costs by up to 94% for inactive files, which is the single biggest lever available for write-once, read-occasionally model artifacts.

Throughput billing under Elastic mode is a second cost axis entirely, separate from storage. Budget for the data actually moving, not just the data sitting still. EBS gp3: $0.08/GB-month. EFS Standard (Multi-AZ): $0.30/GB-month (4× gp3 EBS, 13× S3 Standard ($0.023/GB-month)) Sedai S3 vs EBS vs EFS vs Glacier: 2026 Comparison | SquareOps. Throughput billing under Elastic mode adds a second dimension, a workload that reads heavily from EFS at $0.03/GB can accumulate transfer charges that dwarf storage charges on large datasets. Practitioners should model transfer volume, not just storage volume.

Concrete ML scenarios and the storage architecture each calls for

Low latency, plenty of throughput, nothing to share, and no cross-AZ charges to worry about. Reaching for EFS here just adds latency and cost for a sharing capability nobody asked for.

Distributed training across a multi-node GPU cluster is where things split. EFS handles the shared dataset, so every node reads from one consistent source instead of juggling copies. EBS still handles what's local to each node: the OS, container images, scratch space, since those are inherently single-instance jobs and benefit from EBS's lower latency. Most production clusters run both, each doing the job it's actually built for, not one service trying to cover for the other.

Inference serving with shared model artifacts is EFS's home turf: a training job writes the model once, a fleet of inference pods reads it simultaneously, and a lifecycle policy quietly moves older model versions to the IA tier the moment they're superseded, no manual cleanup required.

Airflow-style orchestration clusters split the same way as the training case.

Large, read-mostly training datasets at multi-terabyte scale are the trickiest case. EFS Standard gets expensive fast at that size. The cost-effective path keeps the data's source of truth in object storage and mounts it with POSIX semantics for the training job, avoiding per-GB EFS Standard pricing while still giving training code the file-system interface it expects. In practice this looks like a cloud file system layered directly over an existing S3, GCS, R2, or Azure Blob bucket, no migration, no ETL pipeline, no code rewrite; 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 tool built around exactly this pattern. Reads hit an NVMe cache at sub-millisecond speed, the bucket stays authoritative, and capacity scales with what's actually cached rather than what got provisioned up front. Scenario 1, single-GPU training on one instance with a local dataset. EFS for DAG files and shared pipeline code, the version-consistency requirement is non-negotiable. EBS for PostgreSQL metadata, Redis message queue, task logs, and Docker images, these are single-instance, latency-sensitive, and must be snapshotted for recovery.

A practical framework for choosing between EBS, EFS, and object-backed file systems

Strip away the pricing tables and the benchmark numbers, and one question decides almost everything: how many compute nodes need the same data at the same time, and how much does latency actually matter for that access? One node with low-latency, transactional needs points straight to EBS. Many nodes needing shared POSIX access with real consistency guarantees points to EFS. Large, read-mostly datasets where cost matters and a bucket already exists point to an object-backed file system layer.

EBS is never a wrong call on its home ground: OS volumes, databases, container runtimes, per-node scratch space, anything that's structurally tied to one instance. EFS is never a wrong call when consistency across nodes is a hard requirement, full stop, and the $0.30 per GB-month Standard price is simply what multi-AZ durability and shared POSIX semantics cost on AWS, since nothing else in the platform offers that natively.

Two cleanup jobs should be done regardless of which side of this a team lands on. On EBS: set a snapshot retention policy before the costs quietly compound, and check whether any gp2 volumes are still floating around when gp3 would save 20 to 30% for free. On EFS: turn on lifecycle policies or Intelligent-Tiering, and take a hard look at whether One Zone covers training data and dev environments that never needed multi-AZ redundancy in the first place. Neither fix is glamorous. Both raise next month's bill directly.