Terraform Cloud คืออะไร? จัดการ Infrastructure ด้วย Remote State และ Team Collaboration 2026

Terraform Cloud คืออะไร? ทำไมถึงเป็นมาตรฐานสำหรับ Infrastructure as Code ในปี 2026

Terraform Cloud เป็นบริการ SaaS ที่พัฒนาโดย HashiCorp ออกแบบมาเพื่อช่วยทีมจัดการ Infrastructure as Code (IaC) อย่างมีประสิทธิภาพ โดยให้ความสามารถในการเก็บ remote state จัดการ workspaces ทำงานร่วมกันเป็นทีม และเชื่อมต่อกับ version control systems อย่างราบรื่น ในยุคที่ cloud infrastructure มีความซับซ้อนมากขึ้นเรื่อยๆ การจัดการ infrastructure ด้วยมือไม่ใช่ทางเลือกที่เหมาะสมอีกต่อไป Terraform Cloud ช่วยแก้ปัญหาเหล่านี้โดยให้ platform ที่ครบวงจรสำหรับการบริหาร infrastructure

ในปี 2026 Terraform Cloud ได้กลายเป็นเครื่องมือมาตรฐานขององค์กรจำนวนมากทั่วโลก ไม่ว่าจะเป็น startup ขนาดเล็กไปจนถึง enterprise ขนาดใหญ่ เพราะมันช่วยแก้ปัญหาหลักๆ ที่ทีม infrastructure เผชิญ ตั้งแต่ state file conflict ไปจนถึงการควบคุม policy และ cost estimation ก่อน deploy จริง

บทความนี้จะพาคุณเข้าใจ Terraform Cloud ตั้งแต่พื้นฐานจนถึงการใช้งานขั้นสูง ครอบคลุมทุกฟีเจอร์สำคัญที่จำเป็นในการจัดการ infrastructure สมัยใหม่ เปรียบเทียบกับ Terraform CLI แบบ local รวมถึง best practices สำหรับทีมที่ต้องการ migrate จาก local workflow มาใช้ Terraform Cloud ในปี 2026

Terraform Cloud vs Terraform CLI: ความแตกต่างที่สำคัญ

ก่อนจะเจาะลึก Terraform Cloud ต้องเข้าใจความแตกต่างระหว่าง Terraform CLI (open source) กับ Terraform Cloud เสียก่อน เพราะหลายคนอาจสับสนว่าทั้งสองอย่างนี้ต่างกันอย่างไร

Terraform CLI (Open Source)

Terraform CLI เป็นเครื่องมือ command-line ที่ทุกคนสามารถ download มาใช้ได้ฟรี ทำงานบนเครื่อง local ของผู้ใช้ เขียน HCL configuration แล้วรัน terraform plan และ terraform apply เพื่อสร้างหรือแก้ไข infrastructure โดย state file จะถูกเก็บไว้ local ใน terraform.tfstate ซึ่งเป็นไฟล์ JSON ที่เก็บสถานะปัจจุบันของ infrastructure ทั้งหมด

ปัญหาหลักของการใช้ Terraform CLI แบบ local คือเมื่อทำงานเป็นทีม state file ไม่สามารถแชร์ได้อย่างปลอดภัย หากคนสองคนรัน terraform apply พร้อมกัน state file อาจเกิด conflict หรือเสียหาย นอกจากนี้ยังไม่มี access control ทุกคนที่เข้าถึง state file สามารถเห็นข้อมูลสำคัญเช่น database passwords หรือ API keys ที่เก็บอยู่ใน state

Terraform Cloud

Terraform Cloud แก้ปัญหาทุกอย่างที่ CLI มีด้วยการย้าย state management ขึ้น cloud ให้ state locking อัตโนมัติ มี role-based access control มี run environment ที่ปลอดภัย และให้ความสามารถเพิ่มเติมอีกมากมาย เปรียบเสมือนการ upgrade จากการเขียนโปรแกรมบนเครื่อง local ไปเป็นการใช้ CI/CD pipeline ที่มีทุกอย่างครบวงจร

ความแตกต่างหลักสามารถสรุปได้ดังนี้ ในด้าน state management Terraform CLI เก็บ state ไว้ local หรือต้อง configure remote backend เอง ขณะที่ Terraform Cloud จัดการ remote state ให้อัตโนมัติพร้อม encryption และ versioning ในด้าน collaboration CLI ไม่มี built-in collaboration ต้องใช้ shared storage เอง แต่ Cloud มี team management, RBAC, workspace sharing ในตัว ในด้าน execution CLI รันบนเครื่อง local ต้องมี credentials ทุกอย่างบนเครื่อง แต่ Cloud รันบน remote runners ที่ปลอดภัย credentials เก็บใน variables ที่ encrypted

