คู่มือ DigitalOcean Reserved IP 2026 — IP คงที่สำหรับ Failover

A practical guide to DigitalOcean Reserved IPs covering pricing, assignment, zero-downtime failover, and high-availability setup with doctl and API examples.

Reserved IP คือ IP address คงที่ที่ DigitalOcean ผูกไว้กับบัญชีผู้ใช้แทนที่จะผูกกับ Droplet ตัวใดตัวหนึ่งโดยตรง ทำให้สามารถย้าย IP เดิมไปยัง Droplet ใหม่ได้ทันทีเมื่อเซิร์ฟเวอร์หลักมีปัญหา โดยไม่ต้องรอ DNS propagate ใหม่ บทความนี้อธิบายวิธีจอง ผูก และย้าย Reserved IP พร้อมตัวอย่างคำสั่ง doctl และ API จริงสำหรับทำระบบ Failover

Reserved IP คืออะไร ต่างจาก Public IP ปกติยังไง

เมื่อสร้าง Droplet บน DigitalOcean ระบบจะกำหนด public IPv4 ให้อัตโนมัติหนึ่งหมายเลข ซึ่ง IP นี้ผูกอยู่กับตัว Droplet โดยตรง หมายความว่าถ้าลบ Droplet ทิ้ง IP นั้นจะถูกคืนกลับเข้าพูลของ DigitalOcean ทันทีและไม่สามารถนำกลับมาใช้ซ้ำได้ ต่อให้สร้าง Droplet ใหม่ในบัญชีเดียวกันก็จะได้ IP ใหม่เสมอ ปัญหานี้เป็นเรื่องปกติสำหรับงานทดสอบ แต่กลายเป็นความเสี่ยงจริงจังในระบบ production ที่ต้อง rebuild หรือ replace เซิร์ฟเวอร์บ่อย เพราะทุกครั้งที่ IP เปลี่ยน ต้องไปแก้ DNS record, config ไฟล์, firewall whitelist และรอ TTL หมดอายุก่อนผู้ใช้ทุกคนจะเห็น IP ใหม่ ซึ่งอาจใช้เวลาหลายนาทีถึงหลายชั่วโมงขึ้นกับค่า TTL ที่ตั้งไว้ Reserved IP แก้ปัญหานี้โดยแยก IP ออกจากวงจรชีวิตของ Droplet อย่างสิ้นเชิง เมื่อจอง Reserved IP มาแล้ว IP นั้นจะเป็นทรัพยากรที่ผูกกับบัญชี (account) ไม่ใช่กับ Droplet ตัวใดตัวหนึ่ง ผู้ใช้เลือกได้ว่าจะผูก (assign) มันเข้ากับ Droplet ตัวไหนก็ได้ในภูมิภาคเดียวกัน และเมื่อไหร่ก็ตามที่ต้องการสลับ ก็แค่สั่ง unassign จาก Droplet เดิมแล้ว assign เข้า Droplet ใหม่ — DNS record ที่ชี้ไปยัง Reserved IP ไม่ต้องแก้อะไรเลยเพราะ IP address เดิมยังคงอยู่ ต่างจากการเปลี่ยน public IP ปกติที่ต้องรอ DNS propagate ใหม่ทุกครั้ง ข้อควรรู้คือ Reserved IP ผูกกับ region ไม่ใช่ผูกกับ Droplet เฉพาะตัว จึงสามารถ assign ให้ Droplet ตัวไหนก็ได้ตราบใดที่ Droplet นั้นอยู่ใน region เดียวกับที่จอง Reserved IP ไว้ (เช่นจองไว้ที่ sgp1 ก็ใช้ได้เฉพาะกับ Droplet ใน sgp1 เท่านั้น ย้ายข้าม region ไม่ได้) และ Reserved IP หนึ่งหมายเลขผูกกับ Droplet ได้ครั้งละหนึ่งตัวเท่านั้น

