Panduan Spot Instance AWS, Azure & GCP 2026: Hemat Hingga 90% Biaya Cloud

Mengapa Spot Instance Jadi Senjata Rahasia Penghematan Cloud di 2026?

Bayangkan Anda bisa menjalankan workload yang sama persis, di infrastruktur cloud yang sama, tapi bayarnya 60-90% lebih murah. Kedengarannya terlalu bagus? Itulah yang ditawarkan spot instance — dan jujur, di tahun 2026 ini teknologinya sudah jauh lebih mature dibanding beberapa tahun lalu.

Spot instance pada dasarnya adalah kapasitas komputasi cloud yang lagi nggak terpakai, yang dijual provider dengan harga diskon besar. Analoginya simpel: seperti tiket pesawat last minute. Maskapai lebih baik jual kursi kosong dengan harga murah daripada biarkan terbang kosong. AWS, Azure, dan GCP semuanya punya varian spot instance masing-masing, dengan karakteristik dan harga yang berbeda-beda.

Data dari Cast AI Kubernetes Cost Benchmark 2025 menunjukkan bahwa organisasi yang mengadopsi spot instance secara strategis berhasil memangkas 25-35% total pengeluaran compute mereka. Survei FinOps Foundation 2025 juga menemukan bahwa adopsi spot instance naik dari 34% ke 52% di kalangan enterprise — lonjakan yang cukup signifikan.

Tapi ada catch-nya: spot instance bisa ditarik kapan saja oleh provider. AWS kasih peringatan 2 menit, sementara Azure dan GCP cuma 30 detik. Tanpa arsitektur yang tepat, penghematan biaya malah bisa berubah jadi downtime yang mahal.

Nah, di artikel ini kita bakal bahas tuntas cara memanfaatkan spot instance di ketiga cloud provider besar — lengkap dengan perbandingan harga, konfigurasi praktis, arsitektur fault-tolerant, dan strategi fallback otomatis. Panduan ini melengkapi 12 strategi optimasi biaya cloud dan panduan optimasi Kubernetes yang sudah kita bahas sebelumnya.

Perbandingan Spot Instance: AWS vs Azure vs GCP

Tabel Perbandingan Lengkap

Sebelum masuk ke implementasi, penting banget untuk paham dulu perbedaan fundamental spot instance di ketiga provider. Masing-masing punya karakteristik unik yang bakal mempengaruhi strategi penggunaannya:

Fitur	AWS Spot Instances	Azure Spot VMs	GCP Spot VMs
Diskon Maksimum	Hingga 90%	Hingga 90%	Hingga 91%
Waktu Peringatan	2 menit	30 detik	30 detik
Batas Waktu Operasi	Tidak ada	Tidak ada	Tidak ada (Preemptible: 24 jam)
Volatilitas Harga	Tinggi (~197 perubahan/bulan)	Rendah (~0,76 perubahan/bulan)	Sangat rendah (~0,35 perubahan/bulan)
Fitur Hibernate	Ya	Tidak	Tidak
Capacity Reservation	Tidak	Tidak	Tidak
Integrasi Kubernetes	EKS + Karpenter	AKS Node Pools	GKE Spot Node Pools
Rebalance Recommendation	Ya	Tidak	Tidak

AWS Spot Instances: Ekosistem Terlengkap, Harga Paling Dinamis

AWS punya ekosistem spot instance yang paling matang di antara ketiganya. Keunggulan utamanya adalah EC2 Rebalance Recommendation — semacam sinyal peringatan dini sebelum interupsi 2 menit yang sesungguhnya. Ini kasih waktu ekstra untuk memigrasikan workload secara proaktif.

Tapi, harga AWS Spot itu fluktuatif banget. Data 2025 menunjukkan rata-rata 197 perubahan harga per bulan untuk instance GPU maupun non-GPU. Artinya, Anda perlu monitoring yang lebih ketat dan strategi diversifikasi instance type yang lebih agresif dibanding provider lain.

Update 2026: AWS merilis instance berbasis Graviton4 (M8g, C8g) yang menawarkan performa per dolar 30-40% lebih baik dari generasi sebelumnya. Kabar baiknya, instance Graviton ini juga tersedia sebagai Spot Instance — jadi kalau Anda baru mulai, ini pilihan terbaik untuk workload baru.

Azure Spot VMs: Stabilitas Harga Terbaik

Azure Spot VMs unggul dalam hal prediktabilitas harga. Dengan rata-rata cuma 0,76 perubahan harga per bulan, Azure jadi pilihan ideal untuk organisasi yang butuh penganggaran lebih pasti. Microsoft juga menyediakan data eviction rate lewat Azure Resource Graph, sehingga Anda bisa pilih VM SKU dengan risiko eviction rendah (0-5%).

