Spot Instances, Savings Plans และ Reserved Instances — คู่มือลดค่า Compute บน AWS, Azure, GCP ปี 2026

คู่มือฉบับสมบูรณ์: Spot Instances, Savings Plans และ Reserved Instances — ลดค่าใช้จ่าย Compute บน AWS, Azure และ GCP ปี 2026

ถ้าคุณเป็นคนที่ต้องดูแลค่าใช้จ่าย Cloud ขององค์กร คุณน่าจะรู้ดีว่า "ค่า Compute" คือตัวร้ายหมายเลขหนึ่งในใบเรียกเก็บเงินรายเดือน โดยทั่วไปแล้ว ค่าใช้จ่ายด้าน Compute (Virtual Machines, Containers, Serverless Functions) คิดเป็นประมาณ 60-70% ของค่า Cloud ทั้งหมด ลองคิดดู — ถ้าองค์กรของคุณจ่ายค่า Cloud เดือนละ 10 ล้านบาท มีอย่างน้อย 6-7 ล้านบาทที่หายไปกับ Compute เฉยๆ

ตลาด Cloud ทั่วโลกมีมูลค่าประมาณ 943 พันล้านดอลลาร์ในปี 2025 และคาดว่าจะ ทะลุ 1 ล้านล้านดอลลาร์ในปี 2026 เม็ดเงินมหาศาลนี้ไหลเข้าสู่ AWS, Azure และ GCP เป็นหลัก

แต่สิ่งที่น่าตกใจจริงๆ คือ จากข้อมูลของ FinOps Foundation พบว่า 30-35% ของค่าใช้จ่าย Cloud ถูกสูญเปล่า ไม่ว่าจะเป็น Instance ที่เปิดทิ้งไว้ไม่มีใครใช้ หรือการจ่ายราคา On-Demand เต็มจำนวนทั้งที่มีทางเลือกอื่นถูกกว่ามาก พูดตรงๆ ว่ามันเจ็บปวดมากเวลาเปิดดูบิลแล้วเห็นตัวเลขพวกนี้

บทความนี้จะพาคุณเจาะลึกกลไกส่วนลด 3 ประเภทหลักที่ Cloud Provider ทุกรายมีให้: Spot Instances (ใช้ Capacity ที่เหลือในราคาถูกมาก), Savings Plans (commit การใช้จ่ายเพื่อรับส่วนลด), และ Reserved Instances (จองล่วงหน้าเพื่อส่วนลดสูงสุด) เราจะเปรียบเทียบข้ามทั้ง 3 Cloud Provider พร้อมตัวอย่าง Terraform code และ case study จริงจากบริษัทระดับโลก งั้นเรามาเริ่มกันเลย

ทำความเข้าใจโมเดลราคา: On-Demand vs Commitment-Based Pricing

ก่อนจะลงรายละเอียด เรามาเข้าใจโมเดลราคาพื้นฐานกันก่อน Cloud Provider ทุกรายมีโมเดลราคา 2 แบบหลักๆ:

On-Demand Pricing

จ่ายตามที่ใช้ ไม่มี commitment ใดๆ เปิด Instance เมื่อไหร่ก็จ่ายเมื่อนั้น ปิดเมื่อไหร่ก็หยุดจ่าย ข้อดีคือยืดหยุ่นสุดๆ แต่ข้อเสีย? แพงที่สุดเช่นกัน นี่แหละคือ "ราคาป้าย" ที่ทุกคนเริ่มต้นใช้งาน

Commitment-Based Pricing

คุณให้คำมั่นว่าจะใช้งานในระดับหนึ่ง (ไม่ว่าจะเป็นจำนวน Instance, ระยะเวลา, หรือจำนวนเงิน) เพื่อแลกกับส่วนลดที่สูงขึ้น ยิ่ง commit มากและนาน ส่วนลดยิ่งมาก แต่ก็แลกมากับความยืดหยุ่นที่ลดลงตามไปด้วย

และยังมีอีกประเภทหนึ่งที่ค่อนข้างพิเศษ นั่นคือ Spot/Preemptible Pricing — เป็นการใช้ Spare Capacity ที่ Cloud Provider มีเหลืออยู่ ราคาถูกมากแต่อาจถูก "เรียกคืน" (evict) ได้ตลอดเวลา ฟังดูน่ากลัวใช่ไหม? แต่จริงๆ แล้วถ้าจัดการดีๆ มันคุ้มค่ามากเลย

มาดูรายละเอียดแต่ละประเภทกัน:

AWS Spot Instances: ส่วนลดสูงสุด 90% สำหรับคนที่พร้อมรับ Interruption

AWS Spot Instances เป็นตำนานของการประหยัดค่า Cloud มาตั้งแต่ปี 2009 เลย หลักการง่ายๆ คือ AWS มี EC2 Capacity ส่วนเกินที่ไม่มีใครใช้ แทนที่จะปล่อยว่างไว้เฉยๆ ก็เอามาขายในราคาถูกให้คุณ — แต่มีเงื่อนไขว่า ถ้ามีคนต้องการ Capacity นั้นกลับคืน (เช่น ลูกค้า On-Demand หรือ Reserved Instance) AWS จะเรียก Instance ของคุณคืนไป

ตัวเลขที่ต้องรู้

• ส่วนลด: สูงสุด 90% จากราคา On-Demand (โดยทั่วไปอยู่ที่ 60-90% ขึ้นอยู่กับ Instance Type และ Region)
• Interruption Notice: คุณจะได้รับ คำเตือนล่วงหน้า 2 นาที ก่อนที่ Instance จะถูก terminate ผ่าน EC2 Metadata Service หรือ CloudWatch Events
• อัตรา Interruption เฉลี่ย: น้อยกว่า 5% ของ Spot Instances ทั้งหมดถูก interrupt ในแต่ละเดือน (แต่ตัวเลขนี้แตกต่างกันมากตาม Instance Type นะ)
• Pricing Model: ราคาผันแปรตาม Supply/Demand แบบ real-time ในปี 2026 AWS มีการเปลี่ยนแปลงราคาเฉลี่ย 197 ครั้งต่อเดือน สำหรับแต่ละ Instance Type/AZ combination — ค่อนข้างวุ่นวายอยู่เหมือนกัน

