คู่มือย้ายจาก AWS มา DigitalOcean 2026

A practical guide for engineering teams planning a migration from AWS to DigitalOcean in 2026, covering service mapping, data migration, DNS cutover, and post-migration cost considerations.

หลายทีมพัฒนาเลือกย้ายระบบจาก AWS มาที่ DigitalOcean เพื่อลดความซับซ้อนของโครงสร้างราคาและการดูแลระบบในแต่ละวัน บทความนี้เป็นคู่มือย้ายระบบแบบเป็นขั้นตอน ตั้งแต่เทียบบริการ วางแผนย้ายข้อมูล ไปจนถึงการสลับ DNS และข้อควรระวังเรื่องต้นทุนหลังย้าย เหมาะสำหรับทีมที่ตัดสินใจย้ายแล้วและต้องการแผนปฏิบัติที่ชัดเจน

เหตุผลที่ทีมย้ายจาก AWS มา DigitalOcean

AWS เป็นผู้ให้บริการคลาวด์ที่มีบริการครอบคลุมที่สุดในตลาด ตั้งแต่ compute, storage, database, machine learning ไปจนถึงบริการเฉพาะทางระดับองค์กรขนาดใหญ่ แต่ความครอบคลุมนี้มาพร้อมความซับซ้อน ทั้งจำนวนบริการที่ต้องเรียนรู้ โครงสร้างราคาที่คิดตามการใช้งานจริงหลายรายการ (compute, storage, IOPS, data transfer ระหว่าง Availability Zone, NAT Gateway, request ต่อ API call) และ console ที่มีตัวเลือกจำนวนมากจนทีมขนาดเล็กถึงกลางอาจใช้เวลานานในการตั้งค่าและดูแลรักษา ทีมที่ตัดสินใจย้ายมา DigitalOcean ส่วนใหญ่ให้เหตุผลคล้ายกันคือ ต้องการโครงสร้างราคาที่คาดเดาได้ง่ายกว่า เพราะ Droplet คิดราคาแบบเหมาจ่ายรายเดือนที่รวม CPU, RAM, SSD และปริมาณ transfer ไว้ในราคาเดียว ไม่ต้องคำนวณแยกทีละรายการเหมือนใบแจ้งหนี้ AWS ที่มักมีหลายสิบบรรทัดในแต่ละเดือน อีกเหตุผลคือทีมที่ไม่มี dedicated cloud engineer หรือ FinOps คอยดูแลบิลทุกเดือน จะพบว่า dashboard ของ DigitalOcean เข้าใจง่ายกว่า และเอกสารประกอบ (DigitalOcean Community Tutorials) เขียนสำหรับนักพัฒนาโดยตรง ไม่ใช่สำหรับสถาปนิกระบบองค์กรขนาดใหญ่เพียงอย่างเดียว นอกจากนี้ยังมีกรณีที่ทีมใช้ AWS เพียงบริการพื้นฐาน เช่น EC2 สำหรับรัน web app, S3 สำหรับเก็บไฟล์ static และ RDS สำหรับฐานข้อมูล โดยไม่ได้ใช้บริการเฉพาะทางของ AWS เช่น Lambda ที่ผูกกับ event source อื่นในระบบนิเวศ AWS, Redshift, หรือ SageMaker กรณีแบบนี้การย้ายมา DigitalOcean มักทำได้ตรงไปตรงมา เพราะ workload เป็นสถาปัตยกรรมมาตรฐานที่รันได้บนแพลตฟอร์มไหนก็ได้ ไม่ได้ผูกกับ proprietary service ของ AWS โดยเฉพาะ สิ่งสำคัญคือบทความนี้ไม่ได้บอกว่า AWS แย่กว่าหรือควรเลิกใช้ AWS ทุกกรณี แต่เป็นคู่มือสำหรับทีมที่ประเมินความต้องการของตัวเองแล้วและตัดสินใจย้ายแล้ว เพื่อให้กระบวนการย้ายราบรื่นที่สุด

