รากฐานของ AWS VPC

ทฤษฎีและกลไกการทำงาน (How it works):
VPC (Virtual Private Cloud) คือหัวใจหลักของเครือข่ายบน AWS ที่ทำงานเสมือนเป็น Data Center ส่วนตัวที่ถูกจำลองขึ้นมาแบบ Logical การสร้าง VPC จำเป็นต้องมีการกำหนดขอบเขตของ IP Address เสมอ ซึ่ง AWS ใช้มาตรฐาน CIDR (Classless Inter-Domain Routing) ในการระบุขนาดของเครือข่าย

ภายใต้สถาปัตยกรรมระดับลึก (Under the hood) VPC ไม่ได้เป็นอุปกรณ์ Physical Router เดี่ยวๆ แต่ถูกควบคุมโดย "Hyperplane" ซึ่งเป็น Distributed System ที่จัดการ SDN (Software Defined Networking) ของ AWS ทำให้ VPC มีความสามารถในการรองรับแบนด์วิดท์มหาศาลโดยไม่มีคอขวด (Bottleneck) จากอุปกรณ์ตัวใดตัวหนึ่ง

เมื่อเรากำหนด CIDR block เช่น 10.0.0.0/16 หมายความว่าเรามี IP Address ทั้งหมด 65,536 IPs (2^(32-16)) ซึ่ง IP เหล่านี้จะถูกจำกัดขอบเขตไม่ให้ซ้ำซ้อนกันได้ใน VPC เดียวกัน (ยกเว้นการทำ Secondary CIDR) การทำความเข้าใจ CIDR Math ถือเป็นพื้นฐานที่สำคัญที่สุด เพราะหากเลือกขนาดของ CIDR ผิดตั้งแต่แรก จะไม่สามารถย่อหรือขยายขอบเขตของ Primary CIDR Block ได้ในภายหลัง ส่งผลให้ต้องทำ VPC Peering หรือลบและสร้าง VPC ใหม่ทั้งหมด

resource "aws_vpc" "main_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "Core-Enterprise-VPC"
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

# ตัวอย่างการขยาย VPC ด้วย Secondary CIDR Block ในภายหลัง
resource "aws_vpc_ipv4_cidr_block_association" "secondary_cidr" {
  vpc_id     = aws_vpc.main_vpc.id
  cidr_block = "10.2.0.0/16"
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในองค์กรขนาดใหญ่ระดับ Enterprise (เช่น ธนาคารหรือ E-commerce แพลตฟอร์ม) ทีม Platform Engineering มักจะออกแบบ VPC ขนาด /16 หรือ /18 ไว้เป็นมาตรฐานสำหรับแต่ละระบบย่อย (Microservices/Bounded Contexts) แต่ในกรณีที่สถาปัตยกรรมใช้ Amazon EKS (Kubernetes) ที่มีการจอง IP ให้กับแต่ละ Pod จำนวนมหาศาล (ผ่าน VPC CNI) ทำให้ IP ใน 10.0.0.0/16 หมดอย่างรวดเร็ว วิธีแก้ในระดับโปรดักชันคือการแนบ (Associate) Secondary CIDR Block ในย่าน IP ที่ไม่ได้ใช้ เช่น 100.64.0.0/10 (CGNAT range) สำหรับใช้กับ EKS Pods โดยเฉพาะ เพื่อสงวน IP ย่านหลักไว้ใช้กับบริการสำคัญ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): การตั้งค่า CIDR Block ที่ซ้ำซ้อนหรือทับซ้อนกัน (Overlapping) ระหว่าง VPCs ในองค์กร เมื่อถึงเวลาที่ธุรกิจเติบโตและต้องนำ VPC เหล่านี้มาเชื่อมต่อกันผ่าน VPC Peering หรือ Transit Gateway ระบบจะไม่สามารถสร้างเส้นทาง (Route) ระหว่างกันได้ เพราะ IP ชนกัน
* Mitigation (วิธีแก้): ใช้เครื่องมือระดับองค์กรในการจัดการ IP อย่าง AWS IPAM (IP Address Manager) เพื่อควบคุมกระบวนการจ่าย IP Address (IP Allocation) ตั้งแต่ศูนย์กลาง ห้ามให้ทีมพัฒนาเลือก CIDR ย่านเดิมๆ เช่น 10.0.0.0/16 ซ้ำซากโดยเด็ดขาด

