โครงสร้างพื้นฐานเครือข่ายระบบคลาวด์ (Cloud-based Networking)

ทฤษฎีและกลไกการทำงาน (How it works): **VPC (Virtual Private Cloud)** คือการจัดแบ่งเครือข่ายแยกส่วนเสมือนจริงในระบบคลาวด์ การประกาศขนาดของ VPC ต้องกำหนดค่าไอพีแบบ **CIDR (Classless Inter-Domain Routing)** ในรูปแบบ `A.B.C.D/Mask` ค่าตัวเลข Mask ด้านหลังจะเป็นตัวระบุจำนวนบิตของที่อยู่ IP ที่จองไว้เป็นตัวเลขเครือข่ายคงที่ เช่น `/16` จะจองช่วงไอพีคงที่ไว้ 2 Octets แรก ทำให้มีพื้นที่ IP ย่อยใช้สอยได้ $2^{32-16} = 65,536$ ที่อยู่ ซึ่งเราต้องระมัดระวังไม่ให้ที่อยู่ IP ของ VPC นี้ไปชนทับกับที่อยู่อื่นของเครือข่ายในองค์กรเมื่อทำการเชื่อมต่อข้ามฝั่ง

# Example block design for a production VPC network
VPC CIDR Range: 10.0.0.0/16 (Allows 65,536 IPs)
  - Public Subnet US-East-1A: 10.0.1.0/24 (Allows 256 IPs)
  - Private Subnet US-East-1A: 10.0.10.0/24 (Allows 256 IPs)
  - Database Subnet US-East-1A: 10.0.20.0/24 (Allows 256 IPs)
                    

Use Case ในชีวิตจริง (Real-world Scenario): วิศวกรคลาวด์ดีไซน์เครือข่าย VPC ขนาดกลางสำหรับแอปพลิเคชันข้อมูลขององค์กร โดยกำหนดย่าน IP ไว้ที่ `10.100.0.0/16` เพื่อหลีกเลี่ยงไม่ให้ชนกับระบบโครงข่ายภายในออนพรีมิส (On-premise network) ที่จองย่าน `10.0.0.0/16` เอาไว้ก่อน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การจัดสรรขนาด CIDR เล็กเกินไป (เช่น `/28` ซึ่งมีเพียง 16 ไอพี) อาจทำให้ไอพีในซับเน็ตไม่เพียงพอเมื่อต้องขยายโหนดคอมพิวเตอร์แบบขนาน (Auto-scaling) แก้ไขโดยจัดทำแผนงานสเปซไอพีล่วงหน้าและเลือกประกาศ CIDR ขนาดกลางเช่น `/16` สำหรับ VPC และ `/24` (256 ไอพี) สำหรับแต่ละ Subnet

ทฤษฎีและกลไกการทำงาน (How it works): เพื่อคุมมาตรฐานความปลอดภัยของเครื่องเซิร์ฟเวอร์ เราต้องแยกซับเน็ตออกเป็น 2 ประเภทหลัก: - **Public Subnet**: ซับเน็ตที่ Route Table มีการจัดเส้นทางปลายทางชี้ไปยัง **Internet Gateway (IGW)** ทำให้อุปกรณ์ในซับเน็ตนี้ได้สิทธิ์สองทางในการคุยกับสาธารณะภายนอก - **Private Subnet**: ซับเน็ตที่ไม่มีเส้นทางออกอินเทอร์เน็ตโดยตรงผ่าน IGW โฮสต์ภายในจะไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตภายนอก ถือเป็นสถานที่ปลอดภัยสำหรับวางข้อมูลสำคัญ

# Route Table configuration for Public Subnet:
Destination: 0.0.0.0/0  -> Target: igw-xxxxxxxx (Internet Gateway)
Destination: 10.0.0.0/16 -> Target: local

# Route Table configuration for Private Subnet:
Destination: 0.0.0.0/0  -> Target: nat-xxxxxxxx (NAT Gateway)
Destination: 10.0.0.0/16 -> Target: local
                    