Best Practices สำหรับ AWS Spot Instances

1. Instance Diversity (กระจาย Instance Type)

อย่ายึดติดกับ Instance Type เดียว! ถ้าคุณต้องการ 4 vCPU + 16GB RAM ไม่จำเป็นต้องใช้แค่ m5.xlarge อย่างเดียว ลองใช้ m5.xlarge, m5a.xlarge, m5d.xlarge, m6i.xlarge, m6a.xlarge, m7i.xlarge ผสมกัน ยิ่งมี Instance Type ให้เลือกเยอะ โอกาสที่จะได้ Spot Capacity ก็ยิ่งสูงขึ้น

2. Availability Zone Flexibility

อย่าผูกติดกับ AZ เดียว ใช้ Spot Fleet หรือ Auto Scaling Group ที่กระจายข้าม AZ เพื่อเพิ่มโอกาสได้ Capacity

3. Handling Interruptions อย่างถูกวิธี

อันนี้สำคัญมาก ติดตั้ง Interruption Handler ที่คอยฟัง EC2 Metadata endpoint หรือ EventBridge event เพื่อทำ graceful shutdown ภายใน 2 นาที:

# ตรวจสอบ Spot Interruption Notice ผ่าน Instance Metadata
#!/bin/bash
while true; do
    HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
        http://169.254.169.254/latest/meta-data/spot/instance-action)
    if [ "$HTTP_CODE" -eq 200 ]; then
        echo "Spot Interruption Notice received!"
        # Drain connections
        # Save checkpoint
        # Deregister from load balancer
        /usr/local/bin/graceful-shutdown.sh
        break
    fi
    sleep 5
done

4. ใช้ Spot Fleet หรือ EC2 Fleet

แทนที่จะ request Spot Instance ทีละตัว ใช้ Fleet เพื่อให้ AWS เลือก Instance Type และ AZ ที่มี Capacity ให้คุณอัตโนมัติ สะดวกกว่าเยอะ:

# สร้าง Spot Fleet Request ด้วย AWS CLI
aws ec2 request-spot-fleet \
    --spot-fleet-request-config '{
        "IamFleetRole": "arn:aws:iam::123456789012:role/aws-ec2-spot-fleet-role",
        "TargetCapacity": 10,
        "SpotPrice": "0.05",
        "AllocationStrategy": "capacity-optimized",
        "LaunchSpecifications": [
            {
                "InstanceType": "m5.xlarge",
                "ImageId": "ami-0abcdef1234567890",
                "SubnetId": "subnet-abc123,subnet-def456,subnet-ghi789"
            },
            {
                "InstanceType": "m5a.xlarge",
                "ImageId": "ami-0abcdef1234567890",
                "SubnetId": "subnet-abc123,subnet-def456,subnet-ghi789"
            },
            {
                "InstanceType": "m6i.xlarge",
                "ImageId": "ami-0abcdef1234567890",
                "SubnetId": "subnet-abc123,subnet-def456,subnet-ghi789"
            }
        ]
    }'

จุดที่ต้องจำคือการใช้ AllocationStrategy: capacity-optimized ซึ่งจะเลือก Instance Pool ที่มี Capacity เหลือมากที่สุด ช่วยลดโอกาส Interruption ได้เยอะเลย

Azure Spot VMs: ความเสถียรด้านราคาที่เหนือกว่า

Azure Spot VMs ทำงานบนหลักการเดียวกับ AWS Spot Instances — ใช้ Spare Capacity ในราคาส่วนลด แต่พอลงลึกไปแล้วมีความแตกต่างที่น่าสนใจหลายจุด:

Eviction Policies

Azure มี Eviction Policy 2 แบบที่คุณเลือกได้:

• Capacity-based eviction: VM จะถูก evict เมื่อ Azure ต้องการ Capacity คืนเพื่อให้บริการ workload ประเภท On-Demand หรือ Reserved
• Price-based eviction: คุณกำหนด max price ที่ยินดีจ่าย ถ้าราคา Spot สูงกว่า max price ที่ตั้งไว้ VM จะถูก evict (หรือจะตั้ง max price เป็น -1 เพื่อจ่ายราคา On-Demand เป็น cap ก็ได้ — ซึ่งส่วนตัวแนะนำวิธีนี้)

นอกจากนี้ คุณยังเลือกได้ว่าเมื่อ VM ถูก evict จะ Stop/Deallocate (เก็บ disk ไว้ เปิดใหม่ได้ทีหลัง) หรือ Delete (ลบทิ้งทั้งหมด)

ราคาที่เสถียรกว่า AWS อย่างมาก

ต้องยอมรับว่าจุดเด่นที่สุดของ Azure Spot VMs คือ ความเสถียรด้านราคา จากการวิจัยพบว่า Azure Spot มีการเปลี่ยนแปลงราคาเฉลี่ยเพียง 0.76 ครั้งต่อเดือน เทียบกับ AWS ที่ 197 ครั้งต่อเดือน สำหรับแต่ละ Instance Type/Region combination

อ่านไม่ผิดหรอก 0.76 vs 197 เลย ต่างกันราวฟ้ากับดิน นี่หมายความว่าคุณสามารถคาดการณ์ค่าใช้จ่ายได้แม่นยำกว่ามากเมื่อใช้ Azure Spot

สาเหตุที่ Azure มีราคาเสถียรกว่าเป็นเพราะ Azure ใช้ระบบ pricing ที่ปรับตามแนวโน้มระยะยาวมากกว่า ไม่ได้ตอบสนองต่อ supply/demand แบบ real-time อย่าง AWS

ตัวอย่าง Terraform สำหรับ Azure Spot VM

