กลับสู่บล็อก
เปรียบเทียบเทคโนโลยี

สเปก API บริการฝากรูป B2B 2026: เช็กลิสต์ 15 ข้อก่อนจัดซื้อ

เผยแพร่เมื่อ8 min read
แชร์

การซื้อบริการ image hosting ให้บริษัทก็เหมือนซื้อ database — ไม่มีใครตัดสินใจจาก landing page อย่างเดียว

ทีมมอบหมายให้ผมประเมิน vendor ทางเลือก ผมเลยรวบรวม incident ทุกครั้งกับบิลที่เซอร์ไพรส์จากสามปีที่ผ่านมาแล้วทำเป็น checklist สิ่งที่ได้ไม่ใช่บทความเปรียบเทียบว่า CDN ไหนมี PoP เยอะกว่า แต่เป็นตารางที่เอาไปแปะใน RFP ให้ vendor ตอบ "Yes / No / Partial" ทีละข้อ ดูผิวเผิน image hosting แต่ละเจ้าเหมือนกัน แต่สถาปัตยกรรมข้างในต่างกันมาก

ถ้าแค่อยากหาบริการฟรีหรือถูกที่สุด ดูที่ เปรียบเทียบ image hosting ฟรี หรือ ทางเลือก Imgur ก่อน บทความนี้เขียนให้ tech lead, ฝ่ายจัดซื้อ SaaS และ DevOps engineer

ทำไมเลือก image hosting สำหรับองค์กรถึงคนละเรื่องกับใช้ส่วนตัว

ผู้ใช้ทั่วไปสนใจ: "อัปโหลดได้มั้ย? แชร์ลิงก์ง่ายมั้ย?"

องค์กรสนใจคำถามคนละชุด สัญญาระบุ SLA หรือเปล่า? API โดนยิงเกิน rate limit แล้ว degrade ยังไง? ค่า Egress จะพุ่งสองเท่าโดยไม่ทันตั้งตัวในเดือนไหนมั้ย? ถ้า auditor ถามว่า EXIF data เก็บนานเท่าไหร่ ตอบได้มั้ย?

พูดตรงๆ เลยนะ การจัดซื้อ image hosting แบบ B2B คือการซื้อสามอย่าง: เส้นต้นทุนที่คาดการณ์ได้ การรับประกันระบบที่ตรวจสอบได้ และ protocol interface ที่ integrate ได้ 15 ข้อข้างล่างหมุนรอบสามเรื่องนี้

ลองเองมาแล้ว — ของฟรีรอด demo ได้ แต่ production ไม่รอด

Checklist 15 ข้อสำหรับ RFP (ก๊อปใส่เอกสารจัดซื้อได้เลย)

นี่คือตารางที่ผมใช้จริงตอนประเมิน vendor ทุกข้อมีวิธีตรวจสอบ ไม่ใช่แค่ถาม "รองรับมั้ย?" แล้วจบ เพราะ vendor ตอบ Yes ทุกข้ออยู่แล้ว

# สเปค วิธีตรวจสอบ เกณฑ์ผ่าน
1 S3 API compatible รัน s3api list-objects-v2 --prefix Response schema ตรงกับ AWS
2 Multipart Upload อัปโหลดไฟล์ 500MB หยุดกลางทาง แล้ว resume รองรับ part retry
3 Pre-signed URL สร้าง URL 15 นาที แล้ว verify signature HMAC-SHA256, ตั้ง TTL ได้
4 Webhook events Trigger event upload/delete HMAC signature + retry mechanism
5 Rate Limit policy รัน burst test ตอบ 429 + Retry-After header
6 SLA terms อ่าน MSA ≥99.9% มี service credit
7 Multi-region ขอ region list ≥2 region, cross-region sync
8 Egress pricing ขอ pricing sheet ราคาต่อหน่วยชัดเจน, มี tier discount
9 Image processing pipeline ทดสอบ on-the-fly transform รองรับ WebP/AVIF, URL params
10 CDN edge nodes รัน global ping test ≥50 PoP, มี node อาเซียน
11 EXIF / Metadata control อัปโหลดรูปที่มี GPS strip แบบเลือกได้
12 Authentication ดู API docs รองรับ OAuth2 + API Key rotation
13 Audit logs ถามเรื่อง log retention ≥90 วัน, export ได้
14 Compliance certs ขอรายงาน SOC 2 / ISO 27001 อย่างน้อยหนึ่งใบ
15 Data residency & deletion ดู DPA เลือก region ได้, hard delete ได้

