URL แบบ presigned ของ S3: คืออะไร ทำงานอย่างไร ขีดจำกัดวันหมดอายุ และตัวอย่างโค้ด

URL แบบ presigned ของ S3 คือลิงก์ชั่วคราวไปยังออบเจกต์หนึ่งรายการในบัคเก็ตส่วนตัว ลิงก์นี้มีลายเซ็นอยู่ใน query string ผู้ที่ถือลิงก์จึงดาวน์โหลด (หรืออัปโหลด) ออบเจกต์นั้นได้โดยไม่ต้องมีข้อมูลรับรองของ AWS จนกว่าลิงก์จะหมดอายุ และบัคเก็ตไม่เคยกลายเป็นสาธารณะ คุณสร้างลิงก์ด้วยคีย์ของคุณเอง ในโค้ดหรือจาก AWS CLI และมีอายุได้ตั้งแต่ 1 วินาทีถึง 7 วัน คู่มือนี้อธิบายวิธีการทำงาน ความหมายของพารามิเตอร์ X-Amz-* ทุกตัว อายุที่เป็นไปได้ โค้ดสำหรับการดาวน์โหลดและอัปโหลด และข้อผิดพลาดที่คุณมีแนวโน้มจะพบมากที่สุด ขีดจำกัดต่าง ๆ นำมาจากเอกสารของ AWS และ Cloudflare ณ เดือนตุลาคม 2026

สรุป URL แบบ presigned ของ S3

URL แบบ presigned ทำงานอย่างไร

1. โค้ดของคุณ (หรือ CLI) รับบัคเก็ต คีย์ของออบเจกต์ เมธอด HTTP และเวลาหมดอายุ
2. SDK ลงนามค่าเหล่านั้นด้วย secret access key ของคุณโดยใช้ AWS Signature Version 4 ในขั้นนี้ยังไม่มีอะไรถูกส่งไปยัง S3
3. คุณมอบ URL ที่ได้ให้ผู้อื่น: เบราว์เซอร์ เพื่อนร่วมงาน หรือแอปมือถือ
4. เมื่อมีการใช้งาน S3 จะคำนวณลายเซ็นใหม่ด้วย secret ของ access key ที่อยู่ใน URL หากตรงกัน URL ยังไม่หมดอายุ และผู้ลงนามมีสิทธิ์ทำการดำเนินการนั้น คำขอก็จะผ่าน

URL มีสิทธิ์เท่ากับผู้ที่ลงนาม AWS ระบุไว้ชัดเจนว่า หากผู้ใช้ IAM หรือ role ที่สร้าง URL อ่านออบเจกต์ไม่ได้ URL จะตอบกลับ 403 ไม่ว่าลายเซ็นจะถูกต้องเพียงใด

พารามิเตอร์ X-Amz หมายถึงอะไร

URL แบบ presigned ของ SigV4 มีลักษณะดังนี้ (เพิ่มการขึ้นบรรทัดใหม่):

https://my-bucket.s3.eu-west-1.amazonaws.com/reports/q3.pdf
  ?X-Amz-Algorithm=AWS4-HMAC-SHA256
  &X-Amz-Credential=AKIAIOSFODNN7EXAMPLE%2F20261017%2Feu-west-1%2Fs3%2Faws4_request
  &X-Amz-Date=20261017T093000Z
  &X-Amz-Expires=3600
  &X-Amz-SignedHeaders=host
  &X-Amz-Signature=5f2c...e91a

หากเปลี่ยนส่วนที่ลงนามไว้ส่วนใดก็ตาม (คีย์ เมธอด อายุ หรือเฮดเดอร์ที่ลงนาม) ลายเซ็นจะไม่ตรงกันอีก โปรดสังเกตด้วยว่า URL เปิดเผยอะไรเป็นข้อความธรรมดาบ้าง: ชื่อบัคเก็ต คีย์ของออบเจกต์แบบเต็ม และ access key ID ของคุณ แต่ secret key ไม่เคยอยู่ใน URL

URL แบบ presigned มีอายุนานเท่าไร

ขีดจำกัดขึ้นอยู่กับข้อมูลรับรองที่ใช้ลงนาม:

นี่อธิบายเรื่องที่ทำให้ประหลาดใจบ่อยที่สุด: คุณขอ 7 วันจากฟังก์ชัน Lambda หรืออินสแตนซ์ EC2 แต่ลิงก์หมดอายุหลังหนึ่งชั่วโมงหรือไม่กี่ชั่วโมง URL มีอายุได้นานเท่ากับข้อมูลรับรองที่อยู่เบื้องหลังเท่านั้น หากคุณต้องการลิงก์ที่มีอายุยาว ให้ลงนามด้วยผู้ใช้ IAM เฉพาะที่มีสิทธิ์อ่านบัคเก็ตนั้นเท่านั้น

