เมื่อโปรเจกต์ infrastructure เริ่มขยายใหญ่ ทีมหลายคนต้องแตะ state file ร่วมกัน การใช้ local state ย่อมจบไม่ได้ดี จึงต้องย้ายไปใช้ remote backend ที่ทำหน้าที่เป็นศูนย์กลางเก็บ state file บทความนี้จะเน้นสองตัวเลือกยอดนิยม คือ S3 (บวก DynamoDB lock) สำหรับทีมที่ใช้ AWS เป็นหลัก และ Terraform Cloud ที่เป็นบริการ SaaS ครบเครื่อง

ทั้งสองตัวเลือกให้ versioning, encryption และ concurrent-safe apply ต่างกันที่ความสามารถในการ run plan/apply บน cloud, policy check และ audit log ซึ่ง Cloud edition มีให้ในกล่องเดียว ส่วน S3 ต้องประกอบเองกับ service อื่น

Setup S3 Backend แบบ Production-Ready

การเก็บ state บน S3 มี 4 องค์ประกอบ: bucket สำหรับเก็บไฟล์, DynamoDB table สำหรับ state locking, KMS key สำหรับ encrypt และ IAM policy จำกัด access

# 1. สร้าง S3 bucket + DynamoDB lock table ก่อน (manual หรือแยก config)
# 2. กำหนด backend ใน configuration ของแต่ละ project

terraform {
  backend "s3" {
    bucket         = "mycompany-tfstate-prod"
    key            = "network/vpc/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    kms_key_id     = "alias/tf-state-key"
    dynamodb_table = "tf-state-lock"
  }
}

• Versioning ON ทุก bucket — รองรับการ restore state เก่าถ้าเกิดปัญหา
• Encryption ด้วย KMS key เฉพาะ ไม่ใช่ SSE default เพื่อจำกัด access ด้วย key policy
• Block Public Access — state file ต้องไม่ public อย่างเด็ดขาด
• DynamoDB lock — ใช้ partition key ชื่อ LockID (string) ขนาดเล็ก ไม่เปลือง RCU/WCU
• IAM policy — เฉพาะ role ที่ใช้ apply เท่านั้นมีสิทธิ์ PutObject/DeleteObject บน bucket

Migrate จาก Local ไป S3

# 1. เพิ่ม backend block ใน configuration (ตัวอย่างด้านบน)
# 2. รัน init — จะถาม confirm การย้าย state
$ terraform init -migrate-state

Initializing the backend...
Do you want to copy existing state to the new backend?
  Enter a value: yes

# 3. ตรวจสอบ state ใน S3
$ aws s3 ls s3://mycompany-tfstate-prod/network/vpc/

Setup Terraform Cloud Backend

Cloud edition มี backend เฉพาะชื่อ cloud ใช้แทน S3 ได้ทันที แค่ระบุ organization + workspace โดยไม่ต้องสร้าง infrastructure รองรับเพิ่ม

terraform {
  cloud {
    organization = "mycompany"

    workspaces {
      name = "production-network"
      # หรือใช้ tags สำหรับ dynamic workspace
      # tags = ["production", "network"]
    }
  }
}

หลังรัน terraform login เพื่อ authenticate และ terraform init tool จะเชื่อมกับ workspace ของ Cloud ให้อัตโนมัติ สามารถเลือกรัน plan/apply บน local หรือ remote ได้ผ่านการตั้งค่าของ workspace

S3 vs Cloud เลือกตัวไหน

• S3 + DynamoDB — ฟรี (จ่ายแค่ storage/request), ควบคุมเต็มที่, ต้อง setup encryption/locking/audit เอง เหมาะกับทีมที่ใช้ AWS เป็นหลักและมีมาตรฐาน IaC ภายใน
• Cloud/Enterprise edition — มี UI สำหรับ review plan, policy check (Sentinel/OPA), SSO, audit log พร้อม; remote apply ไม่ต้องใช้เครื่อง dev; มีค่าใช้จ่ายรายเดือน
• Hybrid — ทีมใหญ่บางแห่งใช้ Cloud edition สำหรับ prod workspace เพื่อ policy enforcement และ S3 สำหรับ experiment ของทีม infra

ข้อควรระวัง

• อย่าเก็บ state ของ bootstrap (bucket/lock table เอง) ไว้บน backend ที่กำลังสร้าง — ต้อง bootstrap ด้วย local state แล้ว import เข้า remote
• ตั้ง lifecycle policy บน S3 ให้เก็บ version เก่าแค่ช่วงหนึ่ง (เช่น 30-90 วัน) ป้องกันค่าใช้จ่ายบวม
• Enable CloudTrail/audit logging เพื่อดูว่าใครเข้าถึง state file ตอนไหน
• จำกัด access Cross-account ให้ละเอียด — state มี attribute sensitive ของ resource ทุกตัว

สรุป

S3 backend เป็นทางเลือกแบบ self-managed ที่ยืดหยุ่นและประหยัด เหมาะกับทีมที่คุ้นเคยกับ AWS อยู่แล้ว ส่วน Cloud edition ให้ประสบการณ์แบบ SaaS พร้อม policy และ UI ในตัว เหมาะกับทีมที่ต้องการ governance สูงและไม่อยากดูแล infrastructure ของ state เอง ไม่ว่าจะเลือกแบบไหน encryption, versioning และ lock เป็นสิ่งที่ต้องมีครบเพื่อความปลอดภัยของ state file ในบทความถัดไปจะเจาะลึกเรื่อง state locking และการจัดการ concurrent apply ระหว่างสมาชิกในทีม