อย่าแค่ติ๊ก Yes/No ทุกข้อต้องให้ vendor แนบลิงก์เอกสารหรือขั้นตอนตรวจสอบทางเทคนิค ข้อไหนไม่มีเอกสาร — เชื่อได้เลยว่า "มีแผนแต่ยังไม่ได้ทำ"

รายละเอียดเทคนิค — จุดที่ vendor ชอบพูดลอยๆ

ตารางเป็นแค่โครงร่าง ข้อด้านล่างคือจุดที่ vendor มักพูดกำกวมที่สุดตอนเจรจาสัญญา

S3 Compatible — ไม่ใช่แค่ประโยคเดียว

"เรา S3 compatible" เป็นประโยคที่ vendor ทุกรายชอบพูด แต่ S3 API มีมากกว่า 200 operation สิ่งสำคัญคือ กลุ่ม operation ที่คุณใช้จริง ทำงานถูกต้องหรือเปล่า

GetObject, PutObject ใครก็มี ลงลึกกว่านั้น:

# Test multipart
aws s3api create-multipart-upload --bucket test --key big.mp4 \
  --endpoint-url https://vendor.example.com

# Test versioning
aws s3api put-bucket-versioning --bucket test \
  --versioning-configuration Status=Enabled

# Test lifecycle
aws s3api put-bucket-lifecycle-configuration ...

จากที่ลองเองมาแล้ว ไม่ถึง 60% ของ vendor ผ่านครบทั้งสามข้อ Bucket lifecycle กับ object lock ขาดบ่อยที่สุด ถ้าขาดสองตัวนี้ audit compliance จะมีปัญหา

Pre-signed URL: TTL และอัลกอริทึมลายเซ็น

นี่คือวิธี auth ที่ใช้มากที่สุดใน B2B ผู้ใช้ปลายทางไม่มี credentials ของคุณ คุณออกตั๋วมีกำหนดเวลาให้เขา

กลไกข้างใต้คือ HMAC-SHA256: method, path, expiry, headers ถูกรวมเป็น string-to-sign แล้วเซ็นด้วย secret key vendor ที่ดีจะให้:

  • TTL ปรับได้ (ตั้งแต่ 1 นาที ถึง 7 วัน)
  • ล็อก source IP ได้ (aws:SourceIp condition)
  • จำกัด HTTP method ได้
  • รองรับ SigV4 (SigV2 เลิกใช้แล้ว vendor ไหนยังใช้ SigV2 ตัดออกเลย)

vendor ที่ไม่ดีจะให้ URL สาธารณะ "ไม่มีวันหมดอายุ" แล้วเรียกว่า signed นี่แหละเหตุผลที่ Pre-signed URL ต้องระบุชัดเจนใน RFP

Webhook Signature — ผมเคยโดนตรงนี้

Webhook เป็นหัวใจของ event-driven architecture อัปโหลดเสร็จ สแกนไวรัสเสร็จ transcode เสร็จ แต่ละ event ต้อง push มาที่ระบบคุณ

แต่ความปลอดภัยของ webhook คือจุดที่ vendor ตัดมุมบ่อยที่สุด implementation แย่ๆ ที่เจอมา:

  1. ไม่มี signature เลย POST เปล่าๆ
  2. มี signature แต่ secret อยู่ใน query string
  3. มี signature แต่ใช้ MD5
  4. มี signature แต่ไม่มี timestamp — replay attack สบายมาก

Webhook ที่ผ่านเกณฑ์ต้องมี:

  • HMAC-SHA256 signature ใน X-Signature header
  • X-Timestamp header, reject request ที่เก่ากว่า 5 นาที
  • Auto retry เมื่อ fail (exponential backoff, อย่างน้อย 3 ครั้ง)
  • Dead letter queue หรือ replay API

ตรวจสอบ webhook ด้วย Go จะเป็นแบบนี้:

func verifyWebhook(body []byte, sig, ts, secret string) bool {
    if time.Since(parseTS(ts)) > 5*time.Minute {
        return false
    }
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write([]byte(ts + "." + string(body)))
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(sig), []byte(expected))
}