When you create a Droplet on DigitalOcean, the system automatically assigns a public IPv4 address. This IP is tied directly to the Droplet itself. If you delete the Droplet, that IP is immediately returned to DigitalOcean's pool and cannot be reused. Even if you create a new Droplet in the same account, you'll get a new IP. This is normal for testing purposes, but becomes a real concern in production systems that frequently need to rebuild or replace servers. Every time the IP changes, you have to update DNS records, config files, firewall whitelists, and wait for the TTL to expire before all users see the new IP. This can take anywhere from minutes to hours depending on the TTL value. Reserved IP solves this by completely separating the IP from the Droplet's lifecycle. When you reserve an IP, it becomes an account-level resource, not tied to any specific Droplet. You can choose to assign it to any Droplet in the same region. Whenever you want to switch, just unassign it from the old Droplet and assign it to the new one—the DNS record pointing to the Reserved IP doesn't need any changes because the IP address remains the same. Unlike changing a regular public IP, you don't have to wait for DNS propagation. Important to note: Reserved IP is tied to a region, not to a specific Droplet. So you can assign it to any Droplet as long as that Droplet is in the same region where you reserved the IP (for example, if you reserve it in sgp1, it can only be used with Droplets in sgp1—you can't move it across regions). One Reserved IP can be attached to only one Droplet at a time.

• Public IP ปกติของ Droplet หายไปทันทีเมื่อลบ Droplet — นำกลับมาใช้ซ้ำไม่ได้
• Reserved IP ผูกกับบัญชี ไม่ใช่ Droplet จึงย้ายไป Droplet ตัวอื่นได้โดย IP เดิมไม่เปลี่ยน
• ผูกได้เฉพาะ Droplet ใน region เดียวกับที่จอง Reserved IP ไว้เท่านั้น

ราคา: ผูก Droplet ฟรี / ไม่ผูก $5/เดือน

จากที่เราทดสอบจริง — ค่าใช้จ่ายของ Reserved IP แบ่งเป็นสองกรณีชัดเจน กรณีแรกคือผูก (attach) เข้ากับ Droplet ที่กำลังทำงานอยู่ — กรณีนี้ไม่มีค่าใช้จ่ายเพิ่มเติมใด ๆ เท่ากับใช้ฟรีตราบใดที่ยังมี Droplet รองรับอยู่ กรณีที่สองคือปล่อยว่างไม่ผูกกับ Droplet ใดเลย (unattached) DigitalOcean จะคิดค่าบริการ $5 ต่อเดือน คิดเป็นอัตรารายชั่วโมงที่ $0.01/ชั่วโมง เช่นเดียวกับการคิดเงิน Droplet แบบ per-second billing ทั่วไป เหตุผลที่ DigitalOcean คิดเงิน Reserved IP ที่ไม่ได้ใช้งานคือ IP address เป็นทรัพยากรจำกัดที่ต้อง reserve ไว้เฉพาะบัญชีแม้ไม่มี Droplet มารองรับ ถ้าปล่อยฟรีไม่มีเงื่อนไข ผู้ใช้จำนวนมากจะจอง IP เก็บไว้เฉย ๆ โดยไม่ใช้งานจริง ทำให้พูล IPv4 ที่มีจำกัดอยู่แล้วตึงตัวเร็วขึ้น ค่าธรรมเนียมนี้จึงเป็นกลไกป้องกันการจองทิ้งไว้เฉย ๆ สิ่งที่ควรรู้เพิ่มคือ Reserved IPv6 ไม่มีค่าใช้จ่ายเลยไม่ว่าจะผูกอยู่หรือไม่ผูกก็ตาม เพราะพูล IPv6 มีขนาดใหญ่กว่า IPv4 มาก ไม่มีข้อจำกัดด้านความขาดแคลนแบบเดียวกัน ดังนั้นถ้าสถาปัตยกรรมรองรับ IPv6 ได้ การใช้ Reserved IPv6 แทนหรือควบคู่กับ IPv4 จะช่วยลดความเสี่ยงเรื่องค่าใช้จ่ายที่ไม่คาดคิดได้ ข้อควรระวังที่พบบ่อยคือลืม Reserved IP ที่เหลือค้างอยู่หลังจากลบ Droplet ที่เคยผูกไว้ — เมื่อ Droplet ถูกลบ Reserved IP จะไม่ถูกลบตามไปด้วย แต่จะเปลี่ยนสถานะเป็น unattached โดยอัตโนมัติและเริ่มคิดค่าบริการ $5/เดือนทันที ควรตรวจสอบหน้า Networking ในหน้า Control Panel เป็นระยะเพื่อดูว่ามี Reserved IP ที่ค้างอยู่โดยไม่ได้ใช้งานหรือไม่ (ข้อมูล ณ กรกฎาคม 2026 — ตรวจสอบราคาล่าสุดที่เว็บผู้ให้บริการ)