ทฤษฎีและกลไกการทำงาน (How it works):
Subnet คือการนำพื้นที่ขนาดใหญ่ของ VPC (เช่น /16) มาหั่นแบ่งย่อยเป็นชิ้นส่วนขนาดเล็ก (เช่น /24) เพื่อจัดกลุ่มและแยกระดับการเข้าถึง (Segmentation) สิ่งที่สำคัญที่สุดของ Subnet ในสถาปัตยกรรม AWS คือ 1 Subnet จะผูกติดกับ 1 Availability Zone (AZ) เท่านั้น และไม่สามารถข้าม AZ ได้ (AZ คือกลุ่มของ Data Center จริงที่มีระบบไฟและเครือข่ายแยกจากกัน)

เพื่อให้ระบบมีความทนทาน (High Availability) และพร้อมรับมือกับภัยพิบัติ (Fault Tolerance) วิศวกรข้อมูลจะต้องหั่น Subnet กระจายออกไปในอย่างน้อย 2 หรือ 3 AZs เสมอ เช่น us-east-1a, us-east-1b, us-east-1c

นอกจากนี้ ในทุกๆ Subnet ที่เราสร้างขึ้น AWS จะมีการยึดครอง (Reserve) 5 IP Addresses แรกไว้เสมอ ได้แก่:
- .0 = Network address
- .1 = VPC Router
- .2 = AWS DNS Resolution
- .3 = จองไว้ใช้ในอนาคต (Future use)
- .255 = Network broadcast (AWS ไม่รองรับ Broadcast จึงยึดไว้)
ดังนั้น Subnet แบบ /24 จะมี IP ให้ใช้งานจริงแค่ 251 IPs เท่านั้น

variable "azs" {
  type    = list(string)
  default = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
}

# สร้าง Private Subnet กระจาย 3 AZs (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24)
resource "aws_subnet" "private_tier" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.main_vpc.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = element(var.azs, count.index)
  
  # ไม่ออกอินเทอร์เน็ตโดยตรง
  map_public_ip_on_launch = false

  tags = {
    Name = "Private-App-Subnet-${element(var.azs, count.index)}"
    Tier = "Private"
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในสถาปัตยกรรม Data Pipeline ระดับโลก มักจะใช้สถาปัตยกรรมแบบ 3-Tier Subnet Strategy ได้แก่
1. Public Tier: เล็กที่สุด (เช่น /28) ใช้สำหรับวาง Load Balancers (ALB) หรือ Bastion Hosts
2. Private App Tier: ขนาดใหญ่ (เช่น /22) สำหรับประมวลผลข้อมูล (Worker Nodes, EKS, Spark Clusters) ซึ่งเป็นส่วนที่มีการ Scale out ขยายจำนวนเครื่องมากที่สุด
3. Private Data Tier: ขนาดปานกลาง (เช่น /24) สำหรับวางฐานข้อมูล RDS, ElastiCache โดยมีการจำกัดการเข้าถึงอย่างเข้มงวดที่สุด
การแยก Tier ชัดเจนช่วยให้สามารถออกแบบ Network ACL และ Route Table ที่รัดกุม (Least Privilege Network) ได้ในระดับสูงสุด

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): แบ่ง Subnet ขนาดเล็กเกินไป (เช่น /28 มีแค่ 11 IPs ให้ใช้) และเมื่อนำไปติดตั้ง RDS แบบ Multi-AZ หรือสร้าง EKS Cluster ทำให้ IP ใน Subnet นั้นหมดเกลี้ยง (IP Exhaustion) คลัสเตอร์ไม่สามารถงอกเครื่องใหม่มารองรับโหลดได้จนล่มในที่สุด
* Mitigation (วิธีแก้): ประเมินจำนวน Resource สูงสุดในช่วง Peak load เสมอ และบวกเผื่อไว้อีก 50% สำหรับการทำ Blue/Green Deployment หรือ Rolling Update แนะนำให้ Subnet สำหรับ Compute Nodes มีขนาดอย่างน้อย /22 หรือ /21