ขาดการเช็ค timestamp ไป replay attack จะทะลุผ่าน event system ทั้งหมดของคุณ

Rate Limit: สองชั้นที่ต้องประเมิน

Rate limit ต้องดูสองชั้น: quota ของคุณเท่าไหร่ กับ เกิน quota แล้วเป็นยังไง

Quota ต่อรองง่าย ปกติเป็น per-second / per-minute อยู่ใน plan สิ่งที่สำคัญจริงๆ คือพฤติกรรมเมื่อเกินลิมิต:

พฤติกรรม ผลประเมิน
503 ตัดการเชื่อมต่อ ไม่ผ่าน
429 ไม่มี Retry-After ผ่านครึ่งเดียว
429 + Retry-After header ผ่าน
429 + Retry-After + quota header ดีเยี่ยม

ได้คะแนนพิเศษถ้ามี X-RateLimit-Remaining header ช่วยให้ code ของคุณ throttle เชิงรุก แทนที่จะต้องมารับ 429 แบบ passive

SLA — ปีศาจอยู่ใน exclusion clause

ทุกเจ้าเขียน 99.9% ซึ่งเท่ากับ downtime 43.2 นาทีต่อเดือน 99.95% คือ 21.6 นาที 99.99% คือ 4.3 นาที

แต่คุณค่าที่แท้จริงของ SLA ไม่ได้อยู่ที่ตัวเลข อยู่ที่ exclusion clause ต้องอ่านทุกบรรทัด:

  • Scheduled maintenance นับเป็น downtime มั้ย?
  • Regional outage นับมั้ย?
  • ช่วง DDoS นับมั้ย?
  • Third-party dependency fail (เช่น upstream DNS) นับมั้ย?

สำคัญกว่าคือกลไก service credit ไม่เข้าเป้า SLA แล้วคืนเท่าไหร่? คืนเป็น credit หรือเงินสด? Credit สะสมได้หรือหมดอายุ?

พูดตรงๆ SLA ส่วนใหญ่เขียนสวย แต่ตอน claim จริงโดน exclusion บล็อก ดังนั้นตอนจัดซื้อ อย่าดูแค่เปอร์เซ็นต์ ขอดู ประวัติ incident จริง 12 เดือนย้อนหลัง ซึ่งสามารถให้ได้ภายใต้ NDA

Egress Pricing — กับดักต้นทุนที่ซ่อนอยู่

Egress (bandwidth ขาออก) คือจุดที่งบ image hosting ระเบิดบ่อยที่สุด กลยุทธ์คลาสสิกของ vendor: storage ถูก แต่ egress แพง

ดูตัวเลขจริง ราคา egress ระหว่าง vendor หลักๆ ต่างกันได้มากกว่า 10 เท่า Cloudflare R2 ให้ zero egress (ภายในเครือข่าย Cloudflare), Cloudinary ใช้ credit model, imgix คิดตาม request อันไหนประหยัดกว่าขึ้นอยู่กับ traffic profile ของคุณทั้งหมด

ก่อนเซ็นสัญญา ต้องได้คำตอบชัดเจนสามข้อ:

  1. มี tier discount ตาม volume มั้ย? ปกติเกิน 10TB/เดือนถึงจะมีส่วนลดชัดเจน
  2. Traffic ข้าม region ภายในนับเป็น egress มั้ย?
  3. CDN cache hit นับเป็น egress มั้ย? vendor บางรายนับ cache hit เป็น billable traffic

ผมเจอเอง: ตอน test 200GB/เดือน ไม่มีปัญหา พอขึ้น production traffic พุ่งไป 8TB ข้ามคืน บิลเพิ่มขึ้นหลักหนึ่ง สัญญาไม่ได้ระบุ overage behavior เดือนนั้นรับไปเต็มๆ

ข้อพิจารณาสำหรับองค์กรไทย

สำหรับบริษัทที่มีผู้ใช้หลักในประเทศไทย ควรเลือก vendor ที่มี PoP ใน Singapore หรือ Bangkok (AWS ap-southeast-1) latency ที่ดีส่งผลต่อประสบการณ์ผู้ใช้โดยตรง นอกจากนี้ตาม PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล) ที่บังคับใช้เต็มรูปแบบแล้ว ข้อมูลส่วนบุคคลอย่าง GPS coordinate ใน EXIF ก็จัดเป็นข้อมูลส่วนบุคคล ต้องมีฐานในการประมวลผลและกลไกลบข้อมูลที่ชัดเจน สอบถาม vendor เรื่อง data residency option และกระบวนการ data deletion ก่อนตัดสินใจ