Use Case ในชีวิตจริง (Real-world Scenario): โครงสร้างพื้นฐานของระบบ ETL วางเซิร์ฟเวอร์ Airflow Worker ที่ต้องดึงข้อมูลดิบและคลังข้อมูล ClickHouse ไว้ใน Private Subnet และติดตั้งเฉพาะหน้าเว็บ API Gateway (เช่น Nginx) ไว้ที่ Public Subnet เพื่อคอยคัดกรองคำขอจากอินเทอร์เน็ต

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การวางเซิร์ฟเวอร์ฐานข้อมูลวิเคราะห์ไว้ผิดที่ใน Public Subnet เป็นความสุ่มเสี่ยงต่อการโดนสแกนพอร์ตเพื่อโจมตีและขโมยข้อมูล แก้ไขโดยย้ายระบบฐานข้อมูลและแอปพลิเคชันประมวลผลทั้งหมดลง Private Subnet ทันทีและสถาปนาการเข้าถึงระบบควบคุมข้ามทางผ่าน Bastion Host เท่านั้น

ทฤษฎีและกลไกการทำงาน (How it works): ตัวประสานสองจุดเชื่อมต่อ: - **Internet Gateway (IGW)**: อุปกรณ์เสมือนเชื่อมต่อระหว่าง VPC และอินเทอร์เน็ตสาธารณะ ทำงานแบบไร้สถานะและไม่จำกัดแบนด์วิดท์ - **NAT Gateway (Network Address Translation)**: อุปกรณ์ใน Public Subnet ทำหน้าที่แปลงที่อยู่ IP ส่วนตัวให้กลายเป็น IP สาธารณะ (NAT) เพื่อให้โฮสต์จาก Private Subnet สามารถสื่อสารยิงข้อความออกนอกอินเทอร์เน็ตเพื่อดาวน์โหลดแพ็กเกจหรืออัปเดตระบบได้ โดยจะปฏิเสธไม่ให้สัญญาณภายนอกเจาะจงวิ่งสวนกลับเข้ามาหา Private Host (การสื่อสารทางเดียว)

# Concept of Network Address Translation flow:
Private Host (10.0.10.15) sends request to external API (142.250.4.1)
  -> Sent via Private Route Table to NAT Gateway (Public IP: 54.12.34.56)
  -> NAT Gateway translates packet headers: Source IP becomes 54.12.34.56
  -> Packet is routed via Internet Gateway to 142.250.4.1
                    

Use Case ในชีวิตจริง (Real-world Scenario): ตัวดึงข้อมูลในระบบจ๊อบของ Spark ค้างในซับเน็ตส่วนตัวต้องการดึงข้อมูลพยากรณ์อากาศจาก API นอกคลาวด์เพื่อรันสรุปสถิติ โดยทรานแซกชันจะสามารถดึงค่าได้ปกติผ่าน NAT Gateway ในขณะที่เซิร์ฟเวอร์หลักยังคงปลอดภัยจากการเจาะ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ตัว NAT Gateway มีค่าบริการรายชั่วโมงและค่าแบนด์วิดท์ส่งผ่านข้อมูลที่ค่อนข้างสูง หากท่อข้อมูลหลักโหลดข้อมูลขนาดใหญ่ระดับเทราไบต์ข้ามผ่าน NAT บิลค่าไฟคลาวด์จะพุ่งขึ้นมหาศาล แก้ไขโดยเปิดใช้งาน **VPC Endpoints** (ทางลัดส่วนตัวเชื่อมหาบริการ S3 หรือ BigQuery ภายในระบบคลาวด์เดียวกันโดยไม่ยอมให้ข้อมูลวิ่งอ้อมผ่าน NAT Gateway)

ทฤษฎีและกลไกการทำงาน (How it works): การคุมกฎความปลอดภัยด้านพอร์ตเครือข่ายแบ่งออกเป็นสองด่านหลัก: - **Network ACLs (NACLs)**: ไฟร์วอลล์ด่านแรกคุมระดับ Subnet ทำงานแบบ **ไร้สถานะ (Stateless)** หมายความว่ากฎขาเข้า (Inbound) และขาออก (Outbound) ต้องระบุแยกจากกันอย่างชัดเจน หากอนุญาตขาเข้าแต่ลืมตั้งขาออก สัญญาณจะตอบกลับไปไม่ได้ - **Security Groups (SGs)**: ไฟร์วอลล์ระดับตัวโฮสต์คอมพิวเตอร์รายตัว ทำงานแบบ **จำสถานะ (Stateful)** หมายความว่าหากอนุญาตสัญญาณขาเข้าให้ผ่านได้แล้ว สัญญาณตอบรับขากลับจะได้รับอนุมัติออกนอกอัตโนมัติโดยไม่ต้องตั้งกฎขาออกแยกอีกครั้ง

