EFS vs. EBS vs. S3 Performance Benchmarks for Agent Workloads
Pick the right storage tier for each agent job, not one service for all four.
Three storage services, three completely different jobs, and one question people keep asking wrong: not "which one is best" but "best for what, at what latency, and at what cost per GB." EBS, EFS, and S3 get ranked like a leaderboard (EBS wins gold, EFS takes silver, S3 gets the participation trophy), and that ranking holds up fine for a normal web app. Agent workloads don't play by those rules. A single agent run might need sub-millisecond reads, a burst of parallel writes, a shared namespace across ten instances, and a 40 GB model checkpoint, all inside the same fifteen minutes, and no single tier covers that whole spread. The job changes four times before lunch, and picking one favorite service for all four is how teams end up debugging a latency problem that was actually an architecture problem.
How EBS, EFS, and S3 store data differently, and why that distinction determines everything downstream
Start with the plumbing. It explains everything that comes later, so skipping it just means relearning it the hard way later.
EBS is block storage: a virtual hard drive bolted onto one EC2 instance. It reads and writes at the block level, and the application on top just sees a disk. Fast and personal, and it belongs to one instance at a time, mostly.
EFS is a filesystem running over NFS, and it scales without anyone provisioning anything by hand. Multiple instances mount the same namespace at once and see the same files. Shared by design, not as an afterthought.
S3 is neither of those things. It's an object store, accessed through a REST API, never mounted anywhere. Every object carries metadata, but there's no folder tree underneath it, no filesystem behavior baked in. Ask for an object, get an object back. That's the whole interaction.
That architecture gap is the whole ballgame, and one of these three breaks first under agent load: S3. EBS's single-instance attachment (Multi-Attach exists, but it caps out) means it's built for one thing talking to one disk. EFS's concurrent-access model bakes coordination overhead into every write, because multiple instances are touching the same files at once. S3's request-response model means latency is a network round trip, not a disk seek, and that gap shows up constantly in the numbers below.
Keep this in your back pocket: EBS and EFS both support POSIX operations, atomic rename, file locking, mmap, fsync. S3 does none of that natively. If agent-written code assumes it can lock a file or rename it atomically, S3 just won't behave the way that code expects, full stop. This is the reason S3 gets ruled out for entire categories of agent work no matter how cheap it looks on the invoice.
EBS latency and IOPS profile: where it excels and where agent workloads hit its ceiling
EBS wins on raw speed. Latency sits sub-millisecond to around 1 to 2 milliseconds, and for a single instance doing random reads, nothing else here comes close, and nothing else needs to.
Current gp3 volumes ship with 3,000 IOPS and 125 MiB/s at baseline, provisionable up to 80,000 IOPS and 2,000 MiB/s on volumes as large as 64 TiB. If a team is still running gp2 in 2025, that's not a design choice, that's an oversight.
Need more? Io2 Block Express tops out at 256,000 IOPS and 4,000 MB/s, still sub-millisecond, with durability rated at 99.999%. Provisionable up to 1,000 IOPS per GiB. That's built for the workloads where a missed millisecond costs real money, transactional databases, not scratch space for a side task.
Io2 also supports Multi-Attach, letting one volume connect to up to 16 Nitro-based instances at once, genuinely useful for a small swarm of agents sharing block storage. But 16 is a hard ceiling, and EFS doesn't have one. If only one instance needs the storage, EBS runs roughly 4x cheaper than EFS for equivalent capacity, and that number alone decides most single-agent architectures. For a single agent doing high-frequency random reads (tool calls hammering the same structured context over and over), EBS is simply faster. It's the cheaper pick too, and there's no real tension between those two facts here.
Where EBS falls apart: past that 16-instance ceiling, or any case where agents need a shared, persistent namespace across sessions without someone manually managing instance attachment by hand. That's a different problem, and it belongs to EFS.
EFS throughput modes and what each one means for parallel agent access
EFS's whole pitch is that the attachment ceiling disappears. Unlimited instances mount the same filesystem at once, which is exactly why EFS becomes the default for parallel agent runs sharing context. No coordination dance, no 16-instance cap, just a shared namespace that everyone reads and writes into.
But "EFS" isn't one setting, it's three throughput modes, and picking the wrong one bites you the moment load spikes.
Bursting mode earns credits at 50 MB/s per TB stored, bursting up to 100 MB/s per TB (with a 100 MB/s floor regardless of size). Fine for agents that fire off requests in bursts and go idle between them. Bad for agents running sustained, continuous parallel writes, because once the burst credits run dry, throughput collapses and everything downstream feels it immediately.
Provisioned mode lets you dial in anywhere from 1 MB/s to 3 GB/s by hand. Good for predictable, steady load. Bad for agent swarms whose demand swings depending on how many instances happen to be running that hour, which is most agent swarms.
Elastic mode is the one actually built for agents. It auto-scales up to 10 GB/s reads and 3 GB/s writes in General Purpose mode, charges by the GB actually moved, and skips burst-credit accounting entirely. When agent parallelism is unpredictable, and it usually is, Elastic is the mode that doesn't punish a bad guess. Start there instead of trying to provision your way around uncertainty you can't actually forecast.
IOPS follow the same shape. Bursting caps around 35,000 read and 7,000 write ops per second on Regional filesystems; Provisioned goes up to 55,000 read and 25,000 write; Elastic is designed to scale beyond those fixed ceilings. General Purpose performance mode gives low single-digit millisecond latency and covers most agent use cases, while Max I/O trades a little latency for throughput that scales without limit, useful for heavily parallelized pipelines running dozens of agents at once.
Cost is where EFS earns some caution. Standard runs single-digit millisecond latency for active data, and Infrequent Access cuts storage cost by up to 92% for anything untouched in 30 days, a good fit for agents that write artifacts once and rarely revisit them. But EFS Standard prices out at $0.30 per GB per month against S3 Standard's $0.023, roughly 13 times more expensive. Park a large artifact library on EFS out of habit and the bill notices fast. Access pattern, not raw capacity, should decide where those files actually live, not whichever tier was easiest to spin up first.
S3 latency reality versus its scale and durability advantages
S3 Standard's time to first byte lands somewhere between 30 and 200 milliseconds. Fine for pulling a batch of artifacts once in a while. A real problem if an agent needs a sub-100ms response on every step of its loop. This is where most people misjudge S3 badly: they price it out, love the number on the invoice, and never check the latency line sitting right above it.
S3 Express One Zone narrows that gap hard: consistent single-digit millisecond latency, up to 10 times faster than Standard, built to handle high request rates without strain. The April 2025 price cuts made it much harder to ignore: storage down 31%, PUT requests down 55%, GET requests down 85%. That's the kind of move that changes which tier makes financial sense, not just which one wins on a benchmark chart somewhere.
Real throughput backs it up. Network path matters here almost as much as which storage class got picked in the first place. For anything latency-sensitive that used to default straight to EFS purely out of habit, Express One Zone's price and latency improvements make it a fair trade worth reconsidering.
And then there's raw scale, which nothing else here competes on. S3 stores more than 400 trillion objects and handles up to 150 million requests per second, backed by 11 nines of durability, at around $23 per TB per month for Standard. For large, durable artifact storage, the economics simply aren't close, and pretending EFS or EBS can compete at that scale is wishful math, not a real comparison.
AWS also announced a few additions at its 2025 New York Summit worth flagging for agent-heavy pipelines: a 50 TB maximum object size, S3 Vectors for native vector storage and query, and S3 Tables with native Apache Iceberg support, broadening what S3 can natively handle for AI workloads. None of that changes the latency math above, but it widens what S3 can reasonably be asked to do.
Mapping four agent workload patterns to the right storage primitive
Four patterns, four different right answers, and treating them as one decision is where most teams go wrong.
High-frequency random reads. A single agent running an inference loop, hammering tool calls that read structured context over and over. EBS gp3 or io2 fits this like a glove: sub-2ms latency, high IOPS, zero network round trip involved. EFS General Purpose can technically do the job, but the NFS round trip adds overhead nobody needs here, and S3 Standard's 30-200ms latency rules it out completely for this pattern.
Parallel writes from an agent swarm. Multiple agents writing checkpoints, logs, or intermediate files at the same time. EFS with Elastic throughput is the structural answer: no attachment ceiling, auto-scaling to 10 GB/s reads and 3 GB/s writes, no burst-credit cliff waiting to trip things up. EBS Multi-Attach caps at 16 instances, so anything bigger needs EFS or S3 multipart upload instead. S3 multipart scales fine for large files, but it has no filesystem semantics, and agents writing lots of small, frequent files feel that in both latency and per-request cost.
Shared persistent context across sessions. Agents resuming work across conversations, reading and writing shared state. This needs a namespace multiple instances can mount at once, and EFS is the native answer here, full stop, no real competitor. EBS Multi-Attach can technically stretch to 16 instances, but it needs application-level locking to avoid stepping on itself, something EFS just handles at the filesystem layer for free. S3 is out too, since it lacks the atomic rename and file-locking behavior agent code often assumes when managing shared state.
Large artifact access. Model weights, training sets, checkpoint files, multi-gigabyte outputs. S3 wins on cost: $0.023 per GB per month against EFS's $0.30, a 13x gap that's hard to argue around no matter how the rest of the pattern shakes out. S3 Express One Zone closes the latency gap enough for throughput-heavy large reads, with high throughput at scale a reasonable expectation for parallel large-object reads. Most working architectures don't pick just one service here anyway. They layer EBS or EFS for active compute-side access and keep S3 as the durable source underneath it. Two layers, not one winner picked off a leaderboard.
What a cloud-agnostic filesystem layer changes about this decision
Every native option carries a built-in constraint. EBS is single-instance by default and locked to AWS. EFS speaks NFS and nothing else, also AWS-only. S3 skips POSIX behavior entirely. Depending on which agent pattern shows up that day, any one of these three turns into a bottleneck sooner or later, and the fix usually isn't picking a fourth AWS service.
One approach gaining ground: mount object storage, S3, GCS, any S3-compatible bucket, as an actual POSIX filesystem. No migration, no ETL job, no rewriting application code around a new API. An NVMe cache layer sits in front and absorbs the gap between "object store round trip" and "local block storage speed."
For agent workloads, that means reads served from a local cache return much faster than a full object-store round trip, writes are durably committed and flushed to the bucket, and the bucket stays the actual source of truth the whole time. Access can be revoked without losing data, and no shadow copy of anything lives outside the account it started in.
On concurrency, this kind of layer is designed to mount across many servers at once, without the AWS lock-in that comes bundled with EFS. On capacity, it avoids the need to provision storage up front, which maps cleanly onto agent workloads where nobody knows in advance whether a given run needs 1 MB or 1 GB.
Some versions pair a serverless execution layer directly with the mounted filesystem, so agents run commands straight against it without spinning up a separate sandbox for every task. That keeps the tool surface from bloating every time someone bolts on a new integration. And because the bucket already is the working data, not a copy waiting to be pulled down, teams doing training or inference can potentially reduce the time expensive compute hardware spends waiting on data to be ready.
None of this replaces EBS or EFS across the board. A workload built around io2's 256,000 IOPS ceiling is well served by native block storage, no argument there. What this competes with directly is EFS, and the "cache on EBS, store on S3" two-layer pattern most teams currently build by hand anyway.
A practical decision framework for choosing storage by workload pattern
Start with concurrency. How many agents or instances actually need to touch the data at the same time, right now, not hypothetically next quarter?
One instance means EBS, cheaper (about 4x less than EFS) and lower latency, no contest worth having. Up to 16 instances with heavy IOPS demand points to EBS io2 with Multi-Attach. Past 16, or if the scale is genuinely unknown ahead of time, that's EFS Elastic or a filesystem layer over object storage.
Next, ask how sensitive the workload is to latency. Is the agent's inner loop stalled waiting on every storage read? Sub-2ms needs mean EBS or a caching filesystem layer, nothing softer will do. Single-digit milliseconds is tolerable territory for EFS General Purpose or S3 Express One Zone, either one works fine there. Batch retrieval or occasional artifact pulls belong on S3 Standard at roughly $23 per TB per month, which wins on cost and durability without a fight.
Then check for POSIX dependency. Does the agent's code rely on atomic rename, file locking, mmap, or fsync? If yes, that rules S3 out entirely: go with EBS, EFS, or a POSIX-compliant filesystem layer instead. If no, S3 or S3 Express One Zone become genuinely viable, and the cost advantage at scale is hard to beat once that constraint is off the table.
Last, weigh artifact size against how often it actually gets touched. Large files that rarely get re-read belong on S3 Standard, S3 Infrequent Access, or EFS Infrequent Access (up to 92% cheaper than EFS Standard) if they need to stay inside an EFS namespace. Large files under frequent, latency-sensitive access are where S3 Express One Zone earns its keep, delivering most of EFS's responsiveness at a fraction of the storage cost.
None of these four questions produces a universal winner, and that's the actual point of asking them separately. Agent workloads change shape mid-run, sometimes mid-request. The storage layer only works if it got picked for the specific job sitting in front of it right then, not for a leaderboard ranking that assumed a much simpler application back when the app only did one thing at a time.