How to

How to Securely Share Files From a Private S3 Bucket

Share files from a private S3 bucket safely: why signed links die before the recipient opens them, and how non-technical staff can share without keys.

JeVaughn FergusonFounder, developer
October 24, 20267 min read
The short versionPlain termsFor builders

To securely share a file from a private S3 bucket, send a signed link that opens one file for a set time, and make sure the credentials behind it outlast that time: the console stops at 12 hours, EC2 role sessions at about 6, and the CLI or an SDK reach 7 days. Name the Region and endpoint for newer Regions, and give non-technical staff a tool with expiring, revocable share links instead of raw keys.

You need to securely share a file from a private S3 bucket with a client, and the link you sent stops working before they open it, or the person who needs to send it cannot use the AWS console at all. The answer is a signed link whose expiry fits the recipient, signed with credentials that outlast it, and a sharing tool for staff who should never handle AWS keys.

A secure share keeps the bucket private, opens one file, and ends on a set date. The recipient needs no AWS account, and nobody hands out long-term IAM credentials.

The sections below cover why share links die early, how to send large files, and how to give non-technical staff a safe way to share.

What a secure S3 file share looks like

A healthcare application needs to deliver a diagnostic report to a patient. The file sits in a private Amazon S3 bucket, and the patient has no AWS account and should get no access to the cloud infrastructure. An S3 signed URL (AWS calls it a presigned URL) acts as a temporary key: it opens one private object for a set period, and nothing else.

The link carries the permissions of whoever signed it. The recipient never logs in, and the bucket stays closed to the public internet. For how presigned URLs are built and created with the CLI and SDKs, see how presigned URLs work: downloads, uploads and expiry.

Share large files from the console

A media production house needs to deliver a 4K master file that runs to hundreds of gigabytes. Email attachments and ordinary sharing links fail at that size. Instead of creating IAM credentials for the vendor, an administrator generates a signed URL for the S3 object, and the vendor downloads that one file without an AWS account.

The Amazon S3 console can generate a presigned URL for an object up to 5 TB, with the same 12-hour limit on expiration.

How non-technical staff can securely share S3 files

A marketing manager needs to send a high-resolution video to an outside agency. Without a standard tool, they ask a DevOps engineer for a link. Under time pressure, the engineer sets a very long expiration or makes the bucket public. Either shortcut breaks least privilege and can leave the file exposed long after the agency has it.

BucketDesk connects to your AWS account through an IAM role and gives the team a plain interface for the files, so nobody handles access keys or learns CLI syntax. The buckets stay private, and every share link has an expiry date. The BucketDesk security page explains how the permissions of the role are scoped.

Staff can preview a file before sharing it, so the right version goes out. Links end on the date that was set, without anyone remembering to clean up.

Pick an expiry that fits the recipient

Choose an expiration that fits the schedule of the recipient and your security policy: long enough for a collaborator in another time zone to download the file, short enough that the link does not linger.

Expiring links keep stale access out of archived email chains and chat logs, and they keep the audit trail for outgoing data short. Store shared files in the right class before you send them; see Amazon S3 storage classes.

Primary sources

Discussion

0 comments · open to guests · moderated
Comments appear after a quick review.

Liked this? Get the next article by email. No schedule, no digest, one click to leave.

Keep reading

All articles →