S3, EBS, EFS. Three AWS storage services, similar-looking names, completely different jobs, and using the wrong one for a task is a classic beginner mistake that leads to weird architectures and surprise bills. The good news: once you understand the one thing that separates them, choosing is easy. Let me explain what each is, in plain terms, and give you a rule that picks the right one every time.
The key distinction: how the storage is accessed
The three services differ mainly in how your application talks to the storage. That single distinction drives everything else.
- EBS is a disk attached to one server.
- EFS is a shared file system many servers can mount at once.
- S3 is object storage you access over an API, not a file system at all.
Get that, and the rest follows.
EBS: a hard drive for one instance
EBS (Elastic Block Store) is a block storage volume, essentially a virtual hard drive you attach to a single EC2 instance. Your operating system sees it as a disk, formats it, and reads and writes to it like any local drive.
Key properties:
- Attached to one instance at a time (in the normal case). It is that instance's disk.
- Lives in one Availability Zone.
- This is where your OS, your databases, and anything that needs fast, low-latency block access lives.
Use EBS for: the boot volume of an EC2 instance, and storage for a database or application that runs on that instance and needs a real disk. If you are thinking "my server needs a drive," that is EBS.
EFS: a shared drive many instances can mount
EFS (Elastic File System) is a managed network file system. Unlike EBS, many instances can mount the same EFS file system at once and see the same files. It grows and shrinks automatically, and it spans Availability Zones.
Use EFS for: workloads where multiple servers need to share the same files, a fleet of web servers serving the same content, a shared home directory, a content management system across instances. If your answer to "which server owns this data" is "several of them, together," that is EFS.
The tradeoff: it is more expensive per GB than EBS and has network-file-system latency, so it is not the right home for a high-performance database. Use it for sharing, not for raw speed.
S3: object storage over an API
S3 (Simple Storage Service) is different in kind. It is not a disk and not a file system. You store objects (files plus metadata) in buckets, and you access them over an HTTP API (GetObject, PutObject), not by mounting a drive. Your app talks to S3 with SDK calls, not filesystem reads.
Key properties:
- Effectively unlimited scale, extremely durable, cheap per GB.
- Accessed over the network by API from anywhere, not tied to an instance.
- Not a filesystem, you cannot "cd into" a bucket, you request objects by key.
Use S3 for: backups, static assets (images, videos, downloads), data lakes, logs, anything you access as whole files rather than editing in place, and static website hosting. If you are storing files an application reads and writes as objects, that is S3, and it is usually the cheapest and most scalable choice.
The rule that picks the right one
Ask "who needs to access this, and how?"
- One instance needs a fast local disk (OS, database)? EBS.
- Multiple instances need to share the same files live? EFS.
- You are storing files you access as objects over an API (assets, backups, logs, data)? S3.
Nine times out of ten the answer is obvious once you frame it that way. The classic mistake is using an EBS volume or EFS for something that should be S3 (like storing uploaded images on a server's disk instead of in a bucket), which makes your app stateful, harder to scale, and more expensive.
A cost note
Rough order, cheapest to most expensive per GB: S3 (cheap, and cheaper still with lifecycle rules moving old data to colder tiers), then EBS, then EFS (the shared-filesystem convenience costs more). This is another reason to default to S3 for anything you can: it is usually both the most scalable and the cheapest. And on EBS specifically, use gp3 volumes, they are cheaper and better than the older gp2.
The take
S3, EBS, and EFS are not competitors, they are three answers to three different questions. EBS is a disk for one instance, EFS is a shared file system for many, and S3 is API-accessed object storage for files at scale. Ask who needs the data and how they access it, and the choice makes itself. Default to S3 whenever your data is really just files, it is usually the cheapest, most scalable, and least painful option.
Which storage service did you misuse first? A lot of people start by saving uploads to an instance's EBS disk, then learn the hard way why that data belonged in S3 the first time they needed a second server.
Top comments (0)