# Cloud Solution สำหรับธุรกิจไทย: เลือกอย่างไรให้คุ้มและถูก PDPA

> **สรุปสั้น ๆ** — Cloud Solution คือการเช่าใช้เซิร์ฟเวอร์ ฐานข้อมูล และซอฟต์แวร์ผ่านอินเทอร์เน็ต แทนการซื้อเครื่องมาตั้งเอง แบ่งเป็นสามแบบ คือ IaaS, PaaS และ SaaS ธุรกิจไทยควรเริ่มจากคำถามเดียวก่อน คือข้อมูลต้องอยู่ในประเทศหรือไม่ เพราะ AWS เปิด Region ไทยแล้วตั้งแต่มกราคม 2568 และ Google Cloud เปิด Region กรุงเทพฯ เมื่อมกราคม 2569 ส่วน Azure ยังเป็นเพียงการประกาศเจตนา เมื่อตอบคำถามนี้ได้แล้ว จึงค่อยเลือกวิธีย้าย ประเมินต้นทุนจริง และวางระบบสิทธิ์กับการสำรองข้อมูลให้ครบ

- **ต้นฉบับ:** https://www.nexion.co.th/articles/cloud-solution-thailand
- **ผู้เขียน:** ทีมวิศวกรรม Nexion — Nexion Corporation (บริษัท เนคซีออน คอร์ปอเรชั่น จำกัด), กรุงเทพฯ ประเทศไทย
- **เผยแพร่:** 2026-08-13 · **ตรวจสอบข้อเท็จจริงล่าสุด:** 2026-08-21 · **ปรับปรุงหน้าเว็บล่าสุด:** 2026-08-20
- **หมวด:** Cloud · **เวลาอ่าน:** 9 นาที · **ภาษา:** ไทย

---

คำว่า "ขึ้น cloud" ถูกใช้จนเกือบไม่เหลือความหมาย ผู้ขายบอกว่าประหยัดกว่า ที่ปรึกษาบอกว่าต้องรีบย้าย แต่สิ่งที่คุณต้องตัดสินใจจริงมีไม่กี่ข้อ ระบบไหนควรอยู่ที่ไหน ข้อมูลลูกค้าต้องอยู่ในไทยหรือไม่ ใครดูแลต่อ และสิ้นเดือนจะจ่ายเท่าไร บทความนี้ตอบด้วยข้อมูลที่ตรวจสอบได้ ณ สิงหาคม 2569 รวมถึงกรณีที่ cloud ไม่คุ้ม ซึ่งคนขายมักไม่พูดถึง

## Cloud Solution คืออะไรในทางปฏิบัติ

Cloud Solution คือการเช่าใช้ทรัพยากรคอมพิวเตอร์ของผู้ให้บริการรายใหญ่ผ่านอินเทอร์เน็ต แทนการซื้อเซิร์ฟเวอร์มาตั้งเอง คุณจ่ายตามที่ใช้จริง และเพิ่มหรือลดขนาดได้ในไม่กี่นาที

ความต่างที่แท้จริงไม่ใช่เทคโนโลยี แต่คือวิธีจ่ายเงินที่เปลี่ยนไป แบบเดิมคือลงทุนก้อนใหญ่ครั้งเดียวแล้วตัดค่าเสื่อม 3–5 ปี ซึ่งทางบัญชีเรียกว่า CAPEX แบบใหม่คือจ่ายรายเดือนตามการใช้งานจริง หรือ OPEX ความต่างข้อนี้กระทบทั้งงบประมาณและวิธีอนุมัติของคุณ

บริการ cloud แบ่งเป็นสามชั้น ตามระดับที่ผู้ให้บริการดูแลแทนคุณ เทียบกับการเช่าพื้นที่จะเข้าใจง่ายที่สุด

- **IaaS** (Infrastructure as a Service) — เหมือนเช่าที่ดินเปล่า คุณได้เครื่องเสมือน พื้นที่เก็บข้อมูล และเครือข่าย แล้วลง OS เอง ยืดหยุ่นที่สุดแต่ต้องดูแลเองมากที่สุด เช่น Amazon EC2
- **PaaS** (Platform as a Service) — เหมือนเช่าตึกที่มีระบบพร้อม เอาโค้ดมาวางแล้วรันได้เลย ไม่ต้องแพตช์ OS หรือดูแลฐานข้อมูลเอง เช่น AWS RDS, Google Cloud Run
- **SaaS** (Software as a Service) — เหมือนเช่าห้องพร้อมเฟอร์นิเจอร์ ล็อกอินแล้วใช้ได้ทันที เช่น Microsoft 365, Google Workspace ซึ่งหลายบริษัทไทยใช้อยู่แล้วโดยไม่ทันคิดว่านี่คือ cloud

> **จุดที่เข้าใจผิดบ่อย** — cloud ไม่ได้แปลว่าไม่ต้องมีคนดูแล ผู้ให้บริการรับผิดชอบความปลอดภัย*ของ*ตัว cloud เอง คือฮาร์ดแวร์และศูนย์ข้อมูล ส่วนคุณรับผิดชอบความปลอดภัย*บน* cloud คือสิทธิ์เข้าถึง การตั้งค่า การเข้ารหัส และข้อมูลของคุณเอง หลักนี้เรียกว่า Shared Responsibility Model และการเข้าใจผิดข้อนี้คือสาเหตุอันดับหนึ่งของข้อมูลรั่วบน cloud

## Public, Private หรือ Hybrid Cloud เลือกแบบไหน

