คำตอบสั้น: Cloudflare Developer Platform คือชุดบริการสำหรับสร้างแอปพลิเคชันจริงบนเครือข่ายของ Cloudflare ไม่ใช่แค่ CDN หรือ WAF มีทั้งคอมพิวต์ (Workers, Containers, Durable Objects, Workflows), สตอเรจ (R2, D1, KV, Hyperdrive), คิวและ data pipeline, บริการรูปภาพ วิดีโอ และ WebRTC รวมถึงชุด AI ครบวงจร จุดที่ต่างจากคลาวด์เจ้าอื่นในเชิงเศรษฐศาสตร์คือ Workers คิดเงินตาม CPU time ไม่ใช่ wall-clock และ R2 ไม่คิดค่า egress เลย เหมาะกับทีมที่ต้องการ latency ต่ำทั่วโลก บิลที่คาดเดาได้ และงานที่กระจายเป็นคำขอสั้นจำนวนมาก แต่ไม่เหมาะกับ monolith เก่าที่พึ่ง native dependency หรืองานที่กินแรมหนักและรันยาว
ทีมส่วนใหญ่ในไทยรู้จัก Cloudflare จากด้าน DNS, CDN, WAF และ DDoS protection ซึ่งเป็นธุรกิจดั้งเดิมของบริษัท แต่ในช่วงห้าถึงหกปีหลัง Cloudflare ค่อย ๆ เปลี่ยนตัวเองเป็นแพลตฟอร์มสำหรับ deploy แอปพลิเคชันเต็มรูปแบบ ทุกวันนี้คุณเขียน API ทั้งตัว เก็บไฟล์ เก็บฐานข้อมูล ต่อคิว รัน LLM ทำวิดีโอคอล และส่งอีเมล ได้โดยไม่ต้องแตะ VM หรือ Kubernetes สักตัว สิ่งที่ยังไม่เปลี่ยนคือความเข้าใจของตลาด หลายทีมจึงยังมองข้ามทั้งแพลตฟอร์มไป เพราะคิดว่าเป็นแค่ชั้น cache หน้าเว็บ
ปัญหาจริงที่วิศวกรเจอไม่ใช่ว่า Cloudflare ทำอะไรได้บ้าง หน้าเอกสารของ Cloudflare ตอบเรื่องนั้นได้ดีกว่าเราแน่นอน ปัญหาคือ จะหยิบ primitive ตัวไหนมาใช้กับปัญหาไหน เพราะบริการหลายตัวดูซ้อนทับกัน KV กับ D1 กับ Durable Objects ต่างก็ "เก็บข้อมูล" แต่ใช้ผิดตัวเมื่อไหร่ ระบบจะพังในแบบที่แก้ยากมากตอนขึ้น production เช่นเดียวกับ Queues กับ Workflows กับ Pipelines ที่ล้วน "ประมวลผลงานเบื้องหลัง" แต่คนละความหมายโดยสิ้นเชิง การเลือกผิดในสัปดาห์แรกมักกลายเป็นหนี้ทางสถาปัตยกรรมในเดือนที่หก
บทความนี้จึงเป็นแผนที่ ไม่ใช่คู่มือ เราจะไล่ทีละหมวดตามที่ Cloudflare จัดกลุ่มเอง บอกว่าแต่ละบริการคืออะไร เหมาะกับงานแบบไหน และที่สำคัญกว่านั้นคือ เมื่อไหร่ที่ไม่ควรใช้ ปิดท้ายด้วยตารางตัดสินใจ ข้อจำกัดที่แก้ไม่ได้ และภาพว่าการย้ายระบบจริงหน้าตาเป็นอย่างไร ราคาทุกตัวที่อ้างในบทความนี้เป็นราคา ณ กรกฎาคม 2026
คอมพิวต์และการรันงาน
นี่คือหัวใจของแพลตฟอร์ม ทุกอย่างที่เหลือมีไว้ให้คอมพิวต์เรียกใช้ Cloudflare มีหน่วยประมวลผลอยู่หลายแบบซึ่งไม่ได้แข่งกันเอง แต่แบ่งกันตามอายุงานและลักษณะ state ถ้าอยากเห็นการเปรียบเทียบแบบละเอียดว่าตัวไหนต่างกันอย่างไรในเชิงโมเดลการรัน เราแยกไว้ในบทความ บริการคอมพิวต์ของ Cloudflare อธิบายทีละตัว
Workers
Workers คือ runtime หลักของแพลตฟอร์ม โค้ด JavaScript, TypeScript, Python หรือ WebAssembly ของคุณรันใน V8 isolate ที่เมืองใกล้ผู้ใช้ที่สุด ไม่ใช่คอนเทนเนอร์ จึงแทบไม่มี cold start และไม่ต้องคิดเรื่อง region เลย ประเด็นเศรษฐศาสตร์ที่สำคัญที่สุดของทั้งแพลตฟอร์มอยู่ตรงนี้ คือ Workers คิดเงินตาม CPU time ไม่ใช่ wall-clock เวลาที่โค้ดคุณนั่งรอฐานข้อมูลหรือรอ API ปลายทางตอบ ไม่ถูกคิดเงิน แพลน Workers Paid อยู่ที่ 5 ดอลลาร์ต่อเดือน รวม 10 ล้านรีเควสต์และ 30 ล้าน CPU-มิลลิวินาที ส่วนเกินคิด 0.30 ดอลลาร์ต่อล้านรีเควสต์ และ 0.02 ดอลลาร์ต่อล้าน CPU-ms (ราคา ณ กรกฎาคม 2026)
เหมาะกับ API, BFF, edge middleware, auth, personalization, A/B routing และงานที่เป็นคำขอสั้น ๆ ปริมาณมหาศาล จุดที่ไม่ควรใช้คือเมื่อคุณต้องการหน่วยความจำเกิน 128 MB ต้องการระบบไฟล์ หรือมีไลบรารีที่ต้อง compile เป็น native binary เรารวมกรณีที่ควรถอยไว้ในบทความ เมื่อไหร่ที่ไม่ควรใช้ Cloudflare Workers และเทียบโมเดลบิลกับ Lambda แบบตัวเลขจริงไว้ใน Cloudflare Workers เทียบกับ AWS Lambda
Workers for Platforms
ถ้าธุรกิจของคุณคือการให้ลูกค้าเขียนโค้ดของเขาเองแล้วรันบนระบบของคุณ เช่น SaaS ที่มีระบบปลั๊กอิน, e-commerce ที่ให้ร้านค้าเขียน logic คิดค่าส่งเอง หรือ low-code platform Workers for Platforms คือสิ่งที่คุณต้องใช้ มันให้คุณ deploy Worker ของลูกค้าหลักหมื่นหลักแสนตัวไว้ใน namespace แยกกัน โดยมี dispatch Worker ของคุณเป็นด่านหน้าที่ตัดสินว่าจะส่งรีเควสต์ไปหา tenant ไหน พร้อมบังคับ limit และ policy ของคุณก่อนโค้ดลูกค้าจะทำงาน อย่าเอามาใช้ถ้าคุณแค่มี Worker หลายตัวของทีมตัวเอง เพราะนั่นคือ Workers ธรรมดาที่มีหลาย script ก็พอ
Durable Objects
Durable Objects คือคำตอบของ Cloudflare ต่อปัญหา "ต้องมีจุดเดียวที่ถูกต้อง" ในระบบกระจาย แต่ละ object มี id ของตัวเอง และทั่วโลกจะมี instance ที่ active อยู่เพียงตัวเดียวต่อ id นั้น ทำให้เขียน counter, lock, rate limiter, ห้องแชท, สถานะเกม หรือ collaborative editor ได้โดยไม่ต้องกลัว race condition และไม่ต้องพึ่ง Redis กลาง WebSocket hibernation ช่วยตัดต้นทุนเวลา connection เปิดค้างแต่ไม่มีข้อความวิ่ง ทำให้ระบบที่มีคนออนไลน์เยอะแต่คุยกันน้อยราคาถูกลงมาก
ข้อควรระวังคือ soft limit ประมาณ 1,000 รีเควสต์ต่อวินาทีต่อ object หนึ่งตัว ถ้าคุณออกแบบให้ traffic ทั้งระบบวิ่งเข้า object เดียว คุณเพิ่งสร้างคอขวดขึ้นมาเอง ต้องแบ่ง object ตาม key ที่กระจายจริง เช่น ต่อห้อง ต่อผู้ใช้ ต่อ order เราเทียบกับการใช้ Redis แบบตรง ๆ ไว้ที่ Durable Objects เทียบกับ Redis
Containers
Containers คือทางออกสำหรับทุกอย่างที่ Workers ทำไม่ได้ คุณ push image ของคุณขึ้นไป แล้วเรียกใช้จาก Worker เหมือนเรียกฟังก์ชัน instance ถูกปลุกตามต้องการและดับเองเมื่อไม่มีงาน ขนาดเครื่องเลือกได้ตั้งแต่ lite (1/16 vCPU, 256 MiB, ดิสก์ 2 GB) ไปจนถึง standard-4 (4 vCPU, 12 GiB, ดิสก์ 20 GB) และเพดานสูงสุดของ instance ปัจจุบันอยู่ที่ 4 vCPU กับ 12 GiB ใช้กับ ffmpeg, headless tool, ไลบรารี Python ที่ต้องคอมไพล์, งานที่ต้องมีระบบไฟล์จริง หรือโค้ดภาษาที่ไม่มีทางไปอยู่บน V8 ได้ ใช้ได้เฉพาะแพลน Workers Paid
สิ่งที่ Containers ไม่ใช่คือ Kubernetes ทดแทน อย่าย้ายทั้งคลัสเตอร์มาที่นี่ มันถูกออกแบบให้เป็น "กล่องเสริม" ที่ Worker เรียกใช้เป็นครั้งคราวสำหรับงานที่หนักหรือแปลก ไม่ใช่ที่รัน service mesh ทั้งชุดตลอด 24 ชั่วโมง
Workflows
Workflows คือ durable execution engine คุณเขียนงานเป็นลำดับ step แต่ละ step ถูกบันทึกผลไว้ ถ้าล้มกลางทางระบบจะ retry เฉพาะ step ที่ล้ม ไม่ต้องเริ่มใหม่ทั้งหมด และ workflow หนึ่งตัวรอข้ามวันข้ามสัปดาห์ได้ เหมาะกับ onboarding flow, ขั้นตอนอนุมัติ, การ sync ข้อมูลกับระบบภายนอกที่ล่มบ่อย, การประมวลผลไฟล์หลายขั้น หรือ AI agent ที่ต้องเรียกเครื่องมือหลายรอบ Cloudflare ประกาศว่าจะเปลี่ยนมาคิดเงินแบบต่อ step ไม่เร็วกว่า 10 สิงหาคม 2026 โดยแพลน Paid รวม 500,000 step ต่อเดือน หลังจากนั้นคิด 0.80 ดอลลาร์ต่อ 100,000 step เพิ่ม อย่าใช้ Workflows แทน queue ธรรมดาสำหรับงานสั้น ๆ ที่แค่อยาก fire-and-forget เพราะคุณจะจ่ายค่า orchestration ที่ไม่ได้ใช้
Browser Run (เดิมชื่อ Browser Rendering)
Browser Run คือ headless Chrome ที่รันอยู่บนเครือข่ายของ Cloudflare สั่งงานผ่าน Puppeteer, Playwright, Chrome DevTools Protocol หรือผ่าน Quick Actions ซึ่งเป็น HTTP endpoint สำเร็จรูปสำหรับ screenshot, PDF, markdown, scrape และ crawl โดยไม่ต้อง deploy โค้ดเลย ใช้กับการสร้าง PDF ใบเสร็จ, OG image, e2e test, การ pre-render หน้าให้ crawler และการดึงข้อมูลจากเว็บที่ render ด้วย JavaScript ใช้ได้ทั้งแพลนฟรีและแพลนจ่ายเงิน จุดที่ต้องระวังคืออย่าใช้เป็น scraper ปริมาณมหาศาลแบบต่อเนื่อง เพราะ browser time คิดเงิน และงานที่ทำได้ด้วย HTTP fetch ธรรมดาไม่ควรเปิด browser ขึ้นมาเลย
สถานะและสตอเรจ
หมวดนี้เป็นจุดที่ทีมพลาดกันมากที่สุด เพราะบริการสี่ห้าตัว "เก็บข้อมูล" เหมือนกันหมด แต่มีโมเดลความสอดคล้อง (consistency) และรูปแบบการเข้าถึงคนละเรื่อง เราแยกอธิบายทีละตัวพร้อมตัวอย่างการใช้งานไว้ที่ บริการสตอเรจของ Cloudflare อธิบายทีละตัว ส่วนตรงนี้จะสรุปให้พอเลือกได้
R2
R2 คือ object storage ที่เข้ากันได้กับ S3 API ค่าจัดเก็บอยู่ที่ 0.015 ดอลลาร์ต่อ GB ต่อเดือน และ ไม่คิดค่า egress เลย ไม่ว่าจะดึงข้อมูลออกเท่าไหร่ (ราคา ณ กรกฎาคม 2026) แพลนฟรีให้ 10 GB พร้อม 1 ล้าน Class A operations และ 10 ล้าน Class B operations ต่อเดือน นี่คือบริการที่ให้เหตุผลทางธุรกิจชัดที่สุดในการย้ายมา Cloudflare เพราะบิลของงานที่มีไฟล์ให้ดาวน์โหลด วิดีโอ ภาพ หรือ dataset มักถูกครอบงำด้วยค่า egress ไม่ใช่ค่าจัดเก็บ
ที่ R2 ไม่เหมาะคืองานที่ต้องการ ecosystem ของ AWS แบบแน่น เช่น Glacier tiering แบบละเอียด, S3 Object Lambda หรือ workflow ที่ผูกกับ EMR และ Athena โดยตรง เราเทียบต้นทุนกับ S3 ทีละแกนไว้ที่ Cloudflare R2 เทียบกับ Amazon S3
D1
D1 คือฐานข้อมูล SQL แบบ serverless ที่สร้างบน SQLite ใช้ผ่าน binding จาก Worker โดยตรง เร็ว ราคาถูก และตั้งขึ้นมาได้ในไม่กี่วินาที ข้อจำกัดที่ต้องรู้ตั้งแต่บรรทัดแรกคือ 10 GB ต่อฐานข้อมูล และเพิ่มไม่ได้ ซึ่งไม่ใช่ข้อบกพร่อง แต่เป็นเจตนา D1 ถูกออกแบบให้คุณสร้างฐานข้อมูลหลายพันตัว แยกต่อ tenant ต่อผู้ใช้ ต่อ workspace ไม่ใช่ก้อนกลางก้อนเดียวของทั้งบริษัท
ถ้าโดเมนของคุณเป็น multi-tenant SaaS ที่แต่ละลูกค้ามีข้อมูลไม่กี่ร้อยเมกะไบต์ D1 คือของที่ใช่ ถ้าคุณมีตารางกลางที่โตเกิน 10 GB ต้องการ JSONB, PostGIS, materialized view หรือ extension อื่น ๆ อย่าฝืน ให้ใช้ PostgreSQL ต่อไป รายละเอียดการเทียบอยู่ใน D1 เทียบกับ PostgreSQL
Workers KV
KV คือ key-value store ที่ replicate ไปทั่วโลกและ optimize มาเพื่อการอ่านโดยเฉพาะ อ่านเร็วมากจากทุกที่ แต่เป็น eventually consistent การเขียนอาจใช้เวลาถึงระดับสิบวินาทีกว่าจะเห็นค่าใหม่ครบทุก edge ใช้กับ feature flag, routing table, config, redirect map, cache ของ token ที่หมดอายุนาน และอะไรก็ตามที่อ่านบ่อยมากแต่เขียนน้อย อย่าใช้ KV กับข้อมูลที่ต้องอ่านค่าล่าสุดทันทีหลังเขียน เช่น ยอดคงเหลือ สต็อกสินค้า หรือสถานะ session ที่เพิ่ง revoke ไป งานพวกนั้นคือหน้าที่ของ Durable Objects หรือ D1
Durable Objects ในฐานะสตอเรจ
นอกจากเป็นหน่วยคอมพิวต์ Durable Objects ยังมีสตอเรจของตัวเองที่ strongly consistent และมี transaction จริง ปัจจุบันใช้ SQLite เป็น backend ทำให้เขียน query SQL ภายใน object ได้ ต่างจาก KV ตรงที่คุณอ่านค่าที่เพิ่งเขียนไปเสร็จได้ทันทีเสมอ เพราะมีอินสแตนซ์เดียวที่ถือความจริงนั้นอยู่ เหมาะกับ state ที่ผูกกับ entity ชัดเจน เช่น สถานะห้องประชุม สถานะ order ตะกร้าสินค้า หรือ session ของผู้ใช้คนหนึ่ง ไม่เหมาะกับการ query ข้ามหลาย object พร้อมกัน เพราะไม่มี global index ให้ join ข้าม object
Hyperdrive
Hyperdrive แก้ปัญหาที่ทำให้หลายทีมเลิกใช้ Workers ตั้งแต่วันแรก คือ Worker หนึ่งตัวรันได้พร้อมกันเป็นหมื่นตัวทั่วโลก แต่ PostgreSQL รับ connection ได้จำกัด Hyperdrive ทำ connection pooling ไว้ให้ที่ edge พร้อม cache ผลลัพธ์ query อ่าน ทำให้คุณต่อฐานข้อมูลเดิมที่อยู่บน AWS, GCP, Neon หรือในดาต้าเซ็นเตอร์ไทยได้โดยไม่ต้องย้าย และฟรีสำหรับผู้ใช้ Workers Paid
กับดักที่ต้องจำให้ขึ้นใจ คือ Hyperdrive ไม่ล้าง cache เมื่อมีการเขียน ค่า max_age เริ่มต้นคือ 60 วินาที แปลว่าถ้าคุณชี้ config ที่เปิด cache ไปยังตาราง sessions หรือ permissions ผู้ใช้ที่คุณเพิ่งแบนอาจยังเข้าระบบได้อีกนาทีหนึ่ง ให้ปิด cache สำหรับตารางที่อ่อนไหว และเปิดเฉพาะ query ที่ทนความล่าช้าได้ วิธีตั้งค่าและรูปแบบการใช้จริงอยู่ที่ ต่อ PostgreSQL เข้ากับ Workers ผ่าน Hyperdrive
คิวและ Data Pipeline
สามบริการนี้ดูเหมือน "งานเบื้องหลัง" เหมือนกัน แต่คนละหน้าที่โดยสิ้นเชิง Queues คือการส่งงานให้ consumer, Pipelines คือการเทข้อมูลจำนวนมากลง data lake, ส่วน Email Service คือ I/O ช่องทางอีเมล เราลงรายละเอียดพร้อมโค้ดตัวอย่างไว้ที่ Queues, Pipelines และ Email Workers ใช้ต่างกันอย่างไร
Queues
Queues คือ message queue แบบ managed ที่ producer เป็น Worker และ consumer ก็เป็น Worker ราคา 0.40 ดอลลาร์ต่อล้าน operation โดยรวม 1 ล้าน operation ไว้แล้ว ข้อความหนึ่งใหญ่ได้สูงสุด 128 KB (ราคา ณ กรกฎาคม 2026) มีทั้ง batching, retry และ dead-letter queue ใช้เมื่อต้องการตัดงานหนักออกจาก request path เช่น ส่งเมล ประมวลผลรูป ยิง webhook ต่อ หรืออัปเดตระบบภายนอกที่ช้า สิ่งที่ต้องระวังคือ consumer มีเพดานการรัน 15 นาทีต่อครั้ง และข้อความเกิน 128 KB ต้องเอา payload ไปพักที่ R2 แล้วส่งแค่ key มาในคิว
Pipelines
Pipelines รับ event จำนวนมากผ่าน HTTP endpoint หรือ Worker binding แปลงด้วย SQL แล้วเขียนลง R2 เป็น Apache Iceberg table หรือไฟล์ Parquet และ JSON พร้อมการันตี exactly-once ใช้กับ clickstream, log ของแอป, telemetry จาก IoT และทุกอย่างที่ปลายทางคือ data warehouse หรือ lakehouse ปัจจุบันอยู่ในสถานะ open beta สำหรับผู้ใช้ Workers Paid และยังไม่คิดเงินนอกเหนือจากค่าจัดเก็บและ operation ของ R2 ตามปกติ อย่าใช้ Pipelines แทน Queues สำหรับงานที่ต้องการ "ทำอะไรสักอย่างต่อหนึ่งข้อความ" เพราะมันคือระบบ ingest ไม่ใช่ระบบสั่งงาน
Email Service (เดิมคือ Email Routing และ Email Workers)
Email Service ทำให้อีเมลกลายเป็น I/O อีกช่องหนึ่งของโค้ดคุณ ขาเข้าคุณรับเมลเข้ามาเป็น event ใน Worker แล้วแยกวิเคราะห์ ตอบกลับ สร้าง ticket หรือส่งต่อได้ตามใจ ขาเข้าไม่คิดเงินและไม่จำกัดจำนวน ส่วนขาออกคิด 0.35 ดอลลาร์ต่อ 1,000 ฉบับบนแพลน Paid (ราคา ณ กรกฎาคม 2026) เหมาะกับ transactional email, ระบบ support ที่รับเมลเข้ามาเป็นตั๋ว และ inbound automation ไม่เหมาะกับการทำ marketing campaign ขนาดใหญ่ที่ต้องการเครื่องมือด้าน deliverability, warm-up IP และรายงานเชิงการตลาด ซึ่งเป็นงานของ ESP เฉพาะทาง
เรียลไทม์และมีเดีย
หมวดนี้เป็นชุดบริการที่ทีมไทยมองข้ามบ่อยที่สุด ทั้งที่ต้นทุนวิดีโอและรูปภาพมักเป็นก้อนใหญ่ในบิลคลาวด์ เราแยกอธิบายทั้งหมวดพร้อมกรณีใช้งานไว้ที่ บริการเรียลไทม์และมีเดียของ Cloudflare
Images
Images ทำสองอย่าง คือเก็บรูปให้ และแปลงรูปให้ตามพารามิเตอร์ใน URL หรือผ่าน binding ใน Worker แพลนฟรีให้ transformation ที่ไม่ซ้ำกัน 5,000 ครั้งต่อเดือน สำหรับรูปที่เก็บไว้ที่อื่นเช่น R2 แพลน Paid คิด 0.50 ดอลลาร์ต่อ 1,000 unique transformation ที่เกินโควตา ค่าจัดเก็บ 5 ดอลลาร์ต่อ 100,000 รูปต่อเดือน และค่าส่ง 1 ดอลลาร์ต่อ 100,000 รูปต่อเดือน (ราคา ณ กรกฎาคม 2026) เหมาะกับ e-commerce, CMS และ user-generated content ที่ต้องการหลายขนาดจากต้นฉบับเดียว ถ้าคุณมีระบบแปลงรูปที่ดีอยู่แล้วและรูปแทบไม่เปลี่ยน การย้ายมาอาจไม่คุ้มค่าแรง
Stream
Stream คือระบบวิดีโอครบวงจร อัปโหลด เข้ารหัส เก็บ และเล่น ทั้ง on-demand และ live ผ่าน API เดียว คิดเงินสองแกนเท่านั้น คือ 5 ดอลลาร์ต่อ 1,000 นาทีที่เก็บ และ 1 ดอลลาร์ต่อ 1,000 นาทีที่ส่งถึงผู้ชม โดยการอัปโหลดและการ encode ฟรี และไม่มีค่า egress แยกต่างหาก (ราคา ณ กรกฎาคม 2026) ขนาดไฟล์ไม่มีผลต่อค่าจัดเก็บ นับตามความยาววิดีโออย่างเดียว จุดที่ต้องพิจารณาคือถ้าผู้ชมของคุณดูวิดีโอเดิมซ้ำ ๆ จำนวนมหาศาล โมเดลนับนาทีที่ส่งอาจแพงกว่าการวางไฟล์ HLS ไว้บน R2 แล้วจ่ายค่าจัดเก็บอย่างเดียว ต้องคำนวณจากพฤติกรรมผู้ชมจริง
RealtimeKit
RealtimeKit คือชั้นบนสุดของกลุ่มเรียลไทม์ ให้ SDK และ UI component สำเร็จรูปสำหรับวิดีโอคอลและเสียง พร้อม primitive อย่าง meeting, participant, preset, stage, waiting room รวมถึงฟีเจอร์อย่างการอัดวิดีโอ แชท โพล breakout room และ virtual background คิดเงินตามนาที เหมาะกับ telehealth, ห้องเรียนออนไลน์, webinar และ social video ที่คุณอยากได้ของใช้งานได้ภายในไม่กี่วัน ไม่ใช่ไม่กี่เดือน อย่าเลือกตัวนี้ถ้าคุณต้องการคุมทุก track และทุก signaling เอง
TURN
TURN คือบริการ relay สำหรับ WebRTC ที่ทำให้ผู้ใช้ซึ่งอยู่หลัง NAT หรือ firewall องค์กรที่เข้มงวดยังเชื่อมต่อกันได้ ไลบรารี WebRTC ทั่วไปเรียกใช้เองอัตโนมัติ คุณแทบไม่ต้องเขียนโค้ดเพิ่ม ฟรีเมื่อใช้คู่กับ Realtime SFU ถ้าใช้เดี่ยวคิด 0.05 ดอลลาร์ต่อ GB โดยมี 1,000 GB แรกของทุกเดือนฟรี (ราคา ณ กรกฎาคม 2026) นี่คือส่วนประกอบที่คุณต้องมีถ้าทำ WebRTC เพื่อผู้ใช้ในองค์กรใหญ่หรือเครือข่ายมือถือไทยที่มี CGNAT ไม่ใช่ของที่เลือกใช้หรือไม่ใช้ตามใจ
Selective Forwarding Unit
Realtime SFU คือ media server ระดับล่างที่ส่งต่อ audio, video และ data track ระหว่างผู้เข้าร่วม โดยไม่ผูกกับแนวคิด "ห้อง" ให้คุณ มีแค่ session และ track แบบ pub/sub คุณต้องจัดการ presence และ signaling เอง คิด 0.05 ดอลลาร์ต่อ GB ที่ส่งออก โดย 1,000 GB แรกต่อเดือนฟรี (ราคา ณ กรกฎาคม 2026) เลือกใช้เมื่อทีมคุณมีความรู้ WebRTC ลึกและต้องการสถาปัตยกรรมที่ไม่เข้าพิมพ์นิยม ถ้าคุณแค่อยากได้ห้องประชุมที่ใช้งานได้ ให้ใช้ RealtimeKit แล้วประหยัดเวลาไปหลายเดือน
AI
ชุด AI ของ Cloudflare ไม่ได้พยายามแข่งกับโมเดล frontier แต่พยายามเป็นที่ที่คุณ ประกอบ ระบบ AI ขึ้นมา โดยมีทั้ง inference, vector store, ชั้นควบคุม และ RAG สำเร็จรูป เราอธิบายวิธีต่อทั้งสี่ตัวเข้าด้วยกันไว้ที่ AI stack ของ Cloudflare อธิบายทั้งชุด
Workers AI
Workers AI ให้คุณเรียกโมเดลโอเพนซอร์สที่รันบน GPU ในเครือข่ายของ Cloudflare ผ่าน binding บรรทัดเดียวใน Worker มีทั้งโมเดลข้อความ embedding รูปภาพ เสียง และโมเดลจัดหมวดหมู่ ข้อดีคือ latency ต่ำเพราะรันข้างโค้ดคุณ และข้อมูลไม่ต้องออกไปหา third-party ข้อจำกัดที่ต้องพูดตรง ๆ คือโมเดลที่ให้มามีขนาดเล็กกว่าโมเดล frontier อย่าง Claude หรือ GPT ระดับบนสุดอย่างมีนัยสำคัญ งาน reasoning ยาว ๆ หรือ context ขนาดใหญ่มากยังไม่ใช่ที่ทางของมัน เราวัดเทียบทีละงานไว้ที่ Workers AI เทียบกับ OpenAI
Vectorize
Vectorize คือ vector database สำหรับ semantic search และ RAG ต่อกับ Workers AI ได้โดยตรง ข้อจำกัดปัจจุบันที่ควรออกแบบเผื่อไว้คือ vector หนึ่งตัวมีได้สูงสุด 1,536 มิติ metadata ต่อ vector ไม่เกิน 10 KiB จำนวน vector ต่อ index สูงสุด 10 ล้านตัว และ topK สูงสุด 50 เมื่อขอค่า metadata หรือ value กลับมาด้วย ถ้าคอร์ปัสของคุณใหญ่กว่านั้นมาก หรือคุณต้องการ hybrid search แบบซับซ้อนพร้อม re-ranking หลายชั้น ให้พิจารณา vector database เฉพาะทาง
AI Gateway
AI Gateway คือ proxy ที่คุณวางไว้หน้า LLM ทุกตัวที่คุณใช้ ไม่ว่าจะเป็น OpenAI, Anthropic, Workers AI หรือเจ้าอื่น แล้วได้ caching, rate limiting, retry, model fallback, log ของทุก prompt และตัวเลขต้นทุนต่อ request มาฟรี ๆ นี่เป็นบริการที่ควรเปิดใช้ตั้งแต่วันแรกของทุกโปรเจกต์ AI แม้คุณจะไม่ได้ใช้ inference ของ Cloudflare เลยก็ตาม เพราะการมองไม่เห็นว่าค่า token หายไปกับ prompt ไหนคือวิธีที่เร็วที่สุดในการทำงบบานปลาย
AI Search (เดิมคือ AutoRAG)
AI Search คือ RAG แบบสำเร็จรูป ชี้ไปที่แหล่งข้อมูลของคุณ เช่น bucket ใน R2 แล้วมันจะจัดการ chunking, embedding, การ index ซ้ำเมื่อข้อมูลเปลี่ยน และการ query ด้วยภาษาธรรมชาติให้เอง มี hybrid search ผสม semantic กับ keyword, metadata filtering และ MCP endpoint ในตัวสำหรับให้ AI agent เรียกใช้ ใช้งานได้ทุกแพลน เหมาะกับ knowledge base, ค้นหาเอกสารภายใน และ agent memory ถ้าคุณต้องการควบคุมกลยุทธ์ chunking หรือ re-ranking แบบละเอียด ให้ประกอบเองด้วย Vectorize กับ Workers AI แทน
เครื่องมือรอบแพลตฟอร์ม
สิ่งที่ทำให้ Cloudflare ใช้งานจริงได้แบบทีมงานมืออาชีพไม่ใช่แค่ตัวบริการ แต่เป็นเครื่องมือรอบ ๆ ที่ทุกอย่างผูกกันด้วย configuration ไฟล์เดียว
Wrangler (CLI)
Wrangler คือ CLI ตัวเดียวที่คุณใช้ตลอดชีวิตโปรเจกต์ ตั้งแต่ init, dev บนเครื่อง, จัดการ binding, สร้าง D1, สร้าง bucket R2, จัดการ secret ไปจนถึง deploy ไฟล์ wrangler.jsonc หรือ wrangler.toml เป็นแหล่งความจริงเดียวของสถาปัตยกรรมคุณ ใครเปิดไฟล์นี้ก็รู้ทันทีว่าแอปนี้ผูกกับอะไรบ้าง ซึ่งเป็นข้อได้เปรียบที่ชัดเจนเมื่อเทียบกับกองไฟล์ Terraform หลายสิบตัว
CI/CD และ Builds
คุณต่อ repository บน GitHub หรือ GitLab เข้ากับ Cloudflare แล้วให้ build และ deploy อัตโนมัติทุกครั้งที่ push ได้ พร้อม preview URL ต่อ branch และระบบ version กับ rollback ที่ย้อนกลับไป deployment ก่อนหน้าได้ในคลิกเดียว สำหรับทีมที่มี pipeline ของตัวเองอยู่แล้ว การเรียก wrangler deploy จาก GitHub Actions ก็ทำงานได้ดีเท่ากันและคุมได้มากกว่า
Observability
Workers มี logs, metrics และ trace ในตัว เปิดใช้ได้จาก configuration และ query ได้จากแดชบอร์ด นอกจากนี้ยังส่งออกไปยังระบบภายนอกอย่าง Datadog หรือ Grafana ได้ ข้อควรรู้คือความละเอียดของ log ที่เก็บย้อนหลังมีขอบเขตของมัน ถ้าคุณต้องการเก็บ audit trail ระยะยาวเพื่อการกำกับดูแล ให้เขียน event ลง Pipelines แล้วเก็บใน R2 ในรูป Iceberg เอง อย่าพึ่ง log retention ของแพลตฟอร์มเป็นหลักฐานทางกฎหมาย
Secret Store
Secret Store เก็บ secret ระดับ account ให้คุณใช้ร่วมกันได้หลาย Worker แทนที่จะต้องตั้งค่าเดิมซ้ำในทุกโปรเจกต์ ควบคุมสิทธิ์การเข้าถึงได้ และเปลี่ยนค่าที่เดียวแล้วมีผลกับทุกที่ที่อ้างถึง ใช้กับ API key ของผู้ให้บริการภายนอก, credential ของฐานข้อมูล และ signing key เท่าที่นโยบายความปลอดภัยขององค์กรอนุญาต
ตารางตัดสินใจ ถ้าคุณต้องการ X ให้ใช้ Y
| ถ้าคุณต้องการ | ใช้ | เหตุผลสั้น ๆ |
|---|---|---|
| รันโค้ดตอบทุกรีเควสต์ ใกล้ผู้ใช้ ทั่วโลก | Workers | ไม่มี cold start คิดเงินตาม CPU time |
| state ที่ถูกต้องแม่นยำต่อผู้ใช้ ต่อห้อง ต่อ order | Durable Objects | หนึ่ง instance ต่อหนึ่ง key ไม่มี race condition |
| WebSocket ที่มีคนออนไลน์เยอะแต่เงียบเป็นส่วนใหญ่ | Durable Objects พร้อม hibernation | ไม่จ่ายค่า connection ที่ไม่มีข้อความวิ่ง |
| รันไบนารีเดิม ffmpeg หรือภาษาที่ไม่ใช่ JavaScript | Containers | มีระบบไฟล์จริง สูงสุด 4 vCPU และ 12 GiB |
| งานหลายขั้นที่รันนาน ล้มแล้วต้อง retry เฉพาะขั้นที่ล้ม | Workflows | durable execution มี state ต่อ step |
| ให้ลูกค้าของคุณ deploy โค้ดของเขาบนระบบคุณ | Workers for Platforms | แยก namespace ต่อ tenant มี dispatch Worker |
| screenshot, PDF, scraping, e2e test | Browser Run | headless Chrome พร้อม Quick Actions |
| เก็บไฟล์ วิดีโอ แบ็กอัป ที่มีคนดึงออกเยอะ | R2 | egress เป็นศูนย์เสมอ |
| ตัดค่า egress ของ S3 ให้เหลือศูนย์ | R2 พร้อม Sippy migration | S3-compatible API ย้ายทีละไฟล์ได้ |
| ฐานข้อมูล relational เล็ก ๆ หนึ่งตัวต่อลูกค้าหนึ่งราย | D1 | สร้างได้เป็นพัน เพดาน 10 GB ต่อฐาน |
| ใช้ PostgreSQL หรือ MySQL เดิมโดยไม่ย้ายฐานข้อมูล | Hyperdrive | pooling และ cache ที่ edge ฟรีบน Workers Paid |
| config, feature flag, redirect map ที่อ่านบ่อยมาก | Workers KV | อ่านเร็วทั่วโลก แต่ eventually consistent |
| counter, lock, rate limit ที่ห้ามผิดพลาด | Durable Objects | strongly consistent มี transaction |
| ตัดงานหนักออกจาก request path | Queues | batching retry และ dead-letter queue |
| เทข้อมูล event ปริมาณมากลง data lake | Pipelines | SQL transform เขียนลง R2 เป็น Iceberg หรือ Parquet |
| รับหรือส่งอีเมลจากในโค้ด | Email Service | ขาเข้าฟรี ขาออก 0.35 ดอลลาร์ต่อ 1,000 ฉบับ |
| รูปหลายขนาดจากต้นฉบับเดียว | Images | transform ผ่าน URL หรือ binding |
| วิดีโอ on-demand หรือ live streaming | Stream | คิดตามนาทีที่เก็บและนาทีที่ส่ง ไม่มีค่า egress |
| วิดีโอคอลที่ใช้งานได้ภายในไม่กี่วัน | RealtimeKit | SDK และ UI สำเร็จรูป คิดตามนาที |
| WebRTC ที่คุมทุก track เอง | Realtime SFU | media server ระดับล่าง คิด 0.05 ดอลลาร์ต่อ GB |
| ให้ WebRTC ทะลุ NAT และ firewall องค์กร | TURN | ฟรีเมื่อใช้คู่กับ SFU |
| inference ราคาถูก ใกล้ผู้ใช้ ข้อมูลไม่ออกนอก | Workers AI | โมเดลโอเพนซอร์สบน GPU ของ Cloudflare |
| semantic search และ RAG | Vectorize | สูงสุด 1,536 มิติ 10 ล้าน vector ต่อ index |
| cache, rate limit, fallback และ log ของ LLM ทุกเจ้า | AI Gateway | วางหน้า provider ไหนก็ได้ เห็นต้นทุนต่อ request |
| RAG ที่ไม่อยากประกอบเอง | AI Search | index อัตโนมัติ hybrid search มี MCP endpoint |
| deploy อัตโนมัติจาก git พร้อม preview ต่อ branch | Workers Builds | rollback กลับ deployment เก่าได้ในคลิกเดียว |
| secret ที่ใช้ร่วมกันหลาย Worker | Secret Store | เก็บระดับ account เปลี่ยนที่เดียวมีผลทุกที่ |
งานแบบไหนที่ Cloudflare ยังไม่ใช่คำตอบ
ถ้าคุณอ่านมาถึงตรงนี้แล้วรู้สึกว่าทุกอย่างฟังดูดีเกินไป นั่นคือสัญญาณว่าต้องอ่านหัวข้อนี้ให้ละเอียดที่สุด ข้อจำกัดต่อไปนี้ไม่ใช่เรื่องที่แก้ได้ด้วยการจ่ายเงินเพิ่ม หลายข้อเป็นผลจากการออกแบบสถาปัตยกรรมโดยเจตนา
128 MB คือเพดาน และเพิ่มไม่ได้ Worker หนึ่ง isolate ได้หน่วยความจำ 128 MB เท่ากันทั้งแพลนฟรีและแพลนจ่ายเงิน ไม่มีปุ่มให้กด ไม่มีแพลนไหนซื้อเพิ่มได้ ถ้าคุณต้องโหลดโมเดล ML ขนาดใหญ่เข้าหน่วยความจำ ต้องประมวลผลรูปความละเอียดสูงเป็นชุด หรือต้องอ่านไฟล์ทั้งไฟล์เข้ามาแล้วแปลง คุณจะชน OOM และวิธีเดียวคือย้ายงานนั้นไปที่ Containers หรือปล่อยไว้บนโครงสร้างเดิม
ไม่มีระบบไฟล์ Workers ไม่มี /tmp ไม่มีดิสก์ ไม่มีอะไรให้เขียนลง ไลบรารีจำนวนมากในระบบนิเวศ Node.js สมมติว่ามีระบบไฟล์อยู่เสมอ และหลายตัวจะพังเงียบ ๆ หรือพังตอน runtime บนโปรดักชัน ไม่ใช่ตอน build ยิ่งถ้าไลบรารีนั้นมี native binding ที่ต้อง compile ด้วย node-gyp คุณจะไปไม่ถึงบรรทัดแรกของโค้ดตัวเองด้วยซ้ำ
D1 ตัน 10 GB ต่อฐานข้อมูล และเพิ่มไม่ได้ ถ้า data model ของคุณมีตารางกลางที่ทุกคนใช้ร่วมกันและมันจะโตเกินสิบกิกะไบต์แน่นอน D1 ไม่ใช่ทางเลือก ไม่ใช่ "ตอนนี้ยังไม่ใช่แต่เดี๋ยวก็ได้" แต่คือไม่ใช่ ต้องเก็บ PostgreSQL ไว้แล้วต่อผ่าน Hyperdrive
เพดานเวลา 15 นาที Cron Trigger, Queue consumer และ Durable Object Alarm มีเพดานการรันที่ 15 นาทีต่อครั้ง งาน batch ที่ต้องรันสองชั่วโมงรวดต้องถูกซอยเป็นชิ้นเล็ก ๆ หรือย้ายไปอยู่ใน Workflows หรือ Containers ส่วน CPU time ของ Worker เองนั้นตั้งได้ถึง 5 นาทีบนแพลน Paid โดยค่าเริ่มต้นคือ 30 วินาที และแพลนฟรีอยู่ที่ 10 มิลลิวินาที ซึ่งเป็นคนละเรื่องกับ 15 นาทีข้างต้น อย่าสับสนกันสองตัวนี้
โมเดล AI เล็กกว่าโมเดล frontier โมเดลโอเพนซอร์สบน Workers AI ทำงานประเภท classification, embedding, สรุปข้อความ และ RAG ที่ context ไม่ยาวมากได้ดี แต่ถ้าคุณต้องการ reasoning ระดับที่โมเดลชั้นนำทำได้ คุณจะไม่ได้มันจาก Workers AI ทางออกที่ถูกต้องคือใช้โมเดลภายนอกผ่าน AI Gateway ไม่ใช่ฝืนใช้โมเดลเล็กแล้วผิดหวัง
Monolith เก่าที่มี native dependency คือของที่ไม่เข้ากัน ถ้าคุณมี Java monolith อายุสิบปีที่ต่อกับ Oracle มี stored procedure หลายพันบรรทัด มี scheduled job ที่กิน CPU เต็มเครื่องคืนละสามชั่วโมง และมีไลบรารีที่ผูกกับ glibc รุ่นเฉพาะ Cloudflare ไม่ได้แก้ปัญหานั้นให้คุณ สิ่งที่ทำได้จริงคือเอา Cloudflare มาวางเป็นชั้นหน้าของ monolith นั้น ไม่ใช่พยายามยัด monolith เข้าไปใน isolate ขนาด 128 MB
สุดท้าย ข้อจำกัดทางเทคนิคเล็ก ๆ ที่กัดตอนไม่ทันตั้งตัว ได้แก่ เพดาน 6 การเชื่อมต่อขาออกพร้อมกันต่อหนึ่ง Worker ซึ่งงานที่ยิง API ปลายทางหลายสิบตัวพร้อมกันจะเจอทันที และขนาด bundle ที่จำกัดไว้ 3 MB บนแพลนฟรีและ 10 MB แบบ gzip บนแพลนจ่ายเงิน ซึ่ง dependency tree ของ Node ที่ไม่ได้ตัดแต่งมักทะลุได้ไม่ยาก
การย้ายจริงหน้าตาเป็นอย่างไร
โครงการย้ายที่ล้มเหลวมักเริ่มด้วยประโยคว่า "เราจะย้ายไป Cloudflare" โครงการที่สำเร็จเริ่มด้วยประโยคว่า "เราจะย้ายส่วนไหนไป Cloudflare" ลำดับที่เราใช้กับลูกค้าจริงมีสี่จังหวะ และแต่ละจังหวะให้ผลตอบแทนได้ก่อนจังหวะถัดไปจะเริ่ม
หนึ่ง ประเมินก่อน เอาบิลคลาวด์ปัจจุบันมากางดูว่าเงินหายไปกับอะไร ในประสบการณ์ของเรา ค่า egress, NAT gateway, load balancer ที่รันตลอดเวลา และ instance ที่รอรับ traffic ที่ไม่เคยมา มักรวมกันเป็นสัดส่วนที่ใหญ่กว่าที่ทีมคิด จากนั้นจัด workload เป็นสามกอง คือกองที่เข้ากับ Workers ได้เลย กองที่ต้องใช้ Containers และกองที่ไม่ควรแตะ
สอง ย้ายชั้น edge ก่อน routing, authentication, rate limiting, caching, request rewriting, personalization, A/B test และ API gateway ทั้งหมดนี้ย้ายมาอยู่บน Workers ได้โดยที่ backend เดิมไม่ต้องรู้เรื่องด้วยซ้ำ มันวางทับหน้าระบบเดิมได้ตรง ๆ ให้ผลด้าน latency ทันที และเป็นการทดสอบว่าทีมของคุณทำงานกับแพลตฟอร์มนี้ได้จริงหรือไม่ โดยไม่ต้องเสี่ยงกับ data layer เลย
สาม เก็บฐานข้อมูลไว้ที่เดิม นี่คือคำแนะนำที่คนมักไม่คาดคิดจากคนที่ทำงานกับ Cloudflare อย่าย้ายฐานข้อมูล ใช้ Hyperdrive ต่อไปยัง PostgreSQL หรือ MySQL ตัวเดิมที่คุณมี ฐานข้อมูลคือส่วนที่ย้ายแล้วเจ็บที่สุดและได้ประโยชน์น้อยที่สุด ถ้าคุณเลือกย้าย ให้ย้ายทีหลัง เมื่อทุกอย่างอื่นนิ่งแล้ว และย้ายเฉพาะเมื่อมีเหตุผลชัดเจนว่าทำไม
สี่ ย้ายสตอเรจไป R2 นี่คือจังหวะที่ตัวเลขในบิลเปลี่ยนจริง เพราะ egress กลายเป็นศูนย์ ทำได้แบบค่อยเป็นค่อยไปด้วยการอ่านจาก R2 ก่อน แล้ว fallback ไปที่ S3 เมื่อไฟล์ยังไม่ถูกคัดลอกมา จนกว่าจะย้ายครบ ตัวเลขต้นทุนก่อนและหลังของเคสจริง เราแจกแจงไว้ที่ ต้นทุนการย้ายจาก AWS มา Cloudflare
ตลอดกระบวนการนี้ ทุกอย่างที่คุณย้ายควรวัดผลได้ ถ้าย้าย edge layer แล้ว p95 latency ของผู้ใช้ในกรุงเทพไม่ดีขึ้น หรือบิลไม่ลด แปลว่าคุณย้ายผิดส่วน ให้หยุดแล้วกลับไปดูการประเมินใหม่
Cipher ออกแบบและ implement ระบบบน Cloudflare Developer Platform ให้ธุรกิจในประเทศไทย ทั้งการวางสถาปัตยกรรมใหม่ตั้งแต่ต้น การย้ายบางส่วนของระบบเดิม และการประเมินว่าโครงสร้างที่คุณมีอยู่จะได้อะไรและไม่ได้อะไรจากการย้าย ถ้าคุณอยากได้ความเห็นที่ตรงไปตรงมาเกี่ยวกับสถาปัตยกรรมของคุณ รวมถึงกรณีที่คำตอบคือ "อย่าย้าย" เราคุยเรื่องนี้ได้
คำถามที่พบบ่อย
Cloudflare Workers ต่างจาก AWS Lambda อย่างไร
Workers รันบน V8 isolate ไม่ใช่คอนเทนเนอร์ จึงแทบไม่มี cold start และคิดเงินตาม CPU time ไม่ใช่เวลาที่นั่งรอ I/O ส่วน Lambda ให้หน่วยความจำได้หลายกิกะไบต์ มีระบบไฟล์ชั่วคราว และรองรับโค้ดที่พึ่ง native dependency ได้ดีกว่ามาก ถ้างานของคุณเป็นคำขอสั้นจำนวนมากที่ต้องการ latency ต่ำทั่วโลก Workers มักถูกกว่าอย่างชัดเจน แต่ถ้าเป็นงานประมวลผลหนักที่กินแรม Lambda ยังเหมาะกว่า
D1 ใช้แทน PostgreSQL ได้หรือไม่
ได้เฉพาะบางกรณีเท่านั้น D1 คือ SQLite ที่มีเพดาน 10 GB ต่อฐานข้อมูลและเพิ่มไม่ได้ ออกแบบมาให้ชาร์ดต่อผู้ใช้หรือต่อ tenant ไม่ใช่ฐานข้อมูลกลางก้อนเดียว ถ้าคุณต้องการ JSONB, extension, full-text search แบบ Postgres หรือตารางที่จะโตเกิน 10 GB ให้เก็บ PostgreSQL ไว้แล้วต่อผ่าน Hyperdrive แทน
R2 ประหยัดกว่า S3 จริงหรือไม่
จริงเมื่อคุณมีทราฟฟิกขาออกเยอะ เพราะ R2 คิดค่าจัดเก็บ 0.015 ดอลลาร์ต่อ GB ต่อเดือน และไม่คิดค่า egress เลย ในขณะที่ S3 คิดค่า egress ต่อ GB ซึ่งมักเป็นก้อนใหญ่ที่สุดในบิลของงานสื่อและไฟล์ดาวน์โหลด (ราคา ณ กรกฎาคม 2026) ถ้าข้อมูลของคุณแทบไม่เคยถูกอ่านออกนอกคลาวด์เลย ส่วนต่างจะน้อยลงมากจนอาจไม่คุ้มค่าย้าย
Workers มีเพดานหน่วยความจำเท่าไร และขยายได้หรือไม่
128 MB ต่อ isolate เท่ากันทั้งแพลนฟรีและแพลนจ่ายเงิน และไม่สามารถเพิ่มได้ไม่ว่าจะจ่ายเท่าไร ถ้างานของคุณต้องการหน่วยความจำมากกว่านั้น ให้แยกส่วนนั้นไปรันบน Containers ซึ่งเลือกขนาดได้ถึง 4 vCPU และ 12 GiB หรือปล่อยไว้บนโครงสร้างพื้นฐานเดิม
ต้องย้ายทั้งระบบมา Cloudflare ทีเดียวหรือไม่
ไม่ต้อง และไม่ควรทำด้วย วิธีที่ได้ผลคือย้ายชั้น edge ก่อน ได้แก่ routing, auth, cache และ API gateway จากนั้นเก็บฐานข้อมูลไว้ที่เดิมแล้วต่อผ่าน Hyperdrive แล้วค่อยย้ายไฟล์ไป R2 เพื่อตัดค่า egress ส่วนงานคำนวณหนักค่อยพิจารณาทีหลังหรือไม่ย้ายเลยก็ได้
Workers AI ใช้แทน OpenAI ได้หรือไม่
ใช้แทนได้ในงานที่โมเดลขนาดกลางทำได้ดีอยู่แล้ว เช่น classification, embedding, การสรุปข้อความ และ RAG ที่ context ไม่ยาวมาก โดยได้เปรียบเรื่อง latency เพราะรันในเครือข่ายเดียวกับ Worker และข้อมูลไม่ต้องออกไปหาผู้ให้บริการภายนอก แต่ถ้างานต้องการ reasoning ระดับโมเดล frontier หรือ context ยาวมาก ให้เรียกโมเดลภายนอกผ่าน AI Gateway แทน
