Terraform คืออะไร? เจาะลึก IaC สำหรับการจัดการ AWS ระดับองค์กร

การจัดการ Infrastructure ระดับ Enterprise ด้วยวิธีการ Manual หรือ “ClickOps” ผ่านหน้า AWS Console ถือเป็นความเสี่ยงและ Technical Debt ที่ไม่อาจยอมรับได้ในระบบ Production จริง รวมถึงความซับซ้อนของ Microservices, Dynamic Workloads และข้อกำหนดด้าน Security Compliance บังคับให้สถาปัตยกรรมต้องถูกนิยามและควบคุมผ่าน Infrastructure as Code (IaC) เพื่อความถูกต้อง (Consistency) และความสามารถในการขยายตัว (Scalability) ที่ยั่งยืน

บทความนี้จะพาคุณเจาะลึก Terraform เครื่องมือ IaC ระดับโลก ว่าทำไมมันถึงเป็น Standard Choice สำหรับการจัดการ AWS ในระดับ Enterprise เหนือกว่า CloudFormation อย่างไร และ Best Practices ในการวาง Architecture ให้ Scale ได้จริงคืออะไร

Infrastructure as Code (IaC) จุดจบของ Manual Provisioning

spectralops.io/blog/how-does-infrastructure-as-code-on-aws-work

ก่อนจะไปถึง Terraform ต้องเข้าใจบริบทของ IaC ในเชิงลึก IaC ไม่ใช่แค่การเขียนสคริปต์ แต่คือแนวคิด “Immutable Infrastructure” (โครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลงแก้ไข แต่สร้างใหม่แทน)

IaC เปลี่ยนการจัดการ Server, Network และ Database ให้กลายเป็น Code (Configuration Files) ซึ่งทำให้เราสามารถนำหลักการของ Software Engineering มาใช้กับ Infrastructure ได้ เช่น:

• Version Control (Git): ตรวจสอบประวัติการแก้ไขได้ทุกบรรทัด (Audit Trail)
• Code Review: ตรวจสอบความถูกต้องก่อน Deploy จริง
• CI/CD Integration: Automate การ Deploy infrastructure ผสานกับ Application Code

Terraform คืออะไร? ทำไมต้อง Declarative?

aws.amazon.com/blogs/mt/aws-organizations-aws-config-and-terraform

Terraform คือ Open-source tool จาก HashiCorp ที่ใช้ภาษา HCL (HashiCorp Configuration Language) ในการนิยาม Infrastructure

จุดเด่นเชิงเทคนิคที่ทำให้ Terraform ชนะใจวิศวกรทั่วโลกคือรูปแบบภาษาที่เป็น Declarative (เชิงประกาศ)

• Imperative (เช่น Shell Script, Ansible): คุณต้องบอก ขั้นตอน การทำงานทีละขั้น (Step-by-step) ว่า “จงสร้าง VM -> จงติดตั้ง Docker -> จงเปิด Port” หากรันซ้ำอาจเกิด Error หรือ Duplicate Resource
• Declarative (Terraform): คุณบอก ผลลัพธ์สุดท้าย (Desired State) ที่ต้องการ เช่น “ฉันต้องการ EC2 3 instances และ Security Group ที่เปิด Port 80”
  • Terraform มีหน้าที่คำนวณ (Compute) ว่า State ปัจจุบันเป็นอย่างไร และต้องทำอะไรเพิ่มเพื่อไปถึงจุดนั้น (Idempotency)

Terraform vs. AWS CloudFormation ทำไม Enterprise เลือก Terraform?

แม้ AWS จะมี CloudFormation (CFN) แต่ Terraform มักเป็นตัวเลือกอันดับ 1 ในระดับ Enterprise ด้วยเหตุผลเชิงกลยุทธ์:

1. Vendor Agnostic (Multi-Cloud Strategy): องค์กรขนาดใหญ่มักไม่ได้ใช้แค่ AWS แต่ยังอาจมี On-premise (VMware), Cloudflare, หรือ Azure ใน Stack เดียวกัน Terraform สามารถจัดการทุกอย่างได้ใน Code ชุดเดียวผ่าน Providers ที่มีให้เลือกนับพัน
2. State Management ที่เหนือกว่า: Terraform เก็บ State ไว้ในไฟล์ (terraform.tfstate) ทำให้เราเห็นภาพรวมของ Infrastructure จริงเทียบกับ Code ได้ชัดเจนกว่า Stack ของ CFN
3. HCL Readability: ภาษา HCL ถูกออกแบบมาให้อ่านง่ายกว่า JSON/YAML ของ CloudFormation มาก ทำให้ Maintain ง่ายในระยะยาว