Menurut data Microsoft, lebih dari 90% workload berhasil diselesaikan tanpa eviction. Artinya? Sebagian besar spot VM jalan sampai pengguna sendiri yang menghentikannya. Cukup meyakinkan, kan?

GCP Spot VMs: Harga Paling Stabil dan Diskon Terdalam

GCP Spot VMs (pengganti Preemptible VMs yang sudah deprecated) menawarkan kombinasi yang menarik: harga paling stabil dengan rata-rata cuma 0,35 perubahan per bulan, plus diskon hingga 91%. Dan nggak ada lagi batas 24 jam seperti Preemptible VMs dulu.

Kekurangannya? GCP tidak menyediakan fitur rebalance recommendation seperti AWS. Anda harus mengandalkan shutdown script dengan window best-effort 30 detik untuk cleanup sebelum VM dihentikan. Agak mepet memang, tapi bisa diatasi dengan arsitektur yang tepat.

Workload yang Cocok (dan Tidak Cocok) untuk Spot Instance

Workload Ideal untuk Spot Instance

Tidak semua workload cocok untuk spot instance — ini penting dipahami sejak awal. Berikut workload yang bisa memanfaatkan spot instance secara optimal:

• Batch Processing & ETL: Job yang bisa di-checkpoint dan dilanjutkan setelah interupsi. Contoh: pemrosesan data harian, transformasi data warehouse.
• CI/CD Pipeline: Build dan test runner yang bisa diulang tanpa efek samping. Jenkins, GitHub Actions, dan GitLab CI semuanya mendukung spot instance.
• Machine Learning Training: Training model yang bisa simpan checkpoint secara periodik. Dengan spot instance, biaya training bisa turun 70-80% — ini saving yang signifikan untuk tim ML.
• Stateless Web Server & API: Aplikasi stateless di belakang load balancer yang bisa di-scale horizontal. Satu instance hilang? Traffic otomatis dialihkan ke instance lain.
• Big Data Processing: Apache Spark, Hadoop, dan EMR natively mendukung spot instance dengan retry mechanism built-in.
• Rendering & Transcoding: Video rendering, image processing, dan media transcoding yang bisa dipecah jadi task-task kecil independen.

Workload yang Harus Dihindari

Dan ini yang perlu Anda hindari — seriously, jangan coba-coba pakai spot untuk workload berikut:

• Database primer (production): Data loss dan downtime pada database primer bisa fatal. Pakai Reserved Instance atau Savings Plan untuk ini.
• Aplikasi stateful monolitik: Aplikasi yang menyimpan state di memori dan nggak bisa di-restart dengan cepat.
• Sistem real-time kritis: Trading platform, sistem kesehatan, atau aplikasi yang butuh uptime 99.99%+.
• Long-running single-threaded job: Job yang butuh waktu berjam-jam tanpa kemampuan checkpoint. Satu interupsi = mulai dari nol lagi.

Implementasi Praktis: AWS Spot Instance dengan Auto Scaling Group

Konfigurasi Mixed Instance Policy

Oke, sekarang masuk ke bagian yang seru. Strategi terbaik di AWS adalah menggunakan Auto Scaling Group (ASG) dengan mixed instance policy. Ini memungkinkan kombinasi Spot dan On-Demand instance dalam satu grup, dengan fallback otomatis:

# cloudformation-spot-asg.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: ASG dengan Mixed Spot + On-Demand Instance

