Why Does AWS Have So Many Storage Services?
AWS offers S3, EBS, EFS, and several other storage services—but why are there so many, and when should you use each one? This article explains the fundamental differences between object, block, and file storage using practical application examples, helping developers choose the right AWS storage service based on how their applications access data.
Why Does AWS Have So Many Storage Services?
When I first started learning AWS, one thing that confused me was the number of storage services.
S3.
EBS.
EFS.
S3 Glacier.
FSx.
At first, they all seemed to answer the same question:
"Where do I store my data?"
But they don't.
The important lesson is that storage is not one problem.
An application might need to store an image, provide a disk to a virtual machine, share files between multiple servers, or archive data that probably won't be accessed for years.
Those requirements are fundamentally different.
This article breaks down three of the most important AWS storage services—Amazon S3, Amazon EBS, and Amazon EFS—and explains how to think about choosing between them.
The Simple Mental Model
Before looking at individual services, remember this:
1
2
3
4
5
6
7
8
9
10
11
AWS STORAGE
|
+-------------+-------------+
| | |
v v v
S3 EBS EFS
| | |
Objects Block Disk File System
| | |
Files, images, EC2 Shared files
videos, backups storage across servers
The biggest difference is how your application interacts with the storage.
- S3 → You store and retrieve objects.
- EBS → You attach a block-storage volume to a compute instance.
- EFS → Multiple compute resources can access a shared file system.
Once you understand that distinction, AWS storage becomes much less confusing.
1. Amazon S3: Store Objects
Let's start with the service most developers encounter first:
Amazon S3 — Simple Storage Service.
S3 is object storage.
Instead of thinking about a traditional disk with folders and files, think about:
1
2
3
4
5
6
Bucket
|
+── profile-picture.jpg
+── resume.pdf
+── video.mp4
+── backup.zip
Your application stores objects in an S3 bucket and retrieves them when needed.
For example, imagine a social media application.
A user uploads:
1
profile.jpg
Instead of storing the image directly inside your application's server, you can upload it to S3.
Your database might store information such as:
1
2
user_id
image_url
while S3 stores the actual image.
The architecture becomes:
1
2
3
4
5
6
7
8
9
10
User
|
v
Your Application
|
v
S3
|
v
profile-picture.jpg
What makes S3 different?
S3 is designed around objects, not a traditional operating-system file system.
An object generally consists of:
- The data
- A key
- Metadata
For example:
1
2
3
4
5
Key:
users/104/profile.jpg
Data:
<image bytes>
Your application doesn't need to mount S3 as the operating system's normal disk to use it.
It interacts with S3 through APIs.
2. When Should You Use S3?
S3 is a natural choice for data such as:
- Images
- Videos
- Documents
- Backups
- Logs
- Data sets
- Static website assets
- Application exports
For example:
1
2
3
4
5
6
7
8
9
E-commerce application
Product:
ID: 501
Name: Laptop
Price: $900
Image:
Stored in S3
The database stores structured information about the product.
S3 stores the large binary object.
This separation is useful because a database doesn't need to become a giant image-storage system.
3. S3 Is Not Your EC2 Hard Drive
This is one of the first distinctions worth remembering.
Suppose you create an EC2 instance.
You might think:
"I'll just put all my application files into S3 and use it like my server's normal hard drive."
That's not what S3 is primarily designed for.
If your application expects a normal filesystem such as:
1
2
3
4
/app
/logs
/uploads
/config
with normal file operations like:
1
2
3
open()
read()
write()
then object storage isn't equivalent to a local disk.
S3 is accessed through an API-oriented object model.
That's where EBS becomes important.
4. Amazon EBS: A Disk for Your EC2 Instance
Amazon Elastic Block Store (EBS) provides block storage volumes that can be attached to EC2 instances.
The easiest mental model is:
EBS is like a virtual hard drive for your EC2 server.
Imagine an EC2 instance:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
EC2 Instance
+-------------+
| |
| Linux OS |
| |
+------+------+
|
|
EBS Volume
+-------------+
| |
| Application |
| Files |
+-------------+
The operating system sees the attached storage as a block device.
You can then create a filesystem on it and mount it.
For example:
1
/dev/xvdf
could be mounted as:
1
/data
Your application can then interact with it like normal filesystem storage.
5. Why Would an EC2 Instance Need EBS?
Think about what happens when you launch an EC2 instance.
The operating system needs somewhere to live.
Applications need disk space.
Logs need somewhere to be written.
Databases may need persistent block storage.
This is where EBS fits.
For example:
1
2
3
4
5
6
7
8
9
EC2
|
+── Operating System
|
+── Application
|
+── Logs
|
+── EBS Volume
EBS is therefore closely associated with compute instances.
It provides block-level storage rather than object storage.
6. EBS vs S3
Now the difference becomes clearer.
Imagine you have a PDF file.
You could store it as an object in S3:
1
2
3
S3
|
└── documents/report.pdf
That's a natural S3 use case.
But imagine your Linux server needs a persistent disk mounted at:
1
/data
That's an EBS-type requirement.
So:
1
2
3
4
5
S3
→ "Store and retrieve this object."
EBS
→ "Give this compute instance persistent block storage."
They're both storage, but they're solving different problems.
7. Amazon EFS: Shared File Storage
Now imagine something different.
You have multiple EC2 instances:
1
2
3
4
5
6
7
8
9
10
11
Load Balancer
|
+-------+-------+
| | |
v v v
EC2 EC2 EC2
| | |
+-------+-------+
|
v
EFS
All three servers need access to the same files.
This is where Amazon Elastic File System (EFS) becomes useful.
EFS provides a managed file system that can be accessed by multiple compute resources.
Think:
EFS is a shared filesystem.
8. Why Not Just Use EBS?
You might ask:
"If EBS gives me a disk, why can't I just attach the same disk to every EC2 instance?"
This is where the storage model matters.
EBS volumes are designed primarily for block storage attached to compute resources, while EFS provides a shared file-system model.
Consider an application where several servers need access to the same uploaded files:
1
2
3
4
5
6
7
8
9
Application
|
+-----------+-----------+
| | |
EC2 EC2 EC2
| | |
+-----------+-----------+
|
EFS
If a file is written to the shared filesystem, other instances can access it through the filesystem.
This can be useful for workloads that genuinely require shared file access.
9. The Three Services Side by Side
Here's the mental model I use:
| Service | Storage model | Think of it as | Typical use |
|---|---|---|---|
| S3 | Object | Cloud object store | Images, videos, backups |
| EBS | Block | Virtual hard drive | EC2 disks, databases |
| EFS | File | Shared network filesystem | Shared files across compute |
The key isn't memorizing the table.
The key is recognizing the storage access pattern.
10. Let's Design a Real Application
Suppose we're building an e-commerce application.
We need to store:
- Product information
- Product images
- Application files
- Server operating-system data
- Shared files between application servers
- Backups
Should we put everything in one storage service?
No.
We can choose storage based on the requirement.
Product information
Use a database.
1
2
3
4
5
6
PostgreSQL
|
+── product_id
+── name
+── price
+── inventory
Product images
Use S3.
1
2
3
4
5
S3
|
+── products/
+── laptop.jpg
+── phone.jpg
EC2 operating system and local application storage
Use EBS.
1
2
3
4
5
6
7
EC2
|
+── EBS
|
+── OS
+── application
+── local data
Shared filesystem
If multiple application servers genuinely require shared filesystem access:
1
2
3
EC2 ─┐
EC2 ─┼── EFS
EC2 ─┘
The architecture becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Internet
|
v
Application
|
+------------+------------+
| | |
v v v
Database S3 EFS
| |
Structured Shared
data files
|
v
EC2
|
EBS
Different storage services can coexist in the same application because they solve different problems.
11. What About S3 Glacier?
There is another important storage category:
archival storage.
Imagine a company has millions of old documents.
Most of them might never be accessed again.
Keeping frequently accessed data in the same storage tier doesn't always make sense.
Amazon S3 provides storage classes designed for different access patterns, including archival options such as S3 Glacier.
The idea is simple:
1
2
3
4
5
6
7
8
9
10
Frequently accessed
|
v
Faster access
|
|
Rarely accessed
|
v
Archive storage
The important concept isn't simply:
"Glacier is cheaper."
The real question is:
How frequently will I need this data, and what retrieval characteristics do I need?
Storage decisions involve both cost and access requirements.
12. Storage Is an Architecture Decision
This is where AWS storage becomes more interesting.
Choosing storage isn't simply:
"Which service stores files?"
Instead, ask:
1. What type of data am I storing?
Is it:
- An object?
- A filesystem?
- Block data?
- An archive?
2. How will the application access it?
Will the application:
- Use an API?
- Mount a filesystem?
- Attach a disk?
- Retrieve data occasionally?
3. Who needs access?
One server?
Multiple servers?
Thousands of users?
4. How frequently is the data accessed?
Constantly?
Occasionally?
Almost never?
5. What are the durability and availability requirements?
Can the data be recreated?
Or would losing it be catastrophic?
These questions are more valuable than memorizing AWS service names.
13. A Simple Decision Tree
When choosing between S3, EBS, and EFS, start here:
1
2
3
4
5
6
7
8
What do I need?
|
+------------+------------+
| | |
Object? Disk for EC2? Shared
| | filesystem?
v v v
S3 EBS EFS
Then ask about the access pattern.
For example:
1
2
3
4
User uploads a video
|
v
S3
1
2
3
4
EC2 needs a persistent disk
|
v
EBS
1
2
3
4
Multiple servers need the same filesystem
|
v
EFS
That's the mental model worth remembering.
14. A Common Beginner Mistake
One of the easiest mistakes when learning AWS is trying to force everything into one service.
For example:
"S3 stores files, so I'll store everything in S3."
Or:
"EC2 has a disk, so I'll store all application uploads on the EC2 disk."
Neither approach is automatically correct.
Cloud architecture is about matching the tool to the access pattern.
A user-uploaded image, an operating-system disk, and a shared filesystem may all contain "files," but they have completely different requirements.
15. What I Would Choose
For a typical modern web application, a reasonable starting point might look like:
1
2
3
4
5
6
7
8
9
Web Application
|
+------------+------------+
| | |
v v v
PostgreSQL S3 EBS
| | |
Structured Images EC2 disk
data /videos
If the application later requires shared filesystem access:
1
2
3
4
5
6
Multiple EC2s
/ | \
/ | \
+--------+--------+
|
EFS
And if large amounts of old data need archival storage:
1
2
3
4
S3
|
v
Archive tier
The architecture evolves according to the application's requirements.
16. The Bigger Lesson
AWS has many storage services because storage isn't a single problem.
There is a major difference between:
1
"Store this object."
and:
1
"Give this server a disk."
and:
1
"Give these servers access to the same filesystem."
Those three requirements lead naturally toward:
1
2
3
S3
EBS
EFS
Once you stop thinking of them as "three places to save files" and start thinking about how applications access data, the AWS storage ecosystem becomes much easier to understand.
Final Takeaway
You don't need to memorize every AWS storage service.
Instead, remember the fundamental models:
1
2
3
4
5
6
7
8
9
10
11
S3
→ Object storage
→ Think: "Store this object."
EBS
→ Block storage
→ Think: "Give this server a disk."
EFS
→ File storage
→ Think: "Give multiple servers a shared filesystem."
And when you encounter another AWS storage service, don't immediately ask:
"What does this service do?"
Ask:
"What storage problem was AWS trying to solve with this service?"
That question will take you much further than memorizing a list of AWS product names.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article