Remote State Management: หัวใจของ Terraform Cloud

Remote state management เป็นฟีเจอร์หลักที่ทำให้ Terraform Cloud มีค่ามหาศาลสำหรับทีม state file ใน Terraform เก็บข้อมูลสำคัญทั้งหมดเกี่ยวกับ infrastructure ที่ถูก provision ไว้ หากสูญหายหรือเสียหาย Terraform จะไม่รู้ว่ามี resources อะไรอยู่บ้าง และอาจสร้าง resources ซ้ำซ้อน

State Locking

เมื่อใช้ Terraform Cloud ทุกครั้งที่มีคนรัน terraform plan หรือ terraform apply ระบบจะทำ state lock อัตโนมัติ หมายความว่าในขณะที่ run กำลังทำงาน จะไม่มีใครสามารถแก้ไข state ได้ ป้องกัน race condition ที่จะทำให้ state เสียหาย สิ่งนี้ต่างจากการใช้ local state ที่ไม่มี locking mechanism หรือการใช้ S3 backend ที่ต้อง configure DynamoDB สำหรับ locking เอง

State Versioning

Terraform Cloud เก็บ version ของ state file ทุกครั้งที่มีการเปลี่ยนแปลง ทำให้สามารถย้อนกลับไปยัง state version ก่อนหน้าได้หากมีปัญหา เช่น หากทำ terraform apply แล้วพบว่ามีปัญหา สามารถ rollback state ไปยัง version ก่อนหน้าได้ทันที ซึ่งเป็นฟีเจอร์ที่ช่วยชีวิตได้จริงในสถานการณ์ฉุกเฉิน

State Encryption

State file มักมีข้อมูลที่อ่อนไหว เช่น database passwords, API keys, และ connection strings Terraform Cloud เข้ารหัส state file ทั้ง at rest และ in transit ด้วย AES-256 encryption ทำให้มั่นใจได้ว่าข้อมูลจะไม่ถูกเข้าถึงโดยไม่ได้รับอนุญาต นอกจากนี้ยังมีการควบคุมว่าใครสามารถเข้าถึง state ได้ผ่าน RBAC ในระดับ workspace

Remote State Data Source

สำหรับโปรเจคขนาดใหญ่ที่แบ่ง infrastructure ออกเป็นหลาย workspaces สามารถใช้ remote state data source เพื่อเข้าถึงข้อมูลจาก workspace อื่นได้ ตัวอย่างเช่น workspace ที่ดูแล VPC สามารถ output subnet IDs ให้ workspace ที่ดูแล EC2 instances ใช้ได้ โดยไม่ต้อง hardcode ค่าใดๆ

# ตัวอย่าง data source สำหรับ remote state
data "terraform_remote_state" "vpc" {
  backend = "remote"
  config = {
    organization = "my-org"
    workspaces = {
      name = "networking-prod"
    }
  }
}

# ใช้ output จาก workspace อื่น
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  subnet_id     = data.terraform_remote_state.vpc.outputs.public_subnet_id
}

Workspaces: การจัดการ Environment Dev/Staging/Prod

Workspaces เป็นหน่วยพื้นฐานของ Terraform Cloud ที่ช่วยแยก infrastructure ออกเป็นส่วนๆ ตามสิ่งที่ต้องการจัดการ ซึ่งต่างจาก Terraform CLI workspaces ที่แค่แยก state file ออกจากกัน Terraform Cloud workspaces มีความสามารถมากกว่ามาก

โครงสร้าง Workspace

แต่ละ workspace ใน Terraform Cloud ประกอบด้วย Terraform configuration (เชื่อมกับ VCS repo), Variables (input variables และ environment variables), State file (ที่ถูก managed อัตโนมัติ), Run history (ประวัติการ plan และ apply ทั้งหมด), Team access (สิทธิ์ของแต่ละทีม) และ Settings ต่างๆ เช่น Terraform version, auto-apply, notification settings

การแบ่ง Workspace ตาม Environment

วิธีที่นิยมที่สุดคือการแบ่ง workspace ตาม environment โดยสร้าง workspace แยกสำหรับ dev, staging, และ production ตัวอย่างเช่น workspace ชื่อ app-dev, app-staging, app-prod ทั้งสามใช้ Terraform configuration เดียวกันจาก repository เดียวกัน แต่ใช้ variables ที่แตกต่างกัน เช่น instance size ใน dev อาจเป็น t3.micro ขณะที่ production เป็น t3.xlarge