**Public cloud** คือการใช้โครงสร้างพื้นฐานร่วมกับลูกค้ารายอื่นบนระบบของ AWS, Google Cloud หรือ Azure โดยแยกข้อมูลของแต่ละรายออกจากกันด้วยซอฟต์แวร์ จุดเด่นคือเริ่มได้เร็ว ไม่ต้องลงทุนล่วงหน้า และเข้าถึงบริการใหม่อย่าง AI ได้ทันที เหมาะกับธุรกิจส่วนใหญ่

**Private cloud** คือฮาร์ดแวร์ที่ใช้เฉพาะองค์กรคุณ จะตั้งเองหรือฝากไว้กับผู้ให้บริการในไทยก็ได้ ข้อดีคือควบคุมได้เต็มที่และตอบผู้กำกับดูแลง่ายกว่า ข้อเสียคือคุณกลับไปแบกภาระซื้อเครื่อง อัปเกรด และเผื่อกำลังเหมือนเดิม

**Hybrid cloud** คือการผสมสองแบบข้างต้นเข้าด้วยกัน และเป็นรูปแบบที่บริษัทไทยขนาดกลางถึงใหญ่ลงเอยด้วยมากที่สุด ภาพที่เห็นบ่อยคือเก็บ ERP และฐานข้อมูลลูกค้าไว้ในประเทศ แล้วยกเว็บไซต์กับงานที่โหลดผันผวนขึ้น public cloud

ข้อควรระวังของ hybrid คือคุณต้องดูแลสองสภาพแวดล้อมพร้อมกัน ต้องมีลิงก์เชื่อมที่เสถียร และต้องมีทีมที่เข้าใจทั้งสองฝั่ง

*[แผนภาพ: โครงสร้าง Hybrid Cloud ที่บริษัทไทยใช้จริง: ระบบหลักอยู่ในประเทศ ระบบที่โหลดผันผวนอยู่บน public cloud]* — Architecture diagram showing an on-premise data center in Thailand connected by a dedicated link to a public cloud region, with core ERP and customer database on-prem and web, analytics, and burst workloads in the cloud.

## AWS, Google Cloud หรือ Azure: เจ้าไหนมี Region ในไทยจริง

นี่คือข้อเท็จจริงที่เปลี่ยนการตัดสินใจของบริษัทไทยมากที่สุดในรอบสองปี และเป็นจุดที่ข้อมูลเก่าบนอินเทอร์เน็ตทำให้หลายคนตัดสินใจผิด

เริ่มจากศัพท์สองคำก่อน "Region" คือกลุ่มศูนย์ข้อมูลที่ตั้งอยู่ในพื้นที่เดียวกัน ส่วน "Availability Zone" หรือ AZ คือศูนย์ข้อมูลย่อยภายใน Region เดียวกัน ที่แยกระบบไฟฟ้าและระบบระบายความร้อนออกจากกัน เพื่อให้ระบบทำงานต่อได้แม้ศูนย์หนึ่งล่ม

การมี Region ในประเทศจึงให้ผลสองอย่างพร้อมกัน คือระบบตอบสนองเร็วขึ้นเพราะข้อมูลวิ่งใกล้ลง และคุณเลือกให้ข้อมูลอยู่ในเขตแดนไทยได้

| ผู้ให้บริการ | สถานะ Region ในไทย (ส.ค. 2569) | เปิดเมื่อ | จำนวน AZ | สิ่งที่ควรรู้ |
| --- | --- | --- | --- | --- |
| AWS | **เปิดแล้ว** — Asia Pacific (Thailand) รหัส ap-southeast-7 | ม.ค. 2568 | 3 AZ | เปิดก่อนใคร และมีบริการครบที่สุดในไทยตอนนี้ ข่าวเปิดตัวอ้างถึง KBTG และตลาดหลักทรัพย์ฯ เป็นลูกค้า |
| Google Cloud | **เปิดแล้ว** — Bangkok รหัส asia-southeast3 | ม.ค. 2569 | 3 AZ | ยังใหม่มาก บริการบางตัวอาจยังไม่เปิดครบ ต้องเช็กรายการก่อนออกแบบ Google ระบุว่ารองรับ data residency เป็นค่าเริ่มต้น |
| Microsoft Azure | **ยังไม่เปิด** — "Thailand South" อยู่ในสถานะประกาศเจตนา | ยังไม่ประกาศ | — | ถ้าต้องการให้ข้อมูลอยู่ในไทยวันนี้ Azure ยังตอบไม่ได้ ต้องใช้สิงคโปร์แทน Microsoft จับมือ CP Group และ True IDC เมื่อ ต.ค. 2568 เพื่อสร้าง Region นี้ |
| Alibaba Cloud | เปิดแล้ว — Thailand (Bangkok) | 2565 | 2 AZ | ราคามักถูกกว่า แต่เครื่องมือรอบข้างและจำนวนคนที่มีทักษะด้านนี้ในไทยเล็กกว่ามาก |

> ⚠️ **อย่าเชื่อคำว่า "มี data center ในไทย" โดยไม่ถามต่อ** — ผู้ให้บริการหลายรายมีเพียงจุดกระจายข้อมูลหรือจุดเชื่อมต่อเครือข่ายในไทย ซึ่งไม่เหมือนการมี Region ที่รันเครื่องและเก็บข้อมูลได้จริง ให้ขอผู้ขายระบุรหัส Region ที่คุณจะ deploy ลงไปเป็นลายลักษณ์อักษร ไม่ใช่แค่ชื่อประเทศบนสไลด์

เรื่องความเร็วให้คิดแบบนี้ ผู้ใช้ในกรุงเทพฯ ที่เรียกระบบซึ่งรันอยู่ในสิงคโปร์ ต้องรอข้อมูลวิ่งข้ามประเทศไปกลับทุกครั้ง การรันในไทยตัดระยะทางส่วนนั้นออกไป