AWS is the most comprehensive cloud service provider on the market, offering services ranging from compute, storage, and database to machine learning and large-scale enterprise-specific services. However, this comprehensiveness comes with complexity: the sheer number of services to learn, pricing structures based on actual usage with multiple line items (compute, storage, IOPS, data transfer between Availability Zones, NAT Gateway costs, and API request charges), and a console with so many options that even mid-sized teams may spend considerable time on setup and maintenance. Teams deciding to migrate to DigitalOcean usually cite similar reasons: they want a more predictable pricing structure because Droplets charge a flat monthly rate that bundles CPU, RAM, SSD, and transfer allowance into a single price, rather than calculating billing line by line the way AWS invoices do with dozens of rows each month. Another reason is that teams without a dedicated cloud or FinOps engineer who oversees billing monthly find DigitalOcean's dashboard easier to understand, and the documentation (DigitalOcean Community Tutorials) is written directly for developers, not exclusively for architects of large enterprises. There are also cases where teams only use basic AWS services such as EC2 for running web apps, S3 for static file storage, and RDS for databases, without using AWS-specific services like Lambda tied to event sources within the AWS ecosystem, Redshift, or SageMaker. In such cases, migrating to DigitalOcean is often straightforward because the workload follows a standard architecture that can run on any platform, not locked into AWS proprietary services. It's important to note that this article is not saying AWS is worse or should be abandoned in all cases, but rather serves as a guide for teams that have assessed their own needs and decided to migrate, to make the process as smooth as possible.

• ราคา Droplet เหมาจ่ายรายเดือน ต่างจาก AWS ที่คิดค่าใช้จ่ายแยกหลายรายการต่อบริการ
• เหมาะกับทีมที่ไม่มี dedicated cloud/FinOps engineer คอยดูแลบิลทุกเดือน
• เหมาะกับ workload มาตรฐาน (web app, API, database) ที่ไม่ผูกกับบริการเฉพาะทางของ AWS

เทียบบริการ: EC2→Droplet, S3→Spaces, RDS→Managed DB

