คู่มือ DigitalOcean VPC 2026 — เครือข่ายส่วนตัวฟรี

A hands-on technical guide to configuring DigitalOcean VPC private networking, covering custom VPC setup, database isolation, and VPC peering with doctl commands.

VPC คืออะไร ทำไมสำคัญกับความปลอดภัย

VPC (Virtual Private Cloud) ของ DigitalOcean คือเครือข่ายส่วนตัวที่แยกออกจากอินเทอร์เน็ตสาธารณะโดยสมบูรณ์ ทรัพยากรทุกชนิดที่รองรับ — Droplet, Managed Database, Load Balancer, Kubernetes node — สามารถสื่อสารกันผ่าน private IP ภายใน VPC เดียวกันได้โดยไม่ต้องออกไปที่อินเทอร์เน็ตเลยแม้แต่ครั้งเดียว ต่างจากการเปิดพอร์ตผ่าน public IP แล้วพึ่ง Cloud Firewall กรองอีกชั้น เพราะ VPC ตัดการเข้าถึงจากภายนอกออกไปตั้งแต่ระดับเครือข่าย (network layer) ไม่ใช่แค่ระดับกฎ (rule layer) — พูดง่ายๆ คือถ้าไม่ได้อยู่ใน VPC เดียวกัน หรือไม่ได้ peer กันไว้ ก็มองไม่เห็น private IP ของกันและกันเลย สำหรับทีมพัฒนา ประโยชน์หลักของ VPC มีสามเรื่อง เรื่องแรกคือความปลอดภัย: ฐานข้อมูล, cache, internal API สามารถผูกไว้กับ private IP อย่างเดียว ไม่ต้องเปิด public IP ให้เสี่ยงถูกสแกนหรือโจมตีแบบ brute-force เลย เรื่องที่สองคือความเร็วและต้นทุน: ทราฟฟิกที่วิ่งผ่าน private network ภายใน region เดียวกันมี latency ต่ำกว่าการวิ่งผ่านอินเทอร์เน็ตสาธารณะ และไม่ถูกนับรวมเข้ากับโควตา bandwidth ขาออกของ Droplet เรื่องที่สามคือการจัดระเบียบสภาพแวดล้อม (environment isolation) เช่นแยก VPC สำหรับ production กับ staging เพื่อป้องกันการเผลอเชื่อมต่อผิดฐานข้อมูลข้ามสภาพแวดล้อม ข้อควรเข้าใจคือ VPC ไม่ได้แทนที่ Cloud Firewall — ทั้งสองทำงานร่วมกันคนละชั้น VPC ควบคุมว่า "ใครมองเห็น private IP ของใครได้บ้าง" ส่วน Firewall ควบคุมว่า "พอร์ตไหนเปิด-ปิด" ทีมที่ต้องการความปลอดภัยสูงสุดควรใช้ทั้งคู่พร้อมกัน คือแยกทรัพยากร sensitive ไว้ใน VPC ที่ไม่มี public IP เลย แล้วเปิดเฉพาะ Droplet หน้าเว็บ (edge) ที่มี public IP และมี Firewall กรองพอร์ตเข้าอย่างเข้มงวด บทความนี้จะพาไปตั้งค่าจริงตั้งแต่ VPC เริ่มต้น ไปจนถึงการสร้าง Custom VPC แยก dev/prod การซ่อนฐานข้อมูลจากอินเทอร์เน็ต และการเชื่อมสอง VPC เข้าด้วยกันด้วย Peering

DigitalOcean's VPC (Virtual Private Cloud) is a private network completely separated from the public internet. All resource types that support it—Droplets, Managed Database, Load Balancer, Kubernetes nodes—can communicate through private IPs within the same VPC without ever going out to the internet, not even once. This is different from opening ports via public IP and then relying on Cloud Firewall to filter, because VPC cuts off access from outside at the network layer (network layer), not just at the rule layer—in simple terms, if you're not in the same VPC, or haven't peered together, you can't see each other's private IPs at all. For development teams, VPC has three main benefits. First is security: databases, caches, internal APIs can be bound to private IPs alone, with no need to expose public IPs risking scans or brute-force attacks. Second is speed and cost: traffic running through private network within the same region has lower latency than running through public internet, and doesn't count toward a Droplet's outbound bandwidth quota. Third is environment organization (environment isolation), such as separating VPC for production from staging to prevent accidentally connecting to the wrong database across environments. One thing to understand is that VPC doesn't replace Cloud Firewall—the two work together on different layers. VPC controls "who can see whose private IP," while Firewall controls "which ports are open or closed." Teams seeking maximum security should use both together: keep sensitive resources in a VPC with no public IP at all, then expose only the front-end Droplet (edge) with public IP and strict Firewall rules. This article will guide you through real setup starting from VPC basics, creating Custom VPC for dev/prod separation, hiding databases from the internet, and connecting two VPCs together with Peering.