# variables.tf - ใช้ร่วมกันทุก workspace
variable "environment" {
  description = "Environment name (dev/staging/prod)"
  type        = string
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "min_instances" {
  description = "Minimum number of instances in ASG"
  type        = number
  default     = 1
}

# main.tf - instance config ปรับตาม environment
resource "aws_autoscaling_group" "app" {
  name                = "${var.environment}-app-asg"
  min_size            = var.min_instances
  max_size            = var.min_instances * 3
  desired_capacity    = var.min_instances
  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }
}

การแบ่ง Workspace ตาม Component

นอกจากแบ่งตาม environment แล้ว ยังนิยมแบ่งตาม infrastructure component เช่น networking, database, application, monitoring แต่ละ component มี lifecycle ที่แตกต่างกัน networking อาจเปลี่ยนแปลงน้อยมาก ขณะที่ application tier อาจ deploy บ่อยครั้ง การแยก workspace ช่วยลด blast radius หากเกิดข้อผิดพลาด เช่น การแก้ไข application tier จะไม่มีทางกระทบ networking layer

ตัวอย่างโครงสร้าง workspace ที่ดีสำหรับองค์กรขนาดกลาง อาจมี workspace networking-prod สำหรับ VPC, subnets, route tables, database-prod สำหรับ RDS, ElastiCache, app-prod สำหรับ EC2, ALB, Auto Scaling Group, monitoring-prod สำหรับ CloudWatch, SNS, Lambda สำหรับ alerting

VCS Integration: เชื่อมต่อกับ GitHub/GitLab

VCS (Version Control System) integration เป็นหนึ่งในฟีเจอร์ที่ทรงพลังที่สุดของ Terraform Cloud ช่วยให้ทีมจัดการ infrastructure ผ่าน Git workflow ที่คุ้นเคย ทำให้ infrastructure changes ผ่านกระบวนการ code review เหมือนกับ application code

การเชื่อมต่อกับ VCS Provider

Terraform Cloud รองรับ VCS providers หลักๆ ทั้งหมด ได้แก่ GitHub (รวม GitHub Enterprise), GitLab (รวม self-hosted), Bitbucket Cloud และ Server, Azure DevOps Services และ Server การเชื่อมต่อทำผ่าน OAuth application ที่สร้างใน VCS provider แล้ว configure ใน Terraform Cloud เมื่อเชื่อมต่อแล้ว workspace สามารถ link กับ repository ที่เก็บ Terraform configuration ได้

VCS-Driven Workflow

เมื่อ workspace เชื่อมกับ VCS repository Terraform Cloud จะทำงานอัตโนมัติตาม Git events เมื่อมี push ไปยัง branch ที่กำหนด (เช่น main) Terraform Cloud จะ trigger run อัตโนมัติ เริ่มจาก plan แล้วรอ approval (หรือ auto-apply หากเปิดไว้) เมื่อมี pull request Terraform Cloud จะทำ speculative plan โดยอัตโนมัติ แสดงผลลัพธ์เป็น comment ใน PR ให้ reviewer เห็น

Speculative Plans on Pull Requests

Speculative plans เป็นฟีเจอร์ที่ช่วยให้ทีมตรวจสอบ infrastructure changes ก่อน merge อย่างมีประสิทธิภาพ เมื่อเปิด PR ที่แก้ไข Terraform configuration Terraform Cloud จะรัน plan อัตโนมัติ แล้วแสดงผลลัพธ์เป็น check status ใน PR ผู้ review สามารถเห็นว่า PR นี้จะสร้าง เปลี่ยนแปลง หรือลบ resources อะไรบ้าง โดยไม่ต้องรัน plan บนเครื่อง local

speculative plan จะไม่สามารถ apply ได้ เป็นเพียง plan เพื่อให้เห็นว่าจะเกิดอะไรขึ้นเท่านั้น ทำให้ปลอดภัยที่จะรันกับทุก PR โดยไม่มีความเสี่ยงต่อ infrastructure จริง ฟีเจอร์นี้ช่วยลดข้อผิดพลาดได้อย่างมาก เพราะทีมสามารถ review infrastructure changes เหมือน review code ปกติ

Sentinel Policies: Governance as Code

Sentinel เป็น policy-as-code framework ที่ HashiCorp พัฒนาขึ้นเพื่อให้องค์กรสามารถกำหนดกฎเกณฑ์และบังคับใช้กับ Terraform runs ได้ ช่วยให้ security team และ platform team สามารถกำหนด guardrails โดยไม่ต้องเป็น bottleneck ในกระบวนการ deployment

ประเภทของ Sentinel Policies

