You're building a file upload service. 10TB of user files today. 100TB in 12 months.
Your team is having a fight.
The backend lead says: "Just use S3. Done."
The DevOps engineer says: "Mount an EBS volume. Simpler, faster."
The platform architect says: "We need EFS — multiple services need to read the same files."
The startup CTO says: "We can't afford cloud storage at scale. Self-host with MinIO."
All four have shipped this in production. All four have opinions backed by scars.
Here's the setup:
— Upload service (NestJS) receives files from mobile + web clients
— ML pipeline needs to read uploaded images for processing
— Audit service needs read access to the same files
— Files range from 5KB profile pics to 2GB video exports
— You're on AWS
What do you pick?
A) S3 — object storage, infinite scale, pay per GB, no servers to manage.
B) EBS — block storage, SSD-backed, attach to your EC2, low latency reads.
C) EFS — managed NFS, shared across multiple EC2 instances simultaneously.
D) MinIO on EC2 — S3-compatible self-hosted object storage, you own the infra.
One of these is the obvious right answer for this scenario.
One of them will destroy your architecture quietly over 6 months.
One is great — but not for this problem.
One is a trap that looks like cost savings.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
If your team has had this exact fight, share this. Someone needs to win it with data, not opinions.
Drop your answer 👇
You're building a file upload service. 10TB of user files today. 100TB in 12 months.
Your team is having a fight.
The backend lead says: "Just use S3. Done."
The DevOps engineer says: "Mount an EBS volume. Simpler, faster."
The platform architect says: "We need EFS — multiple services need to read the same files."
The startup CTO says: "We can't afford cloud storage at scale. Self-host with MinIO."
All four have shipped this in production. All four have opinions backed by scars.
Here's the setup:
— Upload service (NestJS) receives files from mobile + web clients
— ML pipeline needs to read uploaded images for processing
— Audit service needs read access to the same files
— Files range from 5KB profile pics to 2GB video exports
— You're on AWS
What do you pick?
A) S3 — object storage, infinite scale, pay per GB, no servers to manage.
B) EBS — block storage, SSD-backed, attach to your EC2, low latency reads.
C) EFS — managed NFS, shared across multiple EC2 instances simultaneously.
D) MinIO on EC2 — S3-compatible self-hosted object storage, you own the infra.
One of these is the obvious right answer for this scenario.
One of them will destroy your architecture quietly over 6 months.
One is great — but not for this problem.
One is a trap that looks like cost savings.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
If your team has had this exact fight, share this. Someone needs to win it with data, not opinions.
Drop your answer 👇
Top comments (5)
Why A wins (S3):
One storage layer. Zero capacity planning. Every service reads from the same bucket using the S3 key stored in your DB.
At 100TB → ~$2,300/month. Lifecycle policies move cold files to Glacier automatically. S3 events trigger your ML pipeline the moment a file lands. Versioning, encryption, audit logs — all built in, zero extra work.
For greenfield cloud services, this is the default. You only deviate when you have a specific reason not to.
Why B destroys your architecture quietly (EBS):
EBS is a disk. A fast, reliable disk — attached to one EC2 instance at a time.
The moment your ML pipeline runs on a different instance than your upload service, it can't read those files. Add auto-scaling? Each new instance gets a blank disk. Deploy across two AZs? Same problem.
Works perfectly in dev. Silently breaks the moment you scale horizontally. The team that picks EBS here usually discovers this 6 months later when they're doing a painful migration under pressure.
Why C is great — but not here (EFS):
EFS is genuinely powerful. Shared NFS, multiple EC2 instances mount it simultaneously, full POSIX semantics.
The problem: $0.30/GB/month. At 100TB that's $30,000/month vs S3's $2,300/month. A 13x cost difference.
EFS is the right answer when your legacy app is hardcoded to open() / read() / write() filesystem calls and can't be refactored. For a greenfield NestJS service with an S3 SDK? You're paying 13x for filesystem semantics you don't need.
Why D is a cost-savings trap (MinIO):
MinIO is a real product used at hyperscale. S3-compatible API, high throughput, runs on your own hardware.
But self-hosted means you own availability, disk failures, backups, capacity planning, and 3am incidents. At 10–100TB, the engineering cost of running MinIO reliably exceeds S3 spend by a wide margin. You're not saving money — you're converting cloud spend into engineering hours, which cost more.
MinIO makes sense at petabyte scale with dedicated infra teams and painful egress bills. Not here.
Also, it would mean a lot to me if you could support my content and stay in touch 🙏
YouTube: youtube.com/@system-design-lab
LinkedIn: linkedin.com/in/joud-awad/
Medium Blog: joudwawad.medium.com/
Substack: joudawad.substack.com/