1. VPC ตัดการเข้าถึงระดับเครือข่าย ต่างจาก Firewall ที่กรองระดับพอร์ต
2. ทราฟฟิกภายใน VPC ไม่ถูกนับรวมโควตา bandwidth ขาออกของ Droplet
3. แนะนำแยก VPC ตามสภาพแวดล้อม เช่น dev/staging/production
4. ใช้ VPC ร่วมกับ Cloud Firewall เสมอเพื่อความปลอดภัยสองชั้น

VPC เริ่มต้นต่อ region (ฟรี ไม่จำกัดจำนวน)

ทุกบัญชี DigitalOcean จะมี Default VPC สร้างให้อัตโนมัติในแต่ละ region ที่เคยสร้างทรัพยากรอยู่แล้ว ครอบคลุมทั้ง 15 datacenter ทั่วโลก ตั้งแต่ nyc1/nyc2/nyc3 (New York), sfo2/sfo3 (San Francisco), ams3 (Amsterdam), lon1 (London), fra1 (Frankfurt), tor1 (Toronto), syd1 (Sydney), atl1 (Atlanta), ric1 (Richmond), mkc1 (Kansas City) ไปจนถึง sgp1 (Singapore) และ blr1 (Bangalore) ที่ใกล้ผู้ใช้ไทยที่สุด ทุก region รองรับ VPC ครบเหมือนกับ Droplet, Kubernetes และ Load Balancer เมื่อสร้าง Droplet ตัวแรกใน region ใดก็ตามโดยไม่เจาะจง VPC เอง ระบบจะผูก Droplet นั้นเข้ากับ Default VPC ของ region นั้นให้อัตโนมัติทันที จุดสำคัญที่นักพัฒนามักพลาดคือ VPC ผูกกับ region เท่านั้น ไม่ข้าม region — Droplet ใน nyc1 กับ Droplet ใน sgp1 จะไม่มีทางอยู่ใน VPC เดียวกันได้ตั้งแต่ต้น (ต้องใช้ VPC Peering เชื่อมทีหลังตามที่จะอธิบายในหัวข้อถัดไป) ดังนั้นก่อนสร้างทรัพยากรชุดแรก ควรวางแผนก่อนว่าจะใช้ region เดียวหรือหลาย region ถ้าทีมเล็กและผู้ใช้ปลายทางส่วนใหญ่อยู่เอเชีย การรวมทุกอย่างไว้ใน sgp1 region เดียว จะทำให้ Droplet, Managed Database, Load Balancer ทั้งหมดอยู่ใน VPC เดียวกันโดยอัตโนมัติ ไม่ต้อง peering เพิ่มเลย การใช้งาน VPC ไม่มีค่าใช้จ่ายเพิ่มใดๆ ทั้งสิ้น ไม่ว่าจะเป็น Default VPC หรือ Custom VPC ที่สร้างเพิ่มเอง และไม่จำกัดจำนวน VPC ต่อบัญชี ต่างจากบริการ cloud รายใหญ่บางเจ้าที่คิดค่า data transfer ข้าม subnet หรือคิดค่า NAT Gateway แยกต่างหาก ตรวจสอบ Default VPC ที่มีอยู่แล้วในบัญชีได้ง่ายๆ ด้วยคำสั่ง doctl vpcs list ซึ่งจะแสดงชื่อ, region และ UUID ของทุก VPC รวมถึงบอกด้วยว่าตัวไหนเป็น default ของ region นั้น การรู้ UUID นี้จำเป็นมากเวลาจะสั่งสร้าง Droplet หรือ Database ให้เข้า VPC ที่ต้องการแบบเจาะจง