ที่พบบ่อยในทางปฏิบัติ — การเทียบบริการระหว่าง AWS กับ DigitalOcean ควรเข้าใจว่าเป็นการเทียบระดับ 'แนวคิด' ไม่ใช่ระดับ 'สเปกเป๊ะๆ' เพราะโมเดลราคาและวิธีคิดต้นทุนต่างกัน EC2 → Droplet: EC2 instance คิดราคาตาม instance family, ภูมิภาค, ระบบปฏิบัติการ และ storage (EBS) ที่แยกบิลต่างหาก บวกกับค่า data transfer ขาออกที่คิดแยก ส่วน Droplet คิดราคาเหมาจ่ายที่รวม CPU, RAM, SSD และ bandwidth allowance ไว้ในราคาเดียว เช่น Droplet Basic (Shared CPU) เริ่มที่ 512 MiB RAM/1 vCPU/10 GB SSD/500 GiB transfer ราคา 4 ดอลลาร์ต่อเดือน ไปจนถึง 16 GiB RAM/8 vCPU/320 GB SSD/6,000 GiB transfer ที่ 96 ดอลลาร์ต่อเดือน หากต้องการ workload ที่ต้องการ CPU เสถียรแบบ dedicated (เทียบเคียง EC2 instance ประเภท compute-optimized) DigitalOcean มีกลุ่ม Droplets General Purpose (Dedicated CPU) แยกต่างหาก เริ่มต้นที่ 63 ดอลลาร์ต่อเดือน (8GB RAM, 2 vCPU, 25GB SSD) ไปจนถึง 1,260 ดอลลาร์ต่อเดือนสำหรับสเปกสูงสุด ซึ่งเป็นคนละกลุ่มราคากับ Basic Droplet จึงต้องเลือกให้ตรงกับ workload S3 → Spaces: Spaces เป็น Object Storage ที่ใช้ S3-compatible API เหมือนกัน หมายความว่า SDK และเครื่องมือที่เขียนสำหรับ S3 อย่าง s3cmd หรือ AWS SDK ส่วนใหญ่ใช้กับ Spaces ได้โดยแค่เปลี่ยน endpoint เช่นย้ายไฟล์จาก S3 มา Spaces ทำได้ด้วยคำสั่งประมาณ aws s3 sync s3://bucket ./local/ เพื่อดึงไฟล์ลงเครื่องก่อน แล้วอัปโหลดขึ้น Spaces ด้วย s3cmd sync ./local/ s3://new-space --host=sgp1.digitaloceanspaces.com Spaces เริ่มต้นที่ 5 ดอลลาร์ต่อเดือน และมี CDN ในตัว (built-in CDN) โดยไม่ต้องตั้งค่า CloudFront แยกต่างหากแบบที่ S3 ต้องทำ RDS → Managed Database: RDS คิดราคาตาม instance class, storage ที่ provision ไว้ และ IOPS ที่เลือก ซึ่งแยกบิลกันคนละส่วน ส่วน Managed Database ของ DigitalOcean คิดราคาเหมาจ่ายต่อ tier เช่น PostgreSQL และ MySQL tier Basic (1 vCPU/1 GiB RAM, 10-30GiB storage) เริ่มที่ 15.15 ดอลลาร์ต่อเดือน, MongoDB tier Basic เริ่มที่ 15.23 ดอลลาร์ต่อเดือน ส่วนบริการที่เคยชื่อ Managed Redis เปลี่ยนชื่อเป็น Valkey แล้ว (fork ของ Redis ที่ API และคำสั่งเข้ากันได้) เริ่มที่ 15 ดอลลาร์ต่อเดือน หากต้องการพื้นที่เก็บข้อมูลเพิ่มเติมนอกเหนือจาก tier คิดที่ 0.215 ดอลลาร์ต่อ GiB ต่อเดือน ข้อมูลราคาทั้งหมดนี้คือ ณ กรกฎาคม 2026 ควรตรวจสอบราคาล่าสุดที่เว็บผู้ให้บริการก่อนวางแผนงบประมาณจริง

• EC2 → Droplet: ราคาเหมาจ่ายรวม CPU/RAM/SSD/transfer ต่างจาก EC2 ที่แยกบิล EBS และ data transfer
• S3 → Spaces: ใช้ S3-compatible API เดิมได้ เปลี่ยนแค่ endpoint
• RDS → Managed Database: PostgreSQL/MySQL เริ่ม $15.15/mo, MongoDB $15.23/mo, Valkey (เดิมชื่อ Managed Redis) $15/mo
• งาน compute หนักที่ต้องการ CPU เสถียรควรเทียบกับ Droplets General Purpose (Dedicated CPU) เริ่ม $63/mo ไม่ใช่ Basic Droplet

วางแผนย้ายข้อมูลและ Downtime