ทฤษฎีและกลไกการทำงาน (How it works): เมื่อมีระบบงานข้อมูลกระจายอยู่คนละ VPC หรือต่างบัญชีคลาวด์ การเชื่อมโยงให้หากันทำได้ผ่าน 2 เทคนิค: - **VPC Peering**: เชื่อม VPC สองฝั่งเข้าหากันโดยตรงด้วยเราเตอร์เสมือน ข้อมูลวิ่งหากันผ่านโครงข่ายแบ็คโบนภายในของคลาวด์เสมือนอยู่วงแลนเดียวกัน ทรานแซกชันจะสามารถสแกนหากันได้ทุกพอร์ตหากไม่บล็อก - **AWS PrivateLink / VPC Endpoint Services**: เชื่อมโยงผ่านสถาปัตยกรรมแบบ Service Provider/Consumer โดยข้อมูลจะวิ่งผ่านเครือข่ายส่วนตัวด้วยพอยน์เตอร์การ์ดแลนพิเศษ (Elastic Network Interface - ENI) ยอมให้สื่อสารเฉพาะบริการพอร์ตเป้าหมายที่ระบุเท่านั้น ป้องกันไม่ให้เครือข่ายทั้งสองวงเห็นหน้าตาของโครงข่ายกันทั้งหมด

# Concept of VPC Peering vs PrivateLink connection interfaces
VPC Peering:
VPC A (10.0.0.0/16) <==================> VPC B (10.1.0.0/16)
Full network-to-network connectivity over internal backbone routing.

VPC PrivateLink (Gateway / Interface Endpoint):
VPC A (10.0.0.0/16) -> ENI (10.0.1.45) --------[ PrivateLink ]--------> Target Service (S3/Redshift)
Only specific ports of target service are exposed locally.
                    

Use Case ในชีวิตจริง (Real-world Scenario): บริษัทฟินเทคต้องการให้ระบบดึงข้อมูลไปดึงตารางจากผู้ให้บริการภายนอกคลาวด์ โดยเลี่ยงไม่เปิดเครือข่ายชนกับคู่ค้าผ่าน VPC Peering จึงเลือกตั้งจุดเชื่อมแบบ PrivateLink ยิงตรงไปหาพอร์ตบริการคิวรีข้อมูลของคู่ค้า ทำให้ข้อมูลไหลลื่นและมั่นคงปลอดภัย

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การทำ VPC Peering จะล้มเหลวทันทีและไม่สามารถเชื่อมต่อกันได้หากย่าน CIDR ของ VPC ทั้งสองฝั่งมีช่วง IP **ทับซ้อนกัน** (Overlapping CIDR Blocks) แก้ไขโดยศึกษาการตั้งค่าช่วง IP ให้มีเอกลักษณ์แต่แรก หรือแก้ปัญหาย้อนหลังด้วยการใช้ PrivateLink หรือการติดตั้งเราเตอร์แปลงพิกัด (NAT Gateway) จัดสเปคไอพีแยกเฉพาะบริการ

ทฤษฎีและกลไกการทำงาน (How it works): ระบบ Object Storage บนคลาวด์ (เช่น AWS S3, Azure Blob, GCS) มีการแบ่งระดับชั้นการจัดเก็บข้อมูลตามวงจรชีวิต (Data Lifecycle) เพื่อให้เกิดความคุ้มค่าสูงสุด: - **Hot Tier**: สำหรับข้อมูลที่ใช้ประมวลผลเป็นประจำ (บ่อยกว่า 1 ครั้ง/เดือน) ค่าจัดเก็บราย GB ค่อนข้างสูง แต่ค่าเรียกอ่าน (Retrieval) ต่ำ - **Cool/Infrequent Access Tier**: สำหรับข้อมูลเก่าที่ใช้วิเคราะห์นานๆ ที ค่าจัดเก็บถูกลง แต่ต้องระวังค่าธรรมเนียมขั้นต่ำระยะเวลาจัดเก็บ (Minimum Storage Duration) และค่าเรียกอ่านที่สูงขึ้น - **Archive/Glacier Tier**: สำหรับเก็บล็อกยาวนานระดับปีเพื่อส่งตรวจประเมิน (Audit) ค่าจัดเก็บถูกที่สุดจนแทบฟรี แต่เมื่อต้องการอ่านอาจต้องรอระบบละลายน้ำแข็ง (Restore) นานหลายชั่วโมงถึงหลักวัน

  
    MoveOldLogsToArchive
    logs/2026/
    Enabled
    
      90
      STANDARD_IA
    
    
      365
      GLACIER
    
  

                    