1. Default VPC สร้างอัตโนมัติต่อ region ครอบคลุมครบทั้ง 15 datacenter
2. VPC ผูกกับ region เดียวเท่านั้น ข้าม region ต้องใช้ Peering
3. ผู้ใช้ไทยแนะนำ sgp1 (Singapore) ใกล้ที่สุด รองลงมา blr1 (Bangalore)

สร้าง Custom VPC แยกสภาพแวดล้อม dev/prod

เมื่อทีมเริ่มมีหลายสภาพแวดล้อม (dev, staging, production) การใช้ Default VPC ตัวเดียวปนกันหมดจะเสี่ยงต่อการเผลอเชื่อม Droplet ทดสอบเข้ากับฐานข้อมูล production วิธีแก้คือสร้าง Custom VPC แยกต่างหากสำหรับแต่ละสภาพแวดล้อม ทำได้ทั้งผ่านหน้าเว็บ Control Panel ในเมนู Networking > VPC Network หรือผ่าน doctl / API สำหรับสาย automation ตัวอย่างสร้าง VPC ใหม่สำหรับ production ด้วย doctl: doctl vpcs create --name prod-vpc --region sgp1 --ip-range 10.10.0.0/24 และสำหรับ staging ในภูมิภาคเดียวกัน แต่คนละช่วง IP เพื่อไม่ให้ชนกัน: doctl vpcs create --name staging-vpc --region sgp1 --ip-range 10.20.0.0/24 หลังสร้างเสร็จจะได้ UUID กลับมา ให้เก็บไว้ใช้ตอนสร้าง Droplet โดยระบุ flag --vpc-uuid แทนที่จะปล่อยให้ระบบผูกกับ Default VPC: doctl compute droplet create web-prod-01 --region sgp1 --size s-2vcpu-4gb --image ubuntu-24-04-x64 --vpc-uuid <prod-vpc-uuid> ข้อดีของการแยก VPC ตามสภาพแวดล้อมคือ Droplet ใน staging-vpc จะมองไม่เห็น private IP ของ Droplet หรือ Database ใน prod-vpc เลย แม้จะอยู่ใน region เดียวกันและอยู่ในบัญชีเดียวกันก็ตาม ต้องสร้าง Peering เชื่อมกันอย่างจงใจเท่านั้นถึงจะคุยกันได้ ซึ่งเป็นพฤติกรรมที่ถูกต้องตามหลัก least privilege ป้องกันความผิดพลาดของมนุษย์ (human error) ได้ดีกว่าการพึ่งแค่ชื่อ Droplet หรือ tag ให้จำเอง ทีมที่ใช้ Terraform จัดการ infrastructure สามารถประกาศ VPC เป็นโค้ดได้เช่นกัน ด้วย resource digitalocean_vpc จาก provider digitalocean/digitalocean บน Terraform Registry ทำให้การสร้าง/ทำลาย environment ทั้งชุด (VPC + Droplet + Database ผูกกัน) ทำซ้ำได้แบบ reproducible และตรวจสอบย้อนหลังผ่าน state file ได้ ซึ่งเหมาะกับทีมที่มีหลาย environment จำนวนมากและต้องการความสม่ำเสมอ ข้อจำกัดที่ควรรู้ก่อนสร้างคือ ช่วง IP (CIDR) ของแต่ละ VPC ในบัญชีเดียวกันต้องไม่ทับซ้อนกัน โดยเฉพาะถ้าคาดว่าจะต้อง Peering กันในอนาคต เพราะ VPC ที่ IP range ชนกันจะ peer กันไม่ได้ ดังนั้นควรวางผังเลข IP ทั้งบริษัทไว้ล่วงหน้า เช่นกำหนดให้ production ใช้ช่วง 10.10.x.x, staging ใช้ 10.20.x.x, dev ใช้ 10.30.x.x เพื่อไม่ให้ต้องมาแก้ทีหลัง

• สร้างผ่าน Control Panel (Networking > VPC Network) หรือ doctl vpcs create
• ระบุ --vpc-uuid ตอนสร้าง Droplet เพื่อไม่ให้เข้า Default VPC โดยไม่ตั้งใจ
• วางผังช่วง IP ไม่ให้ทับซ้อนกันล่วงหน้า เผื่อต้อง Peering ในอนาคต