ก่อนเริ่มย้ายจริง ควรทำ inventory รายการทรัพยากรทั้งหมดบน AWS ก่อน ทั้ง EC2 instance ที่ใช้งานอยู่, S3 bucket, RDS instance, security group, IAM role ที่ผูกกับ service อื่น และ environment variable หรือ config ที่ hardcode endpoint ของ AWS ไว้ เพื่อให้แน่ใจว่าไม่มีจุดใดตกหล่นระหว่างย้าย ขั้นตอนที่แนะนำคือสร้าง staging environment บน DigitalOcean ที่จำลองสภาพแวดล้อม production ให้ใกล้เคียงที่สุดก่อน เช่นสร้าง Droplet ด้วย doctl compute droplet create staging-app --region sgp1 --size s-2vcpu-4gb --image ubuntu-24-04-x64 แล้วติดตั้ง stack เดียวกับที่ใช้บน EC2 (เช่น Nginx, PHP-FPM, Node.js) จากนั้นทดสอบ deploy แอปพลิเคชันจริงบน staging ก่อนเริ่มย้ายข้อมูลจริง การย้ายไฟล์จาก S3 มา Spaces ทำได้โดยดึงไฟล์ลงเครื่องก่อนด้วย aws s3 sync s3://bucket ./local-backup/ แล้วอัปโหลดขึ้น Spaces ด้วย s3cmd sync ./local-backup/ s3://new-space สำหรับไฟล์ขนาดใหญ่มากอาจพิจารณาทำเป็นรอบ (batch) เพื่อลดภาระ bandwidth ส่วนฐานข้อมูลเป็นจุดที่ต้องวางแผน downtime ให้ดีที่สุด เพราะข้อมูลเปลี่ยนแปลงตลอดเวลาขณะระบบยังทำงาน วิธีพื้นฐานคือ export ด้วย pg_dump หรือ mysqldump จาก RDS แล้ว import เข้า Managed Database ผ่าน connection string ที่ได้จาก DigitalOcean control panel เช่น mysqldump -h rds-endpoint -u user -p dbname > backup.sql ตามด้วย mysql -h managed-db-host -u user -p dbname < backup.sql วิธีนี้เหมาะกับฐานข้อมูลขนาดไม่ใหญ่มากและยอมรับ downtime สั้นๆ ได้ หากฐานข้อมูลมีขนาดใหญ่หรือรับ traffic ต่อเนื่องตลอดเวลา ควรพิจารณาตั้ง replication ชั่วคราวเพื่อ sync ข้อมูลแบบต่อเนื่องก่อน cutover จริง เพื่อลด downtime ให้เหลือแค่ช่วงเวลาสลับ connection string เท่านั้น ควรเลือกช่วงเวลาที่ traffic ต่ำที่สุดสำหรับการ cutover จริง และแจ้งผู้ใช้งานล่วงหน้าหากคาดว่าจะมี downtime ที่มองเห็นได้

1. ทำ inventory ทรัพยากร AWS ทั้งหมดก่อน รวม hardcoded endpoint ในโค้ด
2. สร้าง staging environment บน DigitalOcean ทดสอบ deploy จริงก่อนย้ายข้อมูล
3. ย้ายไฟล์ S3 → Spaces เป็นรอบ (batch) เพื่อลดภาระ bandwidth
4. ฐานข้อมูลขนาดใหญ่ควรพิจารณา replication ชั่วคราวเพื่อลด downtime

ย้าย DNS และทดสอบก่อน Cutover เต็มรูปแบบ

การสลับ DNS คือขั้นตอนสุดท้ายที่ทำให้ traffic จริงไหลไปที่ DigitalOcean แทน AWS จึงควรทดสอบให้มั่นใจที่สุดก่อนสลับจริง ขั้นแรกควรลด TTL ของ DNS record ล่วงหน้าอย่างน้อย 24-48 ชั่วโมงก่อน cutover เพื่อให้การเปลี่ยนแปลงแพร่กระจายเร็วขึ้นตอน cutover จริง ตรวจสอบ TTL ปัจจุบันด้วยคำสั่งเช่น dig cloudpicked.com A +noall +answer แล้วปรับ TTL ให้ต่ำลง เช่น 300 วินาที ผ่าน DNS provider ที่ใช้อยู่ ก่อนสลับ DNS จริง ควรทดสอบว่าแอปพลิเคชันบน Droplet ใหม่ทำงานถูกต้องด้วย domain จริงก่อน โดยไม่ต้องรอสลับ DNS โดยใช้ curl --resolve cloudpicked.com:443:167.99.x.x https://cloudpicked.com เพื่อบังคับให้ curl เชื่อมต่อไปยัง IP ของ Droplet ใหม่โดยตรงแต่ยังส่ง SNI/Host header เป็น domain จริง วิธีนี้ช่วยตรวจสอบ SSL certificate, virtual host configuration และ redirect ต่างๆ ได้ครบก่อนสลับจริง หรือจะแก้ไฟล์ /etc/hosts บนเครื่อง local ชั่วคราวเพื่อทดสอบผ่าน browser ก็ได้เช่นกัน เมื่อทดสอบผ่านหมดแล้ว จึงเปลี่ยน A record (หรือ AAAA สำหรับ IPv6) ให้ชี้ไปยัง IP ของ Droplet ใหม่ หรือ Load Balancer หากมีหลาย Droplet เบื้องหลัง สำหรับระบบที่ต้องการ IP คงที่ข้ามการสร้าง Droplet ใหม่ในอนาคต ควรพิจารณาใช้ Reserved IP ซึ่งฟรีตราบใดที่ผูกกับ Droplet ที่ใช้งานอยู่ (มีค่าใช้จ่าย 5 ดอลลาร์ต่อเดือนเฉพาะตอนไม่ได้ผูกกับ Droplet ใดเลย) เพื่อให้ย้าย IP ไปยัง Droplet ใหม่ได้แบบไม่ต้องแก้ DNS ซ้ำในอนาคต หลัง cutover ควรตรวจสอบการแพร่กระจาย DNS จากหลายจุดด้วยเครื่องมืออย่าง dig +trace หรือบริการตรวจสอบ DNS propagation จากหลายภูมิภาค และเฝ้าดู log/monitoring ของทั้งสองฝั่งในช่วง 24-48 ชั่วโมงแรกเผื่อมี traffic บางส่วนยังค้างอยู่ที่ AWS จาก DNS cache เก่า ก่อนจะปิด instance บน AWS ทิ้งจริง