Resources:
  SpotAutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName: production-api-asg
      MinSize: 4
      MaxSize: 20
      DesiredCapacity: 8
      VPCZoneIdentifier:
        - subnet-abc123  # AZ-a
        - subnet-def456  # AZ-b
        - subnet-ghi789  # AZ-c
      HealthCheckType: ELB
      HealthCheckGracePeriod: 120

      MixedInstancesPolicy:
        InstancesDistribution:
          # 20% On-Demand sebagai baseline stability
          OnDemandBaseCapacity: 2
          OnDemandPercentageAboveBaseCapacity: 20
          # Prioritaskan AZ dengan kapasitas Spot terbanyak
          SpotAllocationStrategy: capacity-optimized
          # Harga maksimum = harga On-Demand (default)
          SpotMaxPrice: ""

        LaunchTemplate:
          LaunchTemplateSpecification:
            LaunchTemplateId: !Ref ApiLaunchTemplate
            Version: !GetAtt ApiLaunchTemplate.LatestVersionNumber

          # Diversifikasi 6+ instance type untuk minimalisir interupsi
          Overrides:
            - InstanceType: m8g.large    # Graviton4 - terbaik 2026
            - InstanceType: m7g.large    # Graviton3 - fallback
            - InstanceType: m6i.large    # Intel - fallback
            - InstanceType: m6a.large    # AMD - fallback
            - InstanceType: c8g.large    # Compute-optimized Graviton4
            - InstanceType: c7g.large    # Compute-optimized Graviton3
            - InstanceType: r7g.large    # Memory-optimized (jika perlu)

  ApiLaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateData:
        ImageId: ami-0abcdef1234567890  # Amazon Linux 2023 ARM64
        InstanceType: m8g.large
        SecurityGroupIds:
          - sg-abc123
        UserData:
          Fn::Base64: |
            #!/bin/bash
            # Install aplikasi dan konfigurasi
            yum update -y
            # ... setup aplikasi Anda di sini

            # Setup Spot interruption handler
            cat > /usr/local/bin/spot-handler.sh << 'HANDLER'
            #!/bin/bash
            # Cek apakah ada notifikasi interupsi Spot
            TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
              -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

            INTERRUPT=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
              http://169.254.169.254/latest/meta-data/spot/instance-action 2>/dev/null)

            if [ ! -z "$INTERRUPT" ]; then
              echo "Spot interruption detected: $INTERRUPT"
              # Drain dari load balancer
              aws elbv2 deregister-targets \
                --target-group-arn $TARGET_GROUP_ARN \
                --targets Id=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
                  http://169.254.169.254/latest/meta-data/instance-id)
              # Tunggu koneksi aktif selesai
              sleep 30
              # Graceful shutdown aplikasi
              systemctl stop myapp
            fi
            HANDLER
            chmod +x /usr/local/bin/spot-handler.sh
            # Poll setiap 5 detik
            while true; do /usr/local/bin/spot-handler.sh; sleep 5; done &

Beberapa poin penting dari konfigurasi di atas:

• OnDemandBaseCapacity: 2 — Ini menjamin minimal 2 instance On-Demand yang nggak bisa diinterupsi, sebagai safety net Anda.
• OnDemandPercentageAboveBaseCapacity: 20 — Dari kapasitas tambahan di atas baseline, 20% bakal On-Demand dan 80% Spot. Keseimbangan yang cukup bagus antara hemat dan stabil.
• SpotAllocationStrategy: capacity-optimized — AWS bakal milih instance pool dengan kapasitas terbanyak, yang artinya kemungkinan interupsi lebih kecil.
• 7 instance type berbeda — Diversifikasi itu kunci. Semakin banyak tipe instance yang Anda daftarkan, semakin kecil kemungkinan semua pool kehabisan kapasitas bersamaan.

EventBridge untuk Handling Interruption Otomatis

Selain polling metadata endpoint, ada cara yang lebih elegan: pakai Amazon EventBridge untuk menangkap sinyal interupsi dan rebalance recommendation secara real-time.

# eventbridge-spot-handler.yaml
AWSTemplateFormatVersion: "2010-09-09"

Resources:
  SpotInterruptionRule:
    Type: AWS::Events::Rule
    Properties:
      Name: spot-interruption-handler
      Description: Tangkap sinyal interupsi Spot Instance
      EventPattern:
        source:
          - "aws.ec2"
        detail-type:
          - "EC2 Spot Instance Interruption Warning"
          - "EC2 Instance Rebalance Recommendation"
      Targets:
        - Arn: !GetAtt SpotHandlerLambda.Arn
          Id: SpotHandlerTarget

  SpotHandlerLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: spot-interruption-handler
      Runtime: python3.12
      Handler: index.handler
      Timeout: 60
      Role: !GetAtt LambdaRole.Arn
      Code:
        ZipFile: |
          import json
          import boto3
          import logging

          logger = logging.getLogger()
          logger.setLevel(logging.INFO)

          ec2 = boto3.client('ec2')
          elbv2 = boto3.client('elbv2')
          sns = boto3.client('sns')

          TARGET_GROUP_ARN = 'arn:aws:elasticloadbalancing:...'
          SNS_TOPIC_ARN = 'arn:aws:sns:...'

          def handler(event, context):
              detail_type = event['detail-type']
              instance_id = event['detail']['instance-id']

              logger.info(f"Event: {detail_type} untuk {instance_id}")

              if detail_type == 'EC2 Instance Rebalance Recommendation':
                  # Rebalance recommendation - ada waktu lebih banyak
                  logger.info(f"Rebalance recommendation untuk {instance_id}")
                  # Notifikasi tim via SNS
                  sns.publish(
                      TopicArn=SNS_TOPIC_ARN,
                      Subject=f'Spot Rebalance: {instance_id}',
                      Message=json.dumps(event, indent=2)
                  )

              elif detail_type == 'EC2 Spot Instance Interruption Warning':
                  # Interupsi akan terjadi dalam 2 menit
                  logger.info(f"Interruption warning untuk {instance_id}")

                  # 1. Deregister dari target group
                  try:
                      elbv2.deregister_targets(
                          TargetGroupArn=TARGET_GROUP_ARN,
                          Targets=[{'Id': instance_id}]
                      )
                      logger.info(f"Deregistered {instance_id} dari target group")
                  except Exception as e:
                      logger.error(f"Gagal deregister: {e}")

                  # 2. Kirim notifikasi
                  sns.publish(
                      TopicArn=SNS_TOPIC_ARN,
                      Subject=f'Spot Interruption: {instance_id}',
                      Message=json.dumps(event, indent=2)
                  )

              return {'statusCode': 200}