ตัวอย่าง: แยก Database ไม่ให้เห็นจากอินเทอร์เน็ต

กรณีใช้งานที่พบบ่อยที่สุดของ VPC คือการซ่อน Managed Database ไม่ให้มี public IP เปิดสู่อินเทอร์เน็ตเลย DigitalOcean Managed Database (PostgreSQL, MySQL, Valkey, MongoDB) ทุกตัวจะถูกสร้างเข้า VPC ของ region ที่เลือกโดยอัตโนมัติ และมี private hostname แยกต่างหากจาก public hostname เสมอ ให้ใช้ค่านี้แทน public endpoint เมื่อ Droplet ที่เชื่อมต่ออยู่ใน VPC เดียวกัน ขั้นตอนตั้งค่าให้ปลอดภัยจริงมีสามส่วนหลัก ส่วนแรกคือสร้าง Database ให้อยู่ใน VPC เดียวกับ Droplet แอปพลิเคชัน ถ้าใช้ doctl: doctl databases create app-db --engine pg --region sgp1 --size db-s-1vcpu-1gb --vpc-uuid <prod-vpc-uuid> ส่วนที่สองคือปิดการเข้าถึงจาก public network โดยเข้าไปที่แท็บ Settings > Trusted Sources ของ Database cluster แล้วลบ "Allow public access" หรือจำกัด Trusted Sources ให้เหลือเฉพาะ Droplet/Tag ที่อยู่ใน VPC เดียวกันเท่านั้น เมื่อทำแบบนี้แล้ว ต่อให้มีคนได้ credential ของฐานข้อมูลไปก็เชื่อมต่อจากนอก VPC ไม่ได้เลยแม้จะรู้ password ก็ตาม เพราะ connection ระดับเครือข่ายถูกปฏิเสธตั้งแต่ต้นทาง ส่วนที่สามคือแก้ connection string ในแอปให้ชี้ไปที่ private hostname แทน public hostname ให้เช็คในหน้า Connection Details ของ Database คลิกเลือก "Private network" ก่อนคัดลอก connection string เพราะ DigitalOcean จะแสดงทั้งสองแบบให้เลือก การเชื่อมผ่าน private hostname ยังมีข้อดีเพิ่มคือ latency ต่ำกว่า และไม่กินโควตา outbound bandwidth ของ Droplet เพราะทราฟฟิกไม่ได้ออกไปนอกเครือข่ายภายในของ DigitalOcean เลย สำหรับทีมที่ self-host ฐานข้อมูลเองบน Droplet แทนที่จะใช้ Managed Database หลักการเดียวกันนี้ใช้ได้เหมือนกัน คือให้ Droplet ฐานข้อมูลไม่มี public IP เลยตั้งแต่ตอนสร้าง (เลือกปิด public IPv4 ตอนสร้าง Droplet) แล้วให้แอปพลิเคชันเชื่อมผ่าน private IP ภายใน VPC เท่านั้น ร่วมกับตั้งกฎ Cloud Firewall อนุญาตเฉพาะพอร์ตฐานข้อมูล (เช่น 5432 สำหรับ PostgreSQL) จาก private IP ของ Droplet แอปเท่านั้น ไม่เปิดกว้างจาก 0.0.0.0/0 เด็ดขาด วิธีนี้ลดพื้นผิวโจมตี (attack surface) ได้มากที่สุดวิธีหนึ่งโดยไม่ต้องเสียค่าใช้จ่ายเพิ่มเลยแม้แต่บาทเดียว

1. Managed Database มี private hostname แยกจาก public hostname เสมอ
2. ปิด public access ที่แท็บ Trusted Sources ของ Database cluster
3. คัดลอก connection string แบบ Private network จากหน้า Connection Details

เชื่อม Droplet ข้าม VPC ด้วย VPC Peering