• ลด TTL ล่วงหน้า 24-48 ชั่วโมงก่อน cutover จริง
• ทดสอบด้วย curl --resolve หรือแก้ /etc/hosts ก่อนสลับ DNS จริง
• ใช้ Reserved IP เพื่อย้าย IP ระหว่าง Droplet ได้โดยไม่ต้องแก้ DNS ซ้ำ
• เฝ้า monitor ทั้งสองฝั่งช่วง 24-48 ชั่วโมงแรกหลัง cutover ก่อนปิด AWS

ข้อควรระวังเรื่องต้นทุนหลังย้าย

จากการรีวิวหลายรอบ aWS มีชื่อเสียงเรื่องโครงสร้างราคาที่ซับซ้อนและมีรายการค่าใช้จ่ายจำนวนมากในแต่ละบิล เช่น ค่า data transfer ระหว่าง Availability Zone, ค่า NAT Gateway ต่อชั่วโมงและต่อ GB ที่ผ่าน, ค่า IOPS แยกจาก storage, ค่า snapshot ที่สะสมเมื่อเวลาผ่านไป และค่า request ต่อ API call ของ S3 ทำให้หลายทีมเจอบิลเซอร์ไพรส์ที่คาดไม่ถึงในบางเดือน ซึ่งเป็นแรงจูงใจหลักที่ทำให้ทีมมองหาโครงสร้างราคาที่คาดเดาง่ายกว่า แต่การย้ายมา DigitalOcean ไม่ได้แปลว่าไม่ต้องระวังเรื่องต้นทุนเลย เพราะยังมีรายการที่ต้องดูแลเช่นกัน ตัวอย่างเช่น Reserved IP ที่ไม่ได้ผูกกับ Droplet ใดเลยจะมีค่าใช้จ่าย 5 ดอลลาร์ต่อเดือนต่อ IP, Volume (Block Storage) คิดที่ 0.10 ดอลลาร์ต่อ GiB ต่อเดือน, Volume snapshot และ Droplet snapshot คิดที่ 0.06 ดอลลาร์ต่อ GiB ต่อเดือน ซึ่งหากลืมลบ snapshot เก่าหรือ Volume ที่เลิกใช้แล้ว ค่าใช้จ่ายจะสะสมไปเรื่อยๆ โดยไม่รู้ตัว เช่นเดียวกับ Managed Database ที่ storage เกิน tier เริ่มต้นจะคิดเพิ่ม 0.215 ดอลลาร์ต่อ GiB ต่อเดือน อีกจุดที่ควรระวังคือการเลือกขนาด Droplet ให้พอดีกับ workload จริง (right-sizing) หลายทีมที่ย้ายมาใหม่มักเลือก Droplet ขนาดใหญ่เกินจำเป็นเพราะกลัวปัญหาประสิทธิภาพ ทั้งที่ Droplet สามารถ resize เพิ่มขนาดภายหลังได้เมื่อ traffic เพิ่มขึ้นจริง เริ่มจากขนาดที่พอดีแล้วปรับตามการใช้งานจริงจะประหยัดกว่า คำแนะนำคือควรตั้ง Billing Alert ผ่าน DigitalOcean control panel ทันทีหลังย้ายเสร็จ เพื่อแจ้งเตือนเมื่อค่าใช้จ่ายเกินเกณฑ์ที่กำหนดไว้ และควรตรวจสอบ resource ที่ไม่ได้ใช้แล้ว (Volume, Snapshot, Reserved IP ที่ไม่ได้ผูก) เป็นระยะทุกเดือน ข้อมูลราคาทั้งหมดในบทความนี้คือ ณ กรกฎาคม 2026 ควรตรวจสอบราคาล่าสุดที่เว็บผู้ให้บริการก่อนวางแผนงบประมาณจริง

