ข้อมูลองค์กรอยู่ที่ไหนจริง: เลือก Region บน Cloud กับข้อผูกพันเรื่องที่ตั้งข้อมูล

ตอนเริ่มโปรเจกต์ใหม่บน Google Cloud หรือ Microsoft Azure ทีมพัฒนาต้องเลือก region ตั้งแต่ขั้นตอนแรก และการตัดสินใจนี้มักจบในเวลาไม่กี่นาที เพราะตอนนั้นยังไม่มีข้อมูลจริงในระบบ ไม่มี use case ที่ต้องอธิบายต่อบอร์ด และไม่มีใครถามว่าข้อมูลจะอยู่ที่ไหน สามปีให้หลัง ระบบเดียวกันมีข้อมูลลูกค้าเป็นล้านแถว ฝ่ายกฎหมายเริ่มถามว่าข้อมูลถูกเก็บไว้ประเทศไหน และคำตอบว่า "ย้าย region ทีหลังได้" ไม่จริงเท่าที่คิดไว้ตอนแรก

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

Region, Zone และ Edge Cache — สามชั้นที่มักถูกปนกัน

เวลาพูดว่า "ข้อมูลอยู่ที่ region ไหน" คำตอบจริง ๆ มีสามชั้นซ้อนกันอยู่ ชั้นแรกคือ region หลัก (primary region) ที่เก็บ compute instance และฐานข้อมูลหลักของระบบ Google Cloud ประกาศว่ามีเครือข่ายครอบคลุม 43 regions และ 130 zones ทั่วโลก (ที่มา: Google Cloud, cloud.google.com/about/locations, ตรวจสอบ 29 กันยายน 2026) Azure ใช้หลักการคล้ายกัน คือให้ลูกค้าระบุ geography ที่ต้องการตั้งแต่ตอนสร้างบริการ และ Microsoft ยืนยันว่าจะไม่ย้ายข้อมูลออกนอก geo ที่เลือกโดยไม่ได้รับอนุญาต (ที่มา: Microsoft Azure, azure.microsoft.com/en-us/explore/global-infrastructure/data-residency, ตรวจสอบ 29 กันยายน 2026)

ชั้นที่สองคือ backup หรือ DR region ซึ่งเป็นคนละการตัดสินใจกับ region หลัก แม้จะเกี่ยวข้องกัน — Azure เองระบุว่าอาจคัดลอกข้อมูลไปยัง region อื่นภายใน geo เดียวกันเพื่อความทนทานของระบบ องค์กรที่วางแผน failover จึงต้องรู้ตำแหน่งของทั้ง region หลักและ region สำรอง ไม่ใช่แค่ region เดียว เรื่องนี้เกี่ยวโยงกับการตัดสินใจตอนระบบล่มที่เราเคยเขียนถึงไว้แยกต่างหาก แต่ประเด็นในบทความนี้คือตำแหน่งที่ตั้งของข้อมูล ไม่ใช่ขั้นตอนตอนเกิดเหตุ

ชั้นที่สามคือ edge cache ของ CDN อย่าง Cloudflare ซึ่งมักถูกเข้าใจผิดว่าเป็นที่เก็บข้อมูลถาวร ความจริงคือ Regional Services ของ Cloudflare ควบคุมว่า data center ไหนเป็นคนถอดรหัสและประมวลผล HTTPS traffic ระหว่างทาง ไม่ใช่ควบคุมว่าข้อมูลปลายทางเก็บอยู่ที่ไหน (ที่มา: Cloudflare, developers.cloudflare.com/data-localization/regional-services, ตรวจสอบ 29 กันยายน 2026) พูดอีกแบบคือ ต่อให้ตั้งค่า edge ให้วิ่งผ่าน data center ในภูมิภาคใกล้ไทย ข้อมูลส่วนบุคคลที่เก็บถาวรยังอยู่ที่ region หลักตามเดิม

