RDS vs S3 vs 'Just a Server' for Data
Learn where different data should live: S3 for files, RDS for relational data, EBS for server disks, and why putting everything on one server is a bad habit.
This lesson is purely conceptual — no AWS usage required.
Picking the right data store
Where different data belongs
Files go to S3. Structured app data goes to RDS. Do not treat one EC2 server like your whole data platform.
S3: where files belong
S3 stores objects in buckets. An object is a file plus metadata. You can store as many objects as you want, with each object up to 50 TB in size.
Use S3 for:
- Uploaded images, PDFs, videos
- Exports and backups
- Static website assets
Do not think of S3 as a relational database. S3 is great for storing files, not for SQL-style relationships like users, orders, comments, and joins.
RDS: where relational app data belongs
RDS is for relational databases such as MySQL or PostgreSQL. It handles tasks like backups, patching, monitoring, and hardware provisioning.
Use RDS for data like:
- Users, orders, products
- Lesson progress, comments
- Anything you want to query with relationships and structured rules
Tip
The clean pattern for files + metadata:
- File itself in S3 (e.g.,
profile-photo.jpg) - Metadata about the file in RDS (e.g.,
user_id,filename,uploaded_at,s3_key)
Do not put big uploaded files directly into relational tables just because "it works."
"Just a server" storage: what that really means
When people say "I'll just save it on the server," they usually mean storage attached to EC2. But there are two important kinds:
EBS (persistent)
EBS is persistent block storage for EC2. An EBS volume persists independently from the associated instance, and snapshots are stored in S3.
Good for: server boot disks, application installs, persistent files needed by one server.
Instance store (temporary)
Instance store is temporary local storage physically attached to the host. It is ideal for temporary data such as buffers, caches, and scratch data.
Warning
Instance store data is temporary. Do not rely on it for valuable long-term data. If the instance stops or terminates, the data is gone.
Why "everything on one server" is a weak pattern
If you put your uploaded files, your app database, and your app itself all on one EC2 instance, you create a fragile setup:
- Harder scaling — your whole system is tied to one machine
- Harder durability thinking — local server choices are not the same as purpose-built storage or managed databases
- Harder operations — you must manage more yourself instead of using managed services
A better architecture pattern
- EC2 or Lambda runs your application
- S3 stores files
- RDS stores relational application data
- CloudWatch helps you watch logs and metrics
Each service does one main job well.
Quick comparison
Micro-activity 1: Sort the data
Micro-activity 2: Fix the bad design
Micro-activity: Fix the bad design
Fragile design
- One EC2 instance handling everything
- Uploaded images saved directly on the server disk
- User records stored in flat files on the same disk
- No separate storage for files
- No managed database
Summary
S3 is for objects and files, RDS is for managed relational databases, EBS is persistent block storage attached to EC2, and instance store is temporary local block storage. These are different jobs.
The best habit is:
- Files in S3
- Structured relational records in RDS
- Server disks used only for server needs, not as the entire long-term data strategy