• ผูกกับ Droplet ที่กำลังทำงาน = ไม่มีค่าใช้จ่ายเพิ่ม
• ไม่ผูก (unattached) = $5/เดือน หรือ $0.01/ชั่วโมง สำหรับ IPv4
• Reserved IPv6 ฟรีเสมอ ไม่ว่าจะผูกหรือไม่ผูกก็ตาม
• ลบ Droplet ไม่ได้ลบ Reserved IP ตามไปด้วย ต้องลบเองถ้าไม่ใช้แล้ว
• ตรวจสอบ Networking > Reserved IPs เป็นระยะเพื่อไม่ให้มีรายการค้างจ่ายฟรี ๆ

จองและผูก Reserved IP เข้า Droplet

การจอง Reserved IP ทำได้สามทาง — ผ่าน Control Panel, ผ่าน doctl CLI, หรือผ่าน DigitalOcean API v2 โดยตรง ในหน้า Control Panel ไปที่เมนู Networking แล้วเลือกแท็บ Reserved IPs จากนั้นกด Reserve IP Address เลือก region ที่ต้องการ (ต้องตรงกับ region ของ Droplet ที่จะผูก) และเลือก Droplet ปลายทางได้ทันทีในขั้นตอนเดียวกัน หรือจะจองทิ้งไว้ก่อนแล้วค่อยผูกทีหลังก็ได้ สำหรับสาย CLI ใช้ doctl ซึ่งเป็นเครื่องมือทางการของ DigitalOcean จองด้วยคำสั่ง doctl compute reserved-ip create --region sgp1 ระบบจะคืนค่า IP address ที่ได้กลับมา จากนั้นผูกเข้ากับ Droplet ด้วย doctl compute reserved-ip-action assign <reserved-ip> <droplet-id> โดย droplet-id หาได้จาก doctl compute droplet list ถ้าต้องการยกเลิกการผูกก็ใช้ doctl compute reserved-ip-action unassign <reserved-ip> และถ้าไม่ต้องการ Reserved IP นั้นอีกต่อไปให้ลบด้วย doctl compute reserved-ip delete <reserved-ip> เพื่อหยุดค่าใช้จ่ายกรณี unattached สำหรับสายที่ต้องการ automate ผ่าน API โดยตรง (เช่นเขียนสคริปต์ failover เอง) เรียก REST API v2 ด้วย curl ได้เช่น สร้าง Reserved IP ใหม่ด้วย curl -X POST -H "Authorization: Bearer $DO_TOKEN" -H "Content-Type: application/json" -d '{"droplet_id":"DROPLET_ID"}' "https://api.digitalocean.com/v2/reserved_ips" หรือถ้าต้องการผูก Reserved IP ที่มีอยู่แล้วเข้ากับ Droplet ตัวใหม่ ให้ยิง action assign ไปที่ endpoint ของ IP นั้นโดยตรง เช่น curl -X POST -H "Authorization: Bearer $DO_TOKEN" -H "Content-Type: application/json" -d '{"type":"assign","droplet_id":"NEW_DROPLET_ID"}' "https://api.digitalocean.com/v2/reserved_ips/45.55.32.11/actions" วิธีนี้เหมาะสำหรับเขียน health-check script ที่ตรวจ Droplet หลักแล้วสั่ง reassign อัตโนมัติเมื่อพบปัญหา หลังผูก Reserved IP เข้ากับ Droplet แล้ว ควรตรวจสอบใน Droplet ว่า IP ถูก bind เข้า network interface จริงด้วยคำสั่ง ip addr show eth0 — DigitalOcean จะเพิ่ม anchor IP ให้อัตโนมัติผ่าน metadata service ปกติไม่ต้องตั้งค่าเน็ตเวิร์กเพิ่มเองในระบบปฏิบัติการทั่วไปอยู่แล้ว