Use Case ในชีวิตจริง (Real-world Scenario): บริษัทยึดหลักเกณฑ์ความปลอดภัยไซเบอร์ ต้องเก็บ Raw Logs เป็นเวลา 5 ปี การใช้ S3 Lifecycle ย้ายล็อกที่เก่ากว่า 1 ปีลง Glacier ทำให้บริษัทประหยัดงบ Cloud Storage ได้กว่า 80% ต่อเดือน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): วิศวกรมือใหม่มักเผลอตั้งกฎย้ายไฟล์ขนาดเล็กมากๆ (ระดับ KBs) ลงสู่ Glacier ซึ่งเป็นการตัดสินใจที่ผิดพลาด เพราะโครงสร้าง Archive จะมีการคิดค่า Overhead และค่าชิ้นไฟล์ (Per-Object Fee) มหาศาลจนบิลคลาวด์อาจแพงกว่าเดิม ควรทำรวมไฟล์ (File Compaction) เป็นบล็อกใหญ่ๆ ก่อนทำ Archive

ทฤษฎีและกลไกการทำงาน (How it works): กลยุทธ์สำคัญที่สุดในการลดค่าใช้จ่ายคลาวด์ไม่ใช่แค่ลดสเปคเครื่อง (Rightsizing) แต่คือการเข้าใจโครงสร้างราคา **Egress Data Transfer (ค่าส่งข้อมูลออก)** บริการคลาวด์เกือบทุกเจ้า (AWS, GCP, Azure) มักให้คุณนำข้อมูลเข้า (Ingress) ฟรี! แต่ชาร์จเงินมหาศาลหากคุณพยายามนำข้อมูลโหลดออกอินเทอร์เน็ต (Egress) หรือวิ่งข้าม Availability Zone (AZ) กุญแจสำคัญคือต้องควบคุมให้การประมวลผลและการจัดเก็บข้อมูลอยู่ภายใน Region และ AZ เดียวกันให้มากที่สุด

# ตัวอย่างสคริปต์ Terraform ที่บังคับสเปค Subnet และ Storage ให้ล็อกอยู่ใน AZ เดียวกัน
resource "aws_instance" "data_worker" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "r5.large"
  subnet_id     = aws_subnet.private_subnet_az1.id
}

# ตั้งค่า S3 Endpoint ให้อยู่ใน VPC เพื่อหลีกเลี่ยงการส่งข้อมูลออกนอกเครือข่ายสู่อินเทอร์เน็ตสาธารณะ
resource "aws_vpc_endpoint" "s3_internal" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.us-east-1.s3"
}
                    

Use Case ในชีวิตจริง (Real-world Scenario): ทีม Data Science ต้องการเทรนโมเดล AI ขนาด 50TB หากดึงข้อมูลจาก Cloud ลงมารันบนเครื่องเซิร์ฟเวอร์ออฟฟิศ (On-premise) จะโดนบิลเรียกเก็บค่าโอนถ่ายข้อมูลออกเป็นหลักแสนบาท วิธีที่ถูกคือต้องเปิดเช่าเครื่อง GPU บนคลาวด์เพื่อเทรนโมเดลให้อยู่ร่วมวงแลนเดียวกันกับ Storage

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การตั้งค่า NAT Gateway และโหลดทราฟฟิกข้อมูลขนาดใหญ่ทะลุ NAT ไปยังบริการ S3/GCS แทนที่จะใช้ **VPC Endpoints** (Gateway Endpoints) ทราฟฟิกนั้นจะถูกประเมินราคาตามแบนด์วิดท์ NAT แบบแพงหูฉี่ ควรตั้ง Route Table ให้อ่าน Storage แบบ Private เสมอ