AWS Storage Decision Guide

AWS storage choices are easier when you start from the workload instead of the service name.

Ask four questions:

1. Is the data object, block, or file?
2. Does it need to be shared across instances?
3. What protocol does the application expect?
4. What are the durability, latency, and cost requirements?

Most wrong storage decisions happen because the application expects one storage semantic and the platform team chooses another for cost or habit.

S3

S3 is object storage. It is the default choice for durable, highly available, internet-scale storage.

Use S3 for static assets, backups, data lakes, logs, document storage, and event-driven processing. Add lifecycle rules when access patterns change over time. Use replication when data must exist in another region or account.

S3 is not a mounted disk. If the application expects POSIX file semantics, use EFS or FSx instead.

That sounds obvious, but it is a recurring architectural mistake: object storage is chosen because it is cheap and durable, then the team spends months rebuilding file-system behavior above it.

EBS

EBS is block storage for EC2. It behaves like a disk attached to an instance.

Use EBS for databases, boot volumes, and applications that need low-latency block access. The main limitation is attachment scope. Most EBS volumes attach to one instance in one AZ.

Snapshot to S3-backed storage for backup and copy snapshots across regions for DR patterns.

One operational gotcha is that resizing EBS at the AWS level is not the whole job. The OS often still needs partition and filesystem growth before the application sees the space.

EFS

EFS is managed NFS file storage. It is multi-AZ and can be mounted by many Linux instances at once.

Use EFS for shared Linux file systems, content directories, and workloads where multiple instances need the same files.

Watch throughput mode and performance mode. File systems with many small files and high metadata operations need careful testing.

EFS is often the right answer when the real requirement is "shared Linux file system without capacity planning." It is the wrong answer when the workload is Windows SMB or when the team is really trying to emulate a block device.

FSx

FSx is for managed file systems with specific engines, such as Windows File Server or Lustre.

Use FSx for Windows when SMB, Active Directory integration, and Windows file semantics matter. Use FSx for Lustre for high-performance compute and data processing workloads.

This is where protocol reality matters. Windows file shares point naturally toward FSx for Windows, not EFS. HPC and ML scratch workloads point toward Lustre, not a general shared file service.

Storage Gateway

Storage Gateway connects on-premises environments to AWS storage. It is useful when existing applications still use file, volume, or tape interfaces but the backend should move toward AWS.

It is not a high-performance general replacement for cloud-native storage. It is a bridge product.

That distinction matters. If the workload is fully in AWS, you usually should not be reaching for Storage Gateway at all.

DataSync vs Storage Gateway

These two services are often confused because both appear in hybrid file discussions.

Use DataSync when the job is to move or synchronize data efficiently.

Use Storage Gateway when the job is to preserve an on-premises interface while the storage backend shifts toward AWS.

Decision Summary

1. Object and cloud-native: S3.
2. Disk for EC2: EBS.
3. Shared Linux file system: EFS.
4. Windows SMB or HPC file system: FSx.
5. Hybrid legacy interface: Storage Gateway.

The wrong storage service usually shows up as operational friction: awkward mounting, bad latency, expensive transfer, or application rewrites. Choose the storage model the application actually needs.