ตัวอย่างที่เห็นได้ชัดคือระบบที่มีหน้าเว็บให้ลูกค้ากรอกแบบฟอร์มติดต่อ ข้อมูลที่กรอกจะถูกส่งไปเก็บที่ region หลักของฐานข้อมูล ส่วน CDN ทำหน้าที่แค่ส่งไฟล์หน้าเว็บอย่าง HTML, CSS และรูปภาพ ให้โหลดเร็วขึ้นจาก data center ที่ใกล้ผู้ใช้ที่สุด ถ้าทีมเข้าใจว่าการมี CDN ในภูมิภาคเอเชียแปลว่าข้อมูลลูกค้าก็อยู่ในภูมิภาคเดียวกันด้วย ก็จะตอบคำถามเรื่อง residency ผิดตั้งแต่ต้น

PDPA กับการส่งข้อมูลออกนอกประเทศ: สิ่งที่ต้องตรวจสอบ ไม่ใช่ข้อสรุปสำเร็จรูป

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) มีหลักเกณฑ์เรื่องการส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศ โดยคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) เป็นผู้ออกประกาศกำหนดรายละเอียด รวมถึงเกณฑ์เรื่องประเทศปลายทางที่มีมาตรฐานคุ้มครองข้อมูลเพียงพอ และมาตรการคุ้มครองที่เหมาะสมสำหรับกรณีที่ยังไม่มีคำวินิจฉัยว่าประเทศปลายทางมีมาตรฐานเพียงพอ (ที่มา: สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล, pdpc.or.th/en/10547, ตรวจสอบ 29 กันยายน 2026)

ในทางปฏิบัติ ข้อมูลที่ไหลออกนอกประเทศไม่ได้มีแค่ฐานข้อมูลหลักของระบบ แต่รวมถึงบริการเสริมที่ทีมพัฒนามักตั้งค่าแยกต่างหาก เช่น ระบบส่งอีเมลยืนยัน บริการวิเคราะห์พฤติกรรมผู้ใช้ หรือระบบ support ticket ที่ใช้ vendor ต่างประเทศ บริการเหล่านี้อาจตั้งอยู่คนละ region จากฐานข้อมูลหลัก และมักถูกมองข้ามเมื่อไล่ตรวจสอบว่าองค์กรมีข้อมูลอะไรไหลไปที่ไหนบ้าง

สิ่งที่บทความนี้ทำได้คือบอกว่าเรื่องนี้มีอยู่จริงและเกี่ยวกับการเลือก region โดยตรง เพราะถ้า region หลักหรือ region สำรองตั้งอยู่นอกประเทศไทย ข้อมูลส่วนบุคคลที่ไหลเข้าไปเก็บหรือประมวลผลที่นั่นอาจเข้าข่ายการส่งข้อมูลออกนอกประเทศตามกฎหมาย สิ่งที่บทความนี้ทำไม่ได้คือฟันธงว่าระบบขององค์กรใดองค์กรหนึ่งเข้าข่ายหรือไม่ เพราะขึ้นอยู่กับประเภทข้อมูล วัตถุประสงค์การประมวลผล และรายละเอียดที่เปลี่ยนได้ตามประกาศของ PDPC เอง คำถามเชิงกฎหมายที่เจาะจงแบบนี้ควรถามฝ่ายกฎหมายหรือเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ขององค์กร หรือติดต่อ PDPC โดยตรง ไม่ใช่สรุปเองจากบทความฝั่งผู้พัฒนาระบบ

Google Cloud และ Azure ให้เลือกที่ตั้งข้อมูลได้แค่ไหน