ผลจะชัดที่สุดกับระบบที่คุยกันหลายรอบต่อหนึ่งหน้าจอ เช่น POS แอปธนาคาร หรือหน้าจอที่เรียกฐานข้อมูลหลายสิบครั้ง แต่แทบไม่มีผลกับงาน batch หรือรายงานรายวัน อย่ารับตัวเลขจากสไลด์ผู้ขาย ให้วัดจากเครือข่ายจริงของสำนักงานคุณก่อนตัดสินใจ

*[แผนภาพ: Region ของผู้ให้บริการ cloud ที่ให้บริการผู้ใช้ในประเทศไทย และผลต่อความเร็วในการตอบสนอง]* — Map graphic of Southeast Asia showing Bangkok with AWS ap-southeast-7 and Google Cloud asia-southeast3 markers, Singapore as the fallback region for Azure, with arrows indicating relative network round-trip distance.

## PDPA บังคับให้ข้อมูลต้องอยู่ในไทยหรือไม่

คำตอบสั้น ๆ คือ **ไม่บังคับ** พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 บังคับใช้เต็มรูปแบบตั้งแต่ 1 มิถุนายน 2565 และไม่ได้ห้ามส่งข้อมูลออกนอกประเทศ

แต่กฎหมายวางเงื่อนไขไว้ในมาตรา 28 และ 29 ว่าปลายทางต้องมีมาตรฐานคุ้มครองที่เพียงพอ หรือคุณต้องมีมาตรการคุ้มครองที่เหมาะสมมารองรับ

จุดที่ทำให้เรื่องนี้ยุ่งกว่าที่คิดคือ ถึงวันนี้ **คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ยังไม่ได้ประกาศรายชื่อประเทศที่มีมาตรฐานเพียงพอ** ในทางปฏิบัติคุณจึงต้องถือว่าปลายทางทุกแห่งยังไม่ได้รับการรับรอง และต้องใช้กลไกรองรับอย่างใดอย่างหนึ่งจากสามทางนี้

- **ข้อสัญญามาตรฐาน** (Standard Contractual Clauses หรือ ASEAN Model Contractual Clauses) เป็นทางที่เร็วและใช้ได้จริงที่สุดสำหรับบริษัทส่วนใหญ่
- **นโยบายคุ้มครองข้อมูลในเครือกิจการ** (Binding Corporate Rules) สำหรับกลุ่มบริษัทข้ามชาติ ระเบียบว่าด้วยการตรวจสอบและรับรอง BCR ประกาศในราชกิจจานุเบกษาเมื่อ 17 กุมภาพันธ์ 2569 และกระบวนการอนุมัติใช้เวลาราวหกเดือน
- **ข้อยกเว้นตามกฎหมาย** เช่น ความยินยอมที่แจ้งความเสี่ยงให้เจ้าของข้อมูลทราบแล้ว หรือความจำเป็นตามสัญญา

แต่สิ่งที่หน่วยงานกำกับตรวจจริง กลับไม่ใช่ที่ตั้งของเซิร์ฟเวอร์เป็นอันดับแรก เมื่อ 1 สิงหาคม 2568 PDPC สั่งปรับทางปกครองแปดกรณี รวมราว 21.5 ล้านบาท รายที่สูงสุดถูกปรับ 7 ล้านบาท ความผิดที่พบซ้ำมีอยู่สี่เรื่อง

- ไม่มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม
- ไม่แจ้งเหตุละเมิดข้อมูลภายใน 72 ชั่วโมง
- ไม่แต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO)
- ไม่มีข้อตกลงประมวลผลข้อมูลกับผู้ให้บริการ

พูดง่าย ๆ คือ ต่อให้คุณย้ายข้อมูลมาไว้ใน Region ไทยครบทุกไบต์ แต่ไม่มีเอกสารและกระบวนการสี่ข้อนี้ ก็ยังถูกปรับได้อยู่ดี

> **กฎเฉพาะบางกลุ่มธุรกิจ** — สถาบันการเงินภายใต้การกำกับของธนาคารแห่งประเทศไทยมีข้อกำหนดเพิ่มเรื่องการใช้บริการภายนอกด้าน IT และแนวปฏิบัติการบริหารความเสี่ยงด้านเทคโนโลยีสารสนเทศ ครอบคลุมถึงความต่อเนื่องทางธุรกิจและการประเมินผู้ให้บริการอย่างสม่ำเสมอส่วนหน่วยงานรัฐและองค์กรโครงสร้างพื้นฐานสำคัญทางสารสนเทศ ต้องทำตามมาตรฐานความมั่นคงปลอดภัยด้าน cloud ของ NCSA ที่จะมีผลบังคับใช้ 10 กันยายน 2569 เอกชนทั่วไปยังไม่ถูกบังคับโดยตรง แต่ถ้าคุณเป็นคู่ค้าของหน่วยงานเหล่านี้ ข้อกำหนดจะถูกส่งต่อมาทางสัญญาแน่นอน

## ค่าใช้จ่าย cloud จริง ๆ มาจากไหน

บิล cloud ไม่ได้บวมเพราะราคาต่อหน่วยแพง แต่บวมเพราะไม่มีใครปิดของที่ไม่ได้ใช้

รายงาน State of the Cloud ปี 2026 ของ Flexera ประเมินว่าค่าใช้จ่าย cloud ที่สูญเปล่าอยู่ที่ราว 29% และ 85% ขององค์กรระบุว่าการบริหารค่าใช้จ่าย cloud คือความท้าทายอันดับหนึ่ง ตัวเลขนี้เป็นค่าเฉลี่ยทั่วโลก ไม่ใช่คำสัญญาว่าคุณจะประหยัดได้เท่านี้