Sentinel policies แบ่งเป็น 3 ระดับความเข้มงวด ระดับ advisory จะแจ้งเตือนเมื่อ policy ถูกละเมิด แต่ไม่บล็อก run ผู้ใช้สามารถเลือกดำเนินการต่อได้ ระดับ soft-mandatory จะบล็อก run เมื่อ policy ถูกละเมิด แต่ผู้ที่มีสิทธิ์ override สามารถอนุมัติให้ผ่านได้ ระดับ hard-mandatory จะบล็อก run อย่างเด็ดขาด ไม่มีใครสามารถ override ได้ เหมาะสำหรับ policy ที่สำคัญมาก เช่น ห้ามสร้าง public S3 bucket

ตัวอย่าง Sentinel Policy

# ห้ามสร้าง EC2 instance ที่ใหญ่กว่า t3.xlarge ใน dev environment
import "tfplan/v2" as tfplan

allowed_types = ["t3.micro", "t3.small", "t3.medium", "t3.large", "t3.xlarge"]

main = rule {
  all tfplan.resource_changes as _, rc {
    rc.type is "aws_instance" and
    rc.change.after.instance_type in allowed_types
  }
}

# ทุก resource ต้องมี tag "Environment" และ "Owner"
import "tfplan/v2" as tfplan

mandatory_tags = ["Environment", "Owner", "CostCenter"]

main = rule {
  all tfplan.resource_changes as _, rc {
    all mandatory_tags as tag {
      rc.change.after.tags contains tag
    }
  }
}

Sentinel policies ช่วยให้องค์กรบังคับใช้มาตรฐานได้ทั่วทั้งองค์กร เช่น ทุก resource ต้องมี tags ที่กำหนด, ห้ามสร้าง public resources, ต้อง encrypt ทุก storage, ห้ามใช้ instance type ที่ใหญ่เกินไปใน non-production environment เป็นต้น

Cost Estimation: ประมาณค่าใช้จ่ายก่อน Deploy

Terraform Cloud มีฟีเจอร์ cost estimation ที่ช่วยประมาณค่าใช้จ่ายของ infrastructure ที่กำลังจะ provision ก่อนที่จะ apply จริง ทำให้ทีมสามารถตัดสินใจอย่างมีข้อมูลว่า changes นี้จะกระทบค่าใช้จ่ายอย่างไร

cost estimation จะแสดงในขั้นตอนหลัง plan สำเร็จ โดยแสดงค่าใช้จ่ายรายเดือนโดยประมาณ ทั้งค่าใช้จ่ายปัจจุบันและค่าใช้จ่ายหลังจาก apply changes ทำให้เห็นชัดเจนว่า changes นี้จะเพิ่มหรือลดค่าใช้จ่ายเท่าไร

ยิ่งไปกว่านั้น สามารถใช้ Sentinel policies ร่วมกับ cost estimation เพื่อบล็อก runs ที่จะเพิ่มค่าใช้จ่ายเกินกว่าที่กำหนด เช่น กำหนดว่า dev environment ไม่สามารถมีค่าใช้จ่ายเกิน $500 ต่อเดือน หรือการ apply ครั้งเดียวไม่สามารถเพิ่มค่าใช้จ่ายเกิน $100 ต่อเดือน

# Sentinel policy: จำกัด cost increase ต่อ run
import "tfrun" as tfrun

max_monthly_increase = 200

main = rule {
  tfrun.cost_estimate.delta_monthly_cost <= max_monthly_increase
}

Private Registry: แชร์ Modules ภายในองค์กร

Terraform Cloud มี private registry ที่ช่วยให้ทีมสามารถสร้าง แชร์ และจัดการ Terraform modules ภายในองค์กรได้ เปรียบเสมือน npm registry แต่สำหรับ Terraform modules ช่วยส่งเสริม code reuse และมาตรฐานในการสร้าง infrastructure

การสร้าง Module ใน Private Registry

Module ใน private registry ต้องอยู่ใน repository แยกต่างหากตาม naming convention ที่กำหนด คือ terraform-PROVIDER-NAME เช่น terraform-aws-vpc หรือ terraform-azurerm-webapp โครงสร้างของ module ต้องมี main.tf, variables.tf, outputs.tf และ README.md เป็นอย่างน้อย

เมื่อ publish module แล้ว ทุกทีมในองค์กรสามารถใช้ module นี้ได้โดยอ้างอิงจาก private registry ทำให้มั่นใจว่า infrastructure ที่สร้างขึ้นทุกทีมใช้มาตรฐานเดียวกัน เช่น VPC ทุกตัวมี subnet layout แบบเดียวกัน, security groups มี rules ที่ได้มาตรฐาน, RDS instances มี backup และ encryption ตาม policy

# การใช้ module จาก private registry
module "vpc" {
  source  = "app.terraform.io/my-org/vpc/aws"
  version = "~> 3.0"

