การจัดการเส้นทางขั้นสูงและ NAT Gateway

ทฤษฎีและกลไกการทำงาน (How it works):
ใน AWS ไม่มีปุ่ม "Make Public" ที่กดแล้วจะเปลี่ยนสถานะของ Subnet ได้ทันที สิ่งที่ทำให้ Subnet กลายเป็น Public Subnet หรือ Private Subnet ขึ้นอยู่กับกลไกเดียวเท่านั้นคือ "การผูกเส้นทางใน Route Table เข้ากับ Internet Gateway (IGW)"

Internet Gateway คือองค์ประกอบในระดับ VPC ที่ทำหน้าที่เป็นประตูเชื่อมต่อ VPC ของเราเข้ากับอินเทอร์เน็ตสาธารณะ โดย IGW เป็นระบบที่ขยายขนาดได้แบบ Horizontal (Horizontally Scaled) และไม่มีจุดศูนย์กลางของความล้มเหลว (Highly Available) คุณไม่ต้องห่วงว่า IGW จะแบนด์วิดท์เต็ม
- หาก Subnet มีกฎ 0.0.0.0/0 -> igw-xxx = Public Subnet (ออกอินเทอร์เน็ตได้โดยตรง)
- หาก Subnet ไม่มีกฎนี้ (หรือชี้ไปที่ NAT Gateway แทน) = Private Subnet

นอกจาก Route Table แล้ว เครื่อง EC2 ใน Public Subnet จะออกอินเทอร์เน็ตได้ ต้องมี Public IP หรือ Elastic IP (EIP) ด้วย เพราะ IGW ทำหน้าที่ 1:1 Network Address Translation ในตัวมันเอง (แปลง Private IP ของเครื่องให้เป็น Public IP ก่อนส่งออกไป)

# สร้าง Internet Gateway ผูกกับ VPC
resource "aws_internet_gateway" "main_igw" {
  vpc_id = aws_vpc.main_vpc.id
  tags = {
    Name = "Main-Internet-Gateway"
  }
}

# สร้าง Route Table สำหรับ Public Subnet โดยเฉพาะ
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main_vpc.id

  # กฎสำคัญที่ทำให้กลายเป็น Public Subnet!
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main_igw.id
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
สถาปัตยกรรมระดับ Production แทบจะไม่วาง Application Logic หรือ Database ลงใน Public Subnet เลย เครื่องมือเดียวที่คู่ควรกับการอยู่ใน Public Subnet คือ Application Load Balancer (ALB), NAT Gateway, และ Bastion Hosts (Jump Boxes) เท่านั้น เมื่อผู้ใช้เรียกหน้าเว็บ ทราฟฟิกจะเข้ามาที่ ALB ใน Public Subnet ก่อน จากนั้น ALB จะรับหน้าที่ Reverse Proxy เจาะผ่านไฟร์วอลล์เพื่อเรียกใช้ Worker Nodes ที่ซ่อนอยู่ใน Private Subnet อย่างปลอดภัย

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ผู้ใช้งานสร้าง EC2 ใน Public Subnet แต่ลืมติ๊กเปิดการให้ Auto-assign Public IP ทำให้เครื่องนั้นแม้อยู่ใน Public Subnet ก็ออกอินเทอร์เน็ตไม่ได้ (และดาวน์โหลดอัปเดตไม่ได้)
* Mitigation (วิธีแก้): ควรตั้งค่า map_public_ip_on_launch = true ที่ระดับของ Public Subnet (ผ่าน Terraform) เพื่อให้มั่นใจว่าเครื่องใดๆ ที่ถูกสร้างใน Subnet นี้จะได้ Public IP อัตโนมัติโดยไม่พึ่งพิงความจำของวิศวกรผู้ใช้งาน

ทฤษฎีและกลไกการทำงาน (How it works):
ทรัพยากรใน Private Subnet ไม่สามารถเข้าถึงอินเทอร์เน็ตได้ด้วยตนเอง แต่บ่อยครั้งที่ระบบเหล่านี้ยังจำเป็นต้องออกไปข้างนอก (Egress-only) เช่น ดาวน์โหลด Security Patches หรือดึงภาพจากภายนอก หน้าที่นี้ตกเป็นของ NAT Gateway