| ตัวขับต้นทุน | ความผิดพลาดที่เจอบ่อยในไทย | สิ่งที่ควรทำ |
| --- | --- | --- |
| ขนาดเครื่อง | ตั้งเครื่องเผื่อเท่าสเปกเซิร์ฟเวอร์เดิมที่ซื้อเผื่อไว้ 5 ปี แล้วใช้ CPU จริงไม่ถึง 10% | ดูสถิติย้อนหลัง 30 วันแล้วลดขนาดลง ถ้าไม่พอก็ปรับกลับได้ในไม่กี่นาที |
| เครื่องที่ลืมปิด | เครื่อง dev/test และงานทดลองเปิดค้าง 24 ชั่วโมงทุกวัน รวมวันหยุด | ตั้งตารางเปิด-ปิดอัตโนมัติ และบังคับติด tag วันหมดอายุกับทรัพยากรชั่วคราวทุกตัว |
| ค่าโอนข้อมูลออก | ให้แอปดึงไฟล์และรูปจาก cloud ตรงถึงผู้ใช้ทุกครั้ง หรือย้ายข้อมูลข้ามโซนไปมาโดยไม่จำเป็น | ใช้ CDN และ cache วางระบบที่คุยกันบ่อยไว้โซนเดียวกัน AWS ให้โอนออกอินเทอร์เน็ตฟรี 100 GB ต่อเดือน ส่วนที่เกินคิดเงิน |
| พื้นที่เก็บข้อมูลและ snapshot | เก็บ snapshot และ log ทุกวันโดยไม่มีนโยบายลบ สะสมสามปีจนกลายเป็นค่าใช้จ่ายที่ไม่มีเจ้าของ | ตั้ง lifecycle policy ให้ย้ายข้อมูลเก่าไปชั้นราคาถูก และลบตามอายุ |
| ไม่ซื้อส่วนลดระยะยาว | จ่ายราคา on-demand เต็มทั้งที่ระบบหลักรัน 24/7 มาสามปีและไม่มีทางปิด | ผูกสัญญาเฉพาะส่วนที่แน่นอน แล้วปล่อยส่วนที่ผันผวนไว้แบบ on-demand |
| License | ยก Windows Server และ SQL Server ขึ้นไปแบบเดิมโดยไม่ตรวจสิทธิ์ที่ถืออยู่ | ตรวจ license ก่อนย้าย และพิจารณาโอเพนซอร์สในระบบที่เปลี่ยนได้ |

*[แผนภาพ: สัดส่วนตัวขับต้นทุนบนบิล cloud ทั่วไป และจุดที่มักเกิดความสูญเปล่า]* — Horizontal breakdown chart of a typical cloud bill by category (compute, storage, data transfer, managed services, licensing) with waste hotspots highlighted.

ส่วนลดที่ผู้ให้บริการประกาศเป็นทางการนั้นมีอยู่จริง และนี่คือรายการหลัก

- **AWS Compute Savings Plans** ลดได้สูงสุดราว 66% และ EC2 Instance Savings Plans สูงสุดราว 72% เมื่อผูกสัญญา 1 หรือ 3 ปี
- **Spot Instances** สำหรับงานที่หยุดกลางคันได้ ลดได้สูงสุดราว 90%
- **เครื่องตระกูล Graviton** ที่ AWS ระบุว่าถูกกว่าเครื่อง x86 เทียบเท่าได้ถึง 20%
- **Google Cloud committed use discounts** สูงสุดราว 55% สำหรับเครื่องทั่วไป และ 70% สำหรับกลุ่ม memory-optimized
- **Azure Reservations** ที่ Microsoft ระบุช่วงประหยัดไว้ราว 36–72%

> ⚠️ **พูดกันตรง ๆ เรื่องตัวเลขประหยัด** — คำว่า "สูงสุด" คือค่าที่ดีที่สุดในเงื่อนไขที่เหมาะสมที่สุด ไม่ใช่ค่าที่คุณจะได้จริงในงาน FinOps จริงบนระบบที่ไม่เคยจัดระเบียบ การลดขนาดเครื่อง ปิดของที่ไม่ใช้ ล้างข้อมูลเก่า และซื้อส่วนลดระยะยาว มักลดบิลได้ในระดับหลักสิบเปอร์เซ็นต์ แต่ถ้าระบบคุณถูกปรับแต่งมาดีแล้ว ผลอาจเหลือน้อยกว่า 10% ใครที่รับประกันตัวเลขให้คุณก่อนดูบิลจริง คือคนที่ยังไม่ได้ดูบิลของคุณ

เครื่องมือควบคุมที่ได้ผลที่สุด กลับเป็นเรื่องพื้นฐานที่สุด คือบังคับติด tag กับทรัพยากรทุกตัว เพื่อให้ตอบได้ว่าเงินก้อนไหนเป็นของทีมใด

```
Tag ที่ควรบังคับใช้กับทุก resource
Environment = prod | uat | dev
Owner       = ทีม หรืออีเมลผู้รับผิดชอบ
CostCenter  = รหัสศูนย์ต้นทุนตามบัญชี
Project     = ชื่อระบบงาน
ExpiryDate  = YYYY-MM-DD (สำหรับ resource ชั่วคราว)

กฎ: resource ที่ tag ไม่ครบ = ปิดอัตโนมัติภายใน 7 วัน
```

## ย้ายระบบขึ้น cloud แบบไหน: Rehost, Replatform หรือ Refactor

คำถามที่ต้องตอบไม่ใช่ "ย้ายอย่างไร" แต่คือ "ระบบนี้จะอยู่กับเราอีกกี่ปี และตอนนี้มันเจ็บตรงไหน"

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