Implementasi Praktis: Azure Spot VMs dengan Virtual Machine Scale Set

Membuat Spot VM Scale Set dengan Azure CLI

Di Azure, Virtual Machine Scale Sets (VMSS) adalah cara terbaik untuk menjalankan Spot VMs dengan fallback otomatis. Dari pengalaman, setup ini relatif straightforward dibanding AWS. Berikut langkah-langkahnya:

# 1. Cek eviction rate untuk VM SKU yang dipilih
az rest --method post \
  --url "https://management.azure.com/subscriptions/{sub-id}/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
  --body '{
    "query": "SpotResources | where type == \"microsoft.compute/skuspotevictionrate/location\" | where sku.name in~ (\"standard_d4s_v5\", \"standard_d4as_v5\", \"standard_d4s_v4\") | where location in~ (\"southeastasia\", \"eastasia\") | project skuName=tostring(sku.name), location, evictionRate=tostring(properties.evictionRate)"
  }'

# 2. Buat VMSS dengan Spot VMs
az vmss create \
  --resource-group myResourceGroup \
  --name mySpotVMSS \
  --image Ubuntu2204 \
  --vm-sku Standard_D4s_v5 \
  --instance-count 5 \
  --priority Spot \
  --eviction-policy Deallocate \
  --max-price -1 \
  --orchestration-mode Flexible \
  --lb myLoadBalancer \
  --zones 1 2 3 \
  --generate-ssh-keys

# 3. Konfigurasi autoscale dengan mixed priority
az vmss update \
  --resource-group myResourceGroup \
  --name mySpotVMSS \
  --set virtualMachineProfile.priority=Regular

# Atau gunakan Bicep template untuk mixed Spot + On-Demand:

// spot-vmss.bicep
param location string = resourceGroup().location
param vmssName string = 'api-spot-vmss'