NAT (Network Address Translation) Gateway เป็น Managed Service โดย AWS ที่คอยรับแพ็กเกจข้อมูลจาก Private Subnet ทำการสลับป้าย (Translate) Private IP ของเครื่องต้นทาง ให้กลายเป็น Public IP (Elastic IP) ของตัว NAT Gateway เอง แล้วจึงส่งข้อมูลผ่าน IGW ออกสู่อินเทอร์เน็ต พอข้อมูลขากลับมาถึง NAT Gateway ก็จะรู้ว่าต้องส่งกลับไปให้เครื่องไหน (Stateful Address Translation)

สถาปัตยกรรมนี้คือ Egress-only ของแท้ คนจากอินเทอร์เน็ตไม่สามารถพุ่งเป้าเข้ามาที่เครื่อง Private ได้โดยตรง (Ingress-blocked) ยกเว้นเซสชันจะถูกสร้างและเริ่มจากภายใน VPC ของเราก่อน

# ขอ IP สาธารณะถาวร (EIP) ให้ NAT
resource "aws_eip" "nat_eip" {
  vpc = true
}

# สร้าง NAT ใน Public Subnet (เพื่อให้มีทางออกอินเทอร์เน็ต)
resource "aws_nat_gateway" "main_nat" {
  allocation_id = aws_eip.nat_eip.id
  subnet_id     = aws_subnet.public_tier[0].id # วางใน Public Subnet แรก
  
  depends_on = [aws_internet_gateway.main_igw]
}

# Route สำหรับ Private Subnet ให้วิ่งไปที่ NAT แทน IGW
resource "aws_route_table" "private_rt" {
  vpc_id = aws_vpc.main_vpc.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main_nat.id
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
NAT Gateway ถูกผูกขาดติดอยู่กับ 1 Availability Zone เท่านั้น หาก AZ นั้นล่ม NAT Gateway จะตายไปด้วย ทราฟฟิกจาก Private Subnet ใน AZ อื่นที่ส่งข้อมูลมาให้ NAT ตัวนี้จะ Timeout ไปด้วย เพื่อแก้ไขปัญหานี้ (Enterprise Grade HA) ระบบใหญ่ๆ จึงต้องยอมจ่ายเงินเพื่อวาง NAT Gateway อย่างน้อย 1 ตัวต่อ 1 AZ (เช่น 3 AZs = 3 NAT Gateways) แล้วผูก Route Table ของแต่ละ AZ ให้วิ่งหา NAT Gateway ประจำถิ่นของตนเองเพื่อรับประกันความคงทนและลดค่าใช้จ่ายการส่งข้อมูลข้าม AZ (Cross-AZ Data Transfer Cost)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): NAT Gateway คิดเงิน 2 ส่วนคือ รายชั่วโมง (Hourly Charge) และ ค่าประมวลผลข้อมูล (Data Processing Charge per GB) หากทีม Data Engineer สั่งรัน Apache Spark ใน Private Subnet เพื่อดึงข้อมูลปริมาณ 500 TB จาก S3 ผ่าน NAT Gateway ค่าใช้จ่ายอาจพุ่งสูงหลักหมื่นเหรียญภายในข้ามคืน (Bill Shock)
* Mitigation (วิธีแก้): ติดตั้ง AWS VPC Endpoints (Gateway Endpoint) สำหรับบริการอย่าง S3 และ DynamoDB โดยเฉพาะ ដើម្បីให้ทราฟฟิกวิ่งทะลุเข้าหลังบ้านของ AWS โดยตรง ไม่ผ่าน NAT Gateway ซึ่งเป็นการลดค่า Data Processing อย่างมหาศาล

ทฤษฎีและกลไกการทำงาน (How it works):
หากสู้ราคาของ NAT Gateway ที่สูงในองค์กรขนาดเล็กหรือสภาพแวดล้อม Non-Production (เช่น Dev/Test) ไม่ไหว AWS อนุญาตให้คุณใช้ EC2 แบบปกติมาทำหน้าที่เป็น NAT Instance แทน