• Reserved IP ที่ไม่ผูก Droplet มีค่าใช้จ่าย $5/เดือน
• Volume คิด $0.10/GiB/เดือน, Snapshot คิด $0.06/GiB/เดือน สะสมได้ถ้าลืมลบ
• Managed Database storage เกิน tier เริ่มต้นคิดเพิ่ม $0.215/GiB/เดือน
• เลือกขนาด Droplet ให้พอดีกับ workload จริง (right-sizing) แล้ว resize ภายหลังได้
• ตั้ง Billing Alert ทันทีหลังย้ายเสร็จ

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

การย้ายจาก AWS มา DigitalOcean เหมาะกับบางสถานการณ์มากกว่าสถานการณ์อื่น การประเมินให้ชัดก่อนตัดสินใจจะช่วยลดความเสี่ยงระหว่างย้ายได้มาก สถานการณ์ที่เหมาะสม เช่น ทีมที่ workload หลักเป็นสถาปัตยกรรมมาตรฐาน ไม่ว่าจะเป็น web application, REST API, background worker หรือฐานข้อมูลเชิงสัมพันธ์ทั่วไป ที่รันได้บน virtual machine หรือ container โดยไม่ผูกกับบริการเฉพาะทางของ AWS เช่น Lambda ที่เชื่อมกับ event source อื่นในระบบนิเวศ AWS จำนวนมาก, Redshift สำหรับ data warehouse, หรือ SageMaker สำหรับ machine learning pipeline นอกจากนี้ทีมขนาดเล็กถึงกลางที่ไม่มี dedicated cloud/FinOps engineer และต้องการโครงสร้างราคาที่คาดเดาง่ายกว่า ก็มักได้ประโยชน์ชัดเจนจากการย้ายมา DigitalOcean อีกกรณีคือทีมที่ผู้ใช้งานส่วนใหญ่อยู่ในภูมิภาคเอเชียตะวันออกเฉียงใต้ เพราะ DigitalOcean มี region สิงคโปร์ (sgp1) และบังกาลอร์ (blr1) ที่ latency ต่ำสำหรับผู้ใช้ในไทย ซึ่งอาจใกล้เคียงหรือดีกว่า region AWS ที่ทีมเคยใช้อยู่เดิม แล้วแต่การตั้งค่าเดิม ในทางกลับกัน สถานการณ์ที่ควรพิจารณาให้รอบคอบก่อนย้าย เช่น ระบบที่ผูกกับบริการเฉพาะทางของ AWS อย่างลึก (deep integration กับ IAM role, CloudFormation stack ที่ซับซ้อน, หรือบริการที่ DigitalOcean ไม่มีเทียบเท่า) การย้ายในกรณีนี้อาจต้องเขียนโค้ดส่วนที่เกี่ยวข้องใหม่ทั้งหมด ไม่ใช่แค่เปลี่ยน endpoint หรือทีมที่มีข้อกำหนดด้าน compliance/certification เฉพาะอุตสาหกรรมที่ผูกกับ AWS โดยเฉพาะ ควรตรวจสอบให้แน่ใจก่อนว่า DigitalOcean ตอบโจทย์ข้อกำหนดเหล่านั้นได้จริง สำหรับทีมที่ยังไม่แน่ใจ แนะนำให้เริ่มย้าย workload ที่มีความเสี่ยงต่ำที่สุดก่อน เช่น environment staging หรือบริการภายในที่ไม่กระทบผู้ใช้ปลายทางโดยตรง เพื่อประเมินความพร้อมของทีมและเครื่องมือก่อนย้าย production จริง