• จองผ่าน Control Panel: Networking > Reserved IPs > Reserve IP Address
• doctl: doctl compute reserved-ip create --region sgp1 แล้ว assign ด้วย reserved-ip-action
• API: ยิง POST ไปที่ /v2/reserved_ips หรือ /v2/reserved_ips/{ip}/actions

ย้าย Reserved IP ระหว่าง Droplet แบบ Zero Downtime

จุดแข็งหลักของ Reserved IP คือความสามารถในการย้ายจาก Droplet ตัวหนึ่งไปอีกตัวหนึ่งโดยที่ IP address ปลายทางที่ผู้ใช้เห็นไม่เปลี่ยนแปลง เหมาะกับสถานการณ์อย่าง blue-green deployment ที่ต้องการสลับทราฟฟิกจากเซิร์ฟเวอร์เวอร์ชันเก่าไปเวอร์ชันใหม่แบบทันที ขั้นตอนทั่วไปคือสร้าง Droplet ใหม่ ติดตั้งและทดสอบแอปพลิเคชันให้เรียบร้อยก่อนโดยเข้าถึงผ่าน public IP ชั่วคราวของ Droplet ตัวใหม่เอง (หรือผ่าน private VPC IP) เมื่อมั่นใจว่าทุกอย่างพร้อมแล้วจึงค่อยสั่งย้าย Reserved IP มาที่ Droplet ใหม่ การย้ายทำได้ด้วยคำสั่งเดียว ไม่ต้อง unassign ก่อนแล้วค่อย assign แยกสองขั้นตอน เพราะ DigitalOcean รองรับการ reassign ตรง ๆ ด้วย doctl compute reserved-ip-action assign <reserved-ip> <new-droplet-id> ระบบจะจัดการ unassign จาก Droplet เดิมและ assign เข้า Droplet ใหม่ให้ในคำสั่งเดียว การสลับฝั่งนี้เกิดขึ้นเร็วมากในระดับเครือข่ายภายในของ DigitalOcean เอง เพราะเป็นการเปลี่ยนเส้นทาง routing ที่ data center ไม่ใช่การรอ DNS propagate เหมือนการเปลี่ยน A record ทั่วไป จึงทำให้ downtime ที่ผู้ใช้ปลายทางสัมผัสได้สั้นกว่าการเปลี่ยน DNS มาก อย่างไรก็ตามควรเข้าใจว่า "zero downtime" ในที่นี้หมายถึงไม่มี DNS propagation delay ไม่ใช่การรับประกันว่าจะไม่มี connection ใดขาดหายเลย connection ที่ค้างอยู่บน Droplet เดิมขณะย้ายอาจถูกตัดได้หากไม่มีกลไก connection draining หรือ session persistence รองรับ สำหรับงานที่ต้องการความต่อเนื่องระดับสูงจริง ๆ ควรออกแบบแอปให้ stateless และรองรับการ retry ฝั่ง client ร่วมด้วย ไม่พึ่งพา Reserved IP เพียงอย่างเดียว ขั้นตอนแนะนำก่อนสลับจริงคือทดสอบด้วยการ assign ชั่วคราวในช่วง maintenance window ก่อน หรือใช้ health check ตรวจสอบ Droplet ใหม่ให้ผ่านทุกจุด (เว็บเซิร์ฟเวอร์, ฐานข้อมูล, TLS certificate, ตัวแปร environment) ก่อนสลับจริง เพราะหลังสลับแล้วทราฟฟิกทั้งหมดจะวิ่งเข้า Droplet ใหม่ทันที ถ้าพบปัญหาก็สามารถสั่ง assign กลับไป Droplet เดิมได้ทันทีเช่นกันด้วยคำสั่งเดียวกัน ทำให้ rollback ทำได้เร็วกว่าการแก้ DNS กลับคืนมาก