ณ วันที่เขียนบทความนี้ สองแพลตฟอร์มอยู่คนละสถานะ Google Cloud เปิด region กรุงเทพฯ (asia-southeast3) ให้บริการแล้ว และระบุว่า region นี้รองรับการเก็บข้อมูลที่ระบุไว้ภายในประเทศไทย (ที่มา: Google Cloud Blog, ประกาศเปิด region กรุงเทพฯ, ตรวจสอบ 29 กันยายน 2026) ส่วน Azure ยังไม่มี region ที่เปิดให้บริการในประเทศไทย การเก็บข้อมูลไว้ในประเทศได้หรือไม่จึงขึ้นกับ provider และบริการที่เลือกใช้ ไม่ใช่ข้อจำกัดเดียวกันทุกเจ้า และเพราะรายชื่อ region เปลี่ยนได้ ควรตรวจจาก region picker หรือหน้า locations ของแต่ละ provider ในวันที่ตัดสินใจจริง

สิ่งที่เลือกได้จริงคือระดับการล็อกตำแหน่งข้อมูล Google Cloud มี organization policy constraint ให้กำหนดได้ว่าทรัพยากรต้องสร้างในภูมิภาคที่กำหนดเท่านั้น และมีผลิตภัณฑ์เสริมอย่าง Assured Workloads ที่ออกแบบมาเพื่อบังคับข้อกำหนดด้าน compliance และ data residency ในระดับที่เข้มงวดกว่าค่าเริ่มต้น ส่วน Azure ระบุว่าบริการส่วนใหญ่ให้ลูกค้าเลือก region ที่ข้อมูลจะถูกเก็บและประมวลผล และจะไม่ย้ายออกนอก geo ที่เลือกโดยไม่ได้รับอนุญาต การตั้งค่าระดับนี้ต้องทำตอนออกแบบระบบ เพราะกำหนดวิธีออกแบบ IAM และ policy ทั้งระบบ และเปิดใช้ทีหลังได้ยากเมื่อมีทรัพยากรที่สร้างไปแล้วในภูมิภาคอื่น

ต้นทุนของการแก้ไขทีหลัง เมื่อระบบใช้งานจริงแล้ว

การย้าย region ของระบบที่ยังไม่มีข้อมูลจริงคือการเปลี่ยนค่า config แต่การย้าย region ของระบบที่ใช้งานจริงแล้วคือโปรเจกต์แยกที่มีต้นทุนซ่อนอยู่หลายชั้น ต้นทุนแรกคือเครื่องมือและเวลาที่ใช้ย้ายข้อมูลจริงโดยไม่ให้สูญหายระหว่างทาง ตามมาด้วยค่าใช้จ่ายจากการรันระบบคู่ขนานทั้ง region เดิมและ region ใหม่ชั่วคราวระหว่างช่วงเปลี่ยนผ่าน ซึ่งหมายถึงค่าโครงสร้างพื้นฐานสองชุดซ้อนกันในช่วงนั้น นอกจากนี้ยังต้องทบทวนสัญญาและข้อตกลงประมวลผลข้อมูล (data processing agreement) กับ vendor ทุกรายที่เชื่อมต่อกับระบบใหม่ และปิดท้ายด้วยเวลาที่ทีมต้องใช้ทดสอบว่าทุกฟีเจอร์ยังทำงานถูกต้องหลังย้าย เพราะทุก integration ที่อ้างอิง endpoint เดิมต้องถูกตรวจสอบใหม่ทั้งหมด

นี่คือเหตุผลที่การเลือก region ควรถูกพูดถึงในห้องประชุมเดียวกับที่พูดถึงงบประมาณและ timeline ของโปรเจกต์ ไม่ใช่ปล่อยให้เป็นค่า default ที่ทีมพัฒนากดผ่านไปเพราะไม่มีใครถาม

ข้อจำกัดที่ต้องพูดตรง ๆ: ไม่ใช่ทุกระบบต้องกังวลเรื่องนี้ตั้งแต่วันแรก