  environment     = var.environment
  cidr_block      = "10.0.0.0/16"
  azs             = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = var.environment == "prod" ? true : false
  tags               = local.common_tags
}

Module Versioning

private registry รองรับ semantic versioning (semver) ทำให้ทีมสามารถ pin version ของ module ที่ใช้ได้ เช่น version = "~> 3.0" จะใช้ version 3.x.x ล่าสุด แต่ไม่ upgrade ไปเป็น 4.0 อัตโนมัติ สิ่งนี้ช่วยป้องกัน breaking changes และทำให้ infrastructure มีเสถียรภาพ

Team Management และ RBAC

Terraform Cloud มีระบบ team management ที่ช่วยจัดการสิทธิ์การเข้าถึงอย่างละเอียด ด้วย Role-Based Access Control (RBAC) ที่สามารถกำหนดสิทธิ์ในระดับ organization, workspace, และ project

Organization Level Permissions

ในระดับ organization สามารถกำหนดสิทธิ์ได้หลายระดับ ตั้งแต่ Owner ที่มีสิทธิ์เต็มทุกอย่างรวมถึงการจัดการ billing และ settings ไปจนถึง Member ที่สามารถเข้าถึงเฉพาะ workspaces ที่ได้รับอนุญาต

Workspace Level Permissions

ในระดับ workspace มีสิทธิ์ที่ละเอียดกว่า ได้แก่ Read ที่สามารถดู state และ run history ได้อย่างเดียว เหมาะสำหรับ auditors หรือ junior developers, Plan ที่สามารถ trigger plan ได้แต่ไม่สามารถ apply เหมาะสำหรับ developers ที่ต้องการทดสอบ changes, Write ที่สามารถ trigger plan และ apply ได้ เหมาะสำหรับ senior engineers หรือ team leads, Admin ที่สามารถจัดการ workspace settings, variables, team access ทุกอย่าง

ตัวอย่างการจัดทีมที่ดี ทีม Platform Engineering มีสิทธิ์ Admin ในทุก workspace ทีม Development มีสิทธิ์ Write ใน dev workspaces แต่เป็น Plan ใน staging และ Read ใน prod ทีม Security มีสิทธิ์ Read ในทุก workspace เพื่อ audit ฝ่าย Management มีสิทธิ์ Read เฉพาะ workspace ที่ต้องการ monitor

Variable Management

Terraform Cloud ให้จัดการ variables ในระดับ workspace โดยแบ่งเป็น Terraform variables (ค่าที่ส่งให้ Terraform configuration เช่น instance_type, environment) และ Environment variables (ค่าที่ตั้งใน shell environment เช่น AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) Variables สามารถกำหนดเป็น sensitive ได้ ซึ่งจะถูก encrypted และไม่แสดงค่าใน UI หรือ API

API-Driven Workflows: ควบคุม Terraform Cloud ผ่าน API

Terraform Cloud มี REST API ที่ครบถ้วนสำหรับทุกการทำงาน ทำให้สามารถ integrate กับเครื่องมือและกระบวนการอื่นๆ ได้อย่างยืดหยุ่น API-driven workflow เหมาะสำหรับทีมที่ต้องการ customize กระบวนการ deployment มากกว่าที่ VCS-driven workflow ให้ได้

ตัวอย่างการใช้ API

# สร้าง run ใหม่ผ่าน API
curl --request POST   --header "Authorization: Bearer $TFC_TOKEN"   --header "Content-Type: application/vnd.api+json"   --data '{
    "data": {
      "type": "runs",
      "attributes": {
        "message": "Deploy via API",
        "auto-apply": false
      },
      "relationships": {
        "workspace": {
          "data": {
            "type": "workspaces",
            "id": "ws-abc123"
          }
        }
      }
    }
  }'   https://app.terraform.io/api/v2/runs

# ดู run status
curl --request GET   --header "Authorization: Bearer $TFC_TOKEN"   https://app.terraform.io/api/v2/runs/run-xyz789

API-driven workflow ช่วยให้สร้าง custom automation ได้ เช่น trigger infrastructure deployment จาก ChatOps (Slack bot), สร้าง self-service portal ที่ non-technical users สามารถ request infrastructure ได้, integrate กับ incident management tools เพื่อ auto-scale infrastructure เมื่อเกิด incident หรือสร้าง custom approval workflows ที่ซับซ้อน

Terraform Cloud Agents: การเข้าถึง Private Network

Terraform Cloud Agents เป็นฟีเจอร์ที่ช่วยให้ Terraform Cloud สามารถ provision infrastructure ใน private network ที่ไม่สามารถเข้าถึงจาก internet ได้ เช่น on-premises datacenter หรือ private cloud ที่อยู่หลัง firewall