# Azure Spot VM ด้วย Terraform
resource "azurerm_linux_virtual_machine" "spot_vm" {
  name                = "spot-worker-vm"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  size                = "Standard_D4s_v5"

  # Spot Configuration
  priority        = "Spot"
  eviction_policy = "Deallocate"
  max_bid_price   = -1  # จ่ายสูงสุดเท่าราคา On-Demand

  admin_username = "adminuser"

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }

  tags = {
    environment = "production"
    cost-center = "spot-workloads"
  }
}

GCP Spot VMs: วิวัฒนาการจาก Preemptible VMs

Google Cloud เปลี่ยนชื่อจาก Preemptible VMs เป็น Spot VMs มาสักพักแล้ว โดยมีการปรับปรุงที่สำคัญหลายอย่าง:

ความแตกต่างจาก Preemptible VMs รุ่นเก่า

• ไม่มีขีดจำกัดระยะเวลาทำงาน: Preemptible VMs รุ่นเก่ามีข้อจำกัดว่าต้องถูก terminate ภายใน 24 ชั่วโมง แต่ Spot VMs ไม่มี maximum runtime limit อีกต่อไปแล้ว VM จะทำงานต่อเนื่องได้ตราบเท่าที่มี Capacity
• ส่วนลด: 60-91% จากราคา On-Demand ขึ้นอยู่กับ Machine Type และ Region
• Interruption Notice: ได้รับ คำเตือนล่วงหน้าแค่ 30 วินาที (สั้นกว่า AWS ที่ให้ 2 นาที เยอะมาก ตรงนี้ต้องระวัง)
• Pricing: ราคาคงที่ตามที่ GCP กำหนด ไม่ผันแปรตาม real-time supply/demand อย่าง AWS ซึ่งทำให้คาดเดาค่าใช้จ่ายได้ง่ายกว่า

ตัวอย่าง Terraform สำหรับ GCP Spot VM

# GCP Spot VM ด้วย Terraform
resource "google_compute_instance" "spot_vm" {
  name         = "spot-worker"
  machine_type = "n2-standard-4"
  zone         = "asia-southeast1-b"

  scheduling {
    preemptible                 = false
    automatic_restart           = false
    provisioning_model          = "SPOT"
    instance_termination_action = "STOP"
  }

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
      size  = 50
      type  = "pd-ssd"
    }
  }

  network_interface {
    network    = "default"
    subnetwork = "default"

    access_config {
      # Ephemeral public IP
    }
  }

  metadata = {
    shutdown-script = <<-EOT
      #!/bin/bash
      echo "Spot VM is being preempted, saving state..."
      /usr/local/bin/save-checkpoint.sh
      /usr/local/bin/drain-connections.sh
    EOT
  }

  labels = {
    environment = "production"
    workload    = "batch-processing"
  }
}

สังเกตว่าใน GCP เราใช้ provisioning_model = "SPOT" และ instance_termination_action = "STOP" เพื่อให้ VM ถูก stop แทน delete เมื่อถูก preempt — เก็บ disk ไว้ พร้อมเปิดใหม่ได้ทันที

ตารางเปรียบเทียบ Spot Offerings ข้าม Cloud Providers

คุณสมบัติ	AWS Spot Instances	Azure Spot VMs	GCP Spot VMs
ส่วนลดจาก On-Demand	สูงสุด 90%	สูงสุด 90%	60-91%
Interruption Notice	2 นาที	30 วินาที (via Scheduled Events)	30 วินาที
ความผันผวนของราคา	สูง (เฉลี่ย 197 ครั้ง/เดือน)	ต่ำมาก (เฉลี่ย 0.76 ครั้ง/เดือน)	ต่ำ (ราคาคงที่เป็น % ของ On-Demand)
Maximum Runtime	ไม่จำกัด	ไม่จำกัด	ไม่จำกัด (เดิม Preemptible จำกัด 24 ชม.)
Eviction Policy Options	Terminate, Stop, Hibernate	Stop/Deallocate, Delete	Stop, Delete
การคาดการณ์ราคา	ยาก (ผันผวนสูง)	ง่าย (เสถียรมาก)	ง่าย (% คงที่)
เหมาะสำหรับ	Batch, CI/CD, Big Data, ML Training	Batch, Dev/Test, Stateless Services	Batch, Data Processing, ML Training

AWS Savings Plans vs Reserved Instances: ความยืดหยุ่น vs ส่วนลดสูงสุด

ถ้า Spot Instances เป็น "การซื้อตั๋วเครื่องบิน Standby" Savings Plans และ Reserved Instances ก็เหมือน "การซื้อตั๋วล่วงหน้า" คุณ commit ว่าจะใช้งานในระดับหนึ่ง และได้ส่วนลดเป็นการตอบแทน เป็นคอนเซปต์ที่ตรงไปตรงมา

AWS Savings Plans

AWS เปิดตัว Savings Plans ในปี 2019 และตั้งแต่นั้นมา AWS ก็ แนะนำให้ลูกค้าใช้ Savings Plans แทน Reserved Instances สำหรับ workload ส่วนใหญ่ เพราะยืดหยุ่นกว่าเยอะ

Savings Plans มี 3 ประเภท:

1. Compute Savings Plans: ยืดหยุ่นที่สุด ใช้ได้กับ EC2, Fargate และ Lambda ข้าม Region, Instance Family, OS, Tenancy ได้หมด ส่วนลดสูงสุดประมาณ 66%
2. EC2 Instance Savings Plans: ผูกกับ Instance Family และ Region แต่เปลี่ยน Size, OS, Tenancy ได้ ส่วนลดสูงสุดถึง 72%
3. SageMaker Savings Plans: สำหรับ Amazon SageMaker โดยเฉพาะ

เงื่อนไขหลัก

• ระยะเวลา: เลือกได้ 1 ปี หรือ 3 ปี (3 ปีได้ส่วนลดมากกว่าแต่ก็ lock นานกว่า)
• การชำระเงิน: All Upfront (จ่ายล่วงหน้าทั้งหมด), Partial Upfront (จ่ายล่วงหน้าบางส่วน), No Upfront (ไม่ต้องจ่ายล่วงหน้า)
• ส่วนลดสูงสุด: สูงถึง 72% เมื่อเลือก 3 ปี + All Upfront
• Commitment: คุณ commit จำนวนเงินต่อชั่วโมง (เช่น $10/hr) ไม่ใช่ commit Instance Type เฉพาะ — ตรงนี้เป็นข้อดีมากเพราะคุณมีอิสระในการเปลี่ยน Instance Type ได้