S3 ตรวจสอบอายุเมื่อคำขอเริ่มต้น การดาวน์โหลดขนาดใหญ่ที่เริ่มหนึ่งวินาทีก่อนครบกำหนดจะเสร็จตามปกติ แต่การลองใหม่หลังครบกำหนดจะล้มเหลวด้วย AccessDenied และข้อความ “Request has expired” การขอเกิน 604,800 วินาทีจะถูกปฏิเสธทันที

วิธีสร้าง URL แบบ presigned

AWS CLI

aws s3 presign s3://my-bucket/reports/q3.pdf --expires-in 3600

คำสั่งนี้ลงนาม URL สำหรับดาวน์โหลด (GET) ค่าเริ่มต้นคือ 3,600 วินาทีและสูงสุด 604,800 วินาที CLI เวอร์ชันล่าสุดใช้ SigV4 เสมอ จึงต้องตั้งค่าภูมิภาคไว้ด้วย สำหรับ URL อัปโหลดคุณต้องใช้ SDK

Python (boto3)

import boto3
from botocore.config import Config

s3 = boto3.client('s3', region_name='eu-west-1', config=Config(signature_version='s3v4'))

url = s3.generate_presigned_url(
    ClientMethod='get_object',
    Params={
        'Bucket': 'my-bucket',
        'Key': 'reports/q3.pdf',
        'ResponseContentDisposition': 'attachment; filename="q3.pdf"',
    },
    ExpiresIn=3600,
)

ตั้งค่า signature_version='s3v4' อย่างชัดเจน เอกสารอ้างอิงของ boto3 เตือนว่า เพื่อความเข้ากันได้กับเวอร์ชันเก่า มิฉะนั้นอาจลงนามด้วย Signature Version 2 แบบเก่าในภูมิภาคที่ยังรองรับ ซึ่งจะทิ้งพารามิเตอร์และเฮดเดอร์บางตัว เช่น Range ไปโดยไม่แจ้ง ResponseContentDisposition เป็นตัวเลือกเสริม: ทำให้เบราว์เซอร์บันทึกไฟล์ด้วยชื่อที่เรียบร้อยแทนการเปิดในหน้า

JavaScript (AWS SDK v3)

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'
import { getSignedUrl } from '@aws-sdk/s3-request-presigner'

const client = new S3Client({ region: 'eu-west-1' })

const url = await getSignedUrl(
  client,
  new GetObjectCommand({ Bucket: 'my-bucket', Key: 'reports/q3.pdf' }),
  { expiresIn: 3600 }
)

หากคุณไม่ระบุ expiresIn presigner ของ JavaScript จะใช้ 900 วินาที (15 นาที)

URL อัปโหลดแบบ presigned (PUT)

หลักการเดียวกันใช้ได้ในทิศทางตรงข้าม คุณลงนาม PutObject สำหรับคีย์หนึ่ง และผู้ที่มี URL จะเขียนออบเจกต์นั้นได้ ไฟล์ส่งตรงจากอุปกรณ์ของเขาไปยังบัคเก็ต และเซิร์ฟเวอร์ของคุณไม่ต้องจัดการไบต์เลย หากมีออบเจกต์ที่ใช้คีย์นั้นอยู่แล้ว จะถูกแทนที่

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3'
import { getSignedUrl } from '@aws-sdk/s3-request-presigner'

const client = new S3Client({ region: 'eu-west-1' })

const url = await getSignedUrl(
  client,
  new PutObjectCommand({
    Bucket: 'my-bucket',
    Key: 'incoming/brief.pdf',
    ContentType: 'application/pdf',
  }),
  { expiresIn: 900, signableHeaders: new Set(['content-type']) }
)

await fetch(url, {
  method: 'PUT',
  headers: { 'Content-Type': 'application/pdf' },
  body: file,
})

การเพิ่ม content-type ลงใน signableHeaders จะผูก URL ไว้กับประเภทนั้น การอัปโหลดที่ใช้ Content-Type ต่างไปจึงถูกปฏิเสธ ใน boto3 สิ่งที่เทียบเท่ากันคือ generate_presigned_url('put_object', Params={'Bucket': ..., 'Key': ..., 'ContentType': 'application/pdf'}) และไคลเอนต์ต้องส่งเฮดเดอร์เดียวกัน

สามสิ่งที่ควรตรวจสอบก่อนอัปโหลดจากเบราว์เซอร์:

• CORS บัคเก็ตต้องมีกฎ CORS ที่อนุญาต origin ของคุณและเมธอด PUT สำหรับการอัปโหลดแบบ multipart ยังต้องเปิดเผยเฮดเดอร์ ETag ด้วย เพราะเบราว์เซอร์ต้องอ่านค่านี้จากแต่ละส่วน
• คีย์ที่กำหนดตายตัว สร้างคีย์ที่ไม่ซ้ำกันบนเซิร์ฟเวอร์ (เช่น ใช้พรีฟิกซ์ UUID) เพื่อไม่ให้ผู้เข้าชมเขียนทับไฟล์ของผู้อื่น
• Checksum SDK ของ AWS ปัจจุบันเพิ่ม CRC checksum ให้การอัปโหลดโดยค่าเริ่มต้น หากการอัปโหลดแบบ presigned ล้มเหลวกับผู้ให้บริการที่รองรับ S3 ด้วยข้อผิดพลาดเรื่องลายเซ็นหรือ checksum ให้ตั้งค่า requestChecksumCalculation: 'WHEN_REQUIRED' บนไคลเอนต์

Presigned POST เป็นกลไกแยกต่างหากสำหรับฟอร์ม HTML ธรรมดา พร้อมนโยบายที่จำกัดขนาดและประเภทเนื้อหาได้ ผู้ให้บริการที่รองรับ S3 ไม่ได้รองรับทุกราย (R2 ไม่รองรับ) presigned PUT จึงเป็นตัวเลือกที่ใช้ได้กว้างกว่า

ไฟล์ขนาดใหญ่: การอัปโหลดแบบ multipart ด้วย presigned URL

PUT ครั้งเดียวไปยัง S3 จำกัดไว้ที่ 5 GB และ AWS แนะนำให้ใช้ multipart ตั้งแต่ประมาณ 100 MB multipart แบ่งไฟล์เป็นสูงสุด 10,000 ส่วน แต่ละส่วนมีขนาดตั้งแต่ 5 MiB ถึง 5 GiB ยกเว้นส่วนสุดท้าย ซึ่งอัปโหลดแยกกัน พร้อมกัน และลองใหม่ได้ทีละส่วน การลงนามทำแยกต่อส่วน: เซิร์ฟเวอร์เริ่มการอัปโหลด ลงนาม URL UploadPart หนึ่งรายการต่อหนึ่งส่วน เบราว์เซอร์ส่งแต่ละชิ้นแล้วรายงาน ETag กลับมา และเซิร์ฟเวอร์ทำให้การอัปโหลดเสร็จสมบูรณ์

import {
  CreateMultipartUploadCommand,
  UploadPartCommand,
  CompleteMultipartUploadCommand,
} from '@aws-sdk/client-s3'

const { UploadId } = await client.send(
  new CreateMultipartUploadCommand({ Bucket: 'my-bucket', Key: 'video/raw.mov' })
)

const partUrl = await getSignedUrl(
  client,
  new UploadPartCommand({ Bucket: 'my-bucket', Key: 'video/raw.mov', UploadId, PartNumber: 1 }),
  { expiresIn: 3600 }
)

await client.send(
  new CompleteMultipartUploadCommand({
    Bucket: 'my-bucket',
    Key: 'video/raw.mov',
    UploadId,
    MultipartUpload: { Parts: [{ PartNumber: 1, ETag: etagFromPartResponse }] },
  })
)

เพิ่มกฎวงจรชีวิตที่ยกเลิกการอัปโหลดแบบ multipart ที่ไม่สมบูรณ์หลังจากไม่กี่วัน มิฉะนั้นส่วนที่ถูกทิ้งไว้จะยังกินพื้นที่เก็บข้อมูลที่ถูกคิดเงิน

URL แบบ presigned บน R2, B2, Spaces และ Wasabi

ผู้ให้บริการที่ใช้ S3 API พร้อม SigV4 รับโค้ดเดียวกันได้ คุณเพียงเปลี่ยน endpoint ภูมิภาค และคีย์ รายละเอียดอาจต่างกัน โปรดตรวจสอบเอกสารของผู้ให้บริการ:

• Cloudflare R2 รองรับ GET, HEAD, PUT และ DELETE แบบ presigned โดยมีอายุตั้งแต่ 1 วินาทีถึง 7 วัน ไม่รองรับ POST แบบ presigned และ URL แบบ presigned ใช้ได้เฉพาะบนโดเมน S3 API (<ACCOUNT_ID>.r2.cloudflarestorage.com) ไม่ใช่บนโดเมนแบบกำหนดเอง ใช้ region: 'auto'
• Backblaze B2 ระบุว่า API ที่รองรับ S3 ของตนรองรับ URL แบบ presigned ที่สร้างด้วย AWS CLI หรือ SDK
• DigitalOcean Spaces และ Wasabi ใช้งานได้ด้วยการเรียก SDK เดียวกันที่ชี้ไปยัง endpoint ของตน