วิธีการทำงาน

Agent เป็น lightweight process ที่รันบนเครื่องภายใน private network ของคุณ agent จะเชื่อมต่อ outbound ไปยัง Terraform Cloud ผ่าน HTTPS ไม่ต้องเปิด inbound port ใดๆ บน firewall เมื่อ Terraform Cloud ต้องการรัน plan หรือ apply สำหรับ workspace ที่กำหนดให้ใช้ agent จะส่งงานไปยัง agent ที่เชื่อมต่ออยู่ agent จะทำ plan หรือ apply บนเครื่องของตัวเอง ซึ่งสามารถเข้าถึง private resources ได้ แล้วส่งผลลัพธ์กลับไปยัง Terraform Cloud

การใช้ agents เหมาะสำหรับสถานการณ์ที่ต้อง provision VMware vSphere VMs ใน datacenter, จัดการ network devices ที่อยู่ใน private network, deploy applications บน Kubernetes cluster ที่อยู่หลัง firewall, จัดการ database instances ที่ไม่ได้ expose ออก internet

Agent Pool Configuration

# ติดตั้ง Terraform Cloud Agent บน Linux
# Download agent
curl -o tfc-agent.zip https://releases.hashicorp.com/tfc-agent/1.15.0/tfc-agent_1.15.0_linux_amd64.zip
unzip tfc-agent.zip -d /opt/tfc-agent

# สร้าง systemd service
cat > /etc/systemd/system/tfc-agent.service << EOF
[Unit]
Description=Terraform Cloud Agent
After=network.target

[Service]
Type=simple
User=tfc-agent
Environment="TFC_AGENT_TOKEN=your-agent-token"
Environment="TFC_AGENT_NAME=datacenter-agent-01"
ExecStart=/opt/tfc-agent/tfc-agent
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now tfc-agent

Terraform Cloud vs Terraform Enterprise

HashiCorp เสนอ Terraform ในรูปแบบ managed service สองแบบ คือ Terraform Cloud (SaaS) และ Terraform Enterprise (self-hosted) ทั้งสองมีฟีเจอร์คล้ายกัน แต่เหมาะกับสถานการณ์ที่ต่างกัน

Terraform Cloud

เป็น SaaS ที่ HashiCorp ดูแลทุกอย่าง ไม่ต้องจัดการ infrastructure สำหรับตัว platform เอง เหมาะสำหรับทีมส่วนใหญ่ที่ต้องการเริ่มใช้งานอย่างรวดเร็ว มี free tier ที่ให้ใช้ได้ฟรีสำหรับทีมขนาดเล็ก ข้อดีคือไม่มี maintenance overhead เริ่มใช้งานได้ทันที อัปเดตฟีเจอร์ใหม่เร็ว ข้อเสียคือ data อยู่บน HashiCorp cloud อาจไม่เหมาะสำหรับองค์กรที่มี data sovereignty requirements

Terraform Enterprise

เป็นเวอร์ชัน self-hosted ที่ติดตั้งบน infrastructure ของตัวเอง เหมาะสำหรับองค์กรที่ต้องการ full control มี compliance requirements ที่เข้มงวด หรือต้องการ air-gapped environment ข้อดีคือ data อยู่ใน infrastructure ของตัวเอง customize ได้มากกว่า เหมาะสำหรับ regulated industries ข้อเสียคือต้อง maintain infrastructure เอง ต้องการ team ที่มี expertise ในการดูแล ค่าใช้จ่ายสูงกว่า

สำหรับองค์กรส่วนใหญ่ Terraform Cloud เป็นตัวเลือกที่เหมาะสมกว่า เพราะ HashiCorp ดูแลทุกอย่าง ทำให้ทีมโฟกัสกับการจัดการ infrastructure แทนที่จะดูแล platform เอง Terraform Enterprise เหมาะสำหรับองค์กรขนาดใหญ่ที่มี regulatory requirements เช่น ธนาคาร โรงพยาบาล หรือหน่วยงานรัฐ

Free Tier Features: เริ่มใช้ Terraform Cloud ฟรี

Terraform Cloud มี free tier ที่ให้ฟีเจอร์มากพอสำหรับทีมขนาดเล็กหรือโปรเจคส่วนตัว สิ่งที่ได้ใน free tier ประกอบด้วย remote state management สำหรับ workspaces ไม่จำกัด, VCS integration กับ GitHub GitLab Bitbucket, remote plan and apply, state versioning, private module registry และ community support

สิ่งที่ไม่ได้ใน free tier ได้แก่ Sentinel policies, cost estimation, team management ขั้นสูง (ได้แค่ 1 team), SSO (SAML), audit logging, concurrent runs (free tier ได้ 1 concurrent run) และ premium support