AWS Reserved Instances (RIs)

Reserved Instances เป็นรุ่นดั้งเดิมที่มีมานาน ข้อดีคือส่วนลดสูงสุดถึง 72% เมื่อใช้ 3 ปี All Upfront แต่ข้อเสียก็มีอยู่พอสมควร:

• ผูกกับ Instance Type, Region (Standard RI) หรือ Instance Family (Convertible RI) เฉพาะ
• Standard RI ไม่สามารถเปลี่ยน Instance Family ได้ (ยกเว้น Convertible RI แต่ส่วนลดจะน้อยลง)
• มี Marketplace สำหรับขาย RI ที่ไม่ต้องการ แต่กระบวนการก็ค่อนข้างยุ่งยากและไม่ได้คืนเต็มจำนวน

Savings Plans vs Reserved Instances: สรุปเปรียบเทียบ

คุณสมบัติ	Savings Plans	Reserved Instances
ส่วนลดสูงสุด	สูงถึง 72%	สูงถึง 72%
ความยืดหยุ่น	สูง (เปลี่ยน Instance Type, Region, OS ได้)	ต่ำ-ปานกลาง (ผูก Instance Type/Region)
ครอบคลุมบริการ	EC2, Fargate, Lambda, SageMaker	EC2 เท่านั้น (มี RDS RI, ElastiCache RI แยกต่างหาก)
การจัดการ	ง่าย (commit $/hr)	ซับซ้อน (ต้องเลือก Instance Type)
Marketplace	ไม่มี (ยกเลิกไม่ได้)	มี (ขาย Standard RI ได้)
AWS แนะนำ	ใช่ (แนะนำสำหรับ workload ส่วนใหญ่)	ยังรองรับ แต่ไม่ใช่ตัวเลือกหลักอีกต่อไป

Azure Reserved VM Instances และ Azure Savings Plan for Compute

Azure มีทั้ง Reserved Instances และ Savings Plan เช่นเดียวกับ AWS แต่ก็มีลูกเล่นเฉพาะตัวอยู่:

Azure Reserved VM Instances

• เลือกระยะเวลา 1 ปี หรือ 3 ปี
• ส่วนลดสูงสุดถึง 72% สำหรับ 3 ปี
• มี Instance Size Flexibility ใน Series เดียวกัน (เช่น ซื้อ D4s v5 สามารถใช้ครอบคลุม D2s v5 x 2 ตัวได้ — ฟีเจอร์นี้สะดวกมาก)
• สามารถ exchange ไปเป็น reservation อื่นได้ (แต่มีข้อจำกัดที่ Microsoft เพิ่มขึ้นเรื่อยๆ)
• เหมาะสำหรับ workload ที่มีการใช้งานคงที่และคาดเดาได้

Azure Savings Plan for Compute

Azure เปิดตัว Savings Plan for Compute ในปี 2022 ตามรอย AWS:

• Commit จำนวนเงินต่อชั่วโมง (เช่น $5/hr)
• ใช้ได้กับ Virtual Machines, Azure App Service, Azure Container Instances และ Azure Functions Premium
• ยืดหยุ่นกว่า Reserved Instances — เปลี่ยน VM Series, Region, OS ได้
• ส่วนลดอาจน้อยกว่า Reserved Instances เล็กน้อย (แลกกับความยืดหยุ่นที่ได้มา ซึ่งมักจะคุ้ม)
• เลือกได้ 1 ปี หรือ 3 ปี

หลักการเดียวกับ AWS เลย: ถ้ามั่นใจเรื่อง Instance Type ก็ใช้ Reserved Instances ถ้าต้องการความยืดหยุ่นก็เลือก Savings Plan

GCP Committed Use Discounts (CUDs): Resource-Based vs Spend-Based

GCP มีแนวทางที่ต่างออกไปจาก AWS และ Azure เล็กน้อย โดยเรียกว่า Committed Use Discounts (CUDs) แบ่งเป็น 2 ประเภทหลัก:

Resource-Based CUDs

• Commit จำนวน vCPU และ Memory ที่จะใช้ใน Region เฉพาะ
• เลือก 1 ปี (ส่วนลดประมาณ 37%) หรือ 3 ปี (ส่วนลดประมาณ 55%)
• ใช้ได้กับ Compute Engine และ Google Kubernetes Engine (GKE)
• ไม่ต้องจ่ายล่วงหน้า — จ่ายรายเดือนตามราคา CUD (ข้อดีมากสำหรับ cash flow)
• เหมาะสำหรับ workload ที่ใช้ Compute Engine เป็นหลักและรู้ปริมาณการใช้งานชัดเจน

Spend-Based CUDs

• Commit จำนวนเงินต่อชั่วโมงที่จะใช้ (คล้าย Savings Plans ของ AWS)
• ยืดหยุ่นกว่า Resource-Based — ใช้ได้กับ Compute Engine, Cloud Run, GKE และ Cloud SQL
• เลือก 1 ปี หรือ 3 ปี
• เปลี่ยน Machine Type, Region ได้ตามต้องการ
• เหมาะสำหรับองค์กรที่ใช้ GCP หลายบริการและต้องการความยืดหยุ่น

อ้อ อีกอย่าง — GCP ยังมี Sustained Use Discounts (SUDs) ที่ให้ส่วนลดอัตโนมัติเมื่อคุณใช้ VM ต่อเนื่องในแต่ละเดือน (ใช้มากกว่า 25% ของเวลาในเดือนนั้น) โดยไม่ต้อง commit อะไรเลย ฟังดูดีใช่ไหม? แต่สิ่งสำคัญที่ต้องรู้คือ SUDs ไม่ได้ใช้ได้กับทุก Machine Type อีกแล้วใน generation ใหม่ๆ ดังนั้นอย่าพึ่งพา SUDs เพียงอย่างเดียว

