คู่มือลดค่าใช้จ่าย DigitalOcean 2026 — เคล็ดลับประหยัดจริง

A practical, fact-checked guide to cutting your DigitalOcean bill through right-sizing, cleanup, alerts, and smart database choices.

ค่าใช้จ่ายบน DigitalOcean มักบานปลายไม่ใช่เพราะราคาสูง แต่เพราะทรัพยากรที่สั่งซื้อไว้เกินความจำเป็นแล้วถูกลืม ไม่ว่าจะเป็น Droplet ที่ใหญ่เกินโหลดจริง Volume ที่แนบไว้แต่ไม่มีใครใช้ หรือ Snapshot เก่าที่ไม่มีใครลบ บทความนี้รวบรวมวิธีตรวจสอบและลดค่าใช้จ่ายบน DigitalOcean แบบเป็นรูปธรรม พร้อมคำสั่ง doctl ที่ใช้ตรวจสอบและจัดการได้จริง อิงราคาจริง ณ กรกฎาคม 2026

เลือกขนาด Droplet ให้พอดี (Right-sizing)

ต้นทุนก้อนใหญ่ที่สุดของบัญชี DigitalOcean ส่วนใหญ่มาจาก Droplet ที่ขนาดไม่สอดคล้องกับโหลดจริง การเช็คแบบ manual ทีละตัวในหน้า Control Panel ทำได้ แต่ถ้ามีหลายสิบ Droplet การใช้ doctl จะเร็วกว่ามาก เริ่มจากดึงรายการทั้งหมดพร้อมสเปกด้วย doctl compute droplet list --format Name,Memory,VCPUs,Disk,Status แล้วนำชื่อ Droplet ไปเทียบกับกราฟ CPU/RAM ใน Monitoring ซึ่งเป็นฟีเจอร์ฟรีในตัว ถ้า Droplet ตัวไหนใช้ CPU เฉลี่ยต่ำกว่า 20% ต่อเนื่องหลายสัปดาห์ นั่นคือสัญญาณว่าเช่าเกินความจำเป็น DigitalOcean แบ่งกลุ่ม Droplet Basic (Shared CPU) เป็นขั้นบันไดละเอียด ตั้งแต่ 512 MiB RAM/1 vCPU/10GB SSD ที่ $4/เดือน ไปจนถึง 2 GiB RAM/1 vCPU/50GB ที่ $12/เดือน หรือ 2 GiB RAM/2 vCPU/60GB ที่ $18/เดือน และ 4 GiB/2 vCPU/80GB ที่ $24/เดือน ความละเอียดของขั้นราคาทำให้ปรับลดได้ทีละขั้นโดยไม่ต้องกระโดดข้ามสเปกที่ไม่จำเป็น สิ่งที่ต้องระวังคือ Droplet กลุ่ม General Purpose (Dedicated CPU) ราคาเริ่มต้นสูงกว่ามาก คือ $63/เดือน สำหรับ 8GB RAM/2 vCPU/25GB SSD ไปจนถึง $1,260/เดือน สำหรับสเปกสูงสุด ถ้าเลือกกลุ่มนี้โดยไม่จำเป็นต้องใช้ CPU แบบ dedicated จริงๆ เช่นงาน batch processing หนักๆ จะเสียเงินเกินความจำเป็นมาก เทียบกับ Basic ที่ทำงานเว็บทั่วไปได้เพียงพอ อีกจุดที่มักถูกมองข้ามคือการคิดเงินแบบ per-second ตั้งแต่ 1 มกราคม 2026 ซึ่งคิดขั้นต่ำ 60 วินาทีหรือ $0.01 แล้วแต่ค่าไหนสูงกว่า วิธีนี้ทำให้ Droplet ที่สร้างไว้ทดสอบสั้นๆ เช่น รัน CI job หรือทดสอบ script แล้ว destroy ทันที ไม่ต้องกังวลเรื่องถูกคิดเงินเต็มชั่วโมงเหมือนผู้ให้บริการบางเจ้า การปรับขนาดทำได้ผ่าน doctl compute droplet-action resize droplet-id --size s-2vcpu-4gb --resize-disk=false โดยปิด resize-disk ถ้าต้องการลดเฉพาะ RAM/CPU และคง disk เดิมไว้ เพราะดิสก์ปรับลดขนาดย้อนกลับไม่ได้

