Skip to main content
In this lesson we’ll cover Amazon S3 pre-signed URLs: what they are, why they exist, common use cases, and practical examples for generating them. Pre-signed URLs let you grant time-limited access to S3 objects without making buckets public or provisioning AWS accounts for unauthenticated users. See the official docs for more: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html

What problem do pre-signed URLs solve?

  • You have a private S3 bucket (recommended for sensitive data).
  • IAM-authenticated identities with proper permissions can get/put objects in that bucket.
  • But sometimes you need to allow a non-AWS (public/unauthenticated) user to access a specific object temporarily.
Options you might consider:
  • Create an AWS account for that person — impractical for most workflows.
  • Make the bucket or object public — often undesirable for security and compliance.
Pre-signed URLs provide a better solution: an IAM-authenticated user or role generates a temporary URL containing a cryptographic signature and metadata. Anyone possessing that URL can perform the signed operation (GET, PUT, or POST) while the URL is valid, without their own AWS credentials. S3 treats the request as if it came from the identity that created the URL.

Typical use cases

  • Secure streaming of private videos (membership-only content).
  • Letting clients upload directly to S3 from the browser or mobile app (reduces backend bandwidth).
  • Sharing a single file with a contractor or vendor for a limited time.
  • Temporary links for downloads in emails or support workflows.
Use case example — secure streaming of private videos:
  • A video-hosting site stores large media files in private S3 buckets.
  • When a paying user requests a video, the backend issues a pre-signed GET URL for the object and returns it to the client.
  • The client fetches the video directly from S3 with the pre-signed URL. S3 authorizes the request using the credentials of the URL creator; users without the URL cannot access the private content.
A diagram titled "Pre-Signed URL Use Case" showing an AWS Cloud box with a User X, a storage bucket icon, and an external user sending/receiving arrows. Three other user avatars to the right are marked with red Xs to indicate denied access.

Direct uploads: cut out the backend

A common pattern is:
  1. Client requests a pre-signed upload URL from your API.
  2. Your API (running with permissions to PutObject) generates a pre-signed PUT or POST URL and returns it to the client.
  3. The client uploads directly to S3 using that pre-signed URL.
Benefits:
  • Files do not traverse your backend — reduces bandwidth and server load.
  • Uploads are faster and more scalable.
  • Backend still controls access (it issues the pre-signed URL and validates metadata, size, etc.).
Supported methods:
  • PUT: Use when you want a simple single-file upload.
  • POST: Use when you need form-based uploads and constraints (e.g., content-type, file size limits).

Example commands and code

AWS CLI (generate a GET presigned URL, valid for 1 hour):
Python (boto3) — generate a presigned GET:
Python (boto3) — generate a presigned POST for browser uploads:
JavaScript (AWS SDK v3) — generate a presigned PUT URL:
These examples show common approaches; adjust parameters (ACLs, encryption headers, content-type) to fit your security requirements.

Key points and constraints

Pre-signed URLs let you perform time-limited operations on S3 as the identity that created the URL — they do not change or escalate permissions. Always ensure the creating identity has only the minimum necessary permissions and set short expirations whenever possible.

How pre-signed URLs work (brief)

  • The URL contains a signature, timestamp, and other metadata. S3 validates this signature on each request.
  • The signature is computed using the signing identity’s credentials (long-term keys or temporary STS tokens).
  • The allowed HTTP method and optional headers are encoded into the signature; requests that do not match the signed parameters are rejected.
  • Anyone with the URL may use it until it expires — treat pre-signed URLs as sensitive secrets and rotate or revoke access by invalidating credentials or changing object keys if necessary.
Anyone who obtains a pre-signed URL can use it until it expires. Do not embed long-lived pre-signed URLs in public repositories, logs, or untrusted locations. Use short expirations and validate uploads on the backend when necessary.
A presentation slide titled "Pre-Signed URLs" with a blue "Note" box and several bullet points. The bullets explain that pre-signed URLs require an expiration date (maximum 7 days for an IAM user) and allow sending requests as the generating user without granting direct bucket access.

Security best practices

  • Use the principle of least privilege for the identity that creates pre-signed URLs.
  • Keep URL expirations as short as practical for the use case.
  • Validate uploaded content server-side if you rely on file type, size or metadata for downstream processing.
  • Prefer pre-signed POST with conditions when you need to restrict fields (content-type, filename prefixes, max size).
  • If you must revoke access immediately, rotate the IAM credentials used to sign URLs or change the object key/location.

Summary

  1. Pre-signed URLs let you grant time-limited download or upload access to S3 objects without making the bucket public or creating AWS accounts for recipients.
  2. Requests using a pre-signed URL are executed with the identity and permissions of the URL generator.
  3. A generated pre-signed URL cannot grant access beyond the generating identity’s permissions; if the creator lacks access, the URL will fail.
A presentation slide titled "Summary" with three numbered points explaining pre-signed URLs for AWS: they grant time-limited download permissions, requests use the identity of the URL creator, and access is limited by the creator's permissions.

References

Watch Video