AWS Storage Services: How Do You Choose Between S3, EBS, EFS, Snow Family, FSx, and Storage Gateway?

AWS has a long list of storage-related services: S3, EBS, EFS, FSx, Storage Gateway, and even an entire Snow Family. If you're new to this, you've probably wondered: it's just storing files, why does AWS need this many services?

The truth is, these services answer completely different questions: what shape should your data take (a whole disk, a shared folder, or individual objects), who gets to use it (one machine, many machines, or an on-prem data center), and what do you do when there's so much data that the network simply can't move it fast enough. This post starts by laying out the three basic storage models, then walks through EBS, EFS, S3, FSx, Storage Gateway, and Snow Family — and the specific problem each one solves.

First, the Three Storage Models: Block, File, and Object

Before we get into service names, we need to nail down the three "shapes" data can take — every service below is built around one of them.

Block storage slices data into fixed-size chunks, and the operating system keeps track of what's in each block — it behaves just like a physical hard drive. It's fast to read and write, and you can format it with any file system, but it's typically mountable to only one machine at a time.

File storage is the folder-hierarchy structure we're all familiar with. Multiple machines can mount the same location over a network protocol (like NFS) and read and write the same files simultaneously — think of it as a shared network drive for the whole office.

Object storage drops the folder hierarchy entirely. Each piece of data is an independent object with its own unique identifier (a key) and metadata, all dropped into a flat storage space (a bucket) and accessed over HTTP APIs instead of being mounted by the OS. It has virtually no capacity limit, which makes it the best fit for large volumes of unstructured data.

Keep these three shapes in mind — once you see EBS, EFS, and S3 below, you won't just be memorizing names, you'll know which model each one maps to.

EBS: Like a USB Drive, Tied to One Machine

EBS (Elastic Block Store) is AWS's implementation of block storage. Think of it as a networked hard drive — once you attach it to an EC2 instance, the OS sees an ordinary disk that you can format, partition, and even boot from.