สามสเปคที่มักถูกมองข้าม

สามข้อนี้ไม่อยู่ในบทความ "เปรียบเทียบ image hosting" ทั่วไป แต่ใช้จริงแล้วเจ็บ

EXIF และ Metadata — ประเด็น compliance

EXIF มีพิกัด GPS, serial number กล้อง, เวลาที่ถ่าย อัปโหลดขึ้น image host สาธารณะ metadata เหล่านี้ติดไปด้วยโดยปริยาย

สำหรับ B2B ต้องถาม:

  • strip EXIF แบบ เลือกได้ มั้ย (ลบ GPS แต่เก็บ copyright)?
  • รองรับ IPTC / XMP metadata manipulation มั้ย?
  • ประมวลผล metadata ตอนอัปโหลดหรือ on-the-fly?

ทั้ง GDPR และ PDPA ถือว่าพิกัด GPS เป็นข้อมูลส่วนบุคคล จัดการไม่ถูกต้อง ความเสี่ยงด้าน compliance ตกมาที่บริษัทคุณโดยตรง

Hybrid Authentication: OAuth2 + API Key

Image host รุ่นเก่าให้แค่ API Key B2B สมัยใหม่ต้องใช้แบบผสม:

  • ระบบต่อระบบ: API Key + IP allowlist
  • Frontend SPA: OAuth2 PKCE flow
  • เข้าถึงชั่วคราว: Pre-signed URL

ถ้า vendor ให้ API Key ถาวรตัวเดียวแล้วบอกให้จัดการ scope เอง แปลว่า vendor โยนความเสี่ยงด้าน security มาให้ลูกค้า ระบบที่ถูกต้องต้องรองรับ scoped token, automatic rotation, และ revocation API

Hard Delete กับ Data Retention

สิทธิ์การถูกลืม (right to be forgotten) ตาม GDPR ต้องดำเนินการภายใน 30 วัน image host หลายเจ้าบอก "เราจะลบ" แต่จริงๆ แค่ soft delete — object ยังอยู่ใน S3, ใน CDN cache, ใน backup tape

ตอนจัดซื้อ ต้องยืนยัน:

  1. การลบระบุอยู่ใน DPA (Data Processing Agreement) หรือเปล่า?
  2. Backup cycle มีกลไกลบตามมั้ย?
  3. vendor ออกหลักฐานการลบได้มั้ย?

ผมเจอ case จริง: ลูกค้าได้รับคำร้องลบข้อมูลตาม GDPR แต่ cold storage backup ของ vendor เก็บ 365 วันไม่สามารถ override ได้ ฝ่ายกฎหมายโต้กลับไปมาสามเดือน

CDN Edge Nodes กับ latency ในโลกจริง

ตัวเลข PoP มักถูกเป่า vendor บอก "300+ PoP" แต่จริงๆ อาจจะ 280 อยู่ในอเมริกาเหนือกับยุโรป อาเซียนมีแค่ 5

วิธีตรวจสอบง่ายมาก: ขอ anycast IP ของ vendor แล้วรัน mtr จาก VPS ในหลายภูมิภาค (กรุงเทพ, Singapore, Tokyo, Frankfurt, Sao Paulo) RTT เกิน 80ms ถือว่าใช้ไม่ได้

ถ้าผู้ใช้ในอาเซียนต้อง route CDN กลับ US West นั่นคือ 150ms+ ขั้นต่ำ เวลาโหลดรูปใน frontend จะช้าจนรู้สึกได้ ในงาน B2B SaaS โดยเฉพาะ e-commerce กับ media ส่งผลกระทบต่อ conversion rate โดยตรง

lpic.cc อยู่ตรงไหนในภาพนี้

พูดตรงๆ: lpic.cc ตอนนี้ไม่ใช่โซลูชัน enterprise B2B