สำหรับทีมเล็กที่มี 2-3 คน free tier เพียงพอสำหรับการเริ่มต้น เมื่อทีมโตขึ้นหรือต้องการฟีเจอร์ governance สามารถ upgrade ไป Plus tier ได้ โดยราคาคิดตาม resource managed

การ Migrate จาก Local State มาใช้ Terraform Cloud

หลายทีมเริ่มต้นด้วย Terraform CLI บน local machine แล้วต้องการ migrate มาใช้ Terraform Cloud เมื่อทีมโตขึ้น กระบวนการ migration ไม่ยุ่งยาก แต่ต้องทำอย่างระมัดระวัง

ขั้นตอนการ Migration

ขั้นตอนที่ 1 สร้าง organization และ workspace ใน Terraform Cloud ก่อน กำหนดชื่อ workspace ให้สื่อความหมาย ตั้งค่า Terraform version ให้ตรงกับที่ใช้อยู่ กำหนด variables ที่จำเป็น

ขั้นตอนที่ 2 เพิ่ม cloud block ใน Terraform configuration เพื่อบอก Terraform ว่าให้ใช้ Terraform Cloud เป็น backend

# เพิ่ม cloud block ใน terraform block
terraform {
  cloud {
    organization = "my-org"
    workspaces {
      name = "my-app-prod"
    }
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# หรือใช้ tags สำหรับหลาย workspaces
terraform {
  cloud {
    organization = "my-org"
    workspaces {
      tags = ["app:my-app", "env:prod"]
    }
  }
}

ขั้นตอนที่ 3 รัน terraform login เพื่อ authenticate กับ Terraform Cloud จากนั้นรัน terraform init Terraform จะถามว่าต้องการ migrate state ไปยัง Terraform Cloud หรือไม่ ตอบ yes แล้ว Terraform จะ upload state file ไปยัง Terraform Cloud อัตโนมัติ

ขั้นตอนที่ 4 ตรวจสอบว่า state ถูก upload เรียบร้อยโดยเข้า Terraform Cloud UI ไปดูที่ workspace แล้วตรวจสอบว่า state มี resources ครบถ้วน รัน terraform plan เพื่อตรวจสอบว่า plan ไม่มี changes (no-op plan) ซึ่งหมายความว่า state ตรงกับ infrastructure จริง

ขั้นตอนที่ 5 ลบ local state file (terraform.tfstate) หลังจากมั่นใจว่า migration สำเร็จ แต่ควรเก็บ backup ไว้สักพักก่อนลบถาวร

Terraform Cloud + GitHub Actions

แม้ Terraform Cloud จะมี VCS integration ในตัว แต่บางทีมอาจต้องการ control กระบวนการ deployment ผ่าน GitHub Actions แทน เพื่อรวมกับ pipeline อื่นๆ เช่น application deployment, testing หรือ notification

GitHub Actions Workflow สำหรับ Terraform Cloud

# .github/workflows/terraform.yml
name: "Terraform Cloud"
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  terraform:
    runs-on: ubuntu-latest
    env:
      TF_API_TOKEN: ${{ secrets.TF_API_TOKEN }}
      TF_CLOUD_ORGANIZATION: "my-org"
      TF_WORKSPACE: "my-app-prod"

    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

      - name: Terraform Init
        run: terraform init

      - name: Terraform Format Check
        run: terraform fmt -check

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Plan
        id: plan
        run: terraform plan -no-color
        continue-on-error: true

      - name: Comment PR with Plan
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          script: |
            const plan = `${{ steps.plan.outputs.stdout }}`;
            const body = `## Terraform Plan Result
            \`\`\`
            ${plan.substring(0, 65000)}
            \`\`\``;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: body
            });

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve

workflow นี้ทำงานร่วมกับ Terraform Cloud โดย terraform init จะเชื่อมต่อกับ Terraform Cloud, plan และ apply จะ execute บน Terraform Cloud runners ไม่ใช่บน GitHub Actions runner ทำให้ได้ประโยชน์ทั้งจาก GitHub Actions (CI/CD pipeline, PR integration) และ Terraform Cloud (remote state, policy enforcement, cost estimation)

Best Practices สำหรับ Team Workflows ในปี 2026

การใช้ Terraform Cloud อย่างมีประสิทธิภาพต้องมีแนวทางปฏิบัติที่ดี ต่อไปนี้คือ best practices ที่ทีม infrastructure ควรนำไปใช้ในปี 2026

1. ใช้ GitOps Workflow