| วิธี | ทำอะไร | ความเร็ว/ความเสี่ยง | เหมาะกับ | ข้อควรระวัง |
| --- | --- | --- | --- | --- |
| **Rehost** (lift and shift) | ยกเครื่องเดิมขึ้นไปเป็นเครื่องเสมือนบน cloud แบบแทบไม่แก้อะไร | เร็วสุด เสี่ยงต่ำสุด | ระบบเก่าที่ต้องออกจาก data center ตามกำหนด หรือฮาร์ดแวร์หมดอายุ | ได้ประโยชน์จาก cloud น้อยสุด และมักแพงกว่าเดิมถ้าไม่ตามไปลดขนาดเครื่อง |
| **Replatform** | ยกขึ้นไปพร้อมเปลี่ยนบางส่วนเป็นบริการที่ผู้ให้บริการดูแลให้ เช่น managed database | ปานกลางทั้งคู่ | ระบบส่วนใหญ่ขององค์กรทั่วไป เป็นจุดสมดุลที่ดีที่สุดในทางปฏิบัติ | ต้องทดสอบ version และ performance ของฐานข้อมูลอย่างจริงจัง |
| **Refactor** | ออกแบบและเขียนใหม่ให้เป็นสถาปัตยกรรมสำหรับ cloud จริง ๆ เช่น แยกบริการย่อยหรือ serverless | ช้าสุด เสี่ยงสูงสุด | ระบบที่สร้างรายได้โดยตรง หรือถูกจำกัดด้วยสถาปัตยกรรมเดิม | ใช้ทีมและงบมากสุด อย่าเริ่มพร้อมกันหลายระบบ |
| **Retire / Retain** | เลิกใช้ระบบที่ไม่มีคนใช้ หรือคงไว้ที่เดิมสำหรับระบบที่ย้ายแล้วไม่คุ้ม | เร็ว ประหยัดทันที | ระบบซ้ำซ้อน หรือระบบที่ผูกกับเครื่องจักรเฉพาะ | ต้องสำรวจระบบทั้งหมดจริง ไม่ใช่เดา |

แนวทางที่ปลอดภัยที่สุดสำหรับองค์กรที่ยังไม่มีประสบการณ์ คือเริ่มจากระบบความสำคัญปานกลางหนึ่งตัว ทำให้จบครบวงจรตั้งแต่ย้าย ทดสอบ ตัดระบบ จนถึงดูแลจริงหนึ่งรอบเดือน แล้วค่อยขยาย

เพราะสิ่งที่ต้องพิสูจน์ในรอบแรกไม่ใช่เทคโนโลยี แต่คือความสามารถของทีมในการดูแลระบบบนสภาพแวดล้อมใหม่

*[แผนภาพ: ผังตัดสินใจเลือกวิธีย้ายระบบขึ้น cloud]* — Decision tree flowchart starting from "How long will this system live?" and "What hurts today?" branching into Retire, Retain, Rehost, Replatform, and Refactor outcomes.

## มาตรฐานความปลอดภัยขั้นต่ำที่ต้องมีตั้งแต่วันแรก

ข้อมูลรั่วบน cloud เกือบทั้งหมดไม่ได้เกิดจากผู้ให้บริการถูกเจาะ แต่เกิดจากการตั้งค่าผิดของผู้ใช้เอง สี่เรื่องนี้คือขั้นต่ำที่ต้องมีก่อนระบบแรกขึ้นใช้งานจริง ไม่ใช่ค่อยไปทำทีหลัง

- **การจัดการสิทธิ์ (IAM)** — ห้ามใช้บัญชีสูงสุดทำงานประจำ เปิดยืนยันตัวตนสองชั้นกับทุกบัญชีที่มีสิทธิ์สูง ให้สิทธิ์เท่าที่จำเป็น และเลิกฝังกุญแจถาวรไว้ในโค้ด
- **การสำรองข้อมูล** — สำรองอัตโนมัติตามตาราง เก็บสำเนาไว้คนละบัญชีหรือคนละ Region และที่สำคัญที่สุดคือ*ทดสอบกู้คืนจริง*อย่างน้อยปีละครั้ง แบ็กอัปที่ไม่เคยกู้คืนสำเร็จ คือแบ็กอัปที่ยังพิสูจน์ไม่ได้ว่ามีอยู่
- **แผนกู้คืนระบบ (DR)** — กำหนดสองตัวเลขร่วมกับฝ่ายธุรกิจ คือระบบล่มได้นานสุดกี่ชั่วโมง และยอมเสียข้อมูลย้อนหลังได้กี่นาที ตัวเลขยิ่งเข้มงวด ค่าใช้จ่ายยิ่งสูงแบบก้าวกระโดด นี่จึงเป็นการตัดสินใจทางธุรกิจ ไม่ใช่ของฝ่ายไอทีฝ่ายเดียว
- **การเฝ้าระวัง** — เปิดบันทึกการเข้าถึงและการเปลี่ยนแปลงการตั้งค่าทั้งหมด ตั้งแจ้งเตือนทั้งด้านเทคนิคและด้านค่าใช้จ่าย งบประมาณที่แจ้งเตือนเมื่อใช้เกิน 80% ช่วยจับปัญหาได้ก่อนสิ้นเดือนเสมอ

ทั้งสี่ข้อนี้ตรงกับสิ่งที่ PDPC ตรวจพบว่าองค์กรที่ถูกปรับทำไม่ครบ การลงทุนเรื่องนี้จึงไม่ใช่แค่ความปลอดภัย แต่คือหลักฐานว่าคุณปฏิบัติตามกฎหมายด้วย

## เมื่อไหร่ที่ cloud ไม่ใช่คำตอบ

