Amazon S3 or Dropbox for file storage and sharing?

Mac
1

I’m trying to choose between Amazon S3 and Dropbox for storing and sharing project files with my small remote team. I need something reliable, cost‑effective, and easy to manage permissions for clients and collaborators. Can anyone share real‑world experiences, pros and cons, and which you’d pick for long‑term use?

2

So I’ve bounced between Amazon S3 and Dropbox for years, and they’re really not interchangeable once you’ve actually lived with both.

What they actually are

Amazon S3 is basically a giant bucket of “objects” that you poke through APIs or command-line tools.
Think: infrastructure, not an app.

  • Built for devs and backend stuff
  • Accessed through SDKs, API calls, CLI, or third‑party tools
  • Great for huge archives, backups, logs, media libraries
  • Pricing makes more sense at scale, especially for cold-ish data

Dropbox, on the other hand, is a sync tool pretending to be a folder:

  • You install the app, you get a folder on your computer
  • Whatever you drop in there syncs across devices
  • Nice UI, sharing links, file history, mobile apps that just work
  • Zero thinking required, which is the main appeal

If you like dragging files around and seeing them in Finder/Explorer, Dropbox feels natural.
If you like aws s3 cp ... or wiring storage into apps or services, S3 is home.

What I actually use and why

For personal stuff and shared folders with other humans, I use Dropbox.
For work-ish stuff (backups, static assets, “I never want to lose this” data), I lean on S3.

If I had to pick one for a main use case:
I’d pick S3 for long‑term storage and backups.

Reasoning:

  • I have a few terabytes of old project files, raw video, and database dumps.
  • They don’t need to sync to every device. I just need them safe, redundant, and accessible on demand.
  • S3’s pricing, lifecycle rules (like auto‑moving to cheaper storage tiers), and reliability fit that better.

If your goal is “replace an external drive and have auto‑sync across laptop/phone/tablet,” then Dropbox wins.
If your goal is “cheap-ish, durable storage for a stupid amount of data that I mostly don’t touch,” then S3 wins.

The annoying part: day‑to‑day access

Here’s the catch: actually using S3 like a regular drive is awkward.
By default you’re dealing with:

  • Web console that’s clunky for lots of files
  • CLI commands
  • Third‑party backup/sync apps

Dropbox is nicer here, but it can eat local disk space and I don’t want every old archive mirrored to my SSD.

That’s where I ended up using CloudMounter as kind of a middle layer.

Link for context:

How I’ve wired it up

On my Mac, I use CloudMounter to mount both:

  • An S3 bucket
  • My Dropbox account

They show up like regular drives in Finder. No syncing, no duplicate local copies unless I explicitly copy something over.

What this changed for S3:

Before:

  • If I wanted to grab an old backup, I’d open the AWS console, dig through buckets, download via the browser or CLI, then move it where I needed it.
  • Editing files directly in S3 was basically “download → edit → re‑upload.”

After:

  • I just open Finder, click the mounted S3 drive, and browse folders like a network share.
  • I can drag a huge folder from my Mac straight into S3, and it uploads in the background.
  • I can open a file directly from the S3 drive, edit it, save, and it’s stored there.

It made S3 feel less like “cloud cold storage behind an API” and more like “a giant external drive in the sky that happens to speak S3.”

For Dropbox:

  • I don’t keep everything “smart synced” locally, so I just mount via CloudMounter when I’m on a smaller SSD.
  • Handy when I’m on my work laptop and don’t want my entire personal Dropbox mirrored there, but still need occasional access to specific folders.

Why I lean S3 + CloudMounter for my main use case

For my particular workflow:

  • Low‑touch, high‑volume data
  • Occasional direct access to big archives
  • Don’t want local disk eaten by sync clients
  • Comfortable with AWS in general

S3 is the main storage, and CloudMounter is the thing that makes it not annoying.

It turns S3 from “infrastructure backend” into “clickable drive icon,” without me having to write scripts or maintain some sync daemon. Dropbox still lives on my machines, but more for:

  • Shared folders with clients and family
  • Quick file exchanges
  • Stuff I actually need on multiple devices instantly

TL;DR version

  • Need simple, user‑friendly file sync, sharing, and mobile access? Use Dropbox.
  • Need scalable, cheaper storage for lots of data, backups, or app assets? Use S3.
  • If you go the S3 route and hate dealing with the web console or CLI all the time, mounting it as a drive with something like CloudMounter makes life noticeably easier.

That combo is what finally made S3 usable for my everyday “grab this file, edit that thing” moments, instead of it just being a black hole of backups.

2 Likes
3

For a small remote team with clients in the mix, Dropbox fits your use case way better than S3 in most cases.

@​mikeappsreviewer is right that S3 is “infrastructure, not an app,” but I’d actually go a step further: unless someone on your team is already comfortable with AWS permissions, buckets, IAM policies, and access keys, S3 is going to feel like using a database when you just needed a shared Google Doc.

Where Dropbox wins for your scenario:

  • Onboarding non‑technical people
    Clients already understand “here’s a folder, here’s a link.”
    Nobody needs an AWS account, keys, or a crash course in S3 ACLs.

  • Permission management that’s actually human

    • Per‑folder sharing
    • Simple “can view / can edit”
    • Easy to revoke access for a client after a project ends
      With S3, you’re juggling bucket policies, IAM users/roles, or pre‑signed URLs. Super flexible, but also super easy to misconfigure.

  • Sync for a remote team
    Your team just installs Dropbox, works in a shared folder, done.
    With S3, you’d need a sync tool, or a custom workflow, or everyone learning CLI / third‑party apps. That’s friction you do not need on a small team.

  • File previews & history
    Native previews of docs, PDFs, images, etc.
    Version history without thinking about it.
    Yes, S3 can do versioning, but the UX is… let’s say “engineer‑flavored.”

Where S3 might make sense for you:

If any of these are true, then S3 becomes interesting:

  • You’re storing hundreds of GBs or TBs of mostly cold data like video archives, backups, raw assets that you rarely touch.
  • You have someone comfortable with AWS doing initial setup of buckets, permissions, lifecycle rules.
  • You care more about long‑term cost than usability.

S3 can be cheaper per GB at scale, especially with infrequent access storage classes and lifecycle policies moving old stuff to cheaper tiers. But you pay that back in management overhead and time.

Hybrid that actually works in practice:

Here’s where I diverge a bit from @​mikeappsreviewer’s setup:

  • Use Dropbox as your “active project workspace”

    • Shared team folders
    • Client delivery folders
    • Day‑to‑day working files

  • Use S3 only for archives

    • When a project is finished, zip the source files / raw assets
    • Upload that to S3 as a long‑term backup
    • Keep only the lightweight final deliverables in Dropbox

That way:

  • Your team and clients get a sane, friendly interface.
  • Your Dropbox space doesn’t explode over time.
  • Your S3 stays mostly write‑once‑read‑rarely, which is what it’s great for.

Making S3 less painful

If you do go the hybrid route, I’d actually second the idea of using something like CloudMounter but for a different reason than just “S3 as a drive.”

CloudMounter lets you:

  • Mount S3 as a drive in Finder / Explorer
  • Treat it like “slow external storage” for archived projects
  • Avoid syncing everything locally like Dropbox does

So you can drag finished projects to the S3 drive, know they’re backed up, and not touch AWS Console or CLI every time. It also works well if you want to mount both S3 and Dropbox in the same UI and keep your laptop SSD from being eaten alive.

Blunt recommendation for your situation:

  • If your main need is team collaboration + client sharing:
    → Start with Dropbox, full stop.

  • If later you notice “wow we’re keeping way too much old junk, this is getting expensive”:
    → Add S3 + CloudMounter purely for project archives.

Trying to run your whole collaboration workflow on S3 for a small, mixed‑tech team is like using Kubernetes to share a Word doc. It works, technically, but you’ll regret your life choices around month two.

4

Short version: for a small remote team with clients, use Dropbox first, then maybe bolt on S3 + CloudMounter later for archives.

I agree with @mikeappsreviewer and @cacadordeestrelas on the big picture, but I think they’re slightly underplaying one thing: how much process you actually want to manage.

1. Collaboration & clients

For what you described (projects, clients, collaborators):

  • Dropbox wins hard on:
    • Shared folders per client / project
    • “View / edit” style permissions
    • Non‑technical people who just click a link and are done
    • Built‑in file previews (PDFs, images, Office, Google Docs, etc.)

Trying to teach a client how to deal with S3 pre‑signed URLs or anything IAM-related is asking for pain. Even internal team members who are not devs will hate S3 as a day‑to‑day workspace.

Here’s where I slightly disagree with them: I wouldn’t immediately complicate things with S3 unless you already know you’ll be sitting on terabytes soon. Starting with S3 “just in case” often turns into overkill setup for a simple workflow.

2. Reliability & cost

Both are reliable enough that “data loss” is not your real worry.

Cost-wise:

  • Dropbox is simpler: flat-ish per-user pricing, predictable.
  • S3 is “cheap per GB” but:
    • You pay in time, setup, and mental overhead.
    • Access patterns matter for pricing.
    • You will spend time reading docs when something 403s at 2AM.

If your team is, say, under a few hundred GB for active projects, that extra complexity is not worth the marginal savings.

3. Permissions & access control

For your use case, “easy to manage permissions” is basically:

  • Can I:
    • Create a folder per client
    • Invite them
    • Remove them when we’re done
    • Not screw anything up by typo-ing a JSON policy

Dropbox does that out of the box.
S3 can do anything, but “anything” is a trap when what you really need is “don’t let Client A see Client B’s folder.”

I’d only bring S3 into the mix when you hit this point:
“We’re keeping tons of finished projects around, they’re not in active use, and Dropbox storage/pricing is starting to feel dumb.”

4. Where S3 + CloudMounter does shine

When you reach that stage, CloudMounter becomes very relevant:

  • Mount S3 as a drive in Finder / Explorer
  • Treat it like cold archive storage
  • Drag an “Archived Projects” folder into it and forget it
  • No need for every team member to learn AWS Console

So a sane phased approach:

  1. Phase 1: All Dropbox

    • Active project files
    • Team collaboration
    • Client review / delivery
    • Very minimal setup, zero training

  2. Phase 2: Add S3 + CloudMounter for archives

    • When a project is done:
      • Compress or bundle source assets
      • Move them to S3 via a CloudMounter-mounted drive
    • Keep only current and “recently finished” work in Dropbox

This keeps Dropbox fast and lightweight, keeps cost predictable, and lets you scale storage cheaply in S3 without forcing your whole team into AWS world.

5. Brutal recommendation

Given your description:

  • Primary tool:
    Use Dropbox for everything “live” with your team and clients.

  • Only if you grow into large, rarely accessed archives:
    Add Amazon S3 + CloudMounter purely as a background archive layer.

Trying to run your small remote team’s daily workflow entirely on S3 is like putting your grocery list in a database cluster. Yeah, it works. No, you will not enjoy maintaining it.