Amazon S3 Presigned URLs: Secure Temporary Object Access – SAP-C02 Study Guide

Purpose of This Lesson

Amazon S3 presigned URLs provide temporary access to a specific object in a private S3 bucket. They are useful when an application needs to let an unauthenticated or externally authenticated user download or upload an object without making the bucket public or distributing AWS credentials.

A presigned URL is generated by an AWS principal with permission to perform the underlying S3 operation. The URL contains a signature and an expiration period, allowing the recipient to use the URL until it expires.

Key Concepts

Temporary access to private objects

A presigned URL can grant access to a specific S3 object for a defined period. The bucket and object can remain private, and the recipient does not need IAM credentials.

Typical use cases include:

• Allowing a customer to download a private report.
• Providing temporary access to an image, video, or document.
• Enabling a browser or mobile application to upload directly to S3.
• Sharing objects with users who authenticate through an application rather than AWS IAM.

How a presigned URL works

The URL is signed using the permissions and credentials of the principal that creates it. It generally includes information such as:

• The target bucket and object key.
• The signing algorithm and credential scope.
• A timestamp.
• An expiration value.
• A cryptographic signature.

Anyone who possesses the complete URL can use it during its validity period. The recipient does not need to be an AWS account user.

Creating a presigned URL with the AWS CLI

The AWS CLI supports presigning an S3 object with aws s3 presign:

aws s3 presign s3://example-private-bucket/reports/report.pdf

The default expiration is typically 3,600 seconds, or one hour. An explicit duration can be specified with --expires-in:

aws s3 presign \
  s3://example-private-bucket/reports/report.pdf \
  --expires-in 900

This creates a URL valid for approximately 15 minutes, subject to the lifetime of the credentials used to sign it.

Required permissions

The principal generating a download URL generally needs s3:GetObject permission for the target object. For an upload URL, the signing principal generally needs s3:PutObject permission.

The presigned URL does not bypass S3 authorization. It delegates the signer’s permitted operation for a limited time. Explicit denies, bucket policies, VPC endpoint policies, object ownership settings, and other applicable controls can still affect access.

Presigned URLs and application authentication

A common architecture places an application authentication layer in front of S3:

1. The user authenticates with the application.
2. The application authorizes access to a particular object.
3. A backend component, such as AWS Lambda, generates a short-lived presigned URL.
4. The application returns the URL to the authorized user.
5. The client accesses S3 directly using the URL.

This pattern avoids routing the entire file transfer through the application server.

Exam-Relevant Takeaways

• A presigned URL grants temporary access to a specific S3 object without making the bucket or object public.
• The URL is a bearer credential: anyone who obtains it can use it while it remains valid.
• The signer must have permission for the operation being presigned, such as s3:GetObject or s3:PutObject.
• Presigned URLs are appropriate for controlled, time-limited sharing, not permanent public distribution.
• The URL expiration cannot extend beyond the effective lifetime of the credentials used to create it. URLs signed with temporary credentials become unusable when those credentials expire, even if the requested URL duration is longer.
• Use short expiration periods and generate URLs only after application-level authorization.
• A presigned URL can be used for uploads as well as downloads, provided the signing principal has the required permissions and the request matches the signed parameters.
• Presigned URLs do not require the recipient to have an IAM user, role, or AWS account.

Architecture Decision Guide

Requirement	Recommended approach	Reason
Temporary download of a private S3 object	S3 presigned GET URL	Provides scoped, time-limited access without public access
Temporary direct upload from a browser or mobile app	S3 presigned PUT URL or presigned POST	Lets the client upload directly to S3 without exposing AWS credentials
Public, cacheable content intended for everyone	CloudFront with an appropriate public delivery model	Better suited to broad distribution and caching than generating individual URLs
Private content delivered through CloudFront	CloudFront signed URL or signed cookie	Controls access at the CDN layer and can use edge caching
Application must authorize each user before sharing	Authenticate in the application, then generate an S3 presigned URL	Separates business authorization from direct object transfer
Long-term access for an AWS workload	IAM role and temporary AWS credentials	More appropriate than repeatedly distributing bearer URLs
Permanent public access to an object	Carefully designed public policy, if acceptable	Presigned URLs are unnecessary when access is intentionally public

Common Exam Traps

• Assuming a presigned URL makes an object public: It does not. Access is limited to requests using the URL and only for its validity period.
• Forgetting that the URL is a bearer token: The recipient does not need identity verification from S3. Anyone who obtains the URL may use it.
• Ignoring the signer’s permissions: A user or role cannot presign an operation that it is not authorized to perform.
• Using an overly long expiration: Longer validity increases the exposure window if the URL is leaked. Temporary credentials can also cause the URL to expire earlier than requested.
• Confusing S3 presigned URLs with CloudFront signed URLs: S3 presigned URLs authorize access directly to S3. CloudFront signed URLs authorize delivery through a CloudFront distribution.
• Assuming bucket public access must be disabled for presigned URLs to work: Presigned URLs can work with a private bucket, but all applicable bucket, identity, endpoint, and organization policies must allow the signed operation.
• Treating a URL as a replacement for application authorization: S3 validates the signature and conditions, not whether the business user is entitled to see the object. The application should authorize the user before issuing the URL.

Real-World Engineer Notes

