Let's cut through the cloud storage noise. You're building a frontend on AWS, and suddenly you're faced with three storage options that sound suspiciously similar. EBS, EFS, S3 — they all store stuff, right?
Wrong. Picking the wrong one is like using a forklift to hang a picture frame. It might work, but you're going to have a bad time.
Here's the developer-friendly breakdown of which storage service to use for your frontend assets, and exactly when to use it .
The Short Answer (Because You're Busy)
Your Frontend Need Use This Why
Static files (HTML, CSS, JS, images) served to users S3 + CloudFront Built for this. Scalable, cheap, globally fast
A server's OS and application code EBS It's your virtual hard drive. Fast, low-latency
Multiple servers sharing the same content EFS Shared network drive. Perfect for web farms
S3 — The Static Asset Superhero 🦸
What it is: Object storage. Think of it as an infinite Dropbox for your files .
When to use: This should be your default choice for frontend assets. S3 is designed to store and serve static files — your HTML, CSS, JavaScript bundles, images, videos, and fonts .
Why it wins for frontend:
Virtually unlimited scale — handles traffic spikes without breaking a sweat
11 nines durability — your files aren't going anywhere (99.999999999%)
Cheap — pay for what you use
HTTP access — files are accessible via URL, perfect for web browsers
Pro tip: Pair S3 with CloudFront (AWS's CDN) for production. CloudFront caches your assets at edge locations worldwide, reducing latency and saving you S3 data transfer costs .
When NOT to use S3:
For files your EC2 instances need to read/write like a file system
For server-side code execution (it's just storage, not compute)
When you need low-latency block-level access
javascript
// Pseudo-code: Upload your frontend build
aws s3 sync ./build/ s3://my-frontend-bucket/ --delete
EBS — The Personal Hard Drive 💽
What it is: Block storage that attaches to a single EC2 instance. It's your virtual hard drive .
When to use: For the server itself, not the assets it serves. EBS is what your EC2 instance uses as its boot volume and for any data that needs fast, low-latency access .
The frontend connection:
Your EC2 server's operating system lives on an EBS volume
Your application code on the server runs from EBS
If you're running a database on EC2 (like PostgreSQL or MySQL), that lives on EBS
Why NOT for frontend assets:
Single-instance only — can't share across multiple servers
AZ-specific — tied to one Availability Zone
Overkill for serving files — you're paying for provisioned capacity whether you use it or not
Example: Your Node.js/Next.js application running on an EC2 instance uses EBS for the OS, runtime, and application code. But the static images your users download? Those should be in S3.
EFS — The Team Shared Drive 📂
What it is: A managed NFS file system that multiple EC2 instances can mount simultaneously .
When to use: When multiple servers need to access the same files at the same time .
Frontend use cases:
A web server farm where all instances need access to the same content files
Shared configuration files across microservices
Content management systems where uploaded media must be accessible from any instance
Development environments where team members share code
The EFS architecture in action: Imagine you have 5 EC2 instances behind a load balancer running the same WordPress site. They all need access to the uploaded media files. EFS lets them all mount the same file system .
Why NOT for frontend assets:
Higher cost than S3 — you pay per GB used
NFS overhead — adds latency compared to direct S3 access
Overkill if you don't need shared write access
The Real-World Architecture 🏗️
In production, you often use all three together:
text
[User Browser]
↓
[CloudFront CDN]
↓
[S3 Bucket] ← Static assets (images, CSS, JS)
|
[Application Load Balancer]
↓
[EC2 Instance #1] ←─┐
↓ │
[EBS Root Volume] │
↓ │
[Application Code] │
│
[EFS Shared Storage]←┘ ← Shared content (CMS uploads, configs)
This pattern uses:
S3 for globally accessible static assets
EBS for each server's OS and application
EFS for content shared across servers
Decision Tree 🌳
Start here:
Do users need to access these files via URL?
Yes → S3 (add CloudFront for production)
No → Go to #2
Does a single server need this as a mounted drive?
Yes → EBS
No → Go to #3
Do multiple servers need to read/write the same files?
Yes → EFS
No → You probably want S3 anyway
The Bottom Line
Stop overthinking this. For 90% of frontend asset use cases, S3 is the answer. It's what it's built for, it's what it does best, and your wallet will thank you.
Use EBS for what the server needs to run. Use EFS when you genuinely need file sharing across instances. But if you're serving files to users? S3 is your friend .
And whatever you do, don't use EBS to serve static assets. That's like using a Ferrari to deliver pizzas — technically possible, but wildly inefficient and expensive .
Top comments (0)