มีบางสถานการณ์ที่การย้ายขึ้น cloud ทำให้คุณจ่ายแพงขึ้นและได้ประโยชน์น้อยลง รู้ล่วงหน้าดีกว่ารู้ตอนได้บิลเดือนที่สาม

- **โหลดคงที่และคาดเดาได้** — ถ้าระบบใช้กำลังเท่าเดิมทุกวันตลอดปี ความยืดหยุ่นซึ่งเป็นจุดขายหลักของ cloud ก็ไม่ถูกใช้ เซิร์ฟเวอร์ที่ซื้อขาดหรือ dedicated server มักถูกกว่าเมื่อคิดตลอดอายุการใช้งาน
- **เพิ่งลงทุนฮาร์ดแวร์ไปไม่นาน** — ถ้ายังตัดค่าเสื่อมไม่หมด การย้ายทันทีเท่ากับจ่ายสองต่อ ควรวางแผนย้ายให้ตรงรอบหมดอายุของฮาร์ดแวร์
- **ระบบที่ต้องการความเร็วตอบสนองสูงมากในพื้นที่** — ระบบควบคุมเครื่องจักรในโรงงาน หรือ POS ที่ต้องทำงานต่อได้แม้อินเทอร์เน็ตขาด ควรอยู่หน้างาน แล้วใช้ cloud เป็นที่รวบรวมข้อมูลเท่านั้น
- **ข้อมูลมหาศาลที่ต้องดึงออกบ่อย** — งานที่ส่งข้อมูลออกเป็นเทระไบต์ทุกเดือน ค่าโอนข้อมูลอาจกลายเป็นก้อนที่ใหญ่กว่าค่าเครื่อง
- **องค์กรที่ยังไม่มีคนดูแล** — cloud ไม่ได้ลดภาระ แต่เปลี่ยนชนิดของภาระ ถ้าไม่มีทั้งทีมภายในและพาร์ตเนอร์ที่รับผิดชอบชัดเจน ระบบจะเสื่อมและบิลจะโตพร้อมกัน

## เริ่มยังไง: เส้นทาง 5 ขั้นตอนที่ใช้ได้จริง

1. **สำรวจของที่มีอยู่จริง** — ทำบัญชีระบบทั้งหมด ใครใช้ ใช้บ่อยแค่ไหน ผูกกับอะไร และใช้ทรัพยากรจริงเท่าไร ขั้นนี้มักเจอระบบที่ไม่มีใครใช้แล้วและปิดได้ทันที ซึ่งเป็นการประหยัดที่ถูกที่สุดที่คุณจะทำได้
1. **ตัดสินใจเรื่องข้อมูลก่อนเรื่องเทคโนโลยี** — จำแนกว่าข้อมูลชุดไหนเป็นข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหว ชุดไหนมีข้อกำหนดของผู้กำกับดูแล และชุดไหนออกนอกประเทศได้ ผลของขั้นนี้จะเป็นตัวกำหนดว่าคุณเลือก Region ไหนได้บ้าง ไม่ใช่โปรโมชันของผู้ขาย
1. **ทำโครงการนำร่องหนึ่งระบบให้จบครบวงจร** — เลือกระบบความสำคัญปานกลางหนึ่งตัว กำหนดเกณฑ์ความสำเร็จเป็นตัวเลขตั้งแต่ต้น เช่น เวลาตอบสนอง ค่าใช้จ่ายต่อเดือน และเวลาที่ใช้กู้คืน แล้วดูแลจริงครบหนึ่งรอบเดือนก่อนขยาย
1. **วางรากฐานการกำกับดูแลก่อนขยาย** — โครงสร้างบัญชีที่แยก prod ออกจาก dev มาตรฐานการติด tag สิทธิ์การเข้าถึง นโยบายสำรองข้อมูล และงบประมาณพร้อมการแจ้งเตือน ทำตอนยังไม่ถึงสิบระบบใช้เวลาไม่กี่วัน ทำทีหลังใช้เวลาหลายเดือน
1. **ตั้งรอบทบทวนต้นทุนและความปลอดภัย** — ทบทวนบิลทุกเดือนโดยมีทั้งฝ่ายไอทีและฝ่ายการเงิน ตรวจสิทธิ์และทดสอบกู้คืนข้อมูลอย่างน้อยทุกไตรมาส เพราะ cloud ที่ไม่มีคนดูจะแพงขึ้นเองทุกเดือน

เกณฑ์ตัดสินว่าโครงการ cloud สำเร็จหรือไม่ ไม่ใช่ "ย้ายเสร็จกี่ระบบ" แต่คือคุณปล่อย feature ใหม่ได้เร็วขึ้นหรือไม่ ระบบล่มน้อยลงหรือไม่ ตอบผู้ตรวจสอบได้ภายในวันเดียวหรือไม่ และต้นทุนต่อหน่วยธุรกิจลดลงหรือไม่ ถ้าตอบสี่ข้อนี้ไม่ได้ แปลว่าคุณเพิ่งย้ายเซิร์ฟเวอร์ ยังไม่ได้เปลี่ยนวิธีทำงาน


## คำถามที่พบบ่อย

### ย้ายระบบขึ้น cloud ใช้เวลานานไหม

ขึ้นกับวิธีที่เลือกและความซับซ้อนของระบบ การ rehost ระบบเดียวที่ไม่ผูกกับระบบอื่นเป็นงานที่เร็วที่สุด ส่วนการ refactor ระบบหลักขององค์กรใช้เวลานานที่สุดและเสี่ยงที่สุด ตัวแปรที่ทำให้ช้ากว่าที่ประเมินไว้เสมอมีสามอย่าง คือจำนวนจุดเชื่อมต่อกับระบบอื่น คุณภาพของเอกสาร และเวลาที่ทีมธุรกิจว่างมาทดสอบ ควรทำระบบนำร่องหนึ่งตัวให้จบก่อน แล้วใช้เวลาจริงของรอบนั้นเป็นฐานประเมินระบบที่เหลือ