ระบบภายในองค์กรขนาดเล็กที่ไม่มีข้อมูลส่วนบุคคลของคนนอก ไม่เชื่อมกับระบบต่างประเทศ และไม่มีแผนขยายไปตลาดอื่นในอนาคตอันใกล้ ไม่จำเป็นต้องยกเรื่อง region กับ PDPA ขึ้นมาเป็นเรื่องที่ต้องรีบตัดสินใจตั้งแต่วันแรก เพราะต้นทุนของการวาง constraint ที่เข้มงวดเกินจำเป็นก็มีจริงเช่นกัน ทั้งเวลาที่เสียไปกับการตั้งค่า organization policy และตัวเลือก region ที่แคบลงจนอาจกระทบ latency หรือราคา สิ่งที่ควรทำในกรณีนี้คือบันทึกไว้เป็นสมมติฐานตั้งต้นว่าระบบนี้ไม่มีข้อมูลข้ามประเทศ แล้วทบทวนสมมติฐานนั้นใหม่ทุกครั้งที่ขอบเขตของระบบเปลี่ยน

ข้อโต้แย้งที่ได้ยินบ่อย

ข้อโต้แย้งที่พบบ่อยที่สุดคือ "cloud provider ที่ใช้อยู่มี compliance certificate ครบอยู่แล้ว ไม่ต้องมาคิดเรื่อง region เพิ่ม" คำตอบคือ certificate ของ provider เช่น ISO 27001 หรือ SOC 2 ยืนยันว่าโครงสร้างพื้นฐานของเขาถูกดูแลตามมาตรฐาน แต่ไม่ได้ตัดสินแทนองค์กรว่าการส่งข้อมูลไปยัง region ที่เลือกเข้าข่ายต้องปฏิบัติตามเงื่อนไขการส่งข้อมูลข้ามประเทศของ PDPA หรือไม่

อีกข้อโต้แย้งที่พบคือ "รอให้ provider ที่ใช้อยู่มี region ในไทยก่อนค่อยตัดสินใจ" ณ วันที่เขียนบทความนี้ Google Cloud มี region กรุงเทพฯ แล้ว ส่วน Azure ยังไม่มี region ที่เปิดให้บริการในไทย และบทความนี้ไม่มีข้อมูลยืนยันว่าจะเปิดเมื่อไร ทางเลือกที่ทำได้จริงสำหรับองค์กรที่ต้องเริ่มระบบตอนนี้คือออกแบบให้ชั้นข้อมูลแยกออกจากชั้นประมวลผลให้ชัดเจนตั้งแต่ต้น เพื่อให้การย้าย region ในอนาคต ถ้าจำเป็น ทำได้ง่ายกว่าระบบที่ผูกทุกอย่างไว้ด้วยกัน

จะเริ่มตรงไหน

เริ่มจากไล่ดูว่าระบบปัจจุบันมีข้อมูลอะไรไหลออกนอกประเทศไทยบ้าง ทั้ง region หลัก region สำรอง และบริการเสริมอย่าง log หรือ analytics ที่บางครั้งถูกตั้งค่าไว้คนละภูมิภาคโดยไม่มีใครสังเกต ถามทุกบริการที่ระบบใช้อยู่ว่าข้อมูลอะไรถูกส่งไปบริการนั้น และประมวลผลอยู่ที่ประเทศไหน คำตอบมักอยู่ในหน้า documentation ของแต่ละบริการเอง

ตามด้วยการคัดแยกว่าข้อมูลไหนเป็นข้อมูลส่วนบุคคลตามความหมายของ PDPA และข้อมูลไหนไม่ใช่ จากนั้นนำรายการนี้ไปถามฝ่ายกฎหมายหรือ DPO ขององค์กรว่าเข้าข่ายต้องปฏิบัติตามเงื่อนไขการส่งข้อมูลข้ามประเทศหรือไม่ และปิดท้ายด้วยการบันทึกการตัดสินใจเรื่อง region ไว้เป็นเอกสารสถาปัตยกรรม พร้อมเหตุผล เพื่อให้ทีมที่มาทีหลังไม่ต้องเดาว่าทำไมระบบถึงตั้งอยู่ที่นี่ การตัดสินใจแบบนี้เป็นส่วนหนึ่งของงานสถาปัตยกรรมระบบที่ทีมเราทำงานร่วมกับองค์กร

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส