If your SaaS product handles file uploads, profile photos, documents, exports, anything, you'll eventually run into the "where do we actually store these files" question. The answer, almost always, is Amazon S3. Here's what you actually need to understand, without the AWS documentation's usual density.
What S3 actually is, in plain terms
S3 is cloud storage for files. Think of it as an enormous, reliable filing cabinet that lives on Amazon's servers instead of yours. You put files in, called "objects," organized into "buckets," and your application fetches them back out when needed.
The reason almost every SaaS product ends up using it: storing files on your own application server is fragile, doesn't scale, and gets expensive fast. S3 is built to hold effectively unlimited files reliably, for a fraction of what running your own storage infrastructure would cost.
The concepts that actually matter for a founder
Buckets. A bucket is a named container for your files. Most products start with one or two buckets, one for user uploads, maybe one for internal backups or exports. You don't need a complicated bucket structure early on.
Object keys. This is just the file's path inside the bucket, like users/1234/profile-photo.jpg. Plan a sensible naming structure early. Retrofitting file organization after you have thousands of files is painful.
Permissions. By default, S3 buckets should be private. Files get accessed through your application, which generates temporary, secure links, not through publicly guessable URLs. This is the single most common security mistake I see: a bucket left public because it was faster to set up that way during a demo, and never locked down before launch.
Storage classes. S3 has different pricing tiers based on how often you access a file. Standard storage for files accessed regularly, cheaper "infrequent access" tiers for backups or old exports rarely touched. Most early-stage products don't need to think about this yet, but it's worth knowing it exists once your storage bill starts to matter.
A common mistake I see founders make
Storing files directly through the browser to your own server first, then re-uploading to S3 from there. This doubles your bandwidth costs and creates an unnecessary bottleneck. The better pattern is a presigned upload URL: your backend generates a temporary, secure link, and the user's browser uploads the file directly to S3, never touching your application server at all. This is a small architectural change with a real cost and performance impact.
A simple mental model for getting started
- Create one private bucket for user-generated content.
- Set up presigned URLs so uploads go directly from the browser to S3.
- Generate temporary signed URLs when your app needs to display or download a file, don't make anything public by default.
- Organize object keys with a clear, consistent structure from day one, ideally including a user or organization ID in the path.
- Don't worry about storage classes or lifecycle rules until your storage costs are actually meaningful. Optimize that later, not on day one.
Where this fits in a bigger SaaS architecture
S3 rarely stands alone. It usually pairs with a CDN in front of it for faster file delivery to users, and sits alongside your main database, which stores metadata about the files, like who uploaded them and when, rather than the files themselves. Keeping that separation clean, files in S3, metadata in your database, is a pattern worth committing to early.
The bottom line
You don't need deep cloud infrastructure expertise to use S3 correctly. You need to understand buckets, keep permissions private by default, and route uploads directly from the browser instead of through your own server. Get those three things right early, and file storage stops being something you think about until you're at a scale where it's a good problem to have.
Suggested internal links: Link to Day 1's Next.js article and Day 20's scalable SaaS architecture piece.
CTA: Setting up file storage for your product? DM "S3" for a quick checklist.