ทุก infrastructure change ต้องผ่าน Git เสมอ ห้ามรัน terraform apply จาก local machine โดยตรง ทุก changes ต้องผ่าน PR ได้ review แล้วจึง merge เพื่อ trigger apply ใน Terraform Cloud สิ่งนี้ทำให้มี audit trail ครบถ้วน มีคนตรวจสอบทุก change และสามารถ revert ได้หากมีปัญหา

2. แบ่ง Workspace ให้เหมาะสม

อย่าใส่ทุกอย่างใน workspace เดียว แต่ก็อย่าแบ่งย่อยเกินไป หลักคิดที่ดีคือแบ่งตาม lifecycle และ ownership ของ resources ถ้า resources มักถูกเปลี่ยนแปลงพร้อมกันและดูแลโดยทีมเดียวกัน ควรอยู่ใน workspace เดียวกัน แต่ถ้ามี lifecycle ต่างกัน ต้องแยก workspace

3. ใช้ Modules สำหรับ Reusable Components

สร้าง modules สำหรับ infrastructure patterns ที่ใช้ซ้ำ เช่น module สำหรับสร้าง standard VPC, module สำหรับ ECS service พร้อม ALB, module สำหรับ RDS instance พร้อม backup เก็บ modules ใน private registry ของ Terraform Cloud เพื่อให้ทุกทีมใช้มาตรฐานเดียวกัน

4. กำหนด Variable Sets

Terraform Cloud มี variable sets ที่ช่วยแชร์ variables ข้าม workspaces เช่น AWS credentials ที่ใช้ร่วมกันทุก workspace ไม่ต้องตั้งค่าซ้ำในแต่ละ workspace ช่วยลดโอกาสผิดพลาดและทำให้จัดการ credentials ง่ายขึ้น

5. เปิดใช้ Run Notifications

ตั้งค่า notification ให้แจ้งเตือนทีมเมื่อมี run ที่ต้อง approve หรือเมื่อ apply สำเร็จหรือล้มเหลว Terraform Cloud รองรับ notification ผ่าน Slack, Microsoft Teams, Email และ generic webhooks ทำให้ทีมรับรู้สถานะของ infrastructure changes ได้ทันที

6. ใช้ Terraform Version Pinning

กำหนด Terraform version ที่ใช้ในแต่ละ workspace อย่างชัดเจน ไม่ใช้ latest version เสมอ เพราะ version ใหม่อาจมี breaking changes ควร test กับ version ใหม่ใน dev workspace ก่อน แล้วจึงค่อย upgrade staging และ production ตามลำดับ

7. Implement Drift Detection

Terraform Cloud มี drift detection ที่จะ run plan อัตโนมัติตาม schedule เพื่อตรวจจับว่ามีใคร (หรือ process ใด) ไปแก้ไข infrastructure โดยไม่ผ่าน Terraform หรือไม่ หากพบ drift จะแจ้งเตือนทีมให้ดำเนินการแก้ไข ไม่ว่าจะเป็นการ import changes เข้า state หรือ revert infrastructure กลับไปตรงกับ code

8. จัดการ Secrets อย่างปลอดภัย

อย่าเก็บ secrets ใน Terraform configuration files เก็บใน Terraform Cloud variables ที่ mark เป็น sensitive หรือใช้ dynamic credentials กับ HashiCorp Vault integration ที่ Terraform Cloud รองรับในตัว ทำให้ credentials ถูกสร้างแบบ short-lived สำหรับแต่ละ run เท่านั้น ไม่ต้องเก็บ long-lived credentials

สรุป Terraform Cloud คืออะไร และเหมาะกับใคร

Terraform Cloud เป็น platform ที่ครบวงจรสำหรับการจัดการ Infrastructure as Code ที่ช่วยให้ทีมทำงานร่วมกันได้อย่างมีประสิทธิภาพ ตั้งแต่ remote state management ที่ปลอดภัย, workspaces ที่ช่วยแยก environments, VCS integration ที่ทำให้ infrastructure changes ผ่าน code review, Sentinel policies ที่ช่วย enforce governance, cost estimation ที่ช่วยควบคุมค่าใช้จ่าย ไปจนถึง private registry ที่ช่วยส่งเสริม code reuse

สำหรับทีมที่เพิ่งเริ่มต้น สามารถใช้ free tier ได้ทันที เมื่อทีมโตขึ้นและต้องการฟีเจอร์ governance สามารถ upgrade ได้ สำหรับองค์กรที่ต้องการ self-hosted solution มี Terraform Enterprise ให้เลือก ไม่ว่าจะเป็นทีมขนาดไหน Terraform Cloud ช่วยให้การจัดการ infrastructure เป็นระเบียบ ปลอดภัย และมีประสิทธิภาพมากขึ้น