ย้ายระบบขึ้น AWS ต้องรู้อะไรบ้าง? เช็กลิสต์ก่อนย้าย และค่าใช้จ่ายจริงที่คนมักคิดไม่ถึง
การย้ายขึ้นคลาวด์ที่ล้มเหลว ส่วนใหญ่ไม่ได้ล้มเพราะเทคนิคยาก — แต่ล้มเพราะย้ายไปโดยไม่รู้ว่า กำลังแก้ปัญหาอะไรอยู่ บทความนี้คือสิ่งที่ผมอยากให้ลูกค้าอ่านก่อนคุยงาน เพื่อจะได้ตัดสินใจจากข้อมูลจริง ไม่ใช่จากกระแส
1. ก่อนอื่น: คุณย้ายไปทำไม?
“ขึ้นคลาวด์แล้วประหยัดกว่า” เป็นความเชื่อที่ผิดบ่อยที่สุด ความจริงคือ ถ้าย้ายระบบเดิมขึ้นไปดื้อ ๆ โดยไม่ปรับอะไรเลย บิลมักจะแพงกว่าเซิร์ฟเวอร์เดิม เพราะคุณจ่ายค่า “ความยืดหยุ่น” ที่ยังไม่ได้ใช้
เหตุผลที่ย้ายแล้วคุ้มจริง มักเป็นข้อใดข้อหนึ่งใน 4 ข้อนี้:
- ▸โหลดขึ้น-ลงไม่แน่นอน — มีช่วงพีค (แคมเปญ, ต้นเดือน) ที่เครื่องเดิมรับไม่ไหว แต่ช่วงปกติเครื่องว่าง
- ▸ระบบล่มไม่ได้ — ต้องการ backup/failover ข้ามโซนแบบอัตโนมัติ ซึ่งทำเองบนเครื่องเดียวไม่ได้
- ▸ทีมโตขึ้น — อยากได้ CI/CD deploy อัตโนมัติ แทนการ SSH เข้าไปแก้ไฟล์บนเครื่องจริง
- ▸เครื่องเก่าหมดอายุ — ถึงรอบต้องซื้อเซิร์ฟเวอร์ใหม่ก้อนใหญ่ เลยเทียบกับการเช่าแทน
ถ้าอ่านครบ 4 ข้อแล้วไม่ตรงสักข้อ — ระบบเดิมเสถียรดี โหลดนิ่ง ทีมเล็ก — การไม่ย้ายก็เป็นคำตอบที่ถูกต้องเหมือนกัน และผมจะบอกตรง ๆ แบบนั้น
2. ค่าใช้จ่ายแอบแฝงที่ทำให้บิลบานปลาย
คนส่วนใหญ่กดดูราคาแค่ค่าเครื่อง (EC2) แล้วคิดว่านั่นคือบิลทั้งหมด ของจริงมีอีกหลายก้อนที่โผล่มาทีหลัง:
| ค่าใช้จ่าย | คนมักลืม เพราะ… |
|---|---|
| Data transfer ขาออก | ขาเข้าฟรี แต่ขาออกคิดเงิน — เว็บที่มีรูป/วิดีโอเยอะโดนหนัก |
| NAT Gateway | คิดทั้งรายชั่วโมง และ ตามปริมาณข้อมูล เป็นตัวดันบิลอันดับต้น ๆ |
| EBS snapshot | สแนปช็อตสะสมไปเรื่อย ๆ ถ้าไม่ตั้งอายุลบอัตโนมัติ |
| Load Balancer | มีค่าคงที่รายชั่วโมงถึงจะไม่มีทราฟฟิกก็ตาม |
| CloudWatch logs | เก็บ log ละเอียดเกินจำเป็น ค่าเก็บสะสมบานได้ |
| ทรัพยากรที่ลืมปิด | เครื่องทดสอบ / IP ที่จองไว้ไม่ได้ใช้ — เงียบ ๆ แต่จ่ายทุกเดือน |
ตั้ง Billing Alert ตั้งแต่วันแรกที่เปิดบัญชี ก่อนจะย้ายอะไรขึ้นไปด้วยซ้ำ ตั้งงบไว้เท่าที่รับได้ แล้วให้มันเมลเตือนเมื่อใกล้ถึง — ใช้เวลา 5 นาที แต่กันบิลช็อกหลักหมื่นได้
3. เลือกวิธีย้ายให้ตรงกับสถานการณ์
ไม่มีวิธีที่ถูกที่สุดวิธีเดียว มีแต่วิธีที่เหมาะกับเวลาและงบที่คุณมี:
ยกทั้งก้อนขึ้นไป
ย้ายระบบเดิมขึ้น EC2 แทบไม่แก้อะไร — เร็วที่สุด เสี่ยงต่ำ แต่ไม่ได้ประโยชน์ของคลาวด์เต็มที่ และมักไม่ประหยัดขึ้น
ย้ายแล้วปรับบางส่วน
ย้ายขึ้นไป แต่เปลี่ยนบางชิ้นเป็นบริการสำเร็จรูป เช่น ใช้ RDS แทนดูแล DB เอง — จุดสมดุลที่ผมแนะนำบ่อยที่สุด
รื้อเขียนใหม่
ออกแบบใหม่ให้เป็น container/serverless — ได้ผลดีที่สุดระยะยาว แต่แพงและใช้เวลานานสุด ไม่เหมาะเป็นก้าวแรก
คำแนะนำจริง: อย่ารื้อใหญ่พร้อมกับย้ายในทีเดียว ถ้าย้ายเสร็จแล้วระบบพัง คุณจะแยกไม่ออกว่าพังเพราะการย้าย หรือเพราะโค้ดที่เพิ่งเขียนใหม่ ย้ายให้เสถียรก่อน แล้วค่อยปรับทีละชิ้น
4. เช็กลิสต์ก่อนวันย้ายจริง
- ทดสอบกู้คืนข้อมูลจริง — ไม่ใช่แค่มีไฟล์ backup แต่ต้องเคยกู้กลับมาสำเร็จจริงอย่างน้อยหนึ่งครั้ง
- ลด TTL ของ DNS ล่วงหน้า 24–48 ชม. — ให้เหลือ 300 วิ ก่อนย้าย จะได้สลับกลับได้เร็วถ้ามีปัญหา
- มีแผนถอยกลับ (rollback) — เขียนเป็นขั้นตอนไว้ก่อน ว่าถ้าพังจะกลับยังไง ใครกดปุ่ม
- รันคู่ขนานก่อนสลับจริง — ให้ระบบใหม่ทำงานพร้อมกับของเดิมสักพัก แล้วเทียบผลลัพธ์
- ตั้ง monitoring ก่อนย้าย ไม่ใช่หลังย้าย — ไม่งั้นจะไม่รู้ว่าระบบใหม่ช้ากว่าเดิมหรือเปล่า
- ย้ายช่วงทราฟฟิกต่ำสุด — และแจ้งลูกค้า/ทีมล่วงหน้าว่าอาจมีช่วงสะดุด
- อย่าเพิ่งลบเซิร์ฟเวอร์เดิม — เก็บไว้อย่างน้อย 2–4 สัปดาห์ ค่าเช่าอีกเดือนถูกกว่าข้อมูลหาย
5. ทำเอง จ้าง freelance หรือจ้างบริษัท?
งานย้ายระบบขึ้นคลาวด์เป็นงาน “ทำครั้งเดียวแต่พลาดไม่ได้” ซึ่งเป็นรูปแบบงานที่จ้างคนนอกคุ้มที่สุด เพราะการจ้างพนักงานประจำมานั่งทำงานที่ทำปีละครั้งนั้นไม่คุ้ม ขณะที่การให้ทีมที่ไม่เคยย้ายมาลองผิดลองถูกกับระบบ production ก็แพงในอีกทางหนึ่ง
สิ่งที่ควรได้จากคนที่คุณจ้าง ไม่ใช่แค่ “ระบบขึ้นไปแล้ว” แต่ต้องมี โครงสร้างที่เขียนเป็นโค้ด (IaC) ส่งมอบด้วย — เพื่อว่าถ้าวันหนึ่งคุณเลิกจ้าง หรือคนทำหายไป ระบบยังสร้างใหม่ได้จากโค้ด ไม่ใช่ความรู้ที่อยู่ในหัวใครคนเดียว ถ้าใครรับงานย้ายคลาวด์แล้วไม่ส่งมอบส่วนนี้ ให้ถามเขาว่าทำไม
สรุป
ย้ายขึ้น AWS ให้สำเร็จ ไม่ได้ต้องการความรู้ลึกที่สุดในโลก แต่ต้องการ เหตุผลที่ชัดว่าย้ายไปทำไม แผนถอยกลับที่ใช้ได้จริง และการมองเห็นค่าใช้จ่ายตั้งแต่วันแรก ทั้งสามข้อนี้ทำได้ตั้งแต่ก่อนแตะปุ่มแรกด้วยซ้ำ