Applies toAmazon S3 (incl. S3 Express One Zone, Mountpoint for S3), Amazon EBS, Amazon EFS, Amazon FSx for Windows File Server, FSx for NetApp ONTAP, FSx for Lustre, FSx for OpenZFS
Start from the access method
| Access | Service |
|---|---|
| Object API (apps, data lakes, backups, media) | S3 |
| Block device for one instance (OS, databases) | EBS |
| Shared POSIX file system (NFS) for Linux, elastic | EFS |
| Windows SMB shares with AD integration | FSx for Windows File Server |
| Multi-protocol NAS (NFS + SMB + iSCSI), NetApp features, SnapMirror | FSx for NetApp ONTAP |
| High-performance parallel FS for HPC/ML, linked to S3 | FSx for Lustre |
| ZFS features, low-latency NFS, migrations from ZFS | FSx for OpenZFS |
Comparison
| S3 | EBS | EFS | FSx Windows | FSx ONTAP | FSx Lustre | |
|---|---|---|---|---|---|---|
| Protocol | HTTPS API | Block | NFS 4.x | SMB | NFS, SMB, iSCSI | Lustre client |
| Sharing | Any number of clients | One instance (Multi-Attach for io2 in limited cases) | Thousands of clients | Many | Many | Many |
| Scaling | Unlimited | Per volume | Elastic | Provisioned | Provisioned + tiering | Provisioned |
| AZ scope | Regional (except Express One Zone) | Single AZ | Regional or One Zone | Single or Multi-AZ | Single or Multi-AZ | Single AZ |
| Backup | Versioning, replication, AWS Backup | Snapshots, AWS Backup | AWS Backup | Backups, shadow copies | Snapshots, SnapMirror, backups | S3 link, backups |
Check region availability and performance limits for each option.
Common mappings
| Workload | Typical choice |
|---|---|
| Windows file server replacement | FSx for Windows (+ DataSync for migration) |
| Linux shared content for web servers / containers | EFS |
| EKS persistent volumes | EBS (RWO), EFS (RWX) |
| Database on EC2 | EBS gp3/io2 |
| Data lake | S3 (+ Lake Formation/Glue) |
| ML training with fast data access | FSx for Lustre linked to S3, or S3 Express One Zone |
| Lift-and-shift from NetApp on-prem | FSx for NetApp ONTAP with SnapMirror |
| Apps that need to read S3 as files | Mountpoint for S3 (read-heavy, sequential writes; not full POSIX) |
Design questions
- What protocol does the application use today, and can it change?
- How many clients, and do they write the same files concurrently?
- Peak throughput, IOPS and latency (measured, not assumed)?
- Single-AZ acceptable, or must the storage survive an AZ loss?
- Restore granularity (file, volume) and RPO/RTO?
- Identity: AD integration needed? POSIX permissions? IAM?
Traps
| Trap | Avoid by |
|---|---|
| EFS for databases or heavy small-file metadata workloads | Use EBS; test EFS throughput modes with real load |
| EBS assumed to survive AZ loss | It's single-AZ. Snapshots/replication for DR |
| Single-AZ FSx for production shares | Multi-AZ deployment where availability matters |
| Using S3 like a file system (renames, appends) | Use a file service or redesign the app |
| Lustre as long-term storage | Treat it as scratch/cache linked to S3 |
Tip
Run a pilot with real data and real client counts for a week. File storage performance depends heavily on file sizes, metadata operations and concurrency, which datasheets don't capture.
Checklist
- Access protocol and sharing model identified
- Performance measured on current system
- Service and deployment type (single/multi-AZ) chosen
- Identity, network and backup designed
- DR replication and RPO confirmed
- Pilot with real workload