เราเน้นนักพัฒนาส่วนตัว, blogger, และผู้ใช้ฟอรัม ด้วยอัปโหลดฟรี, ป้องกันด้วยรหัสผ่าน, เก็บ 30 วัน Backend รันบนคลาวด์อ็อบเจ็กต์สตอเรจพร้อม API ที่สร้างเอง สถาปัตยกรรมใช้เทคนิคหลายอย่างที่กล่าวในบทความนี้ (Pre-signed URL, webhook, EXIF processing) แต่ไม่มี enterprise SLA, ไม่มี SOC 2 certification, ไม่มี DPA

ถ้าคุณเป็น tech lead กำลังประเมิน image hosting ระดับ production เอา checklist นี้ไปใช้กับ Cloudinary, imgix, Cloudflare Images, หรือ ImageKit ถ้าต้องการโซลูชันเบาๆ สำหรับใช้ส่วนตัวหรือทีมเล็ก ลอง lpic.cc ดู — อัปโหลดฟรีที่นี่ แล้วดูว่าตอบโจทย์มั้ย

คำถามที่พบบ่อย

Q1: ทีมเล็กจำเป็นต้องใช้ image hosting ระดับ enterprise มั้ย?

ไม่จำเป็น ถ้าต่ำกว่า 10K MAU และ traffic ไม่เกิน 500GB/เดือน สร้าง layer บน Cloudflare R2 + Workers ได้ ต้นทุนต่ำกว่า $5/เดือน โซลูชัน enterprise มีคุณค่าตรง SLA, compliance, support SLA ซึ่งทีมเล็กอาจไม่จำเป็น แต่ถ้าคุณให้บริการลูกค้า B2B และสัญญากำหนด DPA ก็ไม่มีทางเลือก

Q2: S3 compatible สำคัญจริงมั้ย?

สำคัญมาก S3 คือ API มาตรฐานโดยพฤตินัย Compatible หมายความว่าใช้ SDK ที่สมบูรณ์, Terraform provider, backup tool ได้ ไม่ compatible หมายความว่าถูกล็อกกับ API เฉพาะของ vendor ค่าย้ายในอนาคตสูงมาก นี่คือสัญญาณ vendor lock-in แบบตำราเรียน

Q3: Webhook กับ polling ต่างกันยังไง? ทำไมต้อง webhook?

Polling คือถามทุก N วินาทีว่า "เสร็จยัง?" Webhook คือ vendor push แจ้งเตือนเมื่อเสร็จ ต่างกันที่ latency (วินาที vs มิลลิวินาที) และต้นทุน (quota API call ของคุณ vs ศูนย์) สำหรับ event อย่างอัปโหลดเสร็จ, transcode เสร็จ, สแกนไวรัส — ไม่มี webhook ทำ real-time UX ไม่ได้

Q4: SLA 99.9% กับ 99.99% ต่างกันเยอะจริงมั้ย?

ตัวเลขคือ 43 นาที vs 4 นาทีต่อเดือน สำคัญแค่ไหนขึ้นอยู่กับ business ถ้าเป็นรูปสินค้าใน checkout flow ของ e-commerce ทุกนาทีที่ down คือรายได้หาย ถ้าเป็นรูปในคู่มือพนักงาน 99.9% หรือ 99% ก็ไม่เป็นไร จับคู่ SLA requirement กับผลกระทบ business จริงแทนที่จะไล่ตัวเลขสูงๆ

Q5: Cloudflare R2 zero egress — เลือกเลยได้มั้ย?

ไม่ใช่เสมอไป Zero egress ของ R2 ใช้ได้เฉพาะในเครือข่าย Cloudflare (ผ่าน Workers หรือ CDN) ดึงข้อมูลจาก R2 ไป cloud อื่นยังมีค่าใช้จ่าย นอกจากนี้ราคา Class A operation (เขียน) ของ R2 ไม่ถูก สำหรับ workload เขียนเยอะอ่านน้อย R2 อาจไม่ประหยัด คำนวณต้นทุนรวมจากสัดส่วน read/write จริง

เอกสารอ้างอิง

#image hosting API#S3 compatible#SLA#CDN#Webhook#จัดซื้อองค์กร#DevOps#Signed URL#PDPA
H

เขียนโดย

Harvey Zhang

ผู้ร่วมก่อตั้ง & CTO

วิศวกร Backend และสถาปนิกระบบ