The largest cost line item on most DigitalOcean accounts comes from Droplets whose size doesn't match the actual load. You can check each one manually in the Control Panel, but with dozens of Droplets, doctl is much faster. Start by listing everything with specs: doctl compute droplet list --format Name,Memory,VCPUs,Disk,Status, then cross-reference each Droplet name against the CPU and RAM graphs in Monitoring (a free built-in feature). If a Droplet averages CPU below 20% consistently over several weeks, that's a signal it's oversized. DigitalOcean tiers Droplet Basic (Shared CPU) in fine increments—from 512 MiB RAM/1 vCPU/10GB SSD at $4/month up to 2 GiB RAM/1 vCPU/50GB at $12/month, or 2 GiB RAM/2 vCPU/60GB at $18/month, and 4 GiB/2 vCPU/80GB at $24/month. The granular pricing ladder means you can step down without jumping over unnecessary specs. What to watch for: General Purpose Droplets (Dedicated CPU) start much higher—$63/month for 8GB RAM/2 vCPU/25GB SSD, climbing to $1,260/month at the top. Picking that tier without truly needing dedicated, non-shared CPU—like for heavy batch processing—wastes money compared to Basic for typical websites. One often-missed detail: per-second billing since January 1, 2026, with a minimum of 60 seconds or $0.01, whichever is higher. This means test Droplets spun up for short CI jobs or script validation, then destroyed immediately, don't cost a full hour's rent like some providers charge. Resize works via doctl compute droplet-action resize droplet-id --size s-2vcpu-4gb --resize-disk=false, where setting resize-disk=false keeps your existing disk if you're only dropping RAM/CPU. Note: disk shrinks are irreversible once resized down.

1. ดึงรายการ Droplet ทั้งหมดด้วย doctl compute droplet list เทียบกับกราฟ CPU/RAM ใน Monitoring ก่อนตัดสินใจ resize
2. Droplet Basic เริ่ม $4/เดือน (512 MiB) ถึง $96/เดือน (16 GiB/8 vCPU) ปรับได้ทีละขั้นบันได
3. อย่าเลือก General Purpose (Dedicated CPU) เริ่ม $63/เดือน โดยไม่จำเป็น เพราะแพงกว่า Basic ระดับเดียวกันมาก
4. ใช้ billing แบบ per-second (ขั้นต่ำ 60 วิ หรือ $0.01) ให้เป็นประโยชน์กับ Droplet ทดสอบระยะสั้น

ลบ Snapshot/Volume ที่ไม่ได้ใช้