เจาะลึก Architecture Terraform บน AWS ระดับ Production

การใช้ Terraform เล่นๆ บนเครื่องส่วนตัวกับการใช้ใน Production ขององค์กรนั้นต่างกันอย่างสิ้นเชิง นี่คือ Technical Components ที่ “ต้องมี” สำหรับ Enterprise Grade:

1. Remote State Management & Locking

aws.plainenglish.io/terraform-state-management-strategies-for-collaboration-and-security-cde3ec1da7bf

ปัญหา: หากทีม DevOps หลายคนรัน terraform apply พร้อมกัน State File อาจพัง (Corrupt) หรือเกิด Race Condition ทางแก้ (Best Practice):

• Storage: เก็บ State File บน AWS S3 (เปิด Versioning เพื่อ Rollback ได้)
• Locking: ใช้ AWS DynamoDB Table เพื่อทำ State Locking ป้องกันการรันซ้ำซ้อน หากมีใครกำลัง Deploy ระบบจะ Lock ไม่ให้คนอื่นแก้จนกว่าจะเสร็จ

2. Modular Architecture (DRY Principle)

blog.devops.dev/terraform-modules-46ef5e0963c3

อย่าเขียน Code ทั้งหมดในไฟล์ main.tf ไฟล์เดียว แต่ควรแยกเป็น Modules เพื่อลดความซ้ำซ้อน (Don’t Repeat Yourself)

• Root Module: เรียกใช้ Module ย่อย และกำหนดตัวแปรเฉพาะของ Environment (Dev, Staging, Prod)
• Child Modules: แยกตาม Resource Type เช่น VPC Module, EKS Module, RDS Module ที่เขียนให้ Reusable และรับ Input Variables ได้หลากหลาย

3. Terraform Workspaces & Environments

medium.com/@achanandhi.m/why-do-we-need-terraform-workspaces-35d9959eee77

การแยก Environment (Dev/Prod) ทำได้สองวิธีหลัก:

• Directory Structure (แนะนำสำหรับ Enterprise): แยก Folder ชัดเจน /env/prod และ /env/dev เพื่อความปลอดภัยสูงสุด (Isolation)
• Workspaces: ใช้ Code ชุดเดียวกันแต่สลับ State File (เหมาะสำหรับ environments ที่เหมือนกันเป๊ะๆ แต่ไม่แนะนำสำหรับ Prod vs Non-Prod ที่ต้องการ Access Control แยกขาดจากกัน)

ตัวอย่าง HCL Code และการสร้าง AWS EC2 แบบ Best Practice

ตัวอย่างการเขียนแบบ Declarative โดยใช้ Data Source เพื่อดึง AMI ล่าสุดอัตโนมัติ (ไม่ต้อง Hard code ID)

provider "aws" {
  region = "ap-southeast-1"
}
# 1. ค้นหา AMI Ubuntu ล่าสุด (Dynamic Query)
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}
# 2. สร้าง EC2 Instance
resource "aws_instance" "app_server" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  
  # การใช้ Tags สำคัญมากสำหรับ Cost Allocation ในองค์กร
  tags = {
    Name        = "Enterprise-App-Server"
    Environment = "Production"
    CostCenter  = "IT-Ops-01"
  }
}

อธิบาย Code

1. การกำหนดขอบเขต (Scope)

provider "aws" {
  region = "ap-southeast-1"
}

หน้าที่: บอก Terraform ว่าเรากำลังจะคุยกับ Cloud Provider เจ้าไหน (ในที่นี้คือ AWS) และเจาะจง Region ไปที่ ap-southeast-1 (Singapore)

โดยในระดับ Enterprise เรามักจะไม่ Hardcode region ไว้ตรงนี้ตรงๆ เสมอไป แต่จะใช้ Variables (เช่น var.aws_region) เพื่อให้โค้ดชุดเดียวกันสามารถ Deploy ไปยัง Region อื่นได้ (Reusability) โดยไม่ต้องแก้โค้ด