ทฤษฎีและกลไกการทำงาน (How it works):
Route Table เปรียบเสมือน "ป้ายบอกทาง" และ "เข็มทิศ" ของเครือข่ายภายใน VPC ทุกๆ Subnet จำเป็นต้องผูก (Associate) กับ Route Table 1 ตัวเสมอ เพื่อให้รู้ว่าถ้ารับแพ็กเกจข้อมูลมา จะต้องส่งต่อไปที่ไหน

กลไกที่ควรรู้เกี่ยวกับ Route Table:
1. Main Route Table: ทุก VPC จะมี Main Route Table ติดมาตั้งแต่เกิด หากคุณสร้าง Subnet แล้วลืมผูกกับ Route Table ใดๆ มันจะตกไปใช้ (Fallback) ที่ Main Route Table เสมอ
2. Local Route (The Immutable Rule): ทุก Route Table จะมีกฎตายตัว 1 ข้อเสมอคือ กฎ Local (เช่น 10.0.0.0/16 -> local) ซึ่งทำหน้าที่อนุญาตให้ทุกทรัพยากรภายใน VPC คุยกันเองได้ ไม่ว่าทรัพยากรนั้นจะอยู่ Subnet ไหนก็ตาม และคุณไม่สามารถลบหรือแก้ไขกฎข้อนี้ได้
3. Longest Prefix Match: กลไกการหาเส้นทางของ AWS จะใช้หลักการ "จับคู่คำนำหน้าที่ยาวที่สุด" เช่น หากมีทราฟฟิกส่งไปที่ 10.0.5.1 และมีกฎ 2 ข้อคือ 10.0.0.0/16 -> Target A กับ 10.0.5.0/24 -> Target B ทราฟฟิกจะถูกส่งไปที่ Target B ทันทีเพราะ /24 เจาะจงตัวตน (Specific) มากกว่า /16

resource "aws_route_table" "custom_rt" {
  vpc_id = aws_vpc.main_vpc.id

  # ทราฟฟิกทั่วไป (0.0.0.0/0) วิ่งออก Internet Gateway
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }

  # เฉพาะทราฟฟิกที่วิ่งไป Data Center สาขา 1 ให้มุดอุโมงค์ VPN (Virtual Private Gateway)
  route {
    cidr_block = "192.168.10.0/24"
    gateway_id = aws_vpn_gateway.vgw.id
  }

  tags = {
    Name = "Public-Split-Routing"
  }
}

# ผูก Route Table กับ Subnet
resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public_subnet.id
  route_table_id = aws_route_table.custom_rt.id
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในสถาปัตยกรรมระดับ Enterprise ที่มีการใช้งาน AWS Transit Gateway เพื่อเชื่อมบริษัทลูกในเครือข่ายหลายสิบบริษัท การตั้งค่า Route Table มักจะใช้สถาปัตยกรรม "Blackhole Routing" ร่วมด้วย เช่น เมื่อเราพบว่าเครือข่ายย่อย 10.55.0.0/16 เป็นโซนที่มีมัลแวร์ติดอยู่ หรือถูกโจมตีแบบ DDoS แทนที่จะไปลบเส้นทาง เราสามารถแทรกกฎชั่วคราวชี้ IP ชุดนั้นไปยังเป้าหมายที่เป็น Blackhole (ใน AWS คือการทิ้งแพ็กเกจทิ้งทันที) เพื่อระงับการจราจรแบบฉับพลันโดยไม่ต้องดับเซิร์ฟเวอร์

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ปล่อยให้ Subnet ตกไปอยู่ใน Main Route Table ขาดการจัดการที่ดี วันดีคืนดีทีมวิศวกรฝึกหัดเผลอแก้ Main Route Table ชี้ออก Internet Gateway ทำให้ระบบ Private Database ที่ตกค้างอยู่ใน Main Route Table หลุดออกสู่โลกภายนอก (Data Breach) ทันที
* Mitigation (วิธีแก้): กฎเหล็กข้อแรกของ SRE (Site Reliability Engineering) คือ ห้ามใช้ Main Route Table เด็ดขาด ทุก Subnet ที่สร้างใหม่ "ต้อง" บังคับ Associate กับ Custom Route Table เสมอ และบางองค์กรจะเขียน Main Route Table ให้เป็น Blackhole ทั้งหมดเพื่อเป็นกับดัก (Trap) สำหรับคนที่สร้าง Subnet แล้วลืมผูก Route Table

