How to Share S3 Files Without Giving AWS Console Access

This scene plays out at almost every company on AWS: someone on the business side needs a file that lives in S3. The fastest fix? Spin up an IAM user, give them console access, point them at the bucket.

It works. And then it haunts you for the next six months.

Why console access is a problem

The AWS Console is built for infrastructure operators, not file recipients. When you give someone console access just to grab files, you've handed them the keys to a building and you're hoping they only walk into one room.

You will over-permission. Everyone does.

Writing an IAM policy that grants S3 reads on a specific prefix while hiding everything else is shockingly fiddly. The console needs assorted permissions just to render the bucket list page at all. Half the time, someone gives up debugging the cryptic "Access Denied" errors and slaps on AmazonS3ReadOnlyAccess instead.

That policy reads every bucket in the account. Including the one with your CloudFormation templates. Including the one with deployment artifacts. Including the one with the database backups your security team forgot to lock down.

The console shows too much

Even with S3-only permissions, the console exposes bucket configurations, policies, CORS rules, lifecycle settings, replication. A curious user can read your bucket policies and start mapping out your security boundaries. If you're under any kind of compliance regime, that visibility alone can show up as an audit finding.

You now have new users to manage

Each console user is a real IAM identity. Password policy, MFA enrollment, key rotation, deprovisioning when they leave. If your identity already lives in Okta or Azure AD, you're now running a parallel system just for "people who occasionally need a file."

Your audit story gets messy

CloudTrail logs everything, technically. But "who downloaded which file" turns into a parsing exercise across API events, IAM users, and assumed roles. It's possible, but it's nothing like the clean per-user audit log you'd get from an app that was designed for it.

Alternative 1: S3 pre-signed URLs

The simplest move. You generate a URL that grants temporary access to a specific object, send it over Slack or email, the user clicks it. No credentials, no console.

What's good: Dead simple, no infrastructure, perfect for one-offs.

What's not: It's manual. It doesn't scale to "I need ten files" or "I need to browse this folder." URLs forward to people you didn't intend. There's no real identity tied to who actually clicks the link.

Pre-signed URLs are a building block, not a product. They're what powers the download path inside BucketDrive. As a manual workflow on their own, though, they put you back in the loop.

Alternative 2: CloudFront signed URLs or signed cookies

One step up: stick CloudFront in front of S3 with cryptographic access controls. Signed cookies are the more interesting option here, because a single cookie can grant access to a whole prefix, which means folder-level browsing actually works.

The catch is the setup. You're creating a CloudFront distribution, configuring Origin Access Control to lock down direct S3 access, and writing a token-exchange service that takes authenticated users and hands them signed cookies. That last bit is, basically, an application.

What's good: CDN performance, folder-level access, much safer than raw S3 exposure.

What's not: You're building most of the auth layer yourself. There's no admin UI in the box. By the time you're done, you've built a small product.

Alternative 3: S3 static website hosting

Some teams hand-roll an HTML index page that links to files in the same bucket, slap CloudFront in front, and bolt on Lambda@Edge for auth. It's clever for a tiny use case.

What's good: Cheap, no servers.

What's not: The index pages are static, so somebody (or some script) has to keep them updated. No real listing, no search, no per-user views. Lambda@Edge's tight constraints (5-second timeout, small body limits) make real auth hard. This breaks the moment your needs grow even slightly.

Alternative 4: A purpose-built file portal

There are products that exist exactly for this: web interfaces that sit on top of S3 and give non-technical users a place to log in and grab files. They split into two camps.

EC2-based options like StorageLink and FileMage do the job but bring back everything you went serverless to escape: patching, scaling, monitoring, paging. You've traded one operational problem for another.

Serverless options that deploy into your account are the sweet spot. You get a real product without owning a fleet of EC2 boxes. BucketDrive is one of these. Cognito for auth (with SSO via SAML and OIDC), Cognito groups mapped to bucket-level permissions, pre-signed URLs for downloads, and every action logged to DynamoDB.

If you want a deeper comparison of the options, we wrote one up: AWS Transfer Family alternatives.

What good actually looks like

Whatever you pick, here's the bar.

• Identity-tied access. Every download is tied to a real, authenticated user. No anonymous links. No shared accounts.
• Least-privilege by default. Users see exactly the buckets and folders they're supposed to. Nothing else.
• A real audit trail. Who, what, when, from where. SOC 2, HIPAA, ISO 27001 all want this and they want it in a usable format.
• Data stays in your account. No proxying through someone else's servers.
• SSO that just works. Users log in with their existing corporate credentials. New passwords are bad twice over.
• Nothing to babysit. If the answer involves "and then you patch the EC2 box," you've made a new problem.

The console fails most of these. Pre-signed URLs fail on identity and audit. A custom build can hit them all, but it's expensive. Purpose-built serverless options give you the whole list without the build cost.

It really does come down to how much engineering time you're willing to pour into a problem that's already been solved.