• reassign ทำได้คำสั่งเดียว doctl compute reserved-ip-action assign ไม่ต้อง unassign ก่อน
• เร็วกว่าการเปลี่ยน DNS A record มาก เพราะไม่ต้องรอ TTL propagate
• ทดสอบ Droplet ใหม่ให้พร้อมสมบูรณ์ก่อนสลับจริงเสมอ
• connection ที่ค้างอยู่ระหว่างย้ายอาจขาดได้หากไม่มี connection draining

ตัวอย่าง use case High Availability

จากที่เราทดสอบจริง — รูปแบบ HA พื้นฐานที่ใช้ Reserved IP ทั่วไปคือสถาปัตยกรรม active-passive สอง Droplet ทำงานคู่กัน — Droplet ตัวหลัก (primary) รับทราฟฟิกจริงผ่าน Reserved IP ส่วน Droplet ตัวสำรอง (standby) ติดตั้งซอฟต์แวร์และข้อมูลเวอร์ชันเดียวกันไว้พร้อมใช้งานแต่ไม่ได้รับทราฟฟิก มี monitoring script หรือ health check เฝ้าดู primary อยู่ตลอด เมื่อพบว่า primary ไม่ตอบสนอง (เช่น HTTP health check ล้มเหลวติดต่อกันหลายครั้ง หรือ Droplet เข้าไม่ได้ผ่าน SSH) สคริปต์จะเรียก DigitalOcean API สั่ง reassign Reserved IP มาที่ standby โดยอัตโนมัติ ทำให้ทราฟฟิกไหลไปยัง Droplet สำรองโดยผู้ใช้ปลายทางไม่ต้องรอ DNS เปลี่ยน การเขียนสคริปต์ failover เองมักใช้ร่วมกับเครื่องมือ monitoring ภายนอกอย่าง Uptime Kuma หรือ cron job ที่รันบนเซิร์ฟเวอร์ตัวที่สาม (ไม่ควรรันบน primary หรือ standby เอง เพราะถ้าเซิร์ฟเวอร์ที่รัน monitoring ล่มไปพร้อมกับ primary จะไม่มีใครสั่ง failover ให้) เมื่อ health check ล้มเหลวสคริปต์จะยิง API เรียก reserved-ip-action assign ไปที่ standby ทันที ขั้นตอนนี้ทำให้ระบบมี RTO (Recovery Time Objective) สั้นกว่าการรอ engineer เข้ามาแก้ด้วยมือมาก อีกกรณีที่ใช้บ่อยคือ database failover — Reserved IP ผูกกับ Droplet ที่รัน PostgreSQL หรือ MySQL primary เมื่อ primary มีปัญหา ระบบ replication จะ promote replica ขึ้นเป็น primary ใหม่ จากนั้นค่อยย้าย Reserved IP มาชี้ที่ Droplet ของ replica ตัวใหม่ แอปพลิเคชันฝั่ง client ที่เชื่อมต่อผ่าน connection string ที่ระบุ Reserved IP ไว้จะไม่ต้อง reconfigure อะไรเลย เพราะ IP ปลายทางเดิมยังใช้งานได้ตามปกติ สำหรับระบบที่ต้องรองรับหลาย Droplet รับทราฟฟิกพร้อมกันจริง ๆ (ไม่ใช่แค่สำรองเผื่อ failover) Reserved IP ไม่ใช่คำตอบที่เหมาะสมเพราะผูกได้กับ Droplet ทีละตัวเท่านั้น กรณีนั้นควรใช้ Load Balancer แทนซึ่งกระจายทราฟฟิกไปหลาย backend พร้อม health check ในตัวอยู่แล้ว