ทฤษฎีและกลไกการทำงาน (How it works):
Security Group (SG) คือ Firewall ด่านสุดท้ายที่ครอบปกป้อง Elastic Network Interface (ENI) ระดับตัวเครื่อง (Instance-level) คุณสมบัติโดดเด่นและเป็นแกนกลางสำคัญที่ทำให้ SG แตกต่างจาก Firewall ทั่วไปคือมันเป็น Stateful

คำว่า Stateful หมายถึง SG จะ "จดจำ" สถานะของการเชื่อมต่อเอาไว้ (Connection Tracking) หากมี Request วิ่งผ่านทะลุเข้าไปได้ (Inbound/Ingress) ตอนที่ส่งคำตอบกลับออกมา (Outbound/Egress) มันจะทะลุผ่าน SG กลับออกไปได้ทันที โดยไม่ต้องมีกฎอนุญาตขาออกมารองรับ ทำให้การคอนฟิกง่ายและลดความเสี่ยงจากการเปิดพอร์ตผิดพลาด

อีกกลไกที่ทรงพลังมากคือ Security Group Referencing แทนที่เราจะระบุกฎเป็น IP Address แบบแข็งทื่อ (10.0.1.5/32) เราสามารถเขียนกฎว่า "อนุญาตให้ใครก็ตามที่สวมใส่ Security Group A สามารถเข้าถึง Security Group B ได้" ซึ่งมีประโยชน์มหาศาลในโลก Cloud ยุคใหม่ที่ IP Address ของเซิร์ฟเวอร์เปลี่ยนไปมาตลอดเวลา (Auto Scaling)

# 1. SG สำหรับ Web Server
resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Allow HTTPS from anywhere"
  vpc_id      = aws_vpc.main_vpc.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# 2. SG สำหรับ Database (ห้ามระบุ IP, ให้อ้างอิง Web SG แทน)
resource "aws_security_group" "db_sg" {
  name        = "database-sg"
  description = "Allow MySQL traffic only from Web Servers"
  vpc_id      = aws_vpc.main_vpc.id

  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    # อนุญาตเฉพาะเครื่องที่แปะ web_sg เข้ามาได้เท่านั้น!
    security_groups = [aws_security_group.web_sg.id] 
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในโครงสร้างของระบบ E-commerce แพลตฟอร์มที่มี Microservices จำนวนมาก การกำหนด Firewall ด้วย IP Address เป็นเรื่องที่เป็นไปไม่ได้ เพราะ EKS/Auto Scaling Group ทำให้ Container ดับและเกิดใหม่ด้วย IP ใหม่เป็นหลักร้อยครั้งต่อวัน สถาปนิกคลาวด์จะใช้ "SG Reference" เป็น Zero Trust Architecture หมายความว่า "ต่อให้คุณอยู่ใน Subnet เดียวกันกับ Database หรือมี IP ชุดเดียวกัน แต่ถ้าคุณไม่ได้สวมใส่ SG ที่ได้รับอนุญาต (IAM-like policy for network) แพ็กเกจของคุณจะถูก Drop ทันทีในระดับ Hypervisor"

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): กฎ Circular Dependency (วงจรลูป) หรือการเปิดกฎ Outbound แบบ 0.0.0.0/0 ทิ้งไว้เป็นดีฟอลต์ หากเซิร์ฟเวอร์ถูกเจาะ (RCE) แฮกเกอร์สามารถสั่งให้เซิร์ฟเวอร์นั้นดาวน์โหลดมัลแวร์จากอินเทอร์เน็ตผ่านขา Outbound ที่เปิดทิ้งไว้ หรือดึงข้อมูล Database ออกไปสู่ Server ภายนอกได้ (Data Exfiltration)
* Mitigation (วิธีแก้): บังคับใช้ Least Privilege ทั้งขา Inbound และ Outbound เสมอ และควรใช้ Terraform lifecycle rule create_before_destroy = true เวลาแก้ SG เพื่อไม่ให้จราจรเครือข่ายสะดุด