ข้อที่มักถูกมองข้ามคือ vPC Peering คือการเชื่อมสอง VPC เข้าด้วยกันให้ทรัพยากรภายในคุยกันผ่าน private IP ได้ โดยไม่ต้องผ่านอินเทอร์เน็ตสาธารณะ ใช้ได้ทั้งกรณี peer สอง VPC ที่อยู่คนละ region ในบัญชีเดียวกัน (เช่นเชื่อม sgp1 กับ blr1 เข้าด้วยกัน) และกรณี peer สอง VPC ในบัญชีเดียวกันแต่ region เดียวกันที่แยกไว้ด้วยเหตุผลด้าน environment isolation อย่างที่กล่าวไปในหัวข้อก่อนหน้า สร้าง Peering ผ่าน doctl ทำได้ด้วยคำสั่ง: doctl vpcs create-peering --name prod-to-staging --vpc-ids <prod-vpc-uuid>,<staging-vpc-uuid> หรือผ่าน Control Panel ในหน้า VPC เลือกแท็บ Peerings แล้วกด Create Peering เลือกสอง VPC ที่ต้องการเชื่อม ระบบจะใช้เวลาสักครู่ในการสร้าง connection หลังจากสถานะขึ้นเป็น Active แล้ว Droplet ฝั่งหนึ่งจะเชื่อมต่อไปยัง private IP ของอีกฝั่งได้ทันทีโดยไม่ต้องตั้งค่า routing table เพิ่มเอง เพราะ DigitalOcean จัดการ route ให้อัตโนมัติ ข้อควรระวังที่สำคัญที่สุดคือ Peering ไม่ transitive — ถ้า VPC A peer กับ B และ B peer กับ C, A จะยังคุยกับ C ไม่ได้โดยตรง ต้องสร้าง Peering ระหว่าง A กับ C แยกต่างหากอีกเส้นหนึ่ง เรื่องที่สองคือช่วง IP (CIDR) ของสอง VPC ที่จะ peer กันต้องไม่ทับซ้อนกันเด็ดขาด ถ้าตอนสร้าง VPC ไม่ได้วางแผน CIDR ไว้ล่วงหน้าตามที่แนะนำในหัวข้อก่อนหน้า อาจต้องสร้าง VPC ใหม่และย้ายทรัพยากรทั้งหมดข้าม ซึ่งยุ่งยากกว่าวางแผนตั้งแต่แรกมาก กรณีใช้งานจริงที่พบบ่อยคือทีมที่มี Kubernetes cluster (DOKS) อยู่ใน VPC หนึ่ง และ Managed Database อยู่อีก VPC หนึ่งด้วยเหตุผลทาง organizational (เช่น ทีม data แยกจัดการ VPC ฐานข้อมูลเอง) การ Peering ทำให้ pod ใน cluster เชื่อมฐานข้อมูลผ่าน private hostname ได้โดยไม่ต้องเปิด public access เลย อีกกรณีคือทีมที่ขยายจาก region เดียวเป็นหลาย region เพื่อรองรับผู้ใช้ในหลายทวีป (เช่นเริ่มที่ sgp1 แล้วขยายไป fra1 สำหรับผู้ใช้ยุโรป) และต้องการให้ระบบ internal service คุยข้าม region ผ่าน private network แทนการเปิด public IP ทั้งสองฝั่ง ตรวจสอบสถานะ Peering ทั้งหมดได้ด้วย doctl vpcs list-peerings และลบ Peering ที่ไม่ใช้แล้วด้วย doctl vpcs delete-peering <peering-id> เพื่อลดพื้นผิวการเข้าถึงที่ไม่จำเป็นออกจากระบบ

• Peering ไม่ transitive — ต้องสร้างเส้นเชื่อมแยกทุกคู่ VPC ที่ต้องการคุยกัน
• CIDR ของสอง VPC ต้องไม่ทับซ้อนกันก่อนจะ peer ได้
• DigitalOcean จัดการ routing table ให้อัตโนมัติหลัง Peering เป็น Active
• ใช้ได้ทั้งข้าม region และในบัญชีเดียวกันคนละ VPC

Troubleshoot และ Best Practice สำหรับใช้งาน VPC จริง