กลยุทธ์เชิงปฏิบัติ: ผสม Spot กับ On-Demand อย่างชาญฉลาด

มาถึงส่วนที่สำคัญมากๆ การใช้ Spot Instances ให้ได้ผลดีที่สุดไม่ได้หมายความว่าจะต้องใช้ Spot 100% แต่คือการ ผสม Spot กับ On-Demand ในสัดส่วนที่เหมาะสม

สูตร 70-80% Spot + 20-30% On-Demand

สำหรับ workload ที่ไม่จำเป็นต้องทำงานต่อเนื่องตลอดเวลา (non-critical, fault-tolerant) แนะนำให้ใช้:

• 70-80% Spot Instances สำหรับ capacity หลัก
• 20-30% On-Demand หรือ Savings Plans เป็น baseline ที่ไม่มีทางถูก interrupt

วิธีนี้ช่วยให้คุณมี minimum capacity ที่แน่นอนจาก On-Demand/Savings Plans ในขณะเดียวกันก็ได้ส่วนลดมหาศาลจาก Spot สำหรับ capacity ส่วนที่เหลือ

ใช้ Karpenter สำหรับ Kubernetes Auto-Scaling กับ Spot

ถ้าคุณรัน Kubernetes บน AWS (EKS) ต้องรู้จัก Karpenter ซึ่งเป็น Open-Source node provisioner ที่ออกแบบมาเพื่อจัดการ Spot Instances ได้อย่างชาญฉลาด มันเหนือกว่า Cluster Autoscaler แบบเดิมในหลายด้าน:

• เลือก Instance Type โดยอัตโนมัติจาก pool ของ Instance Types ที่คุณกำหนด
• จัดการ Spot Interruption ได้ gracefully ด้วยการ cordon และ drain node อัตโนมัติ
• รองรับ Consolidation — รวม workload เข้าด้วยกันเมื่อมี capacity เหลือ เพื่อลดจำนวน node
• Provisioning เร็วกว่า Cluster Autoscaler มาก (ไม่ต้องรอ Auto Scaling Group ปรับตัว)

ตัวอย่าง Karpenter NodePool สำหรับ Spot Instances:

# Karpenter NodePool สำหรับ Spot Instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.xlarge
            - m5a.xlarge
            - m5d.xlarge
            - m6i.xlarge
            - m6a.xlarge
            - m7i.xlarge
            - c5.xlarge
            - c5a.xlarge
            - c6i.xlarge
            - r5.xlarge
            - r5a.xlarge
            - r6i.xlarge
        - key: topology.kubernetes.io/zone
          operator: In
          values:
            - ap-southeast-1a
            - ap-southeast-1b
            - ap-southeast-1c
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "1000"
    memory: 4000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
---
# NodePool สำหรับ On-Demand baseline
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: on-demand-baseline
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m6i.xlarge
            - m7i.xlarge
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "200"
    memory: 800Gi
  weight: 10  # Priority ต่ำกว่า spot pool

ตัวอย่าง Terraform สำหรับ AWS Auto Scaling Group แบบ Mixed Instances

# Terraform: Mixed Instances Policy สำหรับ ASG
resource "aws_autoscaling_group" "mixed_fleet" {
  name                = "mixed-spot-ondemand"
  desired_capacity    = 10
  max_size            = 20
  min_size            = 2
  vpc_zone_identifier = var.subnet_ids

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2    # 2 instances เป็น On-Demand เสมอ
      on_demand_percentage_above_base_capacity = 20   # 20% ที่เหลือเป็น On-Demand
      spot_allocation_strategy                 = "capacity-optimized"
      spot_instance_pools                      = 0    # ไม่ใช้เมื่อเป็น capacity-optimized
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
        version            = "$Latest"
      }

      # Instance Type Diversification
      override {
        instance_type     = "m5.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m5a.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m6i.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m6a.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m7i.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "c5.xlarge"
        weighted_capacity = "1"
      }
    }
  }

  tag {
    key                 = "Environment"
    value               = "production"
    propagate_at_launch = true
  }

  tag {
    key                 = "ManagedBy"
    value               = "terraform"
    propagate_at_launch = true
  }
}

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "m5.xlarge"  # Default, จะถูก override โดย mixed_instances_policy

  user_data = base64encode(<<-EOF
    #!/bin/bash
    # ติดตั้ง Spot Interruption Handler
    yum install -y aws-cli jq

    # เริ่ม Application
    systemctl start myapp

    # Monitor for Spot Interruption
    /usr/local/bin/spot-interruption-handler.sh &
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "app-mixed-fleet"
    }
  }
}

Case Studies จากโลกจริง

Case Study 1: Salesforce ย้าย 1,000+ EKS Clusters ไปใช้ Karpenter

Salesforce เป็นหนึ่งในผู้ใช้ Kubernetes รายใหญ่ที่สุดในโลก ด้วย EKS Clusters มากกว่า 1,000 clusters การจัดการ node scaling ด้วย Cluster Autoscaler แบบเดิมเริ่มไม่ไหวแล้ว ทั้งเรื่องประสิทธิภาพและค่าใช้จ่าย

Salesforce ตัดสินใจย้ายมาใช้ Karpenter เพื่อ:

• จัดการ Spot Instances ได้อัจฉริยะมากขึ้น — Karpenter เลือก Instance Type ที่มี capacity เหลือมากที่สุด ลด interruption rate
• ลดเวลา provisioning จากหลายนาทีเหลือไม่กี่วินาที
• ใช้ Node Consolidation เพื่อรวม workload เข้าด้วยกัน ลดจำนวน node ที่ทำงานอยู่

ผลลัพธ์? Salesforce ประหยัดค่า Compute ได้ประมาณ 5% ใน FY2026 ฟังดูอาจไม่เยอะ แต่เมื่อคิดจากขนาด infrastructure ของ Salesforce แล้ว 5% นี่คิดเป็นเงินหลายสิบล้านดอลลาร์ต่อปีเลยนะ นอกจากนี้ยังได้ประโยชน์ด้าน operational efficiency ที่วัดเป็นตัวเงินยากกว่า เช่น ลดเวลาที่ทีม SRE ต้องใช้ในการจัดการ node issues