ที่พบบ่อยในทางปฏิบัติ — snapshot และ Volume เป็นค่าใช้จ่ายแบบเงียบที่สะสมไปเรื่อยๆ โดยไม่มีใครสังเกต เพราะไม่ปรากฏเป็นตัวใหญ่ในหน้า Droplet List แต่ถูกคิดเงินแยกต่างหากทุกเดือน Volume (Block Storage) คิดที่ $0.10/GiB/เดือน เช่น Volume 100 GiB จะเสีย $10/เดือน และ 500 GiB จะเสีย $50/เดือน ส่วน Snapshot ไม่ว่าจะเป็น Droplet Snapshot หรือ Volume Snapshot คิดในอัตราเดียวกันคือ $0.06/GiB/เดือน ปัญหาที่พบบ่อยที่สุดคือ Volume ที่ถูก detach ออกจาก Droplet แล้ว เช่นตอนย้ายข้อมูลหรือ decommission เครื่องเก่า แต่ไม่มีใครลบตัว Volume ทิ้ง ทำให้ยังถูกเรียกเก็บเงินต่อเนื่องทั้งที่ไม่มีการใช้งานจริง วิธีตรวจสอบคือรัน doctl compute volume list --format ID,Name,SizeGigaBytes,DropletIDs แล้วมองหาแถวที่ช่อง DropletIDs ว่างเปล่า นั่นคือ Volume ที่ไม่ได้ผูกกับ Droplet ใดเลย เช่นเดียวกับ Snapshot ที่ควรตรวจด้วย doctl compute snapshot list --resource-type droplet --format ID,Name,ResourceId,SizeGigaBytes,Created และ doctl compute snapshot list --resource-type volume เพื่อดูว่ามี Snapshot เก่าเป็นปีที่ไม่มีความจำเป็นต้องเก็บไว้แล้วหรือไม่ แนวทางที่ใช้ได้จริงคือกำหนดนโยบายการเก็บรักษาเช่น เก็บ Snapshot ล่าสุดไว้ 3 ชุดต่อ Droplet หนึ่งตัว แล้วลบชุดเก่ากว่านั้นทิ้งด้วย doctl compute snapshot delete snapshot-id สำหรับทีมที่มี Droplet จำนวนมาก การเขียนสคริปต์เล็กๆ รันทุกสัปดาห์เพื่อ list แล้วเปรียบเทียบวันที่สร้างจะช่วยลดภาระ manual ได้มาก และควรลบ Volume ที่ไม่ใช้แล้วด้วย doctl compute volume delete volume-id หลังยืนยันว่าไม่มีข้อมูลสำคัญเหลืออยู่ ค่าใช้จ่ายจากรายการเล็กๆ เหล่านี้เมื่อสะสมหลายสิบรายการอาจรวมเป็นเงินจำนวนมากต่อเดือนโดยไม่รู้ตัว

• Volume คิด $0.10/GiB/เดือน, Snapshot (ทั้ง Droplet และ Volume) คิด $0.06/GiB/เดือน สะสมเงียบๆ ทุกเดือน
• หา Volume ที่ไม่ได้ผูกกับ Droplet ด้วย doctl compute volume list แล้วมองหาช่อง DropletIDs ว่าง
• ตรวจ Snapshot เก่าด้วย doctl compute snapshot list --resource-type droplet/volume แล้วกำหนด retention policy เช่น เก็บแค่ 3 ชุดล่าสุด
• ลบด้วย doctl compute snapshot delete และ doctl compute volume delete หลังยืนยันข้อมูลไม่สำคัญแล้ว
• เขียนสคริปต์ตรวจสอบอัตโนมัติรายสัปดาห์ถ้ามี Droplet จำนวนมาก แทนการเช็ค manual

ตั้ง Billing Alert ป้องกันบิลเซอร์ไพรส์

บิลเซอร์ไพรส์บน Cloud มักเกิดจากสาเหตุเดียวกันซ้ำๆ คือไม่มีการแจ้งเตือนล่วงหน้าเมื่อค่าใช้จ่ายเริ่มเกินงบที่ตั้งไว้ DigitalOcean มีฟีเจอร์ Billing Alert ในหน้า Control Panel ที่เมนู Billing ให้ตั้งเกณฑ์เตือนเมื่อยอดใช้จ่ายสะสมในรอบบิลถึงจำนวนที่กำหนด เช่น ตั้งเตือนที่ 80% ของงบประมาณรายเดือน เพื่อให้มีเวลาตรวจสอบและปรับก่อนที่รอบบิลจะปิด ฟีเจอร์นี้เป็นการตั้งค่าผ่านหน้าเว็บเท่านั้น ยังไม่มีคำสั่งใน doctl โดยตรงสำหรับสร้าง Billing Alert สิ่งที่ทำคู่กันได้คือ Alert Policy ของ Monitoring ซึ่งฟรีและครอบคลุม CPU, RAM, Disk, Bandwidth ของแต่ละ Droplet เพราะสาเหตุหนึ่งที่ทำให้บิลพุ่งกะทันหันคือ Bandwidth overage จาก Droplet ที่ Transfer เกินโควตาที่แถมมากับแผน เช่น Droplet $12/เดือนได้ 2,000 GiB, $24/เดือนได้ 4,000 GiB การตั้ง Alert Policy แจ้งเตือนเมื่อ bandwidth ใกล้เพดานทำได้ด้วยคำสั่งลักษณะ doctl monitoring alert-policy create --type v1/insights/droplet/public_outbound_bandwidth --value 80 --compare GreaterThan --window 5m --entities droplet-id --emails [email protected] ซึ่งช่วยจับสัญญาณผิดปกติ เช่น traffic พุ่งจาก bot หรือถูกโจมตี ก่อนที่จะกลายเป็นค่า overage ก้อนใหญ่ในบิลสิ้นเดือน แนวทางที่แนะนำคือตั้งทั้งสองชั้นพร้อมกัน คือ Billing Alert ระดับบัญชีโดยรวม และ Monitoring Alert Policy ระดับ Droplet รายตัวสำหรับ Droplet ที่มีความเสี่ยง traffic ผันผวนสูง เช่น เว็บที่เพิ่งเปิดตัวหรือ API สาธารณะ การมีสองชั้นทำให้เห็นทั้งภาพรวมค่าใช้จ่ายและจุดที่เป็นต้นเหตุเฉพาะเจาะจงได้พร้อมกัน