สำหรับราคาของผู้ให้บริการแต่ละราย ดู การเปรียบเทียบ S3, R2, Spaces, Wasabi และ B2

ข้อผิดพลาดที่พบบ่อยของ URL แบบ presigned และวิธีแก้

พร็อกซีขององค์กรที่เขียนเฮดเดอร์หรือ query string ใหม่ก็ทำให้ลายเซ็นเสียได้เช่นกัน หาก URL ใช้ได้จากเครือข่ายหนึ่งแต่ใช้ไม่ได้จากอีกเครือข่าย ให้ลองทดสอบโดยไม่ผ่านพร็อกซี

แนวทางปฏิบัติด้านความปลอดภัยที่ดี

AWS เรียก URL แบบ presigned ว่า bearer token และแนะนำให้ปกป้องไว้ ในทางปฏิบัติ:

• ตั้งอายุให้สั้น ไม่กี่นาทีสำหรับการอัปโหลดและไฟล์ที่มีความอ่อนไหว ไม่กี่ชั่วโมงสำหรับการดาวน์โหลดทั่วไป สร้างลิงก์ใหม่เมื่อมีคนต้องการไฟล์อีกครั้ง
• ลงนามด้วยตัวตนที่มีสิทธิ์จำกัด ผู้ใช้ IAM หรือ role เฉพาะที่อ่านได้อย่างเดียว (หรือเขียนได้อย่างเดียว) ในพรีฟิกซ์ที่เกี่ยวข้อง จะจำกัดความเสียหายหากลิงก์รั่วไหล
• เพิ่มการป้องกันในนโยบายบัคเก็ต เงื่อนไข s3:signatureAge ปฏิเสธลายเซ็นที่เก่ากว่าอายุที่กำหนด และ aws:SourceIp จำกัดเครือข่ายที่ใช้ลิงก์ได้
• อย่าบันทึกลงล็อก URL แบบ presigned ฉบับเต็มในล็อกของแอปพลิเคชัน ระบบวิเคราะห์ หรือประวัติแชต คือข้อมูลรับรองที่ใช้งานได้จนกว่าจะหมดอายุ
• วางแผนสำหรับสิ่งที่ขาดไป ไม่มีรหัสผ่าน ไม่มีการนับจำนวนดาวน์โหลด และเพิกถอนทีละลิงก์ไม่ได้ ดังนั้นให้วางแอปพลิเคชันไว้ด้านหน้าเมื่อคุณต้องการสิ่งเหล่านั้น

สำหรับเรื่องการแชร์โดยละเอียด พร้อมตัวเลือกที่เพิ่มการควบคุมเหล่านั้น ดู วิธีแชร์ไฟล์ S3 โดยไม่ต้องเปิดบัคเก็ตเป็นสาธารณะ

Nubbo ใช้ URL แบบ presigned อย่างไร

Nubbo สร้างขึ้นบนรูปแบบนี้ เมื่อคุณอัปโหลดในตัวสำรวจ เซิร์ฟเวอร์จะลงนาม PUT (หรือตั้งแต่ 100 MB ขึ้นไป จะเป็นการอัปโหลดแบบ multipart สามส่วนพร้อมกัน) และเบราว์เซอร์ของคุณจะส่งไบต์ตรงไปยังบัคเก็ตของคุณ การดาวน์โหลดไฟล์เดี่ยวใช้ URL GET แบบ presigned ที่ใช้ได้หนึ่งชั่วโมง access key ของคุณถูกเก็บแบบเข้ารหัสด้วย AES-256-GCM และใช้บนเซิร์ฟเวอร์เพื่อลงนามเท่านั้น

ลิงก์แชร์ เพิ่มสิ่งที่ URL แบบ presigned ทั่วไปไม่มี: รหัสผ่าน วันหมดอายุ และขีดจำกัดการดาวน์โหลดตามต้องการ ซึ่ง Nubbo ตรวจสอบก่อนออก URL อายุสั้น และคุณปิดใช้งานลิงก์ได้ทุกเมื่อ การดาวน์โหลดหลายไฟล์เป็น ZIP จะประกอบขึ้นในเบราว์เซอร์ของคุณ ซึ่งดาวน์โหลดแต่ละไฟล์ตรงจากบัคเก็ตของคุณ: Nubbo ไม่เคยเห็นเนื้อหาเลย ข้อยกเว้นที่ต้องบอกตามตรงมีเพียงข้อเดียว: ภาพย่อจะถูกเขียนลงในบัคเก็ตของคุณเองใต้ .nubbo-thumbs/ ทั้งหมดนี้ทำงานเหมือนกันบน Amazon S3, Cloudflare R2, DigitalOcean Spaces, Wasabi, Backblaze B2 และ endpoint สาธารณะที่รองรับ S3