1. Active-passive: primary รับทราฟฟิกจริง standby รอสำรองพร้อม failover
2. Monitoring script ควรรันแยกจาก primary/standby เพื่อไม่ให้ล่มพร้อมกัน
3. ใช้ร่วมกับ database replication ได้ — ย้าย Reserved IP หลัง promote replica
4. ลด RTO ได้มากกว่าการรอแก้ไขด้วยมือหรือรอ DNS propagate

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

Reserved IP เหมาะกับทีมหรือนักพัฒนาที่ต้องการความสามารถ failover ระดับพื้นฐานโดยไม่อยากแบกต้นทุนของ Load Balancer ที่เริ่มต้น $12 ต่อเดือน สำหรับโปรเจกต์ขนาดเล็กถึงกลางที่มี Droplet หลักเพียงตัวเดียวรับทราฟฟิกจริง Reserved IP ที่ผูกอยู่กับ Droplet นั้นไม่มีค่าใช้จ่ายเพิ่มเลย ต่างจาก Load Balancer ที่เก็บค่าบริการทุกเดือนไม่ว่าจะใช้งานมากหรือน้อย ทำให้ Reserved IP เป็นตัวเลือกที่คุ้มค่ากว่าสำหรับระบบที่ไม่จำเป็นต้องกระจายทราฟฟิกไปหลายเครื่องพร้อมกัน แต่ต้องการแค่ "จุดสำรอง" ไว้เผื่อเซิร์ฟเวอร์หลักมีปัญหา กรณีใช้งานที่พบบ่อยอีกแบบคือ blue-green deployment สำหรับทีมที่ deploy โค้ดเวอร์ชันใหม่โดยสร้าง Droplet ใหม่ทั้งตัวแทนที่จะอัปเดตของเดิม (แนวทางนี้ช่วยให้ rollback ทำได้ง่ายกว่าการแก้โค้ดบนเครื่องเดิม) Reserved IP ทำหน้าที่เป็นจุดสลับทราฟฟิกระหว่างเวอร์ชันเก่ากับเวอร์ชันใหม่โดยไม่ต้องแตะ DNS เลยสักครั้ง เหมาะกับทีมที่ deploy บ่อยและต้องการ rollback ได้เร็วหากพบบั๊กหลัง deploy อีกกรณีคือระบบที่ยังไม่พร้อมลงทุนใน managed database หรือ multi-node cluster เต็มรูปแบบ แต่ต้องการ HA ระดับพื้นฐานสำหรับ database self-hosted บน Droplet เอง — ใช้ Reserved IP ผูกกับ primary database และมี replica พร้อม promote เมื่อจำเป็น เป็นวิธีที่ implement ได้เร็วกว่าการตั้ง managed database cluster เต็มรูปแบบ ในทางกลับกัน ถ้าระบบมีทราฟฟิกสูงและต้องกระจายโหลดไปหลาย Droplet พร้อมกันตลอดเวลา (ไม่ใช่แค่สำรอง) หรือทีมต้องการ health check อัตโนมัติแบบเนทีฟไม่ต้องเขียนสคริปต์เอง Load Balancer จะเหมาะสมกว่า Reserved IP ในกรณีนั้น

