Notes on S3 Presigned URL Expiration

This is the English translation of my original Japanese article: https://zenn.dev/arvehisa/articles/079333efe83384

Introduction

Do you ever manually generate S3 Presigned URLs? I occasionally use Presigned URLs to share documents and resources.

Recently, I encountered a phenomenon where the Presigned URL I generated using AWS CLI (logged in via AWS SSO) had a shorter validity period than what I had configured. I'd like to share some important considerations about Presigned URL expiration times.

Presigned URL

A Presigned URL is used to grant temporary access to S3 Objects. Typically, a Presigned URL has an expiration time set, during which the URL can be used to access the S3 Object.

S3 Presigned URL Expiration

In fact, the expiration of a Presigned URL is related to two things:

1. The expiration time specified when issuing the Presigned URL
2. The expiration time of the credentials used to issue the Presigned URL

If either one expires, you will no longer be able to access the S3 Object.

About the Expiration Time Specified During Issuance

When issuing a Presigned URL through the console, you can specify a maximum expiration time of 12 hours.
When issuing programmatically via CLI or CDK, you can specify a maximum expiration time of 7 days.

How to Issue via Console

You can specify a maximum expiration time of 7 days

How to Issue via CLI

aws s3 presign s3://{bucket_name}/{file_name} --expires-in 604800

Specify the expiration time with the --expires-in option. The maximum is 604800 seconds, which is 7 days.

Credential Expiration Time

Another related factor is the expiration time of the credentials used during issuance.
When the credentials used for issuance become invalid, the URL becomes invalid regardless of whether the configured Presigned URL expiration time has been reached.

Examples:

• When using CLI in CloudShell
• When logged into CLI with SSO locally

In these cases, you're not using persistent credentials like IAM users, but rather temporary credentials that are only valid for a few hours.
In such cases, when the CloudShell session ends or the local SSO session expires, the phenomenon occurs where the Presigned URL becomes invalid within a few hours despite setting the expiration to 7 days.

The same applies when issuing programmatically with SDKs. However, when using SDKs embedded within applications, it's common to set short expiration times and issue them each time they're used, so this is rarely a problem.

In my case, I was issuing URLs locally while logged in via SSO CLI, but they expired sooner than expected, resulting in an ExpiredToken error.
Reference: About SSO CLI login
https://dev.classmethod.jp/articles/aws-cli-for-iam-identity-center-sso/

Summary

The expiration of Presigned URLs is not only related to the expiration time set during issuance, but also to the expiration time of the credentials used during issuance.
When issuing with temporary credentials, you need to be careful about the expiration time.

• Issue Presigned URLs with a maximum of 12 hours via console
• Issue via CLI etc. with IAM user credentials

If you want to set a longer validity period, such as several hours or more, consider the above methods.