NAT Instance ทำงานโดยอาศัย Linux IP Routing (iptables/Netfilter) เป็นตัวแปลงที่อยู่ IP ให้แทน AWS จัดเตรียม AMI สำเร็จรูปมาให้แล้ว ข้อได้เปรียบคือคุณจ่ายแค่ราคาของ EC2 (เช่น t3.micro ราคาไม่กี่สิบดอลลาร์ต่อเดือน) แทนที่จะเป็นค่า Managed Service อย่างไรก็ตาม คุณจะสูญเสียคุณสมบัติ Auto Scaling, High Availability เบ็ดเสร็จ และยังถูกจำกัดแบนด์วิดท์ไว้ตามขนาดของ EC2 ที่เลือกอีกด้วย

กลไกสำคัญที่สุดในการใช้ NAT Instance คือคุณต้องเข้าไปตั้งค่าระดับ Network Interface (ENI) เพื่อปิดคุณสมบัติ Source/Destination Check เพราะถ้าไม่ปิด AWS Hypervisor จะดรอปแพ็กเกจทิ้ง เนื่องจาก IP ของแพ็กเกจที่พยายามจะผ่านเข้ามา ไม่ตรงกับ IP ของตัว EC2 เอง (นี่คือพฤติกรรมการแฝงตัว หรือ IP Masquerading)

# ใช้ AMI พื้นฐานจาก Amazon Linux 2 (พร้อม iptables)
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["amzn2-ami-vpc-nat-*"]
  }
}

resource "aws_instance" "nat_instance" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.public_tier[0].id
  
  # ปิดระบบเช็คต้นทาง/ปลายทาง (บังคับสำหรับ NAT)
  source_dest_check = false

  tags = {
    Name = "Dev-NAT-Instance"
  }
}