อ่านเพิ่มเติม : รีวิว AWS EC2 Instance Types เลือกขนาด Server อย่างไรให้คุ้มค่า

2. การดึงข้อมูลแบบ Dynamic

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

หน้าที่: นี่คือหัวใจสำคัญของการเขียนแบบ Dynamic แทนที่เราจะระบุ AMI ID ลงไปตรงๆ (เช่น ami-012345...) ซึ่ง AMI ID จะเปลี่ยนไปตาม Region และเวลา เราใช้ data block สั่งให้ Terraform “ไปค้นหามาให้หน่อย”

• most_recent = true: สั่งให้เลือก Image เวอร์ชั่นล่าสุดเสมอ ช่วยให้เราได้ Security Patch ล่าสุดโดยอัตโนมัติเมื่อ Deploy ใหม่
• owners: ระบุ Account ID ของเจ้าของ Image เพื่อความปลอดภัย (ในที่นี้คือ Canonical เจ้าของ Ubuntu) ป้องกันการดึง Image ปลอมจาก Hacker
• filter: กรองชื่อ Image โดยใช้ Wildcard (*) เพื่อหาเวอร์ชันย่อยล่าสุดของ Ubuntu 20.04

Why Best Practice?: การ Hardcode AMI ID คือ Anti-pattern เพราะทำให้โค้ดพังทันทีเมื่อย้าย Region หรือเมื่อ AMI นั้นเก่าเกินไปจนถูก AWS ลบ

3. การสร้าง Infrastructure

resource "aws_instance" "app_server" {
  ami           = data.aws_ami.ubuntu.id  # <--- จุดเชื่อมโยงข้อมูล
  instance_type = "t3.medium"
  
  tags = {
    Name        = "Enterprise-App-Server"
    Environment = "Production"
    CostCenter  = "IT-Ops-01"
  }
}

หน้าที่: สั่ง Provision EC2 Instance ขึ้นมาจริงๆ

• ami = data.aws_ami.ubuntu.id: นี่คือการอ้างอิง (Reference) ข้อมูลจาก Data Block ด้านบน Terraform จะสร้าง Dependency Graph และรู้ว่าต้องไปค้นหา AMI ก่อน ถึงจะมาสร้าง EC2 ได้
• tags: ส่วนนี้สำคัญมากในระดับองค์กร
  • Environment: เพื่อแยกแยะ Resource ของ Prod vs Dev ป้องกันการลบผิด
  • CostCenter: เพื่อทำ FinOps หรือ Cost Allocation ให้ฝ่ายบัญชีรู้ว่าค่า Server นี้ต้องไปเก็บเงินที่แผนกไหน (IT-Ops-01)

Why Best Practice?: ทรัพยากร (Resource) ที่ไม่มี Tag ในองค์กรใหญ่ถือเป็น “Zombie Resource” ที่ตรวจสอบไม่ได้ การบังคับใส่ Tags ใน Code คือมาตรฐานที่ Cloud Architect ต้องวางไว้

ก้าวต่อไปสู่ Cloud Automation

การเปลี่ยนผ่านจาก Traditional Ops สู่ Infrastructure as Code (IaC) ด้วย Terraform นั้น แม้จะเต็มไปด้วยข้อดี แต่ก็มาพร้อมกับ Learning Curve และความซับซ้อนในการออกแบบ Architecture ให้รองรับ Scale ระดับ Enterprise ทั้งเรื่อง Security, State Management และ Governance

หากองค์กรของคุณกำลังมองหาพาร์ทเนอร์ที่ไม่ได้เป็นเพียงผู้ติดตั้งระบบ แต่เป็น Strategic Advisor ที่ช่วยวางรากฐาน Cloud Infrastructure ให้ถูกต้องตามหลัก Best Practices ตั้งแต่วันแรก

Tangerine พร้อมนำประสบการณ์และความเชี่ยวชาญด้าน Cloud Solutions และ DevSecOps เข้ามาช่วยคุณวิเคราะห์ ออกแบบ และวางระบบ Automation Pipeline เพื่อให้การจัดการ AWS ของคุณมีความปลอดภัย ยืดหยุ่น และพร้อมสำหรับการแข่งขันในยุค Digital อย่างแท้จริง

ปรึกษาผู้เชี่ยวชาญจาก Tangerine เพื่อยกระดับ Cloud Infrastructure ของคุณ คลิกเพื่อติดต่อเรา