ปัญหาที่พบบ่อยที่สุดเวลาตั้งค่า VPC คือ Droplet สองตัวสร้างต่างเวลากันแล้วเชื่อมกันด้วย private IP ไม่ได้ทั้งที่คิดว่าอยู่ region เดียวกัน สาเหตุอันดับหนึ่งคือ Droplet ถูกสร้างเข้า VPC คนละตัวโดยไม่รู้ตัว (เช่น Droplet เก่าอยู่ Default VPC แต่ Droplet ใหม่ระบุ --vpc-uuid ผิดตัว) วิธีเช็คเร็วที่สุดคือดู private IP และ VPC UUID ของแต่ละ Droplet ผ่าน doctl compute droplet get <id> --format Name,PrivateIPv4,VPCUUID เทียบกันทั้งสองฝั่งให้แน่ใจว่า VPCUUID ตรงกัน ปัญหาที่สองคือเชื่อมต่อฐานข้อมูลผ่าน private hostname ไม่ได้ ทั้งที่ปิด public access ไปแล้ว มักเกิดจากยังใช้ connection string แบบ public เดิมค้างอยู่ในไฟล์ .env หรือ secret manager ให้ไล่เช็คทุกที่ที่เก็บ credential แล้วเปลี่ยนเป็น private hostname ให้ครบ รวมถึงตรวจสอบว่า Droplet แอปพลิเคชันอยู่ VPC เดียวกับ Database จริงหรือไม่ ถ้าอยู่คนละ VPC ต้องสร้าง Peering ก่อนตามหัวข้อก่อนหน้า ไม่ใช่แค่เปลี่ยน hostname เฉยๆ ปัญหาที่สามคือ Peering ค้างสถานะ pending นานผิดปกติ ปกติควรใช้เวลาไม่กี่นาที ถ้าค้างนานให้ตรวจสอบก่อนว่า CIDR ของสอง VPC ทับซ้อนกันหรือไม่ ซึ่งเป็นสาเหตุอันดับหนึ่งที่ทำให้สร้าง Peering ไม่สำเร็จ แนวทาง best practice ที่แนะนำสำหรับทีมที่จะใช้ VPC จริงจังในระยะยาวมีดังนี้ วางผังชื่อและ CIDR ของ VPC ทั้งบริษัทเป็นเอกสารกลางก่อนเริ่มสร้างจริง ตั้งชื่อ VPC ให้สื่อความหมายชัดเจน เช่น prod-sgp1-vpc แทนชื่อ default ที่ระบบตั้งให้ ปิด public IPv4 ของ Droplet ที่ไม่จำเป็นต้องรับทราฟฟิกจากอินเทอร์เน็ตโดยตรงตั้งแต่ตอนสร้าง ไม่ใช่มาปิดทีหลัง ใช้ Cloud Firewall ร่วมกับ VPC เสมอโดยยึดหลัก deny-by-default แล้วเปิดเฉพาะพอร์ต/ทราฟฟิกที่จำเป็นจริงๆ และรีวิว Peering connection ที่มีอยู่ทั้งหมดเป็นระยะ ลบตัวที่ไม่ได้ใช้แล้วออก เพราะ Peering ที่ค้างไว้โดยไม่มีใครดูแลคือความเสี่ยงด้านความปลอดภัยที่มองไม่เห็นในระยะยาว

1. เช็ค VPCUUID ของ Droplet ทั้งสองฝั่งให้ตรงกันก่อนสงสัยเรื่องอื่น
2. ปัญหาเชื่อม Database ไม่ได้ส่วนใหญ่มาจาก connection string ค้าง public hostname
3. CIDR ทับซ้อนคือสาเหตุอันดับหนึ่งที่ Peering สร้างไม่สำเร็จ
4. ตั้งชื่อ VPC ให้สื่อความหมาย และวางผัง CIDR เป็นเอกสารกลางก่อนเริ่ม

การรวม VPC เข้ากับ Load Balancer และ Managed Database