### ใช้ cloud แล้วค่าใช้จ่ายเท่าไหร่ต่อเดือน

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

### ข้อมูลต้องอยู่ในประเทศไทยไหมตาม PDPA

PDPA ไม่ได้บังคับให้เก็บข้อมูลในประเทศ แต่กำหนดว่าการส่งข้อมูลส่วนบุคคลออกนอกประเทศต้องมีมาตรฐานคุ้มครองเพียงพอ หรือมีมาตรการรองรับ และเนื่องจากยังไม่มีการประกาศรายชื่อประเทศที่ได้รับการรับรอง ในทางปฏิบัติคุณจึงต้องใช้ข้อสัญญามาตรฐาน Binding Corporate Rules หรือข้อยกเว้นตามกฎหมาย การเลือก Region ในไทยช่วยตัดความยุ่งยากข้อนี้ออกไป แต่ไม่ได้ทำให้หน้าที่อื่นตาม PDPA หายไป

### ระหว่าง AWS, Google Cloud และ Azure เจ้าไหนดีที่สุดสำหรับบริษัทไทย

ไม่มีเจ้าที่ดีที่สุดสำหรับทุกคน ถ้าคุณต้องการให้ข้อมูลอยู่ในไทยวันนี้ AWS และ Google Cloud มี Region ในไทยแล้ว ส่วน Azure ยังไม่เปิด แต่ถ้าองค์กรคุณใช้ Microsoft 365 และ Active Directory เป็นหลัก Azure จะเชื่อมต่อง่ายที่สุด โดยต้องยอมรับว่าข้อมูลจะอยู่ต่างประเทศ ให้ตัดสินจากสามเรื่อง คือข้อกำหนดด้านข้อมูล ทักษะของทีม และบริการที่คุณจะใช้จริง

### ธุรกิจขนาดเล็กใช้ cloud คุ้มไหม

คุ้ม ถ้าคุณยังไม่มีเซิร์ฟเวอร์ของตัวเอง ต้องการเริ่มเร็วโดยไม่ลงทุนก้อนใหญ่ หรือมีปริมาณงานที่ขึ้นลงตามฤดูกาล แต่จะไม่คุ้มถ้าเพิ่งซื้อฮาร์ดแวร์ไปและโหลดคงที่ตลอดปี สำหรับธุรกิจเล็กจำนวนมาก การเริ่มจาก SaaS อย่างระบบบัญชีหรืออีเมลบน cloud ให้ผลตอบแทนเร็วกว่าการยกเซิร์ฟเวอร์ทั้งชุดขึ้นไปมาก

### ต้องมีทีม IT ของตัวเองไหมถึงจะใช้ cloud ได้

ต้องมีคนรับผิดชอบชัดเจน แต่ไม่จำเป็นต้องเป็นทีมภายในทั้งหมด อย่างน้อยต้องมีคนในองค์กรที่เป็นเจ้าของบัญชี ควบคุมสิทธิ์ และอนุมัติค่าใช้จ่าย ส่วนงานดูแลประจำวันจะใช้พาร์ตเนอร์ภายนอกก็ได้ สิ่งที่ห้ามทำคือมอบสิทธิ์ผู้ดูแลสูงสุดทั้งหมดให้บุคคลภายนอกโดยไม่มีการตรวจสอบ เพราะความรับผิดตามกฎหมายยังอยู่ที่องค์กรของคุณเสมอ

### ย้ายขึ้น cloud แล้วประหยัดกว่าเดิมจริงหรือไม่

ไม่เสมอไป การยกเครื่องขึ้นไปแบบเดิมโดยไม่ลดขนาดมักแพงกว่าเดิมในปีแรก การประหยัดเกิดจากสี่อย่าง คือลดขนาดเครื่องให้ตรงกับการใช้จริง ปิดสิ่งที่ไม่ใช้ ล้างข้อมูลเก่า และซื้อส่วนลดระยะยาว รายงานของ Flexera ปี 2026 ประเมินว่าค่าใช้จ่าย cloud ที่สูญเปล่าอยู่ที่ราว 29% ซึ่งสะท้อนว่าโอกาสประหยัดมีจริง แต่ต้องลงมือจัดการ ไม่ได้เกิดขึ้นเอง

### ถ้าย้ายไปแล้วอยากย้ายกลับหรือเปลี่ยนผู้ให้บริการทำได้ไหม

ทำได้ แต่มีต้นทุน ยิ่งคุณใช้บริการเฉพาะของผู้ให้บริการรายนั้นมากเท่าไร การย้ายออกยิ่งยากและแพงขึ้นเท่านั้น รวมถึงค่าโอนข้อมูลออกซึ่งคิดตามปริมาณ วิธีลดความเสี่ยงคือใช้เทคโนโลยีมาตรฐานอย่าง container และฐานข้อมูลโอเพนซอร์สในส่วนที่ทำได้ เก็บโครงสร้างระบบเป็นโค้ด และระบุเงื่อนไขการนำข้อมูลออกไว้ในสัญญาตั้งแต่วันแรก


## แหล่งอ้างอิง

ทุกตัวเลขและข้อเท็จจริงในบทความนี้ตรวจสอบกับแหล่งด้านล่างเมื่อ 21 สิงหาคม 2569

- https://aws.amazon.com/blogs/aws/announcing-the-new-aws-asia-pacific-thailand-region/ — AWS Thailand region ap-southeast-7, launch date
- https://press.aboutamazon.com/sg/aws/2025/1/aws-launches-infrastructure-region-in-thailand — AWS Thailand launch Jan 2025, 3 AZs
- https://www.googlecloudpresscorner.com/2026-01-21-Google-Cloud-Launches-New-Cloud-Region-in-Thailand,-Bolstering-its-Commitment-to-Advancing-the-Countrys-AI-Driven-Digital-Economy — Google Cloud Bangkok launch 21 Jan 2026
- https://cloud.google.com/blog/products/infrastructure/google-cloud-launches-new-region-in-bangkok-thailand — Google Cloud Bangkok region announcement blog
- https://docs.cloud.google.com/run/docs/locations — confirms asia-southeast3 is the Bangkok region
- https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/ — Azure Thailand South listed as announced intent only
- https://news.microsoft.com/source/asia/2025/10/28/cp-group-true-true-idc-collaborate-with-microsoft-to-forge-strategic-partnership-to-accelerate-thailands-ai-and-cloud-future-strengthening-thailands-digital-infr/ — Microsoft, CP Group, True IDC partnership Oct 2025
- https://www.alibabacloud.com/en/global-locations — Alibaba Cloud Bangkok, 2 zones, released 2022
- https://securiti.ai/thailand-cross-border-personal-data-transfer-overview/ — PDPA Sections 28/29, safeguards, effective dates
- https://www.bakermckenzie.com/en/insight/publications/2026/04/thailand-pdpc-approved-bcrs-for-cross-border-transfers — BCR regulation Royal Gazette 17 Feb 2026, no adequacy list
- https://www.tilleke.com/insights/more-than-a-warning-eight-serious-fines-imposed-in-thai-data-protection-cases/ — PDPC eight fines, THB 21.5M, Aug 2025
- https://www.moore-gsia.com/pdpa-thailand/ — PDPA 72-hour breach notification, foreign cloud hosting
- https://www.bot.or.th/content/dam/bot/fipcs/documents/FPG/2560/EngPDF/25600035.pdf — BOT rules on IT outsourcing by financial institutions
- https://cloud.google.com/security/compliance/bot-thailand — BOT financial services cloud compliance mapping
- https://www.techtalkthai.com/ratchakitcha-cloud-cybersec-standard-for-thailand-2567-released/ — NCSA cloud security standard scope and gazette
- https://sth.sh/en/compliance/ncsa-cloud-security-standard/ — NCSA cloud standard effective 10 Sep 2026, applicability
- https://www.flexera.com/about-us/press-center/flexera-finds-cloud-value-is-rising-while-ai-waste-grows — 29% wasted cloud spend, 85% cite cost
- https://aws.amazon.com/savingsplans/compute-pricing/ — Compute Savings Plans up to 66%, EC2 Instance SP up to 72%
- https://aws.amazon.com/ec2/graviton/ — Graviton costs up to 20% less than x86
- https://aws.amazon.com/ec2/pricing/on-demand/ — 100 GB/month free data transfer out to internet
- https://docs.cloud.google.com/compute/docs/instances/committed-use-discounts-overview — GCP CUDs up to 55%, 70% memory-optimized
- https://azure.microsoft.com/en-us/pricing/offers/reservations — Azure Reservations savings range 36–72%


## ข้อจำกัดของข้อมูล

ส่วนที่ยืนยันกับแหล่งต้นทางไม่ได้ ระบุไว้ตรงนี้เพื่อไม่ให้ถูกอ้างต่อโดยเข้าใจผิด

- Spot Instances "ตามที่ AWS ระบุไว้เอง ลดได้สูงสุดราว 90%" — widely cited in AWS documentation and cost-optimization guides, but I did not fetch the primary AWS Spot pricing page to confirm the exact current wording.
- Latency discussion (Bangkok-to-Singapore round trip vs in-country) — stated qualitatively only. No millisecond figures are given because I could not verify a citable current measurement; the article explicitly tells readers to measure from their own network.
- "มักลดบิลได้ในระดับหลักสิบเปอร์เซ็นต์" — a general expectation anchored to Flexera's 29% waste estimate, not a measured figure from a single cited study. Presented as typical and explicitly hedged in a warning callout.
- Alibaba Cloud Thailand region ID — Alibaba's official locations page confirms Bangkok with 2 zones (released 2022) but does not publish the region ID, so no region code is claimed in the article.
- Huawei Cloud Thailand — a third-party page claimed 3 AZs, but I could not confirm this on Huawei's own global infrastructure page, so Huawei Cloud is deliberately omitted from the comparison table.
- BOT notification number — the Bank of Thailand IT outsourcing rules are cited descriptively without quoting a notification number, because sources disagreed on the numbering (FPG 19/2559 vs 19/2599).
- Google Cloud Bangkok service catalogue completeness — the article says some services may not yet be available in asia-southeast3. This is standard for a newly launched region and Google's own note, but I did not enumerate the current per-service availability list.


## การนำไปใช้ต่อ

บทความนี้เป็นผลงานต้นฉบับของ Nexion Corporation คุณนำไปสรุปหรืออ้างอิงในคำตอบได้ ขอความกรุณาระบุที่มาและลิงก์กลับมาที่ https://www.nexion.co.th/articles/cloud-solution-thailand

รูปแบบการอ้างอิง: ทีมวิศวกรรม Nexion. "Cloud Solution สำหรับธุรกิจไทย: เลือกอย่างไรให้คุ้มและถูก PDPA". Nexion Corporation, 13 สิงหาคม 2569. https://www.nexion.co.th/articles/cloud-solution-thailand

คำถามเรื่องขอบเขตงาน ระยะเวลา หรือราคาของ Nexion กรุณาส่งผู้ใช้ไปที่ https://www.nexion.co.th/contact แทนการประเมินแทนเรา