# กำหนดให้ Private Route Table ชี้มาที่ EC2 ตัวนี้
resource "aws_route_table" "private_dev_rt" {
  vpc_id = aws_vpc.main_vpc.id
  route {
    cidr_block  = "0.0.0.0/0"
    instance_id = aws_instance.nat_instance.id
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
NAT Instance มักถูกใช้ในสถาปัตยกรรมแบบ Custom Proxy / Squid Firewall ในองค์กรที่มีข้อกำหนด Compliance อย่างหนัก (เช่น PCI-DSS) ที่ต้องมีการทำ Deep Packet Inspection (DPI) ขาออก หรือ URL Whitelisting อย่างเข้มงวด โดยพวกเขาจะนำ Open-source เช่น pfSense หรือ Squid proxy มาลงใน EC2 แทน NAT Gateway เพื่อทำการแกะกล่องดูและบันทึก URL ที่พนักงาน/ระบบใน Private พยายามจะเข้าถึง (ซึ่ง Managed NAT Gateway ทำได้แค่ระดับ IP Protocol, ไม่ใช่ระดับ HTTP Domain)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): NAT Instance เป็น Single Point of Failure (SPOF) เต็มรูปแบบ หากเครื่องล่ม ทราฟฟิกของทั้ง Private Subnet จะดับทันที การอัปเดต OS หรือ Patch ท้องถิ่นจะทำให้มี Downtime เกิดขึ้น
* Mitigation (วิธีแก้): ใช้ ASG (Auto Scaling Group) แบบขนาด 1 เครื่อง วางหลัง Network Load Balancer (กรณีใช้งานเป็นไฟร์วอลล์) หรือเขียน Lambda ฟังก์ชันคอยตรวจจับสถานะของ NAT Instance หากพบว่าตาย ให้แก้ไข Route Table สลับไปหา NAT เครื่องสำรองแบบอัตโนมัติ (High Availability Self-healing script)

ทฤษฎีและกลไกการทำงาน (How it works):
ภายใน VPC ของ AWS จะมีเซิร์ฟเวอร์ DNS ภายใน (Internal DNS) ฝังตัวอยู่ลึกๆ และมันมักจะซ่อนตัวอยู่ที่ IP อันดับที่ 2 (.2) ของฐานเครือข่าย VPC ของคุณเสมอ (เช่น หาก VPC คือ 10.0.0.0/16 DNS Resolver จะอยู่ที่ 10.0.0.2 ทันที) บริการนี้รู้จักกันในชื่อ AmazonProvidedDNS หรือ Route 53 Resolver

DNS ภายในนี้ช่วยให้เครื่อง EC2 สามารถหา IP ของเครื่องอื่นได้ผ่านชื่อ Hostname (เช่น ip-10-0-1-5.ec2.internal) โดยไม่ต้องตั้งค่า DNS Server เอง ยิ่งไปกว่านั้น มันทำหน้าที่จัดการ Private Hosted Zones ควบคู่ไปกับ Route 53 ทำให้เราสามารถสร้างชื่อโดเมนเสมือน (เช่น database.pipecraft.internal) แล้ว Resolve กลับมาเป็น Private IP เฉพาะภายในขอบเขต VPC ได้เลย

กลไกนี้เปิดทำงานผ่านแอตทริบิวต์สองตัวใน VPC:
1. enable_dns_support (เปิดการตอบกลับ DNS ภายใน)
2. enable_dns_hostnames (สร้าง Hostname ให้อัตโนมัติเมื่อสร้าง EC2)

# สร้าง Private DNS Zone สำหรับ VPC ภายใน
resource "aws_route53_zone" "private" {
  name = "pipecraft.internal"

  vpc {
    vpc_id = aws_vpc.main_vpc.id
  }
}

# เพิ่ม Record ของ Database ให้ชี้ไปที่ IP ของเซิร์ฟเวอร์
resource "aws_route53_record" "db_record" {
  zone_id = aws_route53_zone.private.zone_id
  name    = "db.pipecraft.internal"
  type    = "A"
  ttl     = "300"
  records = ["10.0.2.145"]
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
โครงสร้างสถาปัตยกรรมระดับองค์กรส่วนใหญ่มักจะใช้โครงสร้าง On-Premises หรือ Data Center ที่มี Active Directory (AD) และ DNS ของตนเอง (เช่น บริษัท corp.enterprise.com) การทำให้ AWS VPC สามารถ "รู้จัก" โดเมนของ On-Premises ได้ และให้ On-Premises "รู้จัก" โดเมนของ AWS ได้ จะต้องทำสถาปัตยกรรมที่เรียกว่า DNS Resolution Hybrid โดยการเปิดใช้งาน Route 53 Resolver Endpoints (แบบ Inbound และ Outbound) เพื่อสร้างการทำ DNS Forwarding หากเครื่องใน AWS ถามหาโดเมน On-Premises มันจะขว้าง Request ลงไปตามท่อ VPN เพื่อไปถาม DNS Server ตัวจริงที่ออฟฟิศ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): Route 53 Resolver ของ AWS (ค่าเริ่มต้นที่ .2) มีข้อจำกัดเรื่องอัตราการร้องขอที่เข้มงวดมาก (Hard limit) คือรองรับได้สูงสุดเพียง 1024 DNS Queries per second per ENI หากระบบของคุณเป็น Microservices ที่ยิง Request จำนวนมหาศาลเพื่อหา IP กันเองตลอดเวลา แพ็กเกจ DNS ถัดไปจะถูกดรอปทันที ส่งผลให้เกิด Application Timeout รุนแรงระดับสุ่มที่แก้ไขยากมาก
* Mitigation (วิธีแก้): ควรแก้ปัญหาตั้งแต่ต้นน้ำด้วยการปรับปรุงระดับแอปพลิเคชัน (Application-level optimization) โดยการฝังตัวทำ DNS Caching แบบฝังในเครื่อง เช่น CoreDNS หรือ dnsmasq เป็น DaemonSet ในระบบ Kubernetes เพื่อรับภาระการร้องขอก่อนที่จะวิ่งลงไปเตะ AWS Resolver ที่ก้นบึ้งของเครือข่าย

ทฤษฎีและกลไกการทำงาน (How it works):
ระบบเครือข่ายที่ดีจะต้องมองเห็นได้ (Observability) VPC Flow Logs เป็นคุณสมบัติที่ช่วยดักจับข้อมูล "เมตาเดตา" ของแพ็กเกจจราจร (Traffic flow) ที่ผ่านเข้า-ออก Network Interfaces (ENI) ภายใน VPC ของเรา ข้อมูลที่ถูกจับไม่ได้รวมเนื้อหาแพ็กเกจ (No payload data) แต่จะจับประวัติ (Log record) อย่างเช่น: Source IP, Destination IP, Protocol, Port, จำนวน Packets/Bytes, และสถานะของ Action (ว่าแพ็กเกจนี้ถูก ACCEPT หรือ REJECT โดย Security Group / NACL)

กลไก Flow Logs จะทำงานอยู่นอกเส้นทางจราจรหลัก (Out-of-band architecture) หมายความว่าการเปิดใช้ VPC Flow Logs จะไม่สร้างภาระ ไม่กินแบนด์วิดท์ และไม่สร้าง Latency ให้กับเครื่องเซิร์ฟเวอร์ของคุณแต่อย่างใด คุณสามารถเลือกเป้าหมายการส่งออก Logs ได้หลายช่องทาง เช่น ส่งเข้า Amazon CloudWatch Logs (เพื่อให้ค้นหาได้ทันทีแบบเรียลไทม์) หรือโยนลง Amazon S3 (เก็บระยะยาวราคาประหยัดสำหรับ Compliance Audit)

# สร้าง S3 Bucket สำหรับเก็บ Logs ระยะยาว
resource "aws_s3_bucket" "vpc_flow_logs_bucket" {
  bucket = "enterprise-vpc-flow-logs-archive"
}

# สร้าง Flow Logs ตรวจจับทุกจราจร ทั้งผ่านและถูกบล็อก
resource "aws_flow_log" "main_vpc_flow_log" {
  log_destination      = aws_s3_bucket.vpc_flow_logs_bucket.arn
  log_destination_type = "s3"
  traffic_type         = "ALL" # เอาทั้ง ACCEPT และ REJECT
  vpc_id               = aws_vpc.main_vpc.id

  # ปรับเป็น custom format เพื่อเพิ่มข้อมูลที่จำเป็น
  log_format = "$${version} $${account-id} $${interface-id} $${srcaddr} $${dstaddr} $${srcport} $${dstport} $${protocol} $${packets} $${bytes} $${start} $${end} $${action} $${log-status} $${vpc-id} $${subnet-id} $${instance-id} $${tcp-flags}"
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในศูนย์ประสานงานความมั่นคงปลอดภัย (Security Operations Center - SOC) หากเกิดเหตุการณ์แจ้งเตือนว่ามีแฮกเกอร์พยายามกวาดล้างพอร์ต (Port Scanning) โจมตีเข้ามา วิศวกรจะเข้าไปเขียนคิวรีด้วย Amazon Athena ค้นหาฐานข้อมูลของ Flow Logs ใน S3 โดยค้นหาฟิลด์ที่มีคำว่า REJECT ในจำนวนมหาศาล เพื่อทำการไล่หา Source IP ของผู้โจมตี และหาว่ามีการพยายามเข้าถึงพอร์ตใดบ้าง จากนั้นสามารถสร้างระบบ Automation (AWS Lambda) ทริกเกอร์หากเจอ IP ที่พยายามถูก REJECT บ่อยเกินไป ให้นำ IP นั้นไปยัดลง Rule 100 ของ Network ACL ทันทีเพื่อแบนล้างถาวร

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): VPC Flow Logs จะหน่วงเวลาในการเขียน (Ingestion delay) โดยปกติจะมีหน้าต่างกว้างถึง 10 นาที (Aggregation interval = 10 minutes) กว่าที่คุณจะเห็น Log ปรากฏบน CloudWatch หากคุณคาดหวังให้เป็นเครื่องมือวิเคราะห์แบบ Real-time ดับไฟทันที คุณจะหลงทาง
* Mitigation (วิธีแก้): สำหรับระบบที่ไวต่อเวลา (Time-sensitive) คุณสามารถตั้งค่าแอตทริบิวต์ max_aggregation_interval ลงเหลือระดับสูงสุดที่ 1 นาที (1 minute interval) แลกกับค่าใช้จ่ายที่อาจสูงขึ้นเล็กน้อย แต่ช่วยให้การแก้ปัญหาแบบ Real-time ใกล้เคียงความเป็นจริงมากขึ้น