Case Study 2: Tinybird ลดค่า AWS 20% ด้วย EKS + Karpenter + Spot

Tinybird บริษัท Real-Time Data Analytics ใช้สูตรผสมที่ลงตัวมาก:

• ย้าย workload จาก EC2 แบบ manual มาเป็น EKS (Elastic Kubernetes Service)
• ใช้ Karpenter เป็น node provisioner แทน Cluster Autoscaler
• กำหนดให้ workload ส่วนใหญ่ที่เป็น stateless (API workers, data processors) รันบน Spot Instances
• เก็บเฉพาะ stateful components (databases, message queues) บน On-Demand หรือ Reserved Instances

ผลลัพธ์: ลดค่าใช้จ่าย AWS ลงได้ 20% ตัวเลขนี้น่าประทับใจมาก โดยเฉพาะสำหรับบริษัทที่ optimize infrastructure มาพอสมควรแล้วก่อนหน้านี้ กุญแจสำคัญคือ Karpenter ที่สามารถ:

1. จัดการ Instance Diversity โดยอัตโนมัติ — ไม่ต้องกำหนด Launch Configuration หลายตัว
2. ตอบสนองต่อ Spot Interruption ได้เร็ว — drain pod ไปยัง node อื่นก่อนที่ instance จะถูก terminate
3. Consolidate workload เพื่อลด waste — ถ้ามี node ที่ใช้ resource ไม่ถึง 50% ก็ย้าย pod ไปรวมกับ node อื่น แล้วปิด node ที่ว่าง

FinOps Framework Integration

การเลือกใช้ Spot Instances, Savings Plans หรือ Reserved Instances ไม่ใช่แค่เรื่องเทคนิคอย่างเดียว แต่ต้องเป็นส่วนหนึ่งของ FinOps Framework ขององค์กรด้วย FinOps Lifecycle ประกอบด้วย 3 ขั้นตอน:

1. Inform (ทำความเข้าใจค่าใช้จ่าย)

• วิเคราะห์ usage patterns ของ compute workload ทั้งหมด — workload ไหนใช้ 24/7, workload ไหนใช้เฉพาะเวลาทำงาน, workload ไหนเป็น burst
• สร้าง visibility ผ่าน tagging strategy ที่ดี — tag ทุก resource ด้วย cost center, team, environment, workload type (อันนี้หลายองค์กรมองข้ามไปเลย)
• ใช้เครื่องมืออย่าง AWS Cost Explorer, Azure Cost Management หรือ GCP Billing Reports เพื่อดูว่าค่าใช้จ่ายมาจากไหน
• ระบุว่าค่าใช้จ่ายส่วนไหนเป็น On-Demand ที่สามารถแปลงเป็น commitment-based ได้

2. Optimize (ลดค่าใช้จ่าย)

• Right-Sizing ก่อน Commit: ก่อนจะซื้อ Savings Plans หรือ Reserved Instances ต้อง right-size workload ก่อน! ไม่มีประโยชน์ที่จะ lock ราคาของ Instance ที่ใหญ่เกินไป
• ใช้ Spot สำหรับ workload ที่ fault-tolerant: CI/CD pipelines, batch processing, dev/test environments, stateless web workers
• ใช้ Savings Plans สำหรับ baseline usage: workload ที่รันตลอดเวลาและคาดเดาได้
• ใช้ Reserved Instances เฉพาะเมื่อ: รู้แน่ชัดว่าจะใช้ Instance Type ไหนเป็นเวลานาน และต้องการส่วนลดสูงสุด

3. Operate (ดำเนินการอย่างต่อเนื่อง)

• ตั้ง Budget Alerts เพื่อตรวจสอบว่าค่าใช้จ่ายอยู่ในเป้าหมาย
• Review commitment utilization ทุกเดือน — Savings Plans/Reserved Instances ถูกใช้ครบหรือเปล่า?
• ปรับ Spot Instance strategy ตาม Interruption Rate ที่เปลี่ยนไป
• สร้าง FinOps culture — ทุกทีมต้องรู้ว่า resource ที่ใช้มีค่าใช้จ่ายเท่าไหร่
• ทำ Automation เพื่อปิด resource ที่ไม่ได้ใช้งาน (unused instances, idle load balancers)

FinOps ไม่ใช่โปรเจกต์ที่ทำครั้งเดียวจบ มันเป็น วงจรต่อเนื่อง ที่ต้องทำซ้ำทุกเดือน เพราะ workload เปลี่ยน ราคา Cloud เปลี่ยน และโอกาสในการ optimize ก็เปลี่ยนตามไปด้วย จากประสบการณ์ส่วนตัว องค์กรที่ทำ FinOps review สม่ำเสมอจะเห็นผลลัพธ์ต่างจากองค์กรที่ทำแค่ครั้งเดียวอย่างมาก

Decision Framework: เลือกใช้อะไรเมื่อไหร่?

นี่คือ Decision Framework ที่ใช้ได้กับทุกองค์กร:

ใช้ Spot Instances เมื่อ:

• Workload สามารถรับ interruption ได้ (fault-tolerant)
• มี checkpoint/retry mechanism อยู่แล้ว
• ไม่ใช่ single point of failure — มี instance หลายตัวทำงานพร้อมกัน
• เป็น batch processing, ML training, CI/CD, data analytics, stateless web tier
• ต้องการส่วนลดสูงสุด (60-90%) และพร้อมรับ interruption risk

ใช้ Savings Plans เมื่อ:

• มี baseline compute usage ที่คาดเดาได้ (เช่น ใช้ compute เฉลี่ย $50/hr ตลอดปี)
• ต้องการความยืดหยุ่นในการเปลี่ยน Instance Type, Region, หรือแม้แต่ Service (EC2 → Fargate)
• ไม่แน่ใจว่าจะใช้ Instance Type ไหนในอนาคต (อาจ migrate จาก x86 ไป ARM/Graviton)
• ต้องการส่วนลดดี (สูงถึง 72%) โดยไม่ต้องจัดการ complexity ของ Reserved Instances

ใช้ Reserved Instances เมื่อ:

• รู้แน่ชัด 100% ว่าจะใช้ Instance Type ไหน ใน Region ไหน เป็นเวลา 1-3 ปี
• Workload เป็น steady-state ที่ไม่มีแผนจะเปลี่ยนแปลง (เช่น database server ที่ใช้ Instance Type เดิมมาหลายปีแล้ว)
• ต้องการ Capacity Reservation (จอง capacity ไว้แน่นอน ไม่ใช่แค่ส่วนลด)
• ต้องการขาย commitment ที่ไม่ใช้ผ่าน Marketplace (AWS RI Marketplace)

สูตรผสมที่แนะนำ

ประเภท Workload	สัดส่วนที่แนะนำ	เหตุผล
Production Stateful (DB, Cache)	100% Reserved Instances / Savings Plans	ต้อง reliable 100%, ใช้ 24/7, คาดเดาได้
Production Stateless (Web, API)	30% Savings Plans + 70% Spot	Fault-tolerant, มี multiple instances, ทนการ interrupt ได้
Batch Processing / ML Training	100% Spot	Checkpoint ได้, retry ได้, ไม่กระทบ user-facing
CI/CD Pipelines	100% Spot	Job สั้น, retry ง่าย, ไม่กระทบ production
Dev/Test Environments	100% Spot (ปิดนอกเวลาทำงาน)	ไม่จำเป็นต้อง available ตลอดเวลา

ข้อผิดพลาดที่พบบ่อย (และวิธีหลีกเลี่ยง)

จากประสบการณ์ที่ได้เห็นหลายองค์กรทำกัน นี่คือข้อผิดพลาดที่เจอบ่อยมากเกี่ยวกับ commitment-based pricing และ Spot Instances:

1. ซื้อ Reserved Instances ก่อน Right-Sizing

นี่คือข้อผิดพลาดอันดับหนึ่งเลย หลายองค์กรเห็นว่า Reserved Instances ถูกก็รีบซื้อ โดยไม่ได้ right-size workload ก่อน ผลคือคุณ lock ราคาถูกสำหรับ Instance ที่ใหญ่เกินไปเป็นเวลา 3 ปี ถ้า right-size ก่อนแล้วค่อยซื้อ RI ส่วนลดจะคูณกันเลย

2. Over-Commit

ซื้อ Savings Plans หรือ Reserved Instances มากกว่าที่ใช้จริง commitment ที่ไม่ได้ใช้ = เงินที่เสียเปล่า ควรเริ่มจาก 70-80% ของ steady-state usage แล้วค่อยเพิ่มทีหลังจะปลอดภัยกว่า

3. ใช้ Spot Instance Type เดียว

พูดจริงๆ เห็นเยอะมาก การใช้ Instance Type เดียวสำหรับ Spot เพิ่มความเสี่ยงที่จะถูก interrupt ทั้งกลุ่มพร้อมกัน ควรกระจายอย่างน้อย 5-10 Instance Types

4. ไม่มี Interruption Handling

ใช้ Spot Instances แต่ไม่มี graceful shutdown mechanism เมื่อถูก interrupt ข้อมูลอาจสูญหาย connection อาจขาดกลางคัน ควรมี interruption handler เสมอ ไม่มีข้อยกเว้น

5. ไม่ review commitments เป็นประจำ

ซื้อ Savings Plans 3 ปีแล้วลืมไปเลย ไม่เคย review ว่า utilization เป็นอย่างไร ควร review อย่างน้อยเดือนละครั้ง

6. เปรียบเทียบราคาข้ามผิด baseline

บางทีม claim ว่า "ประหยัดได้ 70%" แต่เทียบกับราคา On-Demand ปกติ ทั้งที่จริงแล้วควรเทียบกับ "ราคาที่ดีที่สุดที่ควรจะจ่าย" ซึ่งอาจเป็นราคา Savings Plans ต้องมี baseline ที่ชัดเจนสำหรับการวัดผล ไม่งั้นตัวเลขจะสวยเกินจริง

7. ลืม Data Transfer Cost

อันนี้คนมองข้ามกันเยอะ Spot Instances ที่กระจายข้าม AZ อาจทำให้ค่า data transfer ระหว่าง AZ สูงขึ้น ต้องคำนึงถึง cross-AZ traffic cost ด้วย ไม่ใช่แค่ค่า compute อย่างเดียว

8. ไม่ใช้ Automation

การจัดการ Spot Instances, monitoring commitment utilization, right-sizing recommendations — ทุกอย่างควรเป็น automated ไม่ใช่ manual process ใช้เครื่องมืออย่าง AWS Compute Optimizer, Azure Advisor, GCP Recommender ร่วมกับ Infrastructure as Code

Terraform Module สำหรับ Multi-Strategy Deployment

มาดูตัวอย่าง Terraform module ที่รวมกลยุทธ์ทั้งหมดเข้าด้วยกัน เอาไปปรับใช้ได้เลย:

# variables.tf
variable "environment" {
  description = "Environment name"
  type        = string
  default     = "production"
}

variable "spot_percentage" {
  description = "Percentage of capacity to run on Spot"
  type        = number
  default     = 70
}

variable "savings_plan_hourly_commitment" {
  description = "Hourly commitment for Compute Savings Plan (USD)"
  type        = number
  default     = 10.0
}

# main.tf
# 1. Savings Plan สำหรับ baseline commitment
resource "aws_savingsplans_plan" "compute" {
  count = var.environment == "production" ? 1 : 0

  plan_type        = "Compute"
  payment_option   = "Partial Upfront"
  term             = "1yr"
  commitment       = var.savings_plan_hourly_commitment

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

# 2. Launch Template
resource "aws_launch_template" "app" {
  name_prefix   = "${var.environment}-app-"
  image_id      = data.aws_ami.amazon_linux.id

  iam_instance_profile {
    name = aws_iam_instance_profile.app.name
  }

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    instance_metadata_tags      = "enabled"
  }

  monitoring {
    enabled = true
  }

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "${var.environment}-app"
      Environment = var.environment
    }
  }
}

