How to Give Non-Technical Users Access to S3 Files

If you run AWS at any kind of scale, you know exactly how this goes. Your buckets are full of files people actually need, but the people who need them can't get to them on their own. The Console is intimidating, IAM is a maze, and "use the CLI" is a non-starter for anyone outside engineering.

So you become the bottleneck. The DMs pile up. "Hey, can you grab that PDF from the reports bucket real quick?" Twenty times a week. Death by file request.

There are a handful of ways out. Some are worse than the problem. Let's go through them.

Option 1: Just give them the AWS Console

The lazy fix. Create an IAM user, hand over the password, point them at S3. Done.

Except it's not done, because the AWS Console is not a file portal. It's a control plane for your entire infrastructure. The S3 page alone has tabs for permissions, bucket policies, lifecycle rules, and a dozen other things that have nothing to do with downloading a PDF. One mis-click and someone's editing a bucket policy.

Even if you carefully scope the IAM policy, you've handed someone a portal that exposes the rest of your AWS environment in the side nav. And most compliance frameworks treat console access as a separate audit trail you have to maintain.

This isn't safer than the bottleneck. It's worse. Save it for technical folks who actually want console access.

Option 2: Pre-signed URLs, on demand

A step up. When someone asks for a file, you generate a pre-signed URL and paste it into Slack. The URL expires on its own, no credentials change hands.

This is fine for the occasional one-off. Where it falls apart is anything with scale or browsing. Twenty files? You're pasting twenty URLs. Need to find the right one in a folder? Can't. New files dropping in every day? Still you, every time.

And the audit trail is fuzzy. The link got clicked, but by whom? URLs forward. Once issued, you can't pull one back early either.

Option 3: Build something yourself

At some point, every team I've seen go down this path ends up here: "let's just build a little internal portal." React app, API behind it, Cognito for auth. How hard could it be?

Here's the list you don't think about until you're three weeks in:

• Auth and session handling, with token refresh that doesn't break
• An API that lists objects and signs URLs
• A frontend with folder navigation, search, and download UX
• Group-based permissions, so finance doesn't see engineering's stuff
• Audit logging that an auditor will actually accept
• Hosting, CI/CD, monitoring, all of it

For a senior dev, that's weeks of work. And then you own it. Forever. Including the 2 AM page when something breaks because a Cognito SDK update changed a default.

If you have a platform team and a real budget, sure. For the rest of us, the math doesn't work out.

Option 4: Use something built for this

The clean answer is to grab a product designed for exactly this problem. Something that drops into your AWS account, plugs into the identity provider you're already using, and gives non-technical users a simple "log in, browse, download" experience.

This is why we built BucketDrive. It deploys as a single CloudFormation stack into your account. Auth runs through Cognito, so you can connect Okta, Azure AD, or any other SAML/OIDC provider you've already set up. Admins map Cognito groups to bucket prefixes. Finance sees finance stuff, legal sees legal stuff, that's it.

The user experience is on purpose boring: log in, see your buckets, click around, download. No console, no CLI, no IAM credentials floating around. Files come through pre-signed URLs generated on the fly, so the data path stays direct from S3 to the user.

Things to actually check before you pick

Wherever you land, run through this list first.

Where does the data live? If files route through someone else's servers, that's a thing your security team has to bless. Solutions that stay inside your AWS account dodge an entire conversation.

Can you bring your own identity? If you have Okta or Azure AD already, you should be able to use them. Creating yet another login is bad UX and worse security.

How granular is the access control? "All buckets or no buckets" doesn't fly. You want bucket and prefix level, mapped to groups.

What's the audit trail look like? If you're under SOC 2, HIPAA, ISO 27001, or any of their cousins, "who downloaded what, when" is the question you need to answer in a hurry.

How much will you maintain? Anything you deploy is something you'll babysit. Pick the option with the smallest tail.

The short version

People need files. The Console is the wrong tool. Pre-signed URLs don't scale. Building it yourself is expensive and never really finished.

The fastest path is something purpose-built that lives in your account and uses your existing identity provider. Your users get self-service. You get your Slack DMs back.