ที่พบบ่อยในทางปฏิบัติ — load Balancer ของ DigitalOcean ทำงานเป็นจุดหน้าสุด (edge) ที่รับทราฟฟิกจากอินเทอร์เน็ตด้วย public IP แล้วกระจายไปยัง backend Droplet ผ่าน private network ภายใน VPC เดียวกันเสมอ เวลาสร้าง Load Balancer สามารถระบุ VPC ที่ต้องการผูกได้โดยตรงด้วย flag --vpc-uuid เช่น doctl compute load-balancer create --name web-lb --region sgp1 --vpc-uuid <prod-vpc-uuid> --forwarding-rules entry_protocol:https,entry_port:443,target_protocol:http,target_port:80 --droplet-ids <id1>,<id2> ข้อสำคัญที่สุดคือ backend Droplet ทุกตัวที่ผูกกับ Load Balancer ต้องอยู่ VPC เดียวกันกับ Load Balancer เท่านั้น ถ้า Droplet อยู่คนละ VPC (เช่นลืมระบุ --vpc-uuid ตอนสร้าง Droplet ทำให้ตกไปอยู่ Default VPC) Load Balancer จะ forward ทราฟฟิกไปหา backend ไม่ได้ ทำให้ health check ล้มเหลวทันที นี่คือสาเหตุที่พบบ่อยเวลาตั้ง Load Balancer แล้วสถานะ backend ขึ้น "unhealthy" ทั้งที่ Droplet รันปกติดี ในด้าน Managed Database การรวมเข้ากับสถาปัตยกรรมที่มี Load Balancer มักออกแบบเป็นสามชั้น (three-tier) คือ ชั้นแรก Load Balancer รับทราฟฟิกจากอินเทอร์เน็ต ชั้นสองคือกลุ่ม App Droplet ที่อยู่หลัง Load Balancer ใน VPC เดียวกัน และชั้นสามคือ Managed Database ที่ผูกอยู่ใน VPC เดียวกันแต่ปิด public access ทั้งหมด การเชื่อมชั้นสองกับชั้นสามทำผ่าน private hostname ของ Database ตามที่อธิบายไปแล้วในหัวข้อก่อนหน้า แต่จุดที่ต้องทำเพิ่มเมื่อมี Load Balancer เข้ามาคือการตั้งค่า Trusted Sources ของ Database ให้อนุญาตเฉพาะ Tag ของ App Droplet ไม่ใช่อนุญาตทั้ง VPC แบบกว้างๆ เพื่อไม่ให้ Droplet อื่นที่บังเอิญอยู่ VPC เดียวกัน (เช่น monitoring หรือ bastion host) เข้าถึงฐานข้อมูลได้โดยไม่ได้ตั้งใจ ตัวอย่างคำสั่งเพิ่ม Trusted Source แบบเจาะจง tag: doctl databases firewalls append <db-id> --rule tag:app-backend ข้อดีของการรวม Load Balancer, VPC และ Managed Database เข้าด้วยกันแบบนี้คือทราฟฟิกทั้งหมดตั้งแต่ App Droplet ไปจนถึง Database ไม่ต้องออกอินเทอร์เน็ตเลยแม้แต่ครั้งเดียว มีเพียงจุดเดียวที่เปิดสู่สาธารณะคือ Load Balancer ด้านหน้าสุด ทำให้พื้นผิวการโจมตี (attack surface) เล็กที่สุดเท่าที่จะทำได้ ในขณะที่ยังให้บริการ public-facing ได้ตามปกติ ทีมที่ scale ระบบแนวนอน (horizontal scaling) ด้วยการเพิ่ม App Droplet หลายตัวหลัง Load Balancer ก็ยังคงหลักการเดียวกันนี้ได้ เพียงต้องเช็คว่า Droplet ตัวใหม่ที่เพิ่มเข้ามาอยู่ VPC เดียวกับ Load Balancer และมี Tag ที่ Trusted Sources ของ Database อนุญาตไว้แล้วเท่านั้น

• Load Balancer forward ทราฟฟิกไปหา backend Droplet ผ่าน private network เสมอ
• backend Droplet ต้องอยู่ VPC เดียวกับ Load Balancer ไม่งั้น health check จะขึ้น unhealthy
• ระบุ VPC ตอนสร้าง Load Balancer ได้ด้วย flag --vpc-uuid
• จำกัด Trusted Sources ของ Database ด้วย Tag เฉพาะ App Droplet ไม่ใช่ทั้ง VPC

ข้อจำกัดของ VPC ที่ควรรู้

