S3 vs EFS vs FSx: When to Use Each (and What They Cost)
S3, EFS, and FSx are the three main storage services in AWS that engineers routinely confuse. They look similar at a glance — managed storage, pay-as-you-go, AWS-operated — but they are designed for radically different access patterns, and choosing the wrong one is one of the most expensive architectural mistakes you can make.
This post is a side-by-side comparison: what each service is genuinely for, what it actually costs, and a decision framework that doesn’t require a whiteboard session.
The 30-second version
| Service | Protocol | Best for | Worst for |
|---|---|---|---|
| S3 | HTTP(S) object API | Anything you’d describe as a “file” that an application reads via SDK or URL | Workloads expecting a POSIX filesystem |
| EFS | NFS v4 | Shared filesystems for Linux workloads, dev environments, container persistent volumes | Cold storage; very small/very many files |
| FSx | SMB, NFS, Lustre, NetApp ONTAP | Windows file shares, HPC workloads, lift-and-shift NAS migrations | Bursty, light, or small-scale storage needs |
If you’re starting fresh and not sure, the answer is S3 by default. The other two exist for specific reasons. We’ll get to those.
Amazon S3 — object storage
S3 is not a filesystem. It is a key-value store of objects, accessed via an HTTP API. There is no “directory” — directories are an illusion of the console.
What you actually pay for
| Component | Cost (us-east-1, Standard) |
|---|---|
| Storage | $0.023 per GB-month |
| PUT/COPY/POST/LIST requests | $0.005 per 1,000 |
| GET/SELECT requests | $0.0004 per 1,000 |
| Data transfer out to internet | $0.09 per GB (first 10 TB) |
| Data transfer between regions | $0.02 per GB |
The two line items that surprise people most are request charges (which dominate the bill for workloads with billions of small objects) and data transfer out (which dominates the bill for anything that serves files to end users without CloudFront in front).
Storage classes that change the maths
S3 has multiple storage classes. Picking the right one routinely cuts storage costs by 30-90%:
| Class | $/GB-month | When |
|---|---|---|
| Standard | $0.023 | Frequently accessed |
| Standard-IA | $0.0125 | Accessed <1x/month |
| One Zone-IA | $0.01 | Reproducible data |
| Glacier Instant Retrieval | $0.004 | Quarterly access |
| Glacier Flexible | $0.0036 | Annual access, minutes-to-hours retrieval |
| Glacier Deep Archive | $0.00099 | Compliance archive, 12-hour retrieval |
| Intelligent-Tiering | $0.023 → $0.00099 | When you can’t predict |
Intelligent-Tiering is the right default for any bucket where you aren’t sure of the access pattern. It costs an extra $0.0025 per 1,000 objects in monitoring fees, but it pays for itself almost immediately for any object larger than ~128 KB.
Amazon EFS — managed NFS
EFS is a managed NFS v4 filesystem. It mounts on Linux EC2 instances, ECS tasks, EKS pods, and Lambda — and presents a POSIX filesystem with shared read/write across many clients.
What you actually pay for
| Component | Cost (us-east-1, Standard) |
|---|---|
| Storage (Standard) | $0.30 per GB-month |
| Storage (Infrequent Access) | $0.025 per GB-month |
| Storage (Archive) | $0.008 per GB-month |
| Read throughput (Elastic mode) | $0.03 per GB transferred |
| Write throughput (Elastic mode) | $0.06 per GB transferred |
| Provisioned throughput | $6.00 per MB/s-month |
The Standard storage price is roughly 13x more expensive than S3 Standard. EFS is convenient. It is not cheap.
Where EFS makes sense
- Multiple EC2 instances or containers need to read/write the same files
- Legacy applications that expect a POSIX filesystem and cannot be rewritten to talk to S3
- CI/CD shared caches across build agents
- Container persistent volumes that need to survive task restarts and pod rescheduling
Where EFS is the wrong answer
- Cold archive data — even EFS Archive is more expensive than S3 Glacier Instant Retrieval.
- Billions of small files — EFS metadata operations are not cheap.
- Single-writer workloads — you’re paying for shared access you don’t use. EBS is cheaper.
Amazon FSx — managed enterprise file systems
FSx is a family of managed file systems for cases EFS doesn’t cover. The variants are:
| FSx flavour | Protocol | Use case |
|---|---|---|
| FSx for Windows File Server | SMB | Windows workloads, Active Directory integration, Windows file shares |
| FSx for Lustre | POSIX, HPC | Massively parallel compute, ML training, video rendering |
| FSx for NetApp ONTAP | NFS, SMB, iSCSI | Lift-and-shift from on-prem NetApp; multi-protocol; snapshots |
| FSx for OpenZFS | NFS | High-performance Linux workloads; ZFS features |
Indicative pricing
| Variant | Storage $/GB-month | Notes |
|---|---|---|
| FSx for Windows | $0.13 (SSD), $0.025 (HDD) | + throughput capacity charges |
| FSx for Lustre | $0.145 (SSD-perf) | Or $0.025 (HDD scratch) |
| FSx for NetApp ONTAP | $0.069 (capacity pool) | + SSD reserved + throughput |
| FSx for OpenZFS | $0.09 (SSD) | + throughput capacity |
FSx is not for general-purpose file storage. It exists for specific use cases — Windows fleets, ML training data sets, NetApp customers — and is priced accordingly.
Cost comparison at realistic scale
Let’s price three workloads to make the differences concrete.
Workload 1: Application uploads, 1 TB total, lightly accessed
| Service | Monthly cost |
|---|---|
| S3 Standard | ~$23 |
| S3 Intelligent-Tiering (after ~30 days of inactivity) | ~$13 |
| EFS Standard | ~$307 |
| FSx for ONTAP | ~$70 + throughput |
Winner: S3. Not close.
Workload 2: Shared CI build cache, 200 GB, accessed by 30 build agents
| Service | Monthly cost |
|---|---|
| S3 Standard | ~$5 + ~$30 in PUT/GET costs |
| EFS Standard (Elastic) | ~$60 + ~$20 throughput |
| EFS Standard with Bursting | ~$60 |
Winner: EFS — because the agents need POSIX semantics and shared writes. S3 looks cheaper until you realise you’d have to redesign the build system to use it.
Workload 3: 10 TB Windows file share for a corporate fleet
| Service | Monthly cost |
|---|---|
| S3 + a third-party SMB gateway | ~$230 + gateway + DIY ops cost |
| EFS | Doesn’t speak SMB |
| FSx for Windows (SSD) | ~$1,300 |
| FSx for Windows (HDD) | ~$250 |
Winner: FSx for Windows (HDD), comfortably. This is the workload FSx was built for.
A simple decision framework
- Does your application talk to storage via HTTP / SDK / URL? → S3.
- Does your application expect a Linux filesystem, shared between multiple clients? → EFS.
- Do you need Windows file shares, Active Directory, or SMB? → FSx for Windows.
- Do you need HPC-grade parallel throughput for ML/scientific compute? → FSx for Lustre.
- Are you migrating from on-prem NetApp and need snapshots, multi-protocol, or dedup? → FSx for ONTAP.
- Single EC2 instance needs a local disk? → EBS, not any of the above.
If you find yourself reaching for EFS or FSx because S3 “feels too restrictive”, pause. The restriction is usually intentional, and S3 will be 5-30x cheaper for the same data.
The most expensive mistake to watch for
The single most common storage mistake in AWS is using EFS for what should be S3 — typically because a team reached for it as “default file storage” without checking the per-GB price. It is entirely possible to have a multi-TB EFS filesystem holding effectively cold data, billing thousands of dollars a month, where the same data on S3 Intelligent-Tiering would cost a fraction of that.
If your AWS bill has an EFS line item bigger than your EC2 line item, that is almost always a signal worth investigating.
If you’d like a second pair of eyes on your storage mix to identify which line items are in the wrong service for the workload, get in touch. Storage is one of the easiest places to find meaningful savings without any application changes — just by putting data in the service it should have lived in from the start.