Private gateway
เริ่มจาก Private network เชื่อม Virtual Router เพื่อออก Internet ด้วย SNAT และใช้ Floating IP เฉพาะ VM ที่ต้องรับจากภายนอก
เหมาะกับระบบเริ่มต้นและบริการภายใน ดู Topology ใน ExplorerRUK-COM / VIRTUAL PRIVATE CLOUD
จัดการ Private Network บน Cloud ให้ตรงกับระบบของคุณ ทั้ง Subnet, Routing และ Access Policy เพื่อให้ Web, App และ Database เชื่อมต่อกันตามสิทธิ์ที่กำหนด พร้อมทีม Ruk-Com ช่วยออกแบบ
NETWORK EXPLORER / SIMULATION
เลือกมุมมอง Gateway, แยก 3 Subnet หรือ Policy ใน Subnet เดียว แล้วทดลอง Flow เพื่อดูหน้าที่ของ Router และ Security Group
Web → Router → SG App :8443 → App
App → Router → SG DB :5432 → Database
ภาพเริ่มต้น: 3 Private subnet · ไม่มี Public endpoint ที่ DB
START WITH YOUR WORKLOAD
เริ่มจาก Private network เชื่อม Virtual Router เพื่อออก Internet ด้วย SNAT และใช้ Floating IP เฉพาะ VM ที่ต้องรับจากภายนอก
เหมาะกับระบบเริ่มต้นและบริการภายใน ดู Topology ใน Explorerแยก Web, App และ Database คนละ Subnet ให้ Router จัดการ Routing ข้าม Network และใช้ Security Group กำหนด Source กับ Port ที่อนุญาต
เหมาะกับระบบหลายชั้นและทีมที่แบ่งหน้าที่ ดู Topology ใน Explorerวาง VM ใน Network เดียวกัน แล้วแยก Access Policy ตามบทบาท Traffic ภายใน Subnet เชื่อมถึงกันโดยตรง และยังผ่านการตรวจ Security Group ที่ VM Port
เหมาะกับระบบที่ต้องการผังเครือข่ายเรียบง่าย ดู Topology ใน ExplorerBUILD THE NETWORK YOU NEED
จัดสรร CIDR, Allocation pool, Gateway, DHCP และ DNS ให้ตรงกับโครงสร้างระบบ และตรวจช่วง IP ไม่ให้ทับซ้อน
กำหนด L3 Routing ระหว่าง Network แบบ IP-managed และให้ VM เชื่อมต่อออก Internet ผ่าน SNAT
ผูก Public IP กับ Private IP ของ VM ที่ต้องรับจากภายนอก โดยเลือก Endpoint ที่จะเปิดอย่างชัดเจน
กำหนด Allow Rule ที่ VM Port ตาม Source, Protocol และ Port พร้อมตรวจทุก Security Group ที่ผูกอยู่กับ VM Port นั้น
ออกแบบ Network ไปพร้อมกับ VM, Compute และ Storage เพื่อรองรับรูปแบบงานเดียวกัน
ให้ทีม Ruk-Com ช่วยทบทวน Topology และ Access matrix กำหนดการดูแลตามสิทธิ์และขอบเขตบริการที่ตกลง
SECURITY AT THE VM PORT
Router จัดการเส้นทางระหว่าง Network ส่วน Security Group กำหนด Connection ที่อนุญาต ตัวอย่างนี้ใช้ Custom SG แบบ Stateful แยกตามบทบาทของ VM
| Source | Destination | Protocol / Port | ผลลัพธ์ |
|---|---|---|---|
| Internet | Web |
TCP 443
|
อนุญาต HTTPS |
| Web SG | App |
TCP 8443
|
อนุญาต Web → App |
| App SG | Database |
TCP 5432
|
อนุญาต App → DB |
| App | Internet |
TCP 443
|
อนุญาต Egress ผ่าน SNAT |
| Web SG | Database |
TCP 5432
|
ไม่ผ่าน: ไม่มี Allow rule ตรงกัน |
ต้องทบทวนทุก SG ที่แนบอยู่ Default SG ในเอกสารแพลตฟอร์มอนุญาตทุก Traffic ตัวอย่างจำกัดสิทธิ์นี้จึงต้องถอด Group ที่ Allow-all และใช้ Custom SG แทน เพราะ Allow rule จากหลาย Group มีผลรวมกัน
Response ผูกกับ Connection เดิม ตัวอย่าง Stateful อนุญาต Traffic ตอบกลับของ Connection ที่ผ่านกฎแล้ว ตรวจค่า Stateful จริงก่อนใช้งาน และกำหนด Egress ที่จำเป็น เช่น DNS ตามระบบ
VPC + CLOUD IAAS
เพิ่ม VM ได้อย่างมีแผน เมื่อรู้ว่าแต่ละระบบอยู่ Subnet ใด ต้องเข้าถึงอะไร และควรเปิดรับจากภายนอกตรงไหน เริ่มจาก Cloud IaaS แล้วออกแบบ VPC ให้ตรงกับ Workload
FROM DIAGRAM TO DEPLOYMENT
รวบรวม VM, CIDR เดิม และ Connection ที่ต้องใช้
เลือก Topology และจุดรับ Traffic จากภายนอก
ทำ Access matrix ตรวจ Router และ SG ร่วมกัน
ทดสอบทั้ง Allow, Block และ Return พร้อมตกลงการดูแล
A FEW GOOD QUESTIONS
VPC ใช้ Logical Isolation เพื่อแยก Network บน Cloud Infrastructure ที่ใช้งานร่วมกัน จึงไม่ได้หมายถึง Dedicated Hardware โดยอัตโนมัติ หากต้องการแยกทรัพยากรเฉพาะองค์กร ให้ทีมช่วยประเมินบริการที่เหมาะสม
ไม่จำเป็น เลือกได้ทั้ง Private network ที่มี Router, แยก Subnet ตาม Tier หรือ Subnet เดียวกับ SG ตามบทบาท โดยพิจารณาจำนวนระบบ การดูแล และสิทธิ์เข้าถึง
ตัวอย่างนี้ไม่ให้ DB มี Public endpoint โดย App เข้าถึง DB ผ่าน Private IP และ SG อนุญาตเฉพาะต้นทางกับพอร์ตที่จำเป็น
แจ้งช่วง IP เส้นทางและข้อกำหนดการเชื่อมต่อให้ทีมประเมินก่อนออกแบบ โดยตรวจความเข้ากันได้และขอบเขตบริการตามโครงการ
LET’S DESIGN YOUR NETWORK
แจ้ง Workload, ช่วง IP และสิทธิ์เข้าถึงที่ต้องการ เพื่อประเมิน Topology และขอบเขตบริการร่วมกัน