☁️ Day 8: Cloud Storage — Where Does Our Data Actually Live?
Learn how AWS S3, EBS, and EFS store application data in the cloud. Understand object, block, and file storage through a simple real-world college portal architecture.
Series: Cloud Computing (24 articles)
- …
- 9☁️ Day 8: Cloud Storage — Where Does Our Data Actually Live? This article
☁️ Day 8/30: Cloud Storage — Where Does Our Data Actually Live?
From running our application to storing what our application creates
Yesterday, we opened the server box.
We discovered that the application running in the cloud can use a virtual machine, and we learned how virtualization allows physical infrastructure to support multiple virtual environments.
But there's one question we left unanswered:
If our application is running on a virtual machine, where does all its data go?
Think about our college examination portal.
Students are uploading:
- 📄 Identity documents
- 📝 Assignment files
- 🖼️ Profile pictures
- 📚 Study materials
- 📋 Examination forms
The application needs to store all of this somewhere.
And suddenly, our simple architecture needs another component.
💾 Our Application Needs a Place to Store Things
So far, our architecture looked something like this:
1
2
3
4
5
6
7
8
9
👩🎓 Students
↓
⚖️ Load Balancer
↙ ↘
↓ ↓
EC2 VM EC2 VM
\ /
\ /
🗄️ Database
But where do the uploaded files go?
We could try putting everything directly inside the application server.
That might work for a small experiment.
But what happens when:
- the server is replaced?
- the application grows?
- multiple servers need access to the same files?
- thousands of documents need to be stored?
- we need backups?
Now we have a new architectural question:
Should our application's compute and storage be tightly tied together?
This is where cloud storage becomes important.
🧠 Think About Your Laptop
Before jumping into AWS, think about your own computer.
You have different types of data:
1
2
3
4
5
6
7
💻 Your Computer
│
├── 📸 Photos
├── 🎬 Videos
├── 📄 Documents
├── 🎵 Music
└── ⚙️ Application Files
Different types of data can require different ways of storing and accessing them.
Cloud computing works in a similar way.
There isn't just one universal type of cloud storage.
Different storage technologies are designed for different jobs.
Today, we'll focus on three important ideas:
🟦 Object Storage
🟩 Block Storage
🟨 File Storage
Once you understand the difference, many cloud architecture diagrams will start making much more sense.
🟦 1. Object Storage — Store Files as Objects
Imagine our college portal needs to store student documents.
For example:
1
2
3
4
5
student_101.jpg
student_101.pdf
student_102.jpg
exam_form_2026.pdf
notes_database_systems.pdf
These are individual files.
This is where object storage becomes useful.
In AWS, the most well-known object storage service is Amazon S3.
Amazon S3 stores data as objects inside buckets. An object consists of the stored data and associated metadata, while the bucket acts as the container for those objects.
Think of it like a huge digital warehouse.
1
2
3
4
5
6
🏢 S3 BUCKET
│
┌──────────┼──────────┐
↓ ↓ ↓
📄 PDF 🖼️ Image 🎬 Video
Object Object Object
Instead of thinking:
"Which physical disk contains this file?"
you interact with the storage service through its interface.
🪣 What Is an S3 Bucket?
A bucket is a container for objects in Amazon S3.
Imagine you have a physical storage room.
1
2
3
4
5
6
🏢 STORAGE ROOM
│
┌───────┼────────┐
↓ ↓ ↓
📄 🖼️ 🎬
File Image Video
The storage room is like the bucket.
The files inside it are the objects.
In S3:
1
2
3
4
5
6
Bucket
│
├── student101.pdf
├── student102.pdf
├── profile.jpg
└── notes.pdf
AWS describes an S3 object as the file/data plus metadata, with each object identified by a key within its bucket.
🔑 What Is an Object Key?
Here's a small detail that becomes useful when working with S3.
An object has a key, which acts as its unique name within a bucket.
For example:
1
student-documents/2026/student101.pdf
The key can look like a folder path.
But technically, S3 general purpose buckets use a flat object structure rather than a traditional hierarchical file system. The apparent folders you see in the console are based on common key prefixes.
You don't need to worry about that distinction yet.
For now, remember:
Bucket = containerObject = stored dataKey = object's name/identifier
🟩 2. Block Storage — When Your Server Needs a Disk
Now let's change the situation.
Our EC2 instance needs a disk to:
- Install an operating system
- Store application files
- Run a database
- Read and write data frequently
Object storage isn't always the right abstraction for this.
We may need something that behaves much more like a hard drive attached to a computer.
That's where block storage comes in.
In AWS, Amazon Elastic Block Store (Amazon EBS) provides block storage volumes that can be attached to EC2 instances. Once attached, an EBS volume can be used much like a physical disk.
Think about your laptop.
1
2
3
💻 Computer
│
└── 💾 Hard Drive
Now think:
1
2
3
☁️ EC2 Instance
│
└── 💾 EBS Volume
That's the basic idea.
🧩 Object Storage vs Block Storage
Let's make this visual.
Object Storage
1
2
3
4
5
☁️ S3
│
┌───────┼───────┐
↓ ↓ ↓
PDF Image Video
Good for storing individual objects such as files and media.
Block Storage
1
2
3
4
5
6
🖥️ EC2
│
↓
💾 EBS
│
Acts like a disk
Useful when an application needs block-level storage attached to compute.
AWS identifies Amazon S3 as object storage and Amazon EBS as block storage for EC2 workloads.
🟨 3. File Storage — When Multiple Systems Need Files
Now imagine something different.
Our college portal has several application servers.
All of them need access to the same collection of files.
1
2
3
4
5
6
7
🖥️ App Server 1
│
↓
📁 Shared Files
↑
│
🖥️ App Server 2
This is where file storage can be useful.
AWS provides Amazon EFS (Elastic File System) as a scalable file storage service for Amazon EC2 and other workloads.
The mental model is similar to a shared network drive:
1
2
3
4
5
6
7
🖥️ Server 1
↘
↘
📁 Shared File System
↗
↗
🖥️ Server 2
Multiple systems can work with files through the shared file system, depending on the architecture and access configuration.
🧠 Three Storage Models — One Simple Analogy
Imagine our college has three different storage requirements.
📸 Requirement 1: Student Photos
Thousands of images need to be stored.
Think: Object Storage
1
2
3
Student Photos
↓
☁️ S3
💻 Requirement 2: EC2 Server Disk
Our application server needs a disk.
Think: Block Storage
1
2
3
EC2
↓
💾 EBS
📁 Requirement 3: Shared Files
Multiple servers need access to the same files.
Think: File Storage
1
2
3
Server 1 ──┐
├── 📁 Shared File System
Server 2 ──┘
So:
Object → Files as objectsBlock → Disk-like storageFile → Shared file system
That's the mental model to remember.
🏗️ Let's Upgrade Our College Portal
Now our architecture is becoming more realistic.
Previously:
1
2
3
4
5
6
7
8
👩🎓 Students
↓
⚖️ Load Balancer
↙ ↘
EC2 VM EC2 VM
\ /
\ /
🗄️ Database
But students are uploading documents.
So let's add storage:
1
2
3
4
5
6
7
8
9
10
👩🎓 Students
↓
⚖️ Load Balancer
↙ ↘
EC2 VM EC2 VM
│ │
└─────┬──────┘
↓
☁️ S3
Student Documents
Now we have separated two different responsibilities:
EC2
Runs the application.
S3
Stores the uploaded objects.
This separation is powerful.
Your application can process the files without making the application server itself the permanent home of every uploaded document.
🔄 Why Separate Compute and Storage?
Remember Day 7?
We learned that virtual machines provide computing environments.
Now imagine we stored all our important files directly on one VM.
1
2
3
4
5
🖥️ EC2
│
┌────┴─────┐
↓ ↓
Application Files
What happens if we replace that VM?
Now we have a problem if the files were stored only on that instance's temporary storage.
Instead:
1
2
3
4
5
6
7
8
9
🖥️ EC2
│
↓
Runs Application
☁️ S3
│
↓
Stores Objects
Now compute and object storage have separate roles.
This is one of the important architectural patterns you'll keep seeing in cloud systems.
⚠️ But Not All Storage Is the Same
Here's an important lesson:
"Cloud storage" doesn't mean one service that solves every storage problem.
The right choice depends on what the application needs.
Ask:
What am I storing?
A photo?
A database?
A log file?
A virtual machine's disk?
A shared file?
How will I access it?
As an object?
Like a disk?
Through a shared file system?
What performance do I need?
Fast random reads and writes?
Large file transfers?
Shared access?
How important is the data?
Do I need versioning?
Backups?
Encryption?
Retention policies?
These questions are what turn storage selection into an architecture decision.
🧠 Think Like a Cloud Architect
Let's test your thinking.
Our college portal has three requirements:
Requirement A
Students upload profile pictures.
Requirement B
Our EC2 instance needs a disk for its operating system and application.
Requirement C
Multiple application servers need access to a shared file system.
Which storage model would you consider?
| Requirement | Storage model |
|---|---|
| Student profile pictures | 🟦 Object storage |
| EC2 disk | 🟩 Block storage |
| Shared files | 🟨 File storage |
The important thing isn't memorizing three AWS service names.
It's understanding why the storage model changes depending on the workload.
🎯 Interactive Challenge
🤔 Where Would You Store It?
You're designing our college portal.
Where would you place each item?
1. A student's profile picture
A. Object storage
B. Block storage
C. Virtual machine memory
B. Block storage
C. Virtual machine memory
2. The disk used by an EC2 instance
A. Object storage
B. Block storage
C. CDN
B. Block storage
C. CDN
3. A shared directory that multiple application servers need to access
A. File storage
B. Object storage only
C. Load balancer
B. Object storage only
C. Load balancer
Think before revealing the answers...
Answers:
1 → A: Object storage
A profile picture is a file/object that can be stored in Amazon S3.
2 → B: Block storage
An EBS volume can provide disk-like block storage for an EC2 instance.
3 → A: File storage
A shared file system such as Amazon EFS can be used when multiple systems need file-based access.
🏗️ Your Turn: Fix the Architecture
Here's today's challenge.
Our application currently looks like this:
1
2
3
4
5
6
7
8
9
👩🎓 Students
↓
⚖️ Load Balancer
↙ ↘
↓ ↓
EC2 VM EC2 VM
\ /
\ /
🗄️ Database
Students now need to upload:
- 📸 Profile pictures
- 📄 Identity documents
- 📝 Assignment PDFs
Your task:
Where would you add storage?
Draw your own architecture.
💡 Hint
Ask yourself:
Are these files part of the application's compute environment, or are they objects that the application needs to store and retrieve?
Then think about which storage model fits best.
🖼️ Visual Concept for Today's Article
Image: "Three Ways to Store Data in the Cloud"
Create one clean visual divided into three sections:
🟦 Object Storage
1
2
3
4
5
Application
↓
S3 Bucket
↙ ↓ ↘
📸 📄 🎬
Label:
Best mental model: Digital warehouse
🟩 Block Storage
1
2
3
4
5
EC2
↓
EBS Volume
↓
💾 Disk-like storage
Label:
Best mental model: Hard drive
🟨 File Storage
1
2
3
4
5
Server 1 ──┐
↓
Shared Files
↑
Server 2 ──┘
Label:
Best mental model: Shared network drive
At the bottom, show:
Object → Block → File
This visual should teach the difference in a few seconds without requiring a long explanation.
🔎 One More Question...
We've now solved an important problem.
Our application can run on EC2.
Our files can live in storage services.
But there's another kind of data our application needs to manage.
Think about our college portal.
Where do we store:
- Student names?
- Registration numbers?
- Exam subjects?
- Login information?
- Exam results?
Putting all of this into ordinary files wouldn't be the best approach.
We need something designed to organize, query, and manage structured application data.
And that's our next architectural layer.
💡 What I Learned Today
Yesterday, we learned how virtual machines provide the computing environment for our applications.
Today, we added another important layer:
Storage.
We learned that cloud storage isn't one single thing.
- 🟦 Object storage → store objects such as images, documents, and videos.
- 🟩 Block storage → provide disk-like storage for compute workloads.
- 🟨 File storage → provide shared file-system access for workloads that need it.
And we learned an important architectural principle:
Compute runs the application. Storage keeps the data.
Separating these responsibilities can make an architecture more flexible and easier to design for different workloads.
☁️ Day 8/30 — Cloud Computing & Cloud Architecture Challenge
Let's look at how far our architecture has come.
Day 5
Where does our application live?
Day 6
How can we design it to handle failures?
Day 7
What actually runs our application?
Day 8
Where does the application's data live?
Our architecture is starting to look much more like a real cloud system:
1
2
3
4
5
6
7
8
9
10
11
12
13
👩🎓 Users
↓
⚖️ Load Balancer
↙ ↘
↓ ↓
EC2 VM EC2 VM
│ │
└─────┬──────┘
↓
☁️ S3 Storage
│
│
🗄️ Database
But there's still one major question.
If S3 stores our files, where do we store the actual application data—students, registrations, results, and transactions?
That's where our next layer begins.
🚀 Day 9: Cloud Databases — Where Does Our Application Data Live?
Because storing a file is one problem...
But storing and querying millions of records is a completely different problem.
Series: Cloud Computing (24 articles)
- …
- 9☁️ Day 8: Cloud Storage — Where Does Our Data Actually Live? This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article