• Keep S3 Block Public Access enabled when the workload requires private objects. Presigned URLs do not require public bucket policies.
• Use object keys that are authorized by the application rather than accepting arbitrary keys from a client.
• Prefer short-lived URLs, especially for sensitive documents. Generate them on demand rather than storing them permanently.
• Avoid logging complete presigned URLs because query parameters contain the authorization material.
• For uploads, constrain the permitted key, content type, size, and other request properties where the selected presigning method supports those conditions.
• Consider S3 event notifications, validation, malware scanning, and lifecycle policies for objects uploaded directly by clients.
• If users need repeated access to many objects, CloudFront signed cookies or an application-controlled download service may provide a better user experience than issuing many individual S3 URLs.
• Test access from a client that has no AWS credentials. This confirms that the URL itself is sufficient and that the bucket is not accidentally relying on the client’s identity.
• Delete temporary test buckets and objects after hands-on exercises to avoid unnecessary storage and request charges.

Quick Reference Summary

• Command: aws s3 presign s3://bucket/key
• Custom duration: --expires-in <seconds>
• Typical default: 3,600 seconds, or one hour
• Download permission: Usually s3:GetObject
• Upload permission: Usually s3:PutObject
• Recipient credentials: Not required
• Bucket visibility: Can remain private
• Security model: Signed bearer URL
• Important limitation: Effective URL lifetime is bounded by the credentials used to sign it
• Primary use case: Temporary, object-level access

Flashcards

1. Q: What problem does an S3 presigned URL solve?

A: It provides temporary access to a private S3 object without making the object public or giving the recipient AWS credentials.

1. Q: What AWS CLI command creates an S3 presigned URL?

A: aws s3 presign s3://bucket/key.

1. Q: How can the expiration period be customized?

A: Use the --expires-in option with a duration in seconds.

1. Q: Does the recipient of a presigned URL need an IAM identity?

A: No. The URL contains the authorization information needed for the permitted request.

1. Q: What permission is generally needed to create a presigned download URL?

A: s3:GetObject for the target object.

1. Q: What permission is generally needed to create a presigned upload URL?

A: s3:PutObject for the target object key.

1. Q: Why is a presigned URL considered a bearer credential?

A: Whoever possesses the complete URL can use it while it remains valid.

1. Q: Does a presigned URL make an S3 bucket public?

A: No. It grants scoped, temporary access to the signed request.

1. Q: Can a presigned URL remain valid after the signer’s temporary credentials expire?

A: No. The URL cannot outlive the effective credentials used to create it.

1. Q: What is a common application pattern for presigned URLs?

A: Authenticate and authorize the user in an application, generate a short-lived URL in a backend component, and let the client transfer the object directly with S3.

Practice Questions

Question 1

A company stores private PDF invoices in Amazon S3. Customers authenticate to a web application and should be able to download only their own invoice for 10 minutes. The company does not want to expose AWS credentials or make the S3 bucket public. Which solution best meets the requirement?

A. Enable public read access on the invoice prefix.
B. Create an S3 presigned GET URL after the application authorizes the customer.
C. Create an IAM user for every customer and return its access keys.
D. Attach an S3 bucket policy allowing access from the customer’s IP address.

Correct answer: B

Explanation: The application can authenticate the customer, authorize the requested invoice, and generate a short-lived presigned URL. The bucket remains private, and the customer does not receive AWS credentials.

Question 2

An application generates an S3 presigned URL with an expiration of 3,600 seconds. The URL is signed using credentials obtained from an IAM role that will expire in 20 minutes. How long can the URL remain usable at most?

A. 3,600 seconds, because that is the URL expiration value.
B. Seven days, because S3 supports long-lived presigned URLs.
C. Approximately 20 minutes, because the URL cannot outlive the temporary credentials.
D. Indefinitely, because the signature is already embedded in the URL.

Correct answer: C

Explanation: A presigned URL created with temporary credentials is bounded by the lifetime of those credentials. Once the role session expires, the URL is no longer usable even if its requested expiration is later.

Question 3

A mobile application must upload user-generated images directly to a private S3 bucket. The backend should control the object key and allow each upload for only five minutes. Which design is most appropriate?

A. Embed an IAM access key and secret key in the mobile application.
B. Make the bucket publicly writable.
C. Have the backend generate a short-lived presigned upload request for an authorized object key.
D. Route every image through a public EC2 instance and write it to S3 using the instance’s root credentials.

Correct answer: C

Explanation: A presigned PUT URL or presigned POST permits direct client upload while keeping AWS credentials private. The backend can authorize the user, constrain the destination, and use a short expiration.

Question 4

An engineer generates an S3 presigned URL successfully, but requests using the URL return AccessDenied. The signing principal has s3:GetObject permission. Which additional area should be investigated first?

A. Whether the URL recipient has an IAM user.
B. Whether an explicit deny exists in a bucket policy, VPC endpoint policy, or organization control.
C. Whether the object must be made public before presigning.
D. Whether S3 requires the recipient to assume the signer’s role.

Correct answer: B

Explanation: Presigning does not override explicit denies or other applicable authorization controls. The effective policy evaluation, object key, region, request method, and signed request parameters should be checked.

Question 5

A business distributes thousands of private video files to subscribers through a global website. Access should be controlled at the CDN layer, and repeated requests should benefit from edge caching. Which option is generally more suitable than issuing individual S3 presigned URLs for every download?

A. CloudFront signed URLs or signed cookies with a private S3 origin.
B. A public S3 bucket with unrestricted read access.
C. IAM users with long-term credentials for every subscriber.
D. An S3 presigned URL with a multi-year expiration.

Correct answer: A

Explanation: CloudFront signed URLs or signed cookies provide access control at the distribution layer and work well with cached content. The S3 origin can remain private using an appropriate CloudFront origin access configuration.