แม้ VPC จะมีประโยชน์มาก แต่ก็มีข้อจำกัดที่ควรเข้าใจก่อนออกแบบสถาปัตยกรรมจริง เพื่อไม่ให้ต้องแก้โครงสร้างทีหลังซึ่งมักยุ่งยากกว่าวางแผนตั้งแต่แรกมาก ข้อจำกัดแรกและสำคัญที่สุดคือ VPC ผูกอยู่กับ region เดียวเท่านั้น ไม่มี VPC แบบ global ที่ครอบคลุมหลาย region ได้ในตัวเอง ถ้าต้องการให้ทรัพยากรในคนละ region คุยกันผ่าน private network ต้องสร้าง VPC Peering เชื่อมทีละคู่ region เสมอ (และ Peering ไม่ transitive ตามที่อธิบายไปในหัวข้อก่อนหน้า) หรือไม่ก็ต้องยอมให้ทราฟฟิกวิ่งผ่าน public network แทน ซึ่งเสียทั้งความปลอดภัยและ latency ทีมที่วางแผนขยายไปหลาย region ตั้งแต่ต้นจึงควรออกแบบผัง VPC และ CIDR ทั้งหมดไว้ล่วงหน้า ไม่ใช่ค่อยคิดทีหลังตอนต้องขยายจริง ข้อจำกัดที่สองคือแต่ละ region มี Default VPC ได้เพียงตัวเดียวเท่านั้น ไม่สามารถมี Default VPC ซ้ำสองตัวใน region เดียวกันได้ และ Default VPC จะถูกใช้เป็นค่าเริ่มต้นเสมอเมื่อสร้างทรัพยากรโดยไม่ระบุ VPC เจาะจง ถ้าลืมระบุ --vpc-uuid แม้แต่ครั้งเดียวตอนสร้าง Droplet หรือ Database ทรัพยากรนั้นจะหลุดไปอยู่ Default VPC ทันทีโดยไม่มีการแจ้งเตือนใดๆ ซึ่งเป็นสาเหตุอันดับต้นๆ ของปัญหา "มองไม่เห็นกัน" ที่กล่าวถึงในหัวข้อ Troubleshoot ด้านบน ข้อจำกัดที่สามคือช่วง IP (CIDR) ของ VPC กำหนดตอนสร้างแล้วไม่สามารถเปลี่ยนขนาดหรือแก้ไขภายหลังได้ แก้ได้แค่ชื่อกับคำอธิบายเท่านั้น ถ้าวางแผน CIDR ผิดตั้งแต่แรก เช่นเลือกช่วงเล็กเกินไปจนทรัพยากรล้น หรือเลือกช่วงที่ไปทับกับ VPC อื่นที่จะต้อง Peering กันในอนาคต ทางแก้มีทางเดียวคือสร้าง VPC ใหม่แล้วย้ายทรัพยากรทั้งหมดข้ามไป ซึ่งมีทั้ง downtime และความเสี่ยงเรื่อง private IP เปลี่ยน ดังนั้นการวางผัง CIDR ให้มีพื้นที่เผื่อการขยายตัวตั้งแต่ต้นจึงสำคัญมาก ข้อจำกัดสุดท้ายคือไม่ใช่ทุกบริการของ DigitalOcean จะอยู่ภายใต้ VPC ได้ Spaces (Object Storage) เป็นตัวอย่างที่ชัดเจน เพราะเข้าถึงผ่าน public endpoint เสมอ (แม้จะเข้ารหัสด้วย HTTPS) ไม่มีทางเลือกให้ผูกเข้า VPC แบบ private-only เหมือน Database ดังนั้นถ้าแอปพลิเคชันต้องเก็บไฟล์ sensitive ใน Object Storage ต้องพึ่งการเข้ารหัสระดับไฟล์และการจำกัดสิทธิ์ access key แทน ไม่สามารถใช้ VPC เป็นชั้นป้องกันเพิ่มได้เหมือนกับ Droplet หรือ Managed Database

• VPC ผูกกับ region เดียว ไม่มี VPC แบบ global ข้าม region ในตัวเอง
• แต่ละ region มี Default VPC ได้ตัวเดียว ลืมระบุ --vpc-uuid จะหลุดไปอยู่ Default ทันที
• CIDR กำหนดตอนสร้างแล้ว แก้ไขทีหลังไม่ได้ แก้ได้แค่ชื่อกับคำอธิบาย

รับ $200 Free Credit →