• ระบบเล็ก-กลางที่มี Droplet หลักตัวเดียว ต้องการ failover สำรองโดยไม่เสียค่า Load Balancer
• Blue-green deployment: สลับทราฟฟิกระหว่างเวอร์ชันเก่า-ใหม่โดยไม่แตะ DNS
• HA แบบ self-hosted database ที่ยังไม่พร้อมย้ายไป managed cluster เต็มรูปแบบ
• ทีมที่ deploy บ่อยและต้องการ rollback เร็วกว่าการแก้ DNS

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

ข้อผิดพลาดที่พบบ่อยที่สุดคือลืมว่า Reserved IP ที่ไม่ผูกกับ Droplet มีค่าใช้จ่าย $5 ต่อเดือน หลายคนจองไว้ทดสอบแล้วลืมลบทิ้ง หรือลบ Droplet ที่ผูกอยู่โดยไม่รู้ว่า Reserved IP จะยังคงอยู่ในสถานะ unattached ต่อไปและเริ่มคิดเงินทันที วิธีป้องกันคือตั้ง billing alert ไว้ และตรวจสอบหน้า Networking > Reserved IPs เป็นระยะเพื่อดูว่ามีรายการค้างไม่ได้ใช้หรือไม่ ถ้าไม่มีแผนใช้งานต่อควรลบทิ้งด้วย doctl compute reserved-ip delete ทันที ข้อผิดพลาดที่สองคือชี้ DNS A record ไปที่ public IP เดิมของ Droplet โดยตรง แทนที่จะชี้ไปที่ Reserved IP ตั้งแต่แรก ทำให้เวลาต้องการสลับ Droplet ในภายหลัง ต้องไปแก้ DNS record ใหม่อยู่ดี เสียประโยชน์ของ Reserved IP ไปเลย บทเรียนคือควรตั้ง DNS ให้ชี้ไปที่ Reserved IP ตั้งแต่วันแรกที่ตั้งระบบ แม้ว่าตอนนั้นจะมี Droplet เดียวและยังไม่มีแผน failover ก็ตาม เพราะการเปลี่ยน DNS record ในภายหลังต้องรอ TTL หมดอายุเหมือนเดิม ข้อผิดพลาดที่สามคือพยายามผูก Reserved IP ข้าม region เช่นจองไว้ที่ sgp1 แล้วพยายาม assign เข้า Droplet ที่ nyc1 ซึ่งทำไม่ได้เพราะ Reserved IP ผูกกับ region ที่จองไว้ตายตัว วิธีแก้คือวางแผน region ให้ชัดเจนตั้งแต่ต้น ถ้าจำเป็นต้องย้าย region จริง ๆ ต้องจอง Reserved IP ใหม่ในภูมิภาคปลายทางแล้วอัปเดต DNS ใหม่ทั้งหมด ข้อผิดพลาดที่สี่คือ firewall rule บน Cloud Firewall หรือ ufw ที่ตั้งไว้อ้างอิง public IP เดิมของ Droplet แทนที่จะอ้างอิง Reserved IP ทำให้หลัง failover แล้ว rule เดิมใช้ไม่ได้กับ Droplet ใหม่ ควรออกแบบ firewall rule โดยอ้างอิง Tags แทนการระบุ IP ตายตัว เพื่อให้กฎเดิมใช้ได้กับทุก Droplet ที่ผูก tag เดียวกันโดยไม่ต้องแก้ทุกครั้งที่สลับเครื่อง ข้อผิดพลาดสุดท้ายคือทดสอบ failover script ไม่เพียงพอก่อนใช้งานจริง เขียนสคริปต์ reassign ไว้แต่ไม่เคยรันจริงจนกว่าจะเกิดเหตุฉุกเฉิน ทำให้พบบั๊กหรือ permission ผิดพลาดตอนที่ต้องการใช้งานจริงพอดี ควรซ้อมสลับ Reserved IP ในช่วง maintenance window ที่วางแผนไว้ล่วงหน้าอย่างน้อยหนึ่งครั้งก่อนพึ่งพาระบบนี้ในสถานการณ์จริง

