s3 presigned url for access to entire folder
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
An S3 presigned URL is great when you want to grant temporary access to one object without sharing AWS credentials. The important limitation is that S3 does not have real folders, only object keys with prefixes. That means you cannot create one presigned URL that magically grants access to every object under a prefix.
Why A Folder Presigned URL Does Not Exist
When you see a folder in the S3 console, you are looking at a UI convenience built on top of key names such as reports/2026/january.csv. The slash characters are part of the key, not a separate directory resource.
A presigned URL signs one HTTP request to one S3 API operation. For example, it can sign GetObject for reports/2026/january.csv. It cannot sign a wildcard request for reports/2026/ and let the client fetch everything under that prefix.
That is why the usual answer is: generate one presigned URL per object, or use a different access model for bulk access.
Generating One URL Per Object Under A Prefix
If the goal is to let a client download several objects from what looks like a folder, list the keys under that prefix and generate a presigned URL for each one.
This approach works well if the number of objects is modest and your application can hand the client a manifest of URLs.
Better Options For Bulk Access
If you need a user to browse or download many objects, per-object presigned URLs can become awkward. In that case, temporary credentials or CloudFront are often a better fit.
One option is to assume a role and return temporary AWS credentials scoped to a specific bucket and prefix. Then the client can call ListObjectsV2 and GetObject directly for that prefix during the credential lifetime.
A policy for that pattern usually grants s3:ListBucket with a prefix condition and s3:GetObject for arn:aws:s3:::my-bucket/reports/2026/*.
Another option is CloudFront signed URLs or signed cookies. That works especially well when the files are being distributed over HTTP and you want CDN caching plus temporary access control. Signed cookies are convenient when many files share the same access rules.
Packaging A Prefix Into One Download
Sometimes the real requirement is not "access a folder" but "download everything in this folder as one file." In that case, a common pattern is to build a ZIP archive on demand, upload that archive to S3, and create a single presigned URL for the ZIP file.
This is a good fit when users want one click and you control the server side workflow.
Common Pitfalls
The most common mistake is assuming that S3 folders are real resources with their own permissions and URLs. They are not. Access control is always happening against bucket operations and object keys.
Another issue is forgetting pagination when listing objects. A single list_objects_v2 call does not guarantee all results if the prefix contains many objects.
Expiration also matters. If you hand out hundreds of presigned URLs with a short lifetime, clients may not finish downloading before the first ones expire.
Finally, do not confuse presigned URLs with authorization for listing. A presigned GetObject URL lets a client download one object, but it does not let the client discover sibling keys under the same prefix.
Summary
- A presigned URL can grant access to one S3 operation on one object, not an entire prefix.
- S3 folders are key prefixes, not first-class directory resources.
- Generate one presigned URL per object when a client needs a small set of files.
- Use temporary credentials or CloudFront for broader prefix-based access.
- If users want one download, create an archive and presign that single object.