• เหมาะกับ workload มาตรฐาน (web app/API/database) ที่ไม่ผูกกับบริการเฉพาะทางของ AWS
• เหมาะกับทีมที่ไม่มี dedicated cloud/FinOps engineer
• ผู้ใช้งานอยู่แถบเอเชียตะวันออกเฉียงใต้ได้ประโยชน์จาก region สิงคโปร์/บังกาลอร์

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

ข้อผิดพลาดแรกที่พบบ่อยคือลืม hardcoded endpoint ของ AWS ในโค้ด เช่น URL ของ S3 bucket ที่ฝังตรงในไฟล์ config หรือ hostname ของ RDS ที่เขียนตรงในโค้ดแทนที่จะอ่านจาก environment variable ทำให้หลังสลับ DNS แล้วแอปยังพยายามเชื่อมต่อ AWS อยู่ วิธีแก้คือ grep หาคำว่า amazonaws.com ทั่วทั้ง codebase ก่อนย้ายจริง และย้าย config ทั้งหมดไปใช้ environment variable ข้อผิดพลาดที่สองคือไม่ได้ทดสอบแอปพลิเคชันบน Droplet ใหม่ให้ครบก่อน cutover โดยเฉพาะ SSL certificate ที่มักออกใหม่ผิดพลาดหรือยังไม่ครอบคลุมทุก subdomain ทำให้ผู้ใช้เจอ browser warning ทันทีหลังสลับ DNS วิธีแก้คือทดสอบด้วย curl --resolve ตามที่กล่าวไว้ในหัวข้อก่อนหน้า และตรวจสอบใบรับรอง SSL ให้ครบทุก domain/subdomain ก่อน cutover จริง ข้อผิดพลาดที่สามคือไม่ได้ตั้งค่า Cloud Firewall ให้ครบก่อนเปิด traffic จริง เพราะ security group เดิมบน AWS ไม่ได้ย้ายมาอัตโนมัติ ต้องสร้าง firewall rule ใหม่บน DigitalOcean เอง เช่นเปิดเฉพาะ port 80/443 สำหรับ web server และ port SSH เฉพาะ IP ที่ทีมใช้งาน หากลืมขั้นตอนนี้อาจเปิดพอร์ตกว้างเกินไปโดยไม่ตั้งใจ ข้อผิดพลาดที่สี่คือประเมิน downtime ของฐานข้อมูลต่ำเกินไป โดยเฉพาะฐานข้อมูลขนาดใหญ่ที่ export/import ด้วย pg_dump/mysqldump ธรรมดาใช้เวลานานกว่าที่คาด ทำให้ downtime จริงยาวกว่าที่แจ้งผู้ใช้ไว้ วิธีแก้คือทดสอบเวลาที่ใช้จริงบน staging ก่อน และพิจารณาใช้ replication แบบต่อเนื่องสำหรับฐานข้อมูลขนาดใหญ่แทนการ dump/restore ทั้งก้อน ข้อผิดพลาดสุดท้ายคือปิด instance บน AWS เร็วเกินไปหลัง cutover ทั้งที่ยังมี traffic บางส่วนค้างอยู่จาก DNS cache เก่าของผู้ใช้บางราย ควรเฝ้า monitor ทั้งสองฝั่งอย่างน้อย 24-48 ชั่วโมงก่อนปิด resource บน AWS จริง เพื่อให้แน่ใจว่าไม่มี traffic เหลือค้างและมี fallback หากพบปัญหาหลัง cutover