The key limitation: an EBS volume can typically only be attached to one EC2 instance at a time (a few volume types support multi-attach, but that's the exception, not the rule). That makes it a fit for database data files, OS boot volumes — anything that's meant to live on one specific machine. The upside is low, stable read/write latency, and even if the attached EC2 instance gets terminated, the EBS volume's data survives and can be reattached to a different machine later.

# Create an EBS volume and attach it to a given EC2 instance
aws ec2 create-volume --availability-zone us-east-1a --size 100 --volume-type gp3
aws ec2 attach-volume --volume-id vol-0123456789abcdef0 \
  --instance-id i-0123456789abcdef0 --device /dev/sdf

But being tied to a single machine hits a wall fast: if multiple machines need to access the same files at once — say, a fleet of web servers sharing user-uploaded images — EBS just doesn't cut it.

EFS: A Shared Folder for Multiple Machines

EFS (Elastic File System) exists to solve exactly that problem. It's a file system you mount over NFS, and multiple EC2 instances — even across Availability Zones — can mount and read/write it at the same time, like an entire data center sharing one network drive.

Unlike EBS, you never have to decide on a capacity upfront — it grows automatically as you write more data, and you only pay for what you actually use. That's where the "Elastic" in the name comes from. It's a good fit for CMS assets shared across multiple servers, or config files and user uploads shared across pods in a container cluster.

That said, EFS's access latency is inherently higher than EBS's — it's going over a network protocol, after all — so it's not the right choice for database files or anything that needs rock-bottom latency. For those, go back to EBS.

S3: Files as Objects in a Warehouse

The two services above are still "file system" concepts — they need to be mounted to a machine to be usable. S3 (Simple Storage Service) breaks out of that framework entirely as object storage: you create a bucket, drop data into it as objects, and each object gets its own key (think of it as a path string, though the structure underneath is actually flat). You access it over HTTP APIs, the AWS SDK, or the CLI — no mounting, no formatting.

// Upload an object to an S3 bucket using the AWS SDK
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3'
 
const client = new S3Client({ region: 'us-east-1' })
await client.send(
  new PutObjectCommand({
    Bucket: 'my-app-assets',
    Key: 'images/avatar.png',
    Body: fileBuffer,
  }),
)

S3 has virtually no capacity limit, and its durability is rated at 99.999999999% (eleven 9s). It's great for static site assets, backups, logs, or a data lake built from massive amounts of unstructured data. It's not meant to replace EBS or EFS, though — S3 has no real file locking and no millisecond-level read/write latency, so it's a bad fit as a database or a real-time working directory for an application. But for "write once, read many times" data, it's basically the default answer in every AWS architecture.

S3 also isn't a single pricing model — within the same bucket, you can put objects into different storage classes based on how often they're accessed. S3 Standard is the default, with the lowest read/write latency, and it's meant for data accessed regularly. If data just sits there and rarely gets read, you can switch to S3 Standard-IA (Infrequent Access) to cut storage costs, though you'll pay extra whenever you do read it. For data that's even colder — barely ever read but can't be deleted, like records you're required to retain for compliance — S3 Glacier is the right tier: storage costs are lowest, but retrieving data takes anywhere from a few minutes to several hours. And if you're not sure how access patterns will change over time, S3 Intelligent-Tiering will automatically move objects between tiers based on actual usage, saving you the trouble of tracking it manually. All of these tiers are fundamentally still S3 — the only difference is how long an object goes unread before it shifts to a cheaper, slower tier.

FSx: The "Native" File System Your Application Insists On

EFS is great, but it's AWS's own implementation of an NFS file system. If your application was built for Windows and needs SMB and Active Directory integration, or if you're running high-performance computing workloads that need a parallel file system like Lustre, EFS isn't the native fit.

FSx exists for exactly this "I need a specific, off-the-shelf file system" situation. It's actually a family of services — the two most common are FSx for Windows File Server (native SMB and Windows file system compatibility) and FSx for Lustre (built for high-performance computing and ML training workloads that need extremely high throughput). Think of it as AWS managing an existing industry-standard file system for you, rather than one AWS invented itself, in exchange for compatibility with your existing systems or tooling.

Storage Gateway: Bringing Cloud Storage to On-Prem, Seamlessly

Every service so far assumes your data already lives entirely inside AWS. But most companies don't move every system to the cloud overnight — plenty of existing applications still run in on-prem data centers, and they only understand traditional file protocols or tape backup interfaces. They can't just call the S3 API directly.

Storage Gateway is exactly that bridge. It's a gateway appliance deployed on-prem (or as a virtual machine) that looks, from an on-prem application's perspective, like an ordinary file server or disk volume — but behind the scenes, it syncs data to S3 or Glacier. That lets existing systems back up and archive data to the cloud without a single code change, which is why it's often the first step companies take on a hybrid-cloud migration.

Snow Family: When the Network's Too Slow, Just Ship a Hard Drive

Everything above assumes your network bandwidth is enough to move data to the cloud. But if a company needs to migrate tens of terabytes — or even petabytes — of data, transferring it over the network could take months. At that scale, the faster option isn't the network at all; it's loading the data onto physical drives and shipping them.

That's exactly what the Snow Family is for — a lineup of rentable physical devices. Snowcone is the smallest, most portable option, good for small-scale data collection at edge locations. Snowball is the common mid-size storage device, meant for migrating data at the scale of a single data center. Snowmobile takes it to the extreme: an entire shipping container truck packed with drives, used to migrate data at the scale of an entire data center — petabytes to exabytes. The process is straightforward: AWS ships you the device, you load your data onto it, and you ship it back for AWS to import at their data center. It's essentially using real-world shipping speed to route around the physical limits of network bandwidth.

So How Do You Actually Choose?

Put these services side by side, and the decision logic really comes down to your data's shape and who needs to use it:

The core logic boils down to one sentence: first nail down your data's shape and how many consumers need it, then think about whether you need compatibility with an existing system, and only then worry about whether the network can move it. In practice, a real system usually uses several of these at once: EBS for the database, EFS for shared application assets, S3 for static assets and backups, Storage Gateway bridging whatever's still sitting on-prem, and Snow Family for the one-time historical data migration.

Wrapping Up

S3, EBS, EFS, FSx, Storage Gateway, and Snow Family aren't competing options — each one maps to a different data shape and use case. EBS is a block disk tied to a single machine, EFS is a file system shared across machines, S3 is a nearly limitless object warehouse, FSx fills the compatibility gap for existing industry-standard file systems, Storage Gateway connects on-prem systems to the cloud without friction, and Snow Family solves the moving problem with physical devices when the network just isn't enough.