# 3. Auto Scaling Group with Mixed Instances
resource "aws_autoscaling_group" "app" {
  name                = "${var.environment}-app-asg"
  desired_capacity    = 10
  max_size            = 30
  min_size            = 3
  vpc_zone_identifier = var.private_subnet_ids

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 3
      on_demand_percentage_above_base_capacity = 100 - var.spot_percentage
      spot_allocation_strategy                 = "capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
        version            = "$Latest"
      }

      dynamic "override" {
        for_each = [
          "m5.xlarge", "m5a.xlarge", "m5d.xlarge",
          "m6i.xlarge", "m6a.xlarge",
          "m7i.xlarge", "m7a.xlarge"
        ]
        content {
          instance_type     = override.value
          weighted_capacity = "1"
        }
      }
    }
  }

  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 80
    }
  }

  lifecycle {
    create_before_destroy = true
  }
}

# 4. EventBridge Rule สำหรับ Spot Interruption
resource "aws_cloudwatch_event_rule" "spot_interruption" {
  name        = "spot-interruption-warning"
  description = "Capture EC2 Spot Instance Interruption Warnings"

  event_pattern = jsonencode({
    "source"      = ["aws.ec2"]
    "detail-type" = ["EC2 Spot Instance Interruption Warning"]
  })
}

resource "aws_cloudwatch_event_target" "spot_interruption_sns" {
  rule      = aws_cloudwatch_event_rule.spot_interruption.name
  target_id = "SendToSNS"
  arn       = aws_sns_topic.alerts.arn
}

resource "aws_sns_topic" "alerts" {
  name = "${var.environment}-spot-interruption-alerts"
}

สรุปและ Action Plan

การ optimize ค่าใช้จ่าย Compute บน Cloud ไม่ได้ยากอย่างที่คิด แต่ต้องทำอย่างเป็นระบบ นี่คือ Action Plan ที่คุณเริ่มทำได้ทันที:

สัปดาห์ที่ 1: Assessment

1. วิเคราะห์ค่าใช้จ่าย Compute ปัจจุบันทั้งหมด — แยกตาม On-Demand, Reserved, Spot, Savings Plans
2. ระบุ workload ที่เป็น fault-tolerant (สามารถย้ายไป Spot ได้)
3. ดู utilization ของ Reserved Instances/Savings Plans ที่มีอยู่
4. คำนวณ potential savings สำหรับแต่ละ strategy

สัปดาห์ที่ 2-3: Quick Wins

1. ย้าย Dev/Test environments ไปใช้ Spot Instances ทั้งหมด
2. ย้าย CI/CD pipelines ไปใช้ Spot Instances
3. ตั้ง schedule สำหรับปิด Dev/Test environments นอกเวลาทำงาน
4. Right-size instances ที่ over-provisioned (ใช้ AWS Compute Optimizer หรือเครื่องมือเทียบเท่าของ Cloud Provider ที่คุณใช้)

สัปดาห์ที่ 4-6: Commitment Strategy

1. ซื้อ Savings Plans สำหรับ 70-80% ของ steady-state baseline usage
2. พิจารณา Reserved Instances สำหรับ database servers และ workload ที่มั่นใจ 100% ว่าจะไม่เปลี่ยน
3. เลือกระยะเวลา 1 ปีก่อนถ้ายังไม่มั่นใจ (ยอมได้ส่วนลดน้อยกว่าแลกกับ flexibility)

สัปดาห์ที่ 7-12: Production Spot Migration

1. Deploy Karpenter (ถ้าใช้ EKS) หรือตั้งค่า Mixed Instances ASG
2. เริ่มจากสัดส่วน Spot ต่ำก่อน (30%) แล้วค่อยๆ เพิ่ม
3. ตั้ง monitoring สำหรับ Spot Interruption Rate และ Application Impact
4. ปรับ Instance Type pool ตามข้อมูล interruption ที่ได้
5. เพิ่มสัดส่วน Spot เป็น 70-80% เมื่อมั่นใจแล้ว

ต่อเนื่อง: Monthly Review

1. Review commitment utilization ทุกเดือน
2. ปรับ Savings Plans/Reserved Instances ตาม usage ที่เปลี่ยนไป
3. ตรวจสอบ new Instance Types ที่อาจให้ price-performance ดีกว่า
4. Update FinOps dashboard และ report ให้ stakeholders

จำไว้ว่า: ตลาด Cloud กำลังจะทะลุ 1 ล้านล้านดอลลาร์ในปี 2026 และ 30-35% ของเงินนั้นถูกสูญเปล่า ทุกบาทที่คุณประหยัดได้จากการ optimize Compute costs คือบาทที่สามารถนำไปลงทุนกับ innovation, product development หรือดึง talent ดีๆ เข้ามาในทีมได้แทน

การใช้ Spot Instances, Savings Plans และ Reserved Instances อย่างชาญฉลาดไม่ใช่แค่เรื่องของการประหยัดเงิน แต่เป็นเรื่องของ Cloud Maturity องค์กรที่เข้าใจและใช้ประโยชน์จากกลไกเหล่านี้ได้ดี แสดงว่ามี Cloud Strategy ที่แข็งแกร่ง พร้อมที่จะ scale ได้อย่างยั่งยืน

เริ่มจากสิ่งเล็กๆ ก่อน — ย้าย workload สักตัวไป Spot, ซื้อ Savings Plans สำหรับ baseline usage ที่มั่นใจ, ตั้ง monitoring ให้ดี — แล้วค่อยๆ ขยายจากตรงนั้น คุณไม่จำเป็นต้องทำทุกอย่างในวันเดียว แต่สิ่งที่สำคัญที่สุดคือ เริ่มทำวันนี้