Updated 28 Aug • 5 mins read
Amazon EFS vs EBS: Cost, Features, and Which to Choose
Amazon EFS and EBS solve different storage problems: EBS is block storage for a single instance, EFS is a shared, elastic file system. This guide compares them on architecture, performance, durability, and cost in US dollars, with a side-by-side table, three worked scenarios, and a decision framework for choosing between them.
The comparison between Amazon EFS and EBS trips people up for a simple reason: the two services are not competing for the same job, yet the pricing pages invite you to compare them as if they were. EBS at eight cents a gigabyte looks obviously cheaper than EFS at thirty. Then you discover that EBS bills for capacity you provisioned and never used, that it attaches to one instance in one Availability Zone, and that the five servers you wanted to share a dataset across would each need their own copy. Suddenly the cheap option costs more than the expensive one.
This guide sets the comparison up properly. It explains what Amazon EBS and Amazon EFS each are and what they are built for, compares them side by side on architecture, performance, durability, and price in US dollars, works through three realistic cost scenarios that show when each one wins, and ends with a decision framework that answers the question most people actually have: which one should I use for this workload.
The short answer Amazon EBS is block storage that attaches to a single EC2 instance in one Availability Zone, like a hard drive, billed on the capacity you provision at about $0.08 per GB-month for gp3. Amazon EFS is a shared network file system that thousands of instances, containers, and Lambda functions can mount simultaneously across Availability Zones, billed only on what you store, at about $0.30 per GB-month for Standard and far less for cold tiers. Choose EBS for boot volumes, databases, and single-instance workloads that need the lowest latency; choose EFS when many clients must share the same files, when you cannot predict capacity, or when you need cross-AZ durability without managing snapshots. EBS is cheaper per gigabyte; EFS is often cheaper in total once sharing and cold-data tiering are counted.
Key Takeaways
- EBS is block storage for one instance in one AZ; EFS is a shared, elastic file system mounted by many clients across AZs. They are complements, not rivals.
- Per gigabyte EBS is far cheaper ($0.08 for gp3 versus $0.30 for EFS Standard), but EBS bills provisioned capacity while EFS bills used capacity and can tier cold files to $0.016 or $0.008.
- EBS wins on latency and IOPS for databases and boot volumes; EFS wins on sharing, elasticity, and cross-AZ durability.
- Once data is shared by several instances or is mostly cold, EFS frequently costs less in total than the EBS volumes needed to replicate it.
- The decision is about access pattern, not price list: single-instance and latency-sensitive goes to EBS, shared and unpredictable goes to EFS.
What Each Service Is Built For
Amazon EBS: a disk for one server
Elastic Block Store provides block-level volumes that attach to an EC2 instance and behave like a local disk: you format them, mount them, and the operating system reads and writes blocks directly. Each volume lives in a single Availability Zone and, with the narrow exception of Multi-Attach on io1 and io2 volumes within one AZ, attaches to one instance at a time. You choose a size and performance class up front and pay for that provisioned capacity whether you fill it or not. This makes EBS the natural home for boot volumes, transactional databases, and any application whose storage belongs to one machine and needs the lowest possible latency. The official EBS pricing page lists the volume types.
Amazon EFS: a file system for everyone
Elastic File System provides a fully managed NFS file system that any number of EC2 instances, ECS tasks, EKS pods, and Lambda functions can mount at the same time, from any Availability Zone in the region. There is nothing to provision: the file system grows and shrinks as you add and remove files, and you pay for the average storage used. Regional file systems replicate across multiple AZs automatically. This makes EFS the natural home for shared content, application uploads, home directories, persistent storage for containers, and lift-and-shift of on-premises NFS workloads. The official EFS pricing page lists the storage classes, and our guide to EFS pricing and cost optimization covers them in depth.
EFS vs EBS: Side-by-Side Comparison
Rates are US East (N. Virginia) list prices as of September 2026 and vary by region.
| Dimension | Amazon EBS | Amazon EFS |
|---|---|---|
| Storage type | Block storage (like a local disk) | Network file system (NFS) |
| Access | One EC2 instance (Multi-Attach: up to 16, same AZ, io1/io2 only) | Thousands of instances, containers, and functions at once |
| Availability Zone scope | Single AZ | Regional (multi-AZ) or One Zone |
| Capacity | Provisioned up front; resize manually | Elastic; grows and shrinks automatically |
| Billing basis | Provisioned GB, whether used or not | GB actually stored (monthly average) |
| Base price per GB-month | gp3 ~$0.08; gp2 ~$0.10; io2 ~$0.125 plus IOPS | Standard ~$0.30; One Zone ~$0.16 |
| Cold tiers | st1 ~$0.045; sc1 ~$0.015 (HDD classes) | Infrequent Access ~$0.016; Archive ~$0.008 plus access fees |
| Performance | Sub-millisecond latency; up to 256,000 IOPS on io2 | Low-millisecond latency; scales throughput with size or Elastic mode |
| Durability | High within one AZ; snapshots for cross-AZ | Multi-AZ replication built in (Regional) |
| Extra charges | IOPS and throughput above baseline; snapshots ~$0.05/GB | Elastic Throughput ($0.03/GB read, $0.06/GB write); access fees on cold tiers |
| Typical uses | Boot volumes, databases, single-node apps | Shared content, CMS, home dirs, container storage, ML datasets |
Performance: Where EBS Wins
Block storage is faster because there is less between the application and the disk. An EBS gp3 volume delivers sub-millisecond latency with 3,000 IOPS and 125 MB/s included, scaling to 16,000 IOPS, and io2 Block Express reaches 256,000 IOPS with consistent single-digit-millisecond tails, which is why every serious database on EC2 runs on EBS. EFS, as a network file system, adds a network hop and NFS protocol overhead, so its latency sits in the low milliseconds rather than sub-millisecond. Its throughput scales well, especially in Elastic mode, and it handles massively parallel access far better than EBS can, but for a single client doing latency-sensitive random I/O, EBS is the right tool. Our explainer on what IOPS means for storage performance covers how to read these numbers.
Sharing and Durability: Where EFS Wins
The case for EFS is everything EBS structurally cannot do. A single EFS file system can be mounted by a fleet of web servers, an autoscaling group, hundreds of containers across three Availability Zones, and a batch of Lambda functions, all reading and writing the same directory tree with standard file semantics. Replicating that with EBS means a volume per instance, a synchronization mechanism you build and maintain, and a consistency problem you own.
Durability follows the same pattern. A Regional EFS file system replicates across multiple AZs automatically, so an AZ outage does not take the data away. An EBS volume is replicated only within its own AZ; surviving an AZ loss means taking snapshots to S3 and restoring into another zone, which is reliable but operational work you have to run. For workloads where sharing or hands-off resilience matters, EFS is not the expensive option; it is the only option that fits.
Cost: Three Scenarios That Show the Real Answer
The per-gigabyte rate is the least useful number in this comparison, because the two services bill different things. Three scenarios make the real trade-off visible. All figures are US East list prices, rounded, before taxes.
| Scenario | EBS cost / month | EFS cost / month | Winner |
|---|---|---|---|
| 1 TB active data, one instance | gp3: ~$82 (1,024 GB provisioned) | Standard: ~$307 plus throughput | EBS, by a wide margin |
| 1 TB, 300 GB active and 700 GB cold, one instance | gp3: ~$82 (must provision the full 1 TB) | ~$90 Standard + ~$11 IA/Archive = ~$101 plus access | Roughly even; EBS slightly ahead |
| 1 TB shared by 5 instances, 300 GB active | 5 x gp3 volumes: ~$410, plus a sync layer you build | One file system: ~$101 plus throughput | EFS, and it is simpler |
Scenario one is the comparison most people make and it is why EBS looks cheap. Scenario two shows how EFS lifecycle tiering closes the gap when most data is cold, because EBS has no equivalent: you provision the whole terabyte at the active rate regardless. Scenario three is the one that matters for shared workloads: once several instances need the same data, EBS multiplies while EFS does not, and the operational cost of keeping five volumes in sync is not on any invoice.
The general lesson is the one that runs through all of AWS storage pricing, covered in our guides to understanding AWS pricing across EC2, S3, EBS, and RDS and cloud storage pricing across providers: price the access pattern, not the gigabyte.
How to Choose: A Decision Framework
Four questions settle nearly every case.
- Does more than one instance need the data at the same time? If yes, EFS. If no, EBS is cheaper and faster.
- Is it a database or boot volume? EBS, without exception. These need block access and the lowest latency.
- Can you predict capacity, and is most of the data active? If yes, EBS's provisioned model is efficient. If capacity is unpredictable or most data goes cold, EFS's elastic billing and tiering win.
- Do you need cross-AZ durability without running snapshots? If yes, a Regional EFS file system gives it to you built in.
In practice most architectures use both: EBS under every instance for the OS and any local database, EFS for the shared layer. On Kubernetes this pattern is nearly universal, EBS for single-pod persistent volumes and EFS for storage that many pods across AZs must share, which is why both appear in our Kubernetes cost optimization guide.
Common Mistakes With Both
- Provisioning EBS for peak and forgetting it. A volume sized for a migration that finished bills its full size forever; right-size or snapshot and delete.
- Leaving EBS volumes unattached. Deleting an instance does not delete its volumes by default, and orphaned volumes are one of the most common AWS waste items.
- Putting single-instance data on EFS. Paying the shared-storage premium for a file system only one server ever mounts wastes roughly three-quarters of the cost.
- Running EFS without lifecycle management. Most file systems hold a long tail of untouched files; leaving them in Standard is the single largest EFS overspend.
- Provisioned Throughput on EFS by default. Elastic mode costs nothing when idle; provisioned throughput bills every hour whether used or not.
Each of these is invisible on an invoice that shows only service totals, which is why storage waste persists. Seeing cost per volume and per file system, attributed to the team that owns it, is what Opslyft's cost visibility is built for, and the wider practice is in our guide to AWS cost optimization.
The Bottom Line
EFS versus EBS is not a question with a winner, because the two services answer different questions. EBS is the disk under a server: fast, cheap per gigabyte, tied to one instance and one zone, and billed on what you provision. EFS is the file system a fleet shares: elastic, regionally durable, mountable by thousands of clients at once, and billed on what you use, with cold tiers that get cheap fast. Put databases and boot volumes on EBS, put shared and unpredictable data on EFS, and count the cost by access pattern rather than by the rate card. Most well-designed AWS estates run both, and the ones that overspend are usually the ones that picked one for the wrong reason.
FAQs
Amazon EBS is block storage attached to a single EC2 instance in one Availability Zone, like a hard drive, and you pay for the capacity you provision. Amazon EFS is a shared network file system that thousands of instances, containers, and Lambda functions can mount at once across Availability Zones, and you pay only for the storage you use. EBS is faster and cheaper per gigabyte; EFS is shared, elastic, and regionally durable.
Per gigabyte, EBS is cheaper: gp3 costs about $0.08 per GB-month against EFS Standard at about $0.30. But EBS bills provisioned capacity whether used or not, while EFS bills only what you store and can tier cold files to Infrequent Access ($0.016) or Archive ($0.008). For data shared by many instances, or data that is mostly cold, EFS can cost less in total; for a single instance's active data, EBS almost always wins.
Use EFS when multiple instances or containers need to read and write the same files, when you need storage that survives an Availability Zone failure without snapshots, when you cannot predict capacity, or when you are migrating an on-premises NFS workload. Typical cases are shared content repositories, CMS uploads, home directories, persistent storage for Kubernetes pods across AZs, and shared data science datasets.
Use EBS for boot volumes, databases, and any workload that runs on one instance and needs the lowest latency and highest IOPS. It is the right choice for transactional databases, single-node applications, and anything where sub-millisecond block access matters more than sharing. EBS is also the cheaper option per gigabyte for active data.
Only in a limited way. EBS Multi-Attach lets io1 and io2 volumes attach to up to 16 instances, but only within a single Availability Zone, and it requires a cluster-aware file system to avoid data corruption. For general multi-instance shared access, especially across AZs, EFS is the purpose-built answer.
For 1 TB of active data on one instance, EBS gp3 costs about $82 a month and EFS Standard about $307 plus throughput. But if 700 GB of that terabyte is cold and tiered by EFS lifecycle management, EFS drops to roughly $101 a month, and if five instances need the same data, EBS would need five volumes at about $410 total while one EFS file system serves them all. The answer depends on sharing and access pattern, not just the per-GB rate.
EFS Regional file systems replicate data across multiple Availability Zones automatically, so they survive an AZ failure without any action from you. EBS volumes live in a single AZ and are replicated only within it, so cross-AZ resilience requires snapshots to S3 and a restore. For durability without operational work, EFS is stronger; for a single AZ, both are highly durable.