• Reserved IP unattached ค้างจ่าย $5/เดือน — ตั้ง billing alert + ตรวจสอบเป็นระยะ
• ตั้ง DNS ให้ชี้ Reserved IP ตั้งแต่แรก ไม่ใช่ public IP ของ Droplet โดยตรง
• ผูกข้าม region ไม่ได้ — วางแผน region ให้ตรงกับ Droplet ปลายทางเสมอ

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

หลักปฏิบัติแรกคือตั้ง DNS ทุก record ที่เกี่ยวข้องกับเซิร์ฟเวอร์หลักให้ชี้ไปที่ Reserved IP ตั้งแต่วันแรกของการตั้งระบบ แม้ว่าตอนนั้นจะยังไม่มีแผน HA ชัดเจนก็ตาม เพราะต้นทุนของการทำแบบนี้ตั้งแต่แรกแทบเป็นศูนย์ (ถ้าผูกอยู่กับ Droplet ก็ไม่มีค่าใช้จ่ายเพิ่ม) แต่ให้ความยืดหยุ่นในการ scale หรือ failover ในอนาคตโดยไม่ต้องแตะ DNS อีกเลย หลักที่สองคือเก็บ API token สำหรับสคริปต์ failover ไว้อย่างปลอดภัย ไม่ hardcode ลงในโค้ดที่ commit เข้า repository ควรใช้ environment variable หรือ secret manager และจำกัดสิทธิ์ token ให้ทำได้เฉพาะสิ่งที่จำเป็น (scope ต่ำสุดที่ยังใช้งานได้) เพื่อลดความเสียหายหาก token รั่วไหล หลักที่สามคือเขียน runbook หรือเอกสารขั้นตอน failover ไว้ให้ทีมทุกคนเข้าถึงได้ ระบุชัดเจนว่าเมื่อไหร่ควร trigger failover ด้วยมือ เมื่อไหร่ปล่อยให้สคริปต์อัตโนมัติจัดการเอง และขั้นตอน rollback หากการ failover ทำให้เกิดปัญหาใหม่ เอกสารนี้สำคัญโดยเฉพาะเวลาที่ engineer ที่คุ้นเคยกับระบบไม่ว่างหรือไม่อยู่ในช่วงเกิดเหตุ หลักที่สี่คือทดสอบ failover เป็นประจำ ไม่ใช่แค่ตั้งไว้ครั้งเดียวตอน setup ระบบภายนอกและ dependency มักเปลี่ยนแปลงไปตามเวลา (เวอร์ชัน OS, library, certificate ที่หมดอายุ) การซ้อม failover อย่างน้อยไตรมาสละครั้งช่วยให้มั่นใจว่าระบบยังทำงานได้จริงเมื่อจำเป็น หลักสุดท้ายคือพิจารณาใช้ Reserved IP ร่วมกับเครื่องมืออื่นตามขนาดของระบบ สำหรับระบบเล็กใช้ Reserved IP เดี่ยว ๆ กับ monitoring script ง่าย ๆ ก็เพียงพอ แต่เมื่อระบบโตขึ้นและต้องรองรับทราฟฟิกที่กระจายไปหลาย Droplet พร้อมกันจริง ควรพิจารณาเปลี่ยนไปใช้ Load Balancer ที่มี health check และ automatic failover ในตัวอยู่แล้วแทนการดูแลสคริปต์เองทั้งหมด และอย่าลืมลบ Reserved IP ที่เลิกใช้แล้วทุกครั้งเพื่อไม่ให้มีค่าใช้จ่ายค้างโดยไม่จำเป็น

• ตั้ง DNS ชี้ Reserved IP ตั้งแต่วันแรกแม้ยังไม่มีแผน HA
• เก็บ API token ด้วย environment variable/secret manager ไม่ hardcode
• เขียน runbook ขั้นตอน failover และ rollback ให้ทีมเข้าถึงได้

รับ $200 Free Credit →