1. Hardcoded endpoint ของ AWS ในโค้ด — grep หา amazonaws.com ก่อนย้าย
2. ไม่ทดสอบ SSL/virtual host ก่อน cutover — ใช้ curl --resolve ทดสอบก่อนเสมอ
3. ลืมตั้ง Cloud Firewall ใหม่ — security group เดิมไม่ย้ายมาอัตโนมัติ

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

การย้ายระบบขนาดใหญ่ควรทำแบบเป็นขั้น (phased migration) แทนการย้ายทุกอย่างพร้อมกันในครั้งเดียว เริ่มจากส่วนที่มีความเสี่ยงต่ำสุดก่อน เช่นย้ายไฟล์ static จาก S3 มา Spaces ก่อน เพราะไม่กระทบ traffic เขียน/อ่านแบบ real-time มากนัก ตามด้วยย้าย application server จาก EC2 มา Droplet โดยรันคู่ขนานกับของเดิมชั่วคราวเพื่อทดสอบ แล้วจึงย้ายฐานข้อมูลเป็นลำดับสุดท้ายเพราะเป็นส่วนที่มีความเสี่ยงสูงสุดและ downtime กระทบมากที่สุด ควรใช้เครื่องมือ automation อย่าง doctl หรือ Terraform provider ของ DigitalOcean ในการสร้าง infrastructure แทนการคลิกสร้างผ่าน control panel ทีละอย่าง เพราะช่วยให้ย้ายซ้ำหรือ rollback ได้ง่ายกว่าหากพบปัญหาระหว่างทาง และทำให้ staging environment กับ production environment มีการตั้งค่าตรงกันแบบ reproducible ควรเก็บ resource บน AWS ไว้ในสถานะ 'พร้อมใช้แต่ไม่รับ traffic' อย่างน้อยระยะหนึ่งหลัง cutover แทนที่จะปิดทันที เพื่อให้มี rollback path หากพบปัญหาที่ไม่คาดคิดหลังย้าย เมื่อมั่นใจว่าระบบบน DigitalOcean เสถียรแล้วในช่วงเวลาที่กำหนดไว้ล่วงหน้า (เช่น 1-2 สัปดาห์) จึงค่อยปิด resource บน AWS จริง ควรเขียน runbook สำหรับขั้นตอน cutover ไว้ล่วงหน้าอย่างละเอียด รวมถึงขั้นตอน rollback หากพบปัญหา และกำหนดผู้รับผิดชอบแต่ละขั้นตอนให้ชัดเจน เพื่อลดความสับสนในวันที่ cutover จริง โดยเฉพาะหากทีมมีสมาชิกหลายคนที่ต้องประสานงานพร้อมกัน สุดท้าย ควรตั้ง Monitoring และ Alert Policy บน DigitalOcean ให้ครบตั้งแต่ก่อน cutover ไม่ใช่หลังจากนั้น เพื่อให้ทีมเห็นปัญหาได้ทันทีตั้งแต่ช่วงแรกที่ traffic เริ่มไหลเข้าระบบใหม่ ซึ่ง DigitalOcean มี monitoring และ 1 uptime check ให้ใช้งานฟรีต่อบัญชีอยู่แล้ว

• ย้ายแบบเป็นขั้น (phased) เริ่มจากความเสี่ยงต่ำสุดไปสูงสุด: static files → app server → database
• ใช้ doctl/Terraform สร้าง infrastructure แทนคลิกทีละอย่าง เพื่อ reproducibility
• เก็บ resource บน AWS ไว้เป็น rollback path 1-2 สัปดาห์ก่อนปิดจริง

รับ $200 Free Credit →