ทฤษฎีและกลไกการทำงาน (How it works):
Network Access Control List (NACL) คือ Firewall ชั้นนอกสุดที่ครอบคลุมพื้นที่ "ระดับ Subnet" (Subnet-level) แตกต่างจาก Security Group ตรงที่ NACL เป็น Stateless หมายความว่ามัน "ไม่จดจำ" สิ่งที่เกิดขึ้น หากคุณอนุญาตให้ Request เข้ามาในระบบได้ (Inbound) ถ้าคุณต้องการให้ระบบตอบกลับ (Outbound) คุณต้องเขียนกฎอนุญาตขาออกมารองรับอย่างชัดเจน ไม่เช่นนั้นคำตอบจะถูกบล็อกทิ้งที่ประตูทางออก

การประมวลผลกฎของ NACL จะอ่านตาม "ลำดับหมายเลข (Rule Number)" จากค่าน้อยไปมาก (เช่น 100, 110, 120) และจะหยุดอ่านทันทีเมื่อเจอกฎที่ตรงกัน (First-match wins)

NACL ถูกออกแบบมาให้เป็นด่านกั้นหยาบๆ (Coarse-grained) และมีบทบาทสำคัญมากในการสร้าง Explicit Deny (การปฏิเสธอย่างชัดเจน) ซึ่งใน Security Group คุณทำไม่ได้ (SG ทำได้แค่อนุญาตให้เข้า, ไม่มีคำสั่งห้าม)

resource "aws_network_acl" "db_nacl" {
  vpc_id = aws_vpc.main_vpc.id
  subnet_ids = [aws_subnet.private_tier[0].id]

  # Rule 100: บล็อก IP ของแฮกเกอร์ที่ตรวจพบ (Explicit Deny) แบบเด็ดขาด
  ingress {
    protocol   = "tcp"
    rule_no    = 100
    action     = "deny"
    cidr_block = "203.0.113.50/32"
    from_port  = 0
    to_port    = 0
  }

  # Rule 200: อนุญาตให้ Web Subnet ยิงพอร์ต 3306 เข้ามาได้
  ingress {
    protocol   = "tcp"
    rule_no    = 200
    action     = "allow"
    cidr_block = "10.0.1.0/24"
    from_port  = 3306
    to_port    = 3306
  }

  # Egress Rule 100: (สำคัญมาก!) อนุญาตให้พอร์ตขากลับ (Ephemeral Ports) ออกไปได้
  egress {
    protocol   = "tcp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "10.0.1.0/24"
    from_port  = 1024
    to_port    = 65535
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
สมมติว่าเกิดการโจมตีแบบ DDoS หรือพบว่ามีเครื่องเซิร์ฟเวอร์ในต่างประเทศ (เช่น ไอพี 8.8.x.x) กำลังพยายาม Brute-force ระบบล็อกอินของคุณ หากคุณใช้ Security Group คุณจะไม่สามารถสั่งบล็อกมันโดยตรงได้ คุณต้องพึ่งพา AWS WAF หรือตัวป้องกันระดับบน แต่ด้วย NACL คุณสามารถเพิ่มกฎ Rule Number 50: DENY 8.8.x.x/16 ทำให้แพ็กเกจขยะทั้งหมดถูกทิ้ง (Drop) ตั้งแต่ระดับพรมแดนของ Subnet ก่อนที่ทราฟฟิกจะหลุดเข้าไปกินซีพียู (CPU resources) หรือกิน Connection limit ของเครื่อง EC2

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): วิศวกรใหม่มักจะตกม้าตายเรื่อง Ephemeral Ports (พอร์ตลอย) เมื่อ Client ติดต่อ Server ด้วยพอร์ต 443 Server จะตอบกลับไปยัง Client ด้วยพอร์ตแบบสุ่มในช่วง (1024-65535) หากวิศวกรลืมเปิดพอร์ต Egress ทิ้งไว้ ทราฟฟิกจะ Timeout
* Mitigation (วิธีแก้): อย่าใช้ NACL เป็นไฟร์วอลล์หลัก ให้มองเป็น "Guardrails ชั้นนอก" เท่านั้น แนะนำให้ปล่อย NACL เป็น Allow All โดยดีฟอลต์ (เหมือนที่ AWS สร้างมาให้) และใช้ NACL เพื่อทำ Blacklisting หรือบล็อกพอร์ตอันตรายระดับโลก (เช่น ปิดพอร์ต 22 (SSH) ขาเข้าจากทุก IP ยกเว้นวง Corporate IP) นอกนั้นยกหน้าที่การคัดกรองแบบละเอียดให้ Security Group จัดการแทน