• ตั้ง Billing Alert ที่ Control Panel เมนู Billing เพื่อแจ้งเตือนเมื่อยอดสะสมถึงเกณฑ์ที่กำหนด (ยังไม่มีคำสั่ง doctl โดยตรง)
• Bandwidth overage เป็นสาเหตุบิลพุ่งที่พบบ่อย ตรวจโควตา transfer ต่อแผน เช่น $12/เดือน=2,000 GiB, $24/เดือน=4,000 GiB
• ใช้ doctl monitoring alert-policy create ตั้งแจ้งเตือน bandwidth/CPU รายตัว Droplet ฟรี ไม่มีค่าใช้จ่ายเพิ่ม
• ตั้งเตือนล่วงหน้าที่ 80% ของงบ ไม่ใช่ 100% เพื่อให้มีเวลาตอบสนองก่อนรอบบิลปิด
• ใช้ Billing Alert ระดับบัญชีคู่กับ Monitoring Alert ระดับ Droplet เพื่อเห็นทั้งภาพรวมและจุดต้นเหตุ

ใช้ Reserved IP เฉพาะที่จำเป็น

Reserved IP เป็น IP แบบคงที่ที่ย้ายระหว่าง Droplet ได้โดยไม่ต้องแก้ DNS มีประโยชน์มากสำหรับ Failover แต่มีเงื่อนไขราคาที่ต้องเข้าใจให้ชัดก่อนใช้งาน คือถ้า Reserved IP ผูกอยู่กับ Droplet ที่กำลังทำงานอยู่ (attached) จะไม่มีค่าใช้จ่ายเพิ่ม แต่ถ้าจองไว้แล้วไม่ได้ผูกกับ Droplet ใดเลย (unattached) จะถูกคิดเงิน $5/เดือน หรือคิดเป็นรายชั่วโมงที่ $0.01/ชั่วโมง ข้อยกเว้นคือ Reserved IPv6 ซึ่งฟรีเสมอไม่ว่าจะผูกอยู่หรือไม่ก็ตาม สถานการณ์ที่ทำให้เสียเงินโดยไม่จำเป็นคือการจอง Reserved IP ไว้ล่วงหน้าสำหรับแผน Failover ในอนาคต แล้วปล่อยว่างไว้เป็นเดือนก่อนเริ่มใช้งานจริง หรือจองไว้ตอนทดสอบระบบแล้วลืมผูกกับ Droplet ทดสอบ ทำให้ Reserved IP กลายเป็นค่าใช้จ่ายที่ไม่มีใครใช้งานจริง วิธีตรวจสอบทำได้ด้วย doctl compute reserved-ip list --format IP,DropletID,RegionSlug แล้วมองหาแถวที่ DropletID ว่างเปล่า นั่นคือ IP ที่กำลังถูกคิดเงิน $5/เดือนอยู่โดยไม่มีการใช้งาน ถ้าไม่มีแผนใช้ในระยะสั้น ควรปล่อยคืนด้วย doctl compute reserved-ip delete ip-address สำหรับสถาปัตยกรรมที่ต้องการ High Availability จริงๆ เช่นระบบที่ต้องสลับ Droplet หลักไปสำรองได้ทันทีเมื่อเกิดปัญหา Reserved IP คุ้มค่าเพราะไม่ต้องรอ DNS propagate ซึ่งอาจกินเวลาหลายนาทีถึงหลายชั่วโมง แต่สำหรับ Droplet เดี่ยวที่ไม่มีแผน Failover หรือใช้ Load Balancer อยู่แล้วซึ่งมี IP คงที่ในตัวอยู่แล้ว การใช้ Public IP ปกติของ Droplet ก็เพียงพอโดยไม่ต้องเสียค่า Reserved IP เพิ่ม

