ざっくり言うと、どちらも 「本来は非公開のファイルを、認証済みユーザーだけに一時的に見せる」 ときに使います。
違いは、1個のファイルにアクセスさせたいか、複数のファイルにまとめてアクセスさせたいかです。
| 方式 | 向いているケース | 例 |
|---|---|---|
| Signed URL / Presigned URL | 特定の1ファイルだけ許可 | PDFを1件ダウンロード |
| Signed Cookie | 複数ファイル・配下のパスをまとめて許可 |
/projects/123/* の画像やPDFをまとめて閲覧 |
Presigned URL
例えばS3に、
private-bucket/project123/document.pdf
という非公開ファイルがあるとします。
APIに
GET /documents/123/download
とアクセスすると、バックエンドが権限を確認して、
https://s3...document.pdf?X-Amz-Signature=...
のような一定時間だけ有効なURLを返します。
つまり、
ユーザー
↓
API
↓ 権限チェック
Presigned URL発行
↓
S3から直接ダウンロード
という使い方です。
向いているのは、
- PDFダウンロード
- Excelダウンロード
- 画像1枚取得
- S3へのファイルアップロード
などです。
Signed Cookie
こちらはCloudFrontでよく使います。
例えばユーザーが、
/project/123/
の下にある
/page1.jpg
/page2.jpg
/page3.jpg
/thumbnail.jpg
などを大量に見る場合。
1ファイルごとにSigned URLを作るのは面倒なので、
/project/123/*
へのアクセスを許可するCookieを発行します。
ブラウザには例えば、
CloudFront-Policy
CloudFront-Signature
CloudFront-Key-Pair-Id
というCookieが保存されます。
その後は、
ブラウザ
↓ Cookie付き
CloudFront
↓
S3
でファイルを取得できます。
つまり、URL自体は普通のURLのままです。
一番大事な違い
例えば図面PDFを1件だけ取得するなら、
Signed URL
が分かりやすいです。
一方、PDFを画像化して、
page1.png
page2.png
page3.png
...
を画面上で大量に表示するなら、
Signed Cookie
の方が適しています。
システムに当てはめると
ユーザーがコンテンツを見る
↓
APIがDBを確認
↓
このユーザーはこのファイルを見てよいか判定
↓
Signed Cookieを発行
↓
CloudFront経由でS3のファイルを見る
という構成です。
そのため、DBのレコードを先に消してしまうと、
「このユーザーがこのファイルを見る権限がある」
という判定に必要な情報がなくなる
↓
Signed Cookieを発行できない
ということが起きます。
なので、覚え方としては、
Presigned URL = 「この1ファイルを○分だけ見ていいよ」
Signed Cookie = 「このフォルダ配下を○分だけ見ていいよ」
くらいで。