resource vmss 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = {
  name: vmssName
  location: location
  sku: {
    name: 'Standard_D4s_v5'
    tier: 'Standard'
    capacity: 6
  }
  properties: {
    orchestrationMode: 'Flexible'
    platformFaultDomainCount: 3

    virtualMachineProfile: {
      priority: 'Spot'
      evictionPolicy: 'Deallocate'
      billingProfile: {
        maxPrice: -1 // Bayar harga Spot berapapun (di bawah On-Demand)
      }

      scheduledEventsProfile: {
        terminateNotificationProfile: {
          enable: true
          notBeforeTimeout: 'PT5M' // 5 menit advance notice
        }
      }

      osProfile: {
        computerNamePrefix: 'spot'
        adminUsername: 'azureuser'
        linuxConfiguration: {
          disablePasswordAuthentication: true
          ssh: {
            publicKeys: [
              {
                path: '/home/azureuser/.ssh/authorized_keys'
                keyData: 'ssh-rsa AAAA...'
              }
            ]
          }
        }
      }

      storageProfile: {
        imageReference: {
          publisher: 'Canonical'
          offer: 'ubuntu-24_04-lts'
          sku: 'server'
          version: 'latest'
        }
        osDisk: {
          createOption: 'FromImage'
          managedDisk: {
            storageAccountType: 'Premium_LRS'
          }
        }
      }

      networkProfile: {
        networkInterfaceConfigurations: [
          {
            name: '${vmssName}-nic'
            properties: {
              primary: true
              ipConfigurations: [
                {
                  name: 'ipconfig1'
                  properties: {
                    subnet: {
                      id: '/subscriptions/.../subnets/default'
                    }
                    loadBalancerBackendAddressPools: [
                      {
                        id: '/subscriptions/.../backendAddressPools/myPool'
                      }
                    ]
                  }
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Poin penting: gunakan maxPrice: -1 agar VM Anda hanya di-evict karena kapasitas (bukan harga), dan aktifkan terminateNotificationProfile untuk dapat notifikasi 5 menit sebelum eviction — jauh lebih lega dari default 30 detik.

Implementasi Praktis: GCP Spot VMs dengan Managed Instance Group

Membuat Spot VM di GCP dengan gcloud CLI

Untuk GCP, prosesnya agak berbeda. Kita pakai Managed Instance Group (MIG) untuk orkestrasi spot VM-nya:

# 1. Buat instance template dengan provisioning-model SPOT
gcloud compute instance-templates create spot-api-template \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --image-family=ubuntu-2404-lts-amd64 \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=50GB \
  --boot-disk-type=pd-balanced \
  --metadata=startup-script='#!/bin/bash
    # Install dan konfigurasi aplikasi
    apt-get update && apt-get install -y nginx

    # Setup shutdown script untuk graceful termination
    cat > /etc/systemd/system/spot-shutdown.service << EOF
[Unit]
Description=Spot VM Shutdown Handler
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/spot-shutdown.sh
TimeoutStartSec=25

[Install]
WantedBy=halt.target reboot.target
EOF

    cat > /usr/local/bin/spot-shutdown.sh << EOF
#!/bin/bash
# Drain koneksi dari load balancer
# GCP otomatis menghapus instance dari backend service
# Tapi kita bisa melakukan cleanup tambahan di sini
echo "Spot VM preemption detected, graceful shutdown..."
systemctl stop nginx
# Flush log dan state
sync
EOF
    chmod +x /usr/local/bin/spot-shutdown.sh
    systemctl enable spot-shutdown.service
  '

# 2. Buat Managed Instance Group (MIG) multi-zona
gcloud compute instance-groups managed create spot-api-mig \
  --template=spot-api-template \
  --size=6 \
  --zones=asia-southeast1-a,asia-southeast1-b,asia-southeast1-c \
  --region=asia-southeast1

# 3. Konfigurasi autoscaler
gcloud compute instance-groups managed set-autoscaling spot-api-mig \
  --region=asia-southeast1 \
  --min-num-replicas=3 \
  --max-num-replicas=15 \
  --target-cpu-utilization=0.65 \
  --cool-down-period=120 \
  --mode=on

# 4. Konfigurasi autohealing (restart otomatis jika gagal health check)
gcloud compute health-checks create http spot-api-health \
  --port=80 \
  --request-path=/health \
  --check-interval=10s \
  --timeout=5s \
  --healthy-threshold=2 \
  --unhealthy-threshold=3

gcloud compute instance-groups managed set-autohealing spot-api-mig \
  --region=asia-southeast1 \
  --health-check=spot-api-health \
  --initial-delay=120

Catatan penting untuk GCP: Pakai --instance-termination-action=STOP (bukan DELETE) agar VM cuma dihentikan saat preemption. Kenapa? Karena ini memungkinkan VM di-restart otomatis oleh MIG ketika kapasitas tersedia kembali, tanpa perlu bikin instance baru dari awal. Hemat waktu dan effort.

Arsitektur Fault-Tolerant untuk Spot Instance

Pattern 1: Layered Purchasing Strategy

Ini strategi yang menurut saya paling efektif — dan paling sering saya rekomendasikan. Intinya, gabungkan beberapa model pembelian dalam satu arsitektur:

• Layer 1 — Savings Plan/Reserved Instance (20-30%): Untuk baseline workload yang selalu jalan 24/7. Hemat 30-72% dari harga On-Demand.
• Layer 2 — Spot Instance (50-60%): Untuk mayoritas kapasitas variable. Hemat 60-90% dari harga On-Demand.
• Layer 3 — On-Demand (10-20%): Sebagai safety buffer untuk sudden spike atau saat kapasitas Spot nggak tersedia.

Dengan komposisi ini, rata-rata penghematan keseluruhan bisa sampai 50-65% dibanding kalau semua pakai On-Demand. Lumayan banget, kan?

Pattern 2: Queue-Based Architecture untuk Batch Processing

Arsitektur berbasis queue itu yang paling natural untuk spot instance. Alasannya sederhana: ada pemisahan jelas antara submission dan eksekusi task. Kalau satu worker mati, task-nya tinggal diambil worker lain.

#!/usr/bin/env python3
"""
Queue-based Spot Instance Worker
Menggunakan AWS SQS dengan graceful interruption handling
"""

import boto3
import json
import signal
import sys
import time
import requests
from datetime import datetime

sqs = boto3.client('sqs', region_name='ap-southeast-1')
s3 = boto3.client('s3', region_name='ap-southeast-1')

QUEUE_URL = 'https://sqs.ap-southeast-1.amazonaws.com/123456789/processing-queue'
RESULT_BUCKET = 'my-results-bucket'
CHECKPOINT_BUCKET = 'my-checkpoint-bucket'

class SpotWorker:
    def __init__(self):
        self.running = True
        self.current_message = None
        self.current_task_id = None

        # Handle SIGTERM (dikirim saat Spot interruption)
        signal.signal(signal.SIGTERM, self.handle_shutdown)
        signal.signal(signal.SIGINT, self.handle_shutdown)

    def handle_shutdown(self, signum, frame):
        print(f"[{datetime.now()}] Shutdown signal diterima (signal {signum})")
        self.running = False

        # Simpan checkpoint jika ada task yang sedang berjalan
        if self.current_task_id:
            self.save_checkpoint()

        # Kembalikan message ke queue agar bisa diproses worker lain
        if self.current_message:
            self.return_message_to_queue()

        sys.exit(0)

    def check_spot_interruption(self):
        """Cek metadata endpoint untuk spot interruption notice"""
        try:
            token_resp = requests.put(
                'http://169.254.169.254/latest/api/token',
                headers={'X-aws-ec2-metadata-token-ttl-seconds': '21600'},
                timeout=1
            )
            resp = requests.get(
                'http://169.254.169.254/latest/meta-data/spot/instance-action',
                headers={'X-aws-ec2-metadata-token': token_resp.text},
                timeout=1
            )
            if resp.status_code == 200:
                print(f"Spot interruption notice: {resp.json()}")
                return True
        except requests.exceptions.RequestException:
            pass
        return False

    def save_checkpoint(self):
        """Simpan progress saat ini ke S3"""
        checkpoint = {
            'task_id': self.current_task_id,
            'progress': self.current_progress,
            'timestamp': datetime.now().isoformat()
        }
        s3.put_object(
            Bucket=CHECKPOINT_BUCKET,
            Key=f'checkpoints/{self.current_task_id}.json',
            Body=json.dumps(checkpoint)
        )
        print(f"Checkpoint tersimpan untuk task {self.current_task_id}")

    def load_checkpoint(self, task_id):
        """Muat checkpoint sebelumnya jika ada"""
        try:
            resp = s3.get_object(
                Bucket=CHECKPOINT_BUCKET,
                Key=f'checkpoints/{task_id}.json'
            )
            return json.loads(resp['Body'].read())
        except s3.exceptions.NoSuchKey:
            return None

    def return_message_to_queue(self):
        """Kembalikan message visibility agar bisa diproses ulang"""
        sqs.change_message_visibility(
            QueueUrl=QUEUE_URL,
            ReceiptHandle=self.current_message['ReceiptHandle'],
            VisibilityTimeout=0  # Langsung visible kembali
        )
        print("Message dikembalikan ke queue")

    def process_task(self, task_data):
        """Proses task dengan periodic checkpoint"""
        task_id = task_data['task_id']
        self.current_task_id = task_id
        self.current_progress = 0

        # Cek apakah ada checkpoint sebelumnya
        checkpoint = self.load_checkpoint(task_id)
        start_from = checkpoint['progress'] if checkpoint else 0

        if start_from > 0:
            print(f"Melanjutkan task {task_id} dari progress {start_from}")

        total_items = task_data.get('total_items', 100)

        for i in range(start_from, total_items):
            if not self.running:
                break

            # Cek spot interruption setiap 10 iterasi
            if i % 10 == 0 and self.check_spot_interruption():
                self.save_checkpoint()
                self.return_message_to_queue()
                return False

            # ... proses item ke-i ...
            time.sleep(0.1)  # Simulasi processing
            self.current_progress = i + 1

            # Checkpoint setiap 50 item
            if (i + 1) % 50 == 0:
                self.save_checkpoint()

        self.current_task_id = None
        return True

    def run(self):
        """Main loop: ambil dan proses message dari queue"""
        print("Spot Worker dimulai, menunggu task...")

        while self.running:
            response = sqs.receive_message(
                QueueUrl=QUEUE_URL,
                MaxNumberOfMessages=1,
                WaitTimeSeconds=20,
                VisibilityTimeout=300
            )

            messages = response.get('Messages', [])
            if not messages:
                continue

            msg = messages[0]
            self.current_message = msg
            task_data = json.loads(msg['Body'])

            print(f"Memproses task: {task_data['task_id']}")

            success = self.process_task(task_data)

            if success:
                # Hapus message dari queue jika selesai
                sqs.delete_message(
                    QueueUrl=QUEUE_URL,
                    ReceiptHandle=msg['ReceiptHandle']
                )
                print(f"Task {task_data['task_id']} selesai")

            self.current_message = None

if __name__ == '__main__':
    worker = SpotWorker()
    worker.run()

Pattern queue-based ini powerful banget karena tiga alasan: pertama, kalau Spot Instance diinterupsi, message otomatis balik ke queue setelah visibility timeout berakhir. Kedua, worker lain bisa lanjutkan dari checkpoint terakhir. Dan ketiga, nggak ada data yang hilang. Simpel tapi efektif.

Pattern 3: Kubernetes Spot Node Pool dengan Karpenter

Buat organisasi yang sudah pakai Kubernetes (cek panduan optimasi Kubernetes kami), Karpenter adalah pilihan terbaik untuk provisioning spot node secara otomatis. Honestly, ini game changer kalau Anda sudah familiar dengan EKS:

# karpenter-spot-nodepool.yaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    spec:
      requirements:
        # Diversifikasi instance type
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["6"]
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values: ["4", "8", "16"]
        # Prioritaskan Spot, fallback ke On-Demand
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        # Multi-AZ untuk high availability
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
        # Prioritaskan Graviton (ARM64) untuk cost efficiency
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64", "amd64"]

      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

  # Budget: jangan hapus lebih dari 10% node dalam 10 menit
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s
    budgets:
      - nodes: "10%"
        duration: 10m

  # Batas total resource
  limits:
    cpu: 200
    memory: 400Gi

---
# Konfigurasi node class
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster

  # Aktifkan Spot interruption handling
  instanceStorePolicy: RAID0

Karpenter secara otomatis bakal: milih instance type dengan harga Spot terbaik, lakukan bin-packing yang efisien, ganti node yang diinterupsi dengan cepat, dan fallback ke On-Demand kalau kapasitas Spot lagi nggak tersedia. Semuanya hands-off setelah konfigurasi awal.

Monitoring dan Optimasi Berkelanjutan

Dashboard Monitoring Spot Instance

Monitoring spot instance itu beda dari instance biasa — ada metrik tambahan yang perlu dipantau seperti interruption rate, savings percentage, dan fallback frequency. Berikut contoh Terraform untuk bikin CloudWatch dashboard-nya:

# Terraform: CloudWatch Dashboard untuk Spot Monitoring
resource "aws_cloudwatch_dashboard" "spot_monitoring" {
  dashboard_name = "spot-instance-monitoring"

  dashboard_body = jsonencode({
    widgets = [
      {
        type   = "metric"
        x      = 0
        y      = 0
        width  = 12
        height = 6
        properties = {
          title   = "Spot vs On-Demand Instance Count"
          metrics = [
            ["AWS/AutoScaling", "GroupTotalInstances",
             "AutoScalingGroupName", "production-api-asg",
             { stat = "Average", period = 300 }],
            ["AWS/EC2", "SpotInstanceCount",
             "AutoScalingGroupName", "production-api-asg",
             { stat = "Average", period = 300 }]
          ]
          view    = "timeSeries"
          region  = "ap-southeast-1"
          period  = 300
        }
      },
      {
        type   = "metric"
        x      = 12
        y      = 0
        width  = 12
        height = 6
        properties = {
          title   = "Spot Interruption Events"
          metrics = [
            ["SpotMetrics", "InterruptionCount",
             { stat = "Sum", period = 3600 }],
            ["SpotMetrics", "RebalanceRecommendationCount",
             { stat = "Sum", period = 3600 }]
          ]
          view    = "timeSeries"
          region  = "ap-southeast-1"
        }
      },
      {
        type   = "metric"
        x      = 0
        y      = 6
        width  = 24
        height = 6
        properties = {
          title   = "Cost Savings: Spot vs On-Demand"
          metrics = [
            ["SpotMetrics", "HourlySavings",
             { stat = "Sum", period = 3600 }],
            ["SpotMetrics", "SpotSpend",
             { stat = "Sum", period = 3600 }],
            ["SpotMetrics", "OnDemandEquivalent",
             { stat = "Sum", period = 3600 }]
          ]
          view    = "timeSeries"
          region  = "ap-southeast-1"
        }
      }
    ]
  })
}

KPI yang Harus Dipantau

Untuk memastikan strategi spot instance Anda berjalan optimal, berikut KPI yang wajib dipantau secara rutin:

• Spot Adoption Rate: Persentase total compute yang jalan di Spot Instance. Target: 30-60% untuk production, 80-100% untuk non-production.
• Interruption Rate: Frekuensi interupsi per minggu. Rata-rata industri kurang dari 5%, tapi target Anda harusnya di bawah 3% dengan diversifikasi yang tepat.
• Fallback Frequency: Seberapa sering sistem harus fallback ke On-Demand. Kalau terlalu sering, itu sinyal bahwa diversifikasi instance type perlu ditambah.
• Effective Discount Rate: Diskon rata-rata aktual yang Anda dapatkan. Bandingkan spend aktual vs biaya On-Demand equivalent.
• Mean Time to Recovery (MTTR): Waktu rata-rata dari interupsi sampai workload jalan lagi. Target: di bawah 5 menit.

Kesalahan Umum dan Cara Menghindarinya

1. Hanya Menggunakan Satu Instance Type

Ini kesalahan paling fatal — dan sayangnya masih sering saya temui. Kalau Anda cuma pakai satu tipe instance (misalnya m5.xlarge), seluruh fleet Anda bisa diinterupsi bersamaan saat pool tersebut kehabisan kapasitas. Selalu diversifikasi ke minimal 6-8 instance type yang berbeda, termasuk berbagai family (m, c, r) dan generasi.

2. Tidak Menyiapkan Fallback ke On-Demand

Spot instance tanpa mekanisme fallback sama aja dengan berjudi. Pastikan Auto Scaling Group atau Instance Group Anda bisa otomatis meluncurkan On-Demand instance saat kapasitas Spot nggak tersedia.

3. Menggunakan Spot untuk Stateful Workload Tanpa Checkpoint

Menjalankan database atau long-running job tanpa mekanisme checkpoint di Spot Instance? Itu resep bencana. Kalau Anda harus pakai Spot untuk workload seperti ML training, pastikan checkpoint disimpan setiap 5-15 menit. Nggak ada tawar-menawar soal ini.

4. Mengabaikan Cross-AZ Deployment

Kapasitas Spot bervariasi antar Availability Zone. Semua Spot Instance di satu AZ? Risiko interupsi massal meningkat drastis. Selalu deploy ke minimal 3 AZ — ini non-negotiable.

5. Tidak Memonitor Penghematan Aktual

Banyak tim mengasumsikan mereka hemat besar dengan Spot Instance, tapi nggak pernah ngukur secara aktual. Jangan jadi tim seperti itu. Gunakan AWS Cost Explorer, Azure Cost Management, atau GCP Billing untuk memverifikasi penghematan yang sebenarnya — Anda mungkin kaget hasilnya (positif maupun negatif).

FAQ: Pertanyaan yang Sering Diajukan tentang Spot Instance

Apakah spot instance aman untuk production?

Ya, spot instance aman untuk production asalkan arsitektur Anda dirancang dengan benar. Kuncinya: gunakan multiple instance type (minimal 6), deploy di beberapa Availability Zone, siapkan fallback ke On-Demand, dan pastikan aplikasi Anda stateless atau punya mekanisme checkpoint. Perusahaan besar seperti Netflix dan Lyft menjalankan mayoritas workload production mereka di spot instance — jadi bukan hal baru.

Berapa besar penghematan realistis dari spot instance?

Penghematan aktual tergantung provider dan instance type, tapi secara umum: AWS kasih diskon 60-90%, Azure 60-90%, dan GCP 60-91%. Dengan strategi layered (kombinasi Spot + Savings Plan + On-Demand), penghematan total compute biasanya berkisar 40-65% dibanding full On-Demand.

Apa yang terjadi saat spot instance diinterupsi?

Provider mengirim sinyal peringatan: AWS kasih 2 menit, Azure dan GCP kasih 30 detik (Azure bisa dikonfigurasi hingga 5 menit via Scheduled Events). Dalam window ini, aplikasi Anda harus melakukan graceful shutdown: simpan state, drain koneksi dari load balancer, dan selesaikan request yang sedang berjalan. Setelah itu, Auto Scaling Group otomatis meluncurkan instance pengganti.

Spot instance mana yang paling cocok untuk pemula?

Kalau baru mulai, jangan langsung ke production. Coba dulu dengan workload non-production: CI/CD pipeline, development/staging environment, atau batch processing. Azure Spot VMs jadi pilihan terbaik untuk pemula karena harganya paling stabil dan prediktabel. Setelah nyaman dan paham polanya, baru perluas ke workload production yang stateless.

Bagaimana cara memilih antara AWS, Azure, dan GCP spot instance?

Pilih berdasarkan kebutuhan utama Anda: GCP untuk stabilitas harga dan prediktabilitas tertinggi (harga berubah cuma 0,35x/bulan), Azure untuk keseimbangan antara harga stabil dan ekosistem Microsoft (terutama kalau sudah punya lisensi), dan AWS untuk ekosistem terlengkap dengan fitur rebalance recommendation dan hibernate — meski harganya paling fluktuatif (197 perubahan/bulan).