• Reserved IP ที่ผูกกับ Droplet ที่ทำงานอยู่ = ฟรี, ที่ไม่ผูก (unattached) = $5/เดือน ($0.01/ชม.)
• Reserved IPv6 ฟรีเสมอแม้ไม่ผูก ใช้แทน IPv4 ได้ถ้าไม่จำเป็นต้องรองรับ IPv4 เท่านั้น
• ตรวจ IP ที่ไม่ได้ใช้งานด้วย doctl compute reserved-ip list แล้วดูช่อง DropletID ว่างเปล่า
• ปล่อยคืน IP ที่ไม่ใช้ด้วย doctl compute reserved-ip delete เพื่อหยุดค่าใช้จ่ายรายเดือน
• ใช้ Reserved IP เฉพาะกรณี Failover จริง ถ้ามี Load Balancer อยู่แล้วอาจไม่จำเป็นต้องมี Reserved IP เพิ่ม

เทียบ Managed Database vs Self-host ด้านต้นทุน

การเปรียบเทียบ Managed Database กับการติดตั้งฐานข้อมูลเองบน Droplet ต้องดูมากกว่าตัวเลขราคาบนหน้าจอ เพราะราคาที่ถูกกว่าของการ self-host มักแลกมาด้วยเวลาและความเสี่ยงที่ไม่ได้แสดงเป็นตัวเลขชัดเจน Managed Database ของ DigitalOcean เริ่มต้นที่ระดับ Basic tier (1 vCPU, 1 GiB RAM) ราคา PostgreSQL และ MySQL อยู่ที่ $15.15/เดือน, Valkey ซึ่งเป็นชื่อใหม่ของ Managed Redis หลังเปลี่ยน license (API และคำสั่งยังเข้ากันได้กับ Redis) อยู่ที่ $15.00/เดือน และ MongoDB อยู่ที่ $15.23/เดือน ถ้าต้องการพื้นที่เก็บข้อมูลเพิ่มเติมนอกเหนือโควตาเริ่มต้น คิดที่ $0.215/GiB/เดือน เทียบกับการติดตั้งฐานข้อมูลเองบน Droplet ขนาดใกล้เคียงกัน เช่น Droplet Basic 2 GiB RAM/1 vCPU ที่ $12/เดือน หรือ 2 GiB/2 vCPU ที่ $18/เดือน ตัวเลขราคาต่อเดือนดูถูกกว่า Managed Database ชัดเจน แต่สิ่งที่ Managed Database รวมอยู่ในราคาแล้วคือ automated backup รายวัน, patch security อัตโนมัติ, high availability แบบ standby node ในระดับที่สูงกว่า Basic และ monitoring เฉพาะฐานข้อมูล ซึ่งถ้าต้อง self-host ต้องตั้งค่าเองทั้งหมด ทั้ง cron job สำหรับ pg_dump หรือ mysqldump การอัปเดต security patch ด้วยมือ และการตรวจสอบ replica เอง งานเหล่านี้กินเวลาทีมงานซึ่งมีต้นทุนแฝงที่ไม่ปรากฏในบิล DigitalOcean หลักการตัดสินใจที่ใช้ได้จริงคือ ถ้าเป็นฐานข้อมูล production ที่ธุรกิจพึ่งพา หรือทีมไม่มีคนดูแล database ops โดยเฉพาะ ค่าใช้จ่ายส่วนต่างของ Managed Database มักคุ้มกว่าความเสี่ยงข้อมูลหายหรือ downtime จาก security patch ที่ไม่ได้อัปเดต แต่ถ้าเป็นฐานข้อมูลสำหรับ dev/staging หรือ side project ที่ไม่มี SLA และทีมมีความรู้ database ops อยู่แล้ว การ self-host บน Droplet ราคาประหยัดกว่าและยังปรับแต่งค่า config ได้อิสระกว่า Managed tier

• Managed DB Basic tier: PostgreSQL/MySQL $15.15/เดือน, Valkey $15.00/เดือน, MongoDB $15.23/เดือน (1 vCPU/1 GiB RAM); storage เพิ่ม $0.215/GiB/เดือน
• Self-host บน Droplet $12-18/เดือนถูกกว่าตัวเลขหน้าบิล แต่ไม่รวม backup/patch/HA อัตโนมัติ ต้องทำเอง
• Managed Redis เปลี่ยนชื่อเป็น Valkey แล้ว (fork ที่ API เข้ากันได้) self-host เองบน Droplet ยังเรียก Redis ได้ตามปกติ

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

เทคนิคลดค่าใช้จ่ายที่กล่าวมาทั้งหมดมีประโยชน์ต่างกันไปตามลักษณะการใช้งานจริง สำหรับทีมสตาร์ทอัพขนาดเล็กที่มี Droplet ไม่กี่ตัวแต่ต้องควบคุมงบให้แน่น การตั้ง Billing Alert และตรวจ right-sizing เดือนละครั้งอาจเพียงพอแล้ว เพราะจำนวน Droplet น้อยพอที่จะตรวจด้วยมือได้ไม่ยาก แต่สำหรับเอเจนซี่หรือทีมที่ดูแล Droplet ให้ลูกค้าหลายสิบราย การตรวจ Snapshot Volume และ Reserved IP ที่ไม่ได้ใช้แบบสคริปต์อัตโนมัติรายสัปดาห์คุ้มค่ากว่ามาก เพราะค่าใช้จ่ายเล็กๆ ที่กระจายอยู่ในหลายบัญชีลูกค้ารวมกันแล้วอาจเป็นก้อนใหญ่ สภาพแวดล้อม dev/staging ที่ใช้งานเฉพาะช่วงเวลาทำงานเป็นอีกกรณีที่ได้ประโยชน์ชัดเจนจากระบบ billing แบบ per-second เช่น ทีมที่ destroy Droplet staging ตอนเลิกงานแล้วสร้างใหม่ตอนเช้าด้วยสคริปต์ที่ผูกกับ Snapshot หรือ Custom Image จะจ่ายเฉพาะช่วงที่ใช้งานจริง แทนที่จะเปิดทิ้งไว้ 24 ชั่วโมงทั้งที่ใช้งานจริงแค่ 8-10 ชั่วโมงต่อวัน วิธีนี้เหมาะกับทีมที่มี CI/CD pipeline อยู่แล้วเพราะสามารถผูกขั้นตอน destroy และ recreate เข้ากับ workflow ได้ไม่ยาก ส่วนการเทียบ Managed Database กับ self-host เหมาะกับจังหวะที่ทีมกำลังตัดสินใจสถาปัตยกรรมใหม่ หรือกำลังพิจารณาย้ายจากฐานข้อมูลที่ self-host อยู่เดิมไปเป็น Managed เพราะเริ่มมีปัญหาเรื่อง downtime จาก patch ที่ทำเอง ส่วนการตรวจสอบ Reserved IP ที่ไม่ได้ใช้เหมาะกับช่วงหลังทำ migration หรือ decommission ระบบเก่า เพราะเป็นช่วงที่มักมีทรัพยากรค้างอยู่จากการย้ายที่ไม่ได้ทำความสะอาดให้ครบ

1. ทีมเล็ก Droplet ไม่กี่ตัว ตรวจ right-sizing และ Billing Alert ด้วยมือเดือนละครั้งเพียงพอ
2. เอเจนซี่ดูแล Droplet หลายสิบบัญชี ใช้สคริปต์ doctl อัตโนมัติตรวจ Snapshot/Volume/Reserved IP รายสัปดาห์
3. dev/staging ใช้เฉพาะเวลาทำงาน destroy และ recreate Droplet ตามรอบ ใช้ประโยชน์จาก billing แบบ per-second
4. ทีมกำลังตัดสินใจสถาปัตยกรรมฐานข้อมูลใหม่ หรือย้ายจาก self-host ที่มีปัญหา downtime ควรเทียบต้นทุน Managed DB

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

ข้อผิดพลาดอันดับแรกที่พบบ่อยที่สุดคือลบ Droplet โดยไม่ตรวจสอบว่ามี Volume แนบอยู่หรือไม่ก่อน เพราะ DigitalOcean ไม่ลบ Volume ให้อัตโนมัติเมื่อ Droplet ถูกลบ เพื่อป้องกันข้อมูลหาย ผลคือ Volume ยังคงอยู่และถูกคิดเงิน $0.10/GiB/เดือนต่อไปเรื่อยๆ ทั้งที่ไม่มี Droplet ให้ใช้งานแล้ว วิธีแก้คือตรวจ doctl compute volume list หลัง decommission ทุกครั้งเป็นขั้นตอนมาตรฐาน ไม่ใช่แค่ลบ Droplet แล้วจบ ข้อผิดพลาดที่สองคือสับสนระหว่าง Droplet Basic กับ General Purpose (Dedicated CPU) เพราะทั้งสองกลุ่มมีสเปก RAM ใกล้เคียงกันในบางระดับแต่ราคาต่างกันมาก การเลือกกลุ่ม Dedicated CPU ทั้งที่งานเป็นเว็บทั่วไปที่ไม่ต้องการ CPU แบบ dedicated จริงจะเสียเงินเกินความจำเป็นตั้งแต่ $63/เดือนขึ้นไป ทั้งที่ Basic ระดับใกล้เคียงอาจเพียงพอในราคาต่ำกว่ามาก ควรตรวจสอบชื่อ slot ให้แน่ใจก่อนสร้างเสมอ ข้อผิดพลาดที่สามคือปล่อย Reserved IP ค้างไว้แบบ unattached เป็นเวลานานหลังทดสอบเสร็จ ซึ่งแต่ละ IP เสีย $5/เดือนเงียบๆ ถ้ามีหลาย IP ค้างพร้อมกันจะกลายเป็นค่าใช้จ่ายที่มองไม่เห็นในหน้า Droplet List เลย ข้อผิดพลาดที่สี่คือไม่ตั้ง Billing Alert ตั้งแต่แรก แล้วมารู้ตัวอีกทีตอนบิลสิ้นเดือนมาแล้ว ซึ่งแก้ไม่ทันเพราะรอบบิลปิดไปแล้ว และข้อผิดพลาดสุดท้ายที่พบบ่อยในทีมที่เพิ่งเริ่มใช้ Managed Database คือประเมินค่า storage เพิ่มเติมต่ำไป เพราะ storage overage คิดที่ $0.215/GiB/เดือน ซึ่งถ้าข้อมูลโตเร็วโดยไม่ได้วางแผน อาจทำให้ค่า storage เพิ่มขึ้นเกินกว่าที่งบประมาณตั้งไว้

• ลบ Droplet แล้วลืม Volume ที่แนบอยู่ ตรวจ doctl compute volume list ทุกครั้งหลัง decommission
• สับสน Basic กับ General Purpose (Dedicated CPU) ที่แพงกว่ามาก ($63/เดือนขึ้นไป) เช็คชื่อ slot ก่อนสร้างเสมอ
• ปล่อย Reserved IP unattached ค้างนาน เสีย $5/เดือนต่อ IP โดยไม่รู้ตัว

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

แนวทางที่ยั่งยืนที่สุดในการควบคุมค่าใช้จ่ายบน DigitalOcean คือทำให้การตรวจสอบเป็นกิจวัตรที่ทำซ้ำได้ ไม่ใช่การไล่เช็คด้วยมือครั้งเดียวแล้วลืม จุดเริ่มต้นที่ดีคือใช้ Tags กับทุก Droplet Volume และ Snapshot ตั้งแต่สร้าง เพื่อให้กรองด้วย doctl ได้ง่าย เช่น แท็กตามทีม สภาพแวดล้อม (dev/staging/prod) หรือโปรเจกต์ แล้วดึงรายงานด้วย doctl compute droplet list --tag-name env:staging --format Name,Memory,VCPUs เพื่อดูเฉพาะกลุ่มที่ต้องการตรวจ ควรตั้ง checklist รายเดือนที่รวมทุกจุดที่กล่าวมาไว้ในที่เดียว ได้แก่ ตรวจ CPU/RAM utilization เทียบกับขนาด Droplet ตรวจ Volume และ Snapshot ที่ไม่ได้ผูกกับทรัพยากรใดๆ ตรวจ Reserved IP unattached ทบทวนว่า Billing Alert ยังตั้งค่าตรงกับงบประมาณปัจจุบันหรือไม่ และทบทวนว่าฐานข้อมูลที่ self-host อยู่ยังเหมาะสมหรือควรย้ายไป Managed แล้ว สำหรับทีมที่มีทรัพยากรจำนวนมาก การเขียนสคริปต์รวมคำสั่ง doctl เหล่านี้เป็นไฟล์เดียวแล้วรันผ่าน cron หรือ CI schedule จะช่วยลดภาระได้มากกว่าเช็ค manual ทุกเดือน นอกจากนี้ควรใช้ฟีเจอร์ฟรีที่มีอยู่แล้วให้เต็มที่ก่อนเพิ่มเครื่องมือภายนอก เช่น VPC และ Cloud Firewall ที่ไม่มีค่าใช้จ่ายเพิ่มเลย ควรเปิดใช้เป็นมาตรฐานทุก Droplet โดยไม่ต้องพึ่งเครื่องมือ security เพิ่มเติมที่มีค่าใช้จ่าย เช่นเดียวกับ Monitoring ที่ฟรีพร้อม 1 Uptime Check ต่อบัญชี ควรใช้แทนการสมัครบริการ monitoring ภายนอกถ้าความต้องการยังไม่ซับซ้อนเกินไป และสำหรับเว็บไซต์ static ล้วนๆ อย่าง Hugo หรือ Jekyll ควรพิจารณา App Platform Free Tier ที่ให้ 3 apps static site ฟรี แทนการเช่า Droplet เพิ่ม เพราะประหยัดกว่าเต็มๆ สำหรับ workload ที่ไม่ต้องการ server ฝั่ง backend

• ติด Tags ทุก Droplet Volume และ Snapshot ตั้งแต่สร้าง เพื่อกรองตรวจสอบด้วย doctl ได้ง่ายภายหลัง
• ทำ checklist รายเดือน: right-sizing, Volume/Snapshot ค้าง, Reserved IP unattached, Billing Alert, self-host vs Managed DB
• เขียนสคริปต์รวมคำสั่ง doctl รันผ่าน cron หรือ CI แทนเช็ค manual ถ้ามีทรัพยากรจำนวนมาก
• ใช้ VPC และ Cloud Firewall (ฟรีทั้งคู่) เป็นมาตรฐานทุก Droplet ก่อนพึ่งเครื่องมือภายนอกที่มีค่าใช้จ่าย
• เว็บ static ล้วนพิจารณา App Platform Free Tier (3 apps ฟรี) แทนเช่า Droplet เพิ่ม

รับ $200 Free Credit →