Spot Instance strategije za AWS, Azure i GCP: Uštedite do 90% na troškovima oblaka

Uvod: Zašto su spot instance najmoćniji alat za smanjenje troškova oblaka

U svijetu cloud computinga postoji jedan resurs koji većina organizacija ili potpuno ignorira ili — što je možda još gore — koristi na pogrešan način. Govorim o spot instancama. Dok većina tvrtki uredno plaća punu cijenu za On-Demand kapacitet, pametnije organizacije koriste spot instance i ostvaruju uštede do 90% na istim računalnim resursima.

Zvuči predobro da bude istina? Iskreno, i ja sam tako mislio kad sam prvi put čuo za ovo. Ali nije prevara — postoji samo jedna kvaka: cloud provider može te resurse povući s obavijesti od samo 30 sekundi do 2 minute.

Prema najnovijim podacima iz 2025. godine, organizacije koje koriste mješavinu On-Demand i spot instanci postižu prosječnu uštedu od 59%, dok one koje pokreću isključivo spot instance bilježe smanjenje troškova od čak 77%. A s obzirom na to da globalno tržište FinOpsa u 2025. doseže vrijednost od 5,5 milijardi dolara uz godišnji rast od 34,8%, jasno je da optimizacija troškova oblaka više nije nice-to-have — postala je strateški imperativ.

Dakle, krenimo redom. U ovom vodiču proći ćemo kroz sve što trebate znati o spot instancama na tri velika cloud providera — AWS, Azure i GCP. Od osnovnih koncepata do naprednih strategija upravljanja prekidima, Karpenter integracije i hibridnih pristupa koji kombiniraju spot instance sa Savings Planovima i reserved instancama.

Što su spot instance i kako zapravo funkcioniraju

Spot instance su vrsta cloud računalnih resursa dostupnih po znatno nižim cijenama u usporedbi s tradicionalnim On-Demand tarifama. U suštini, to je neiskorišteni računalni kapacitet koji cloud provideri prodaju po sniženim cijenama kako bi osigurali maksimalnu iskoristivost svoje infrastrukture. Zamislite to kao last-minute ponude za hotelske sobe — hotel radije proda sobu jeftino nego da ostane prazna.

Ali evo ključne razlike u odnosu na On-Demand instance: spot instance mogu biti prekinute od strane providera kada im taj kapacitet zatreba za korisnike koji plaćaju punu cijenu. To znači da vaš workload mora biti dizajniran da podnese iznenadne prekide. Nije to toliko strašno koliko zvuči, ali zahtijeva drugačiji pristup arhitekturi.

Kako svaki provider definira spot instance

Svaki od tri velika cloud providera ima svoju implementaciju s različitim karakteristikama:

• AWS Spot Instances: Neiskorišteni EC2 kapacitet dostupan po popustu do 90%. AWS šalje obavijest o prekidu 2 minute prije terminacije — što vam daje barem malo prostora za graceful shutdown.
• Azure Spot VMs: Microsoftova implementacija fokusirana na prekidive workloadove s popustima do 90%. Ovdje je situacija nešto napetija jer Azure pruža obavijest od samo 30 sekundi prije eviction događaja.
• GCP Spot VMs: Evolucija prijašnjih preemptible VM-ova s popustima do 91%. Google Cloud također daje obavijest od 30 sekundi, ali ponašanje prekida je konzistentnije nego kod AWS-a (što je za neke timove zapravo prednost).

Usporedba ključnih karakteristika

Prije nego što zaronimo u detalje svake platforme, pogledajmo usporedbu na jednom mjestu:

Karakteristika	AWS Spot	Azure Spot VM	GCP Spot VM
Maksimalni popust	Do 90%	Do 90%	Do 91%
Obavijest o prekidu	2 minute	30 sekundi	30 sekundi
Stabilnost	Veća stopa prekida u prvom satu	Stabilnija, manje ranih prekida	Usporediva s Azureom
Kubernetes integracija	EKS + Karpenter	AKS	GKE
Hibernate opcija	Da	Ne	Ne
Alokacijske strategije	Capacity-optimized, price-capacity-optimized	Eviction policy (deallocate/delete)	Automatsko upravljanje

AWS Spot Instance: Detaljni vodič

Amazon Web Services nudi najzreliji i najfleksibilniji ekosustav za spot instance — i to s razlogom. S obzirom na veličinu AWS-ove infrastrukture, količina dostupnog spot kapaciteta je ogromna, ali isto tako varijabilna. AWS Spot Advisor kategorizira stope prekida u raspone: ispod 5%, 5-10%, 10-15%, 15-20% i iznad 20%. Moj savjet? Ciljajte na instance s kategorijom ispod 10% za produkciju.

Postavljanje Auto Scaling grupe sa spot instancama

Najrobusniji način korištenja spot instanci na AWS-u je kroz Auto Scaling grupe s mješovitom konfiguracijom instanci. Evo kako to izgleda u praksi:

# AWS CLI: Kreiranje launch template za spot instance
aws ec2 create-launch-template \
  --launch-template-name spot-web-template \
  --version-description "v1" \
  --launch-template-data '{"ImageId": "ami-0abcdef1234567890", "InstanceRequirements": {"VCpuCount": {"Min": 2, "Max": 8}, "MemoryMiB": {"Min": 4096, "Max": 16384}, "InstanceGenerations": ["current"], "SpotMaxPricePercentageOverLowestPrice": 100}, "TagSpecifications": [{"ResourceType": "instance", "Tags": [{"Key": "Environment", "Value": "production"}, {"Key": "CostCenter", "Value": "CC-WEBTEAM"}, {"Key": "SpotManaged", "Value": "true"}]}]}'

Obratite posebnu pozornost na InstanceRequirements blok — umjesto specificiranja točnih tipova instanci, koristimo attribute-based instance type selection. To AWS-u daje fleksibilnost da sam odabere optimalan tip instance ovisno o trenutnoj dostupnosti i cijeni. Ovo je, iskreno govoreći, jedna od najvažnijih best praksi za smanjenje stope prekida, a iznenađujuće malo timova je koristi.

Konfiguracija Mixed Instances Policy

Za produkcijske workloadove, preporučujem korištenje mješovite politike koja kombinira On-Demand i spot instance:

# CloudFormation: Auto Scaling grupa s mješovitim instancama
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  WebASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 4
      MaxSize: 20
      DesiredCapacity: 8
      MixedInstancesPolicy:
        InstancesDistribution:
          OnDemandBaseCapacity: 2
          OnDemandPercentageAboveBaseCapacity: 25
          SpotAllocationStrategy: price-capacity-optimized
          SpotInstancePools: 0
        LaunchTemplate:
          LaunchTemplateSpecification:
            LaunchTemplateId: !Ref SpotWebTemplate
            Version: !GetAtt SpotWebTemplate.LatestVersionNumber
          Overrides:
            - InstanceType: m6i.xlarge
            - InstanceType: m6a.xlarge
            - InstanceType: m5.xlarge
            - InstanceType: m5a.xlarge
            - InstanceType: c6i.xlarge
            - InstanceType: c6a.xlarge
            - InstanceType: r6i.xlarge
            - InstanceType: r6a.xlarge
      VPCZoneIdentifier:
        - subnet-abc123
        - subnet-def456
        - subnet-ghi789

Ova konfiguracija osigurava da uvijek imate barem 2 On-Demand instance kao stabilnu bazu, dok se ostatak popunjava prema price-capacity-optimized strategiji. Diversifikacija preko 8 tipova instanci i 3 zone dostupnosti dramatično smanjuje vjerojatnost masovnog prekida — a to je upravo ono što želite u produkciji.

Upravljanje EC2 Spot prekidima

AWS nudi dva mehanizma za proaktivno upravljanje prekidima:

• Spot Instance Interruption Notice: Obavijest 2 minute prije terminacije, dostupna putem instance metadata servisa i EventBridge-a.
• EC2 Instance Rebalance Recommendation: Rani signal koji upozorava da je spot instanca pod povećanim rizikom od prekida. Ovo vam daje dodatno vrijeme za reakciju, i definitivno ga ne biste trebali ignorirati.

# Python skripta za praćenje spot prekida putem metadata servisa
import requests
import time
import subprocess
import sys

METADATA_URL = "http://169.254.169.254/latest/meta-data/spot/instance-action"
TOKEN_URL = "http://169.254.169.254/latest/api/token"

def get_token():
    """Dohvat IMDSv2 tokena."""
    response = requests.put(TOKEN_URL,
                          headers={"X-aws-ec2-metadata-token-ttl-seconds": "300"},
                          timeout=2)
    return response.text

def check_spot_interruption():
    """Provjera postoji li obavijest o prekidu spot instance."""
    token = get_token()
    headers = {"X-aws-ec2-metadata-token": token}
    try:
        response = requests.get(METADATA_URL, headers=headers, timeout=2)
        if response.status_code == 200:
            return response.json()
    except requests.exceptions.RequestException:
        pass
    return None

def graceful_shutdown():
    """Izvršavanje graceful shutdown procedura."""
    print("SPOT PREKID DETEKTIRAN! Pokrecem graceful shutdown...")
    subprocess.run(["systemctl", "stop", "nginx"], check=False)
    time.sleep(10)
    subprocess.run(["aws", "s3", "sync", "/app/state/",
                    "s3://my-app-state/checkpoint/"], check=False)
    print("Graceful shutdown zavrsen.")
    sys.exit(0)

if __name__ == "__main__":
    print("Pracenje spot prekida pokrenuto...")
    while True:
        action = check_spot_interruption()
        if action:
            print(f"Akcija: {action}")
            graceful_shutdown()
        time.sleep(5)

Azure Spot VM: Specifičnosti i strategije

Azureov pristup spot instancama razlikuje se od AWS-a u nekoliko ključnih aspekata. Prema najnovijim istraživanjima, Azure Spot VM-ovi su zapravo stabilniji — imaju manje ranih prekida, posebno u prvih 12 sati rada. No, tu je i loša vijest: obavijest o eviction događaju je znatno kraća, samo 30 sekundi. Dakle, vaša shutdown procedura mora biti brza i efikasna.

Kreiranje Spot VM-a na Azureu

# Azure CLI: Kreiranje Spot VM-a
az vm create \
  --resource-group rg-spot-workloads \
  --name spot-worker-01 \
  --image Ubuntu2204 \
  --size Standard_D4s_v5 \
  --priority Spot \
  --eviction-policy Deallocate \
  --max-price 0.08 \
  --admin-username azureadmin \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --tags Environment=production CostCenter=CC-4521 SpotManaged=true

Ključni parametar ovdje je --eviction-policy. Azure nudi dvije opcije:

• Deallocate: VM se delocira, ali disk i mrežna konfiguracija ostaju sačuvani. VM se može ponovno pokrenuti kad kapacitet postane dostupan. Plaćate samo pohranu — što je super za workloadove koji se mogu pauzirati.
• Delete: VM i svi njegovi resursi se potpuno brišu. Koristite za potpuno efemerne workloadove gdje vam stanje uopće nije bitno.

Azure Spot VM Scale Sets

Za ozbiljnije produkcijske scenarije, Azure preporuča korištenje Virtual Machine Scale Sets (VMSS) sa spot konfiguracijom:

// Bicep template: Spot VMSS konfiguracija
resource spotVMSS 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = {
  name: 'spot-worker-vmss'
  location: resourceGroup().location
  sku: {
    name: 'Standard_D4s_v5'
    tier: 'Standard'
    capacity: 10
  }
  properties: {
    overprovision: true
    upgradePolicy: {
      mode: 'Automatic'
    }
    virtualMachineProfile: {
      priority: 'Spot'
      evictionPolicy: 'Deallocate'
      billingProfile: {
        maxPrice: -1  // Placajte do On-Demand cijene
      }
      scheduledEventsProfile: {
        terminateNotificationProfile: {
          enable: true
          notBeforeTimeout: 'PT5M'
        }
      }
    }
  }
}

Obratite pozornost na scheduledEventsProfile — Azure Scheduled Events API pruža obavijest o nadolazećem eviction događaju, čime vaša aplikacija dobiva više vremena za graceful shutdown nego što pruža osnovna 30-sekundna obavijest. Definitivno uključite ovo u svoju konfiguraciju.

Azure Spot praćenje troškova

Azure Cost Management nudi specifične filtre za praćenje spot troškova. Mala, ali korisna preporuka: kreirajte zasebnu resource grupu za spot resurse i postavite budgetska upozorenja putem Azure Cost Alerts. Zvuči kao sitnica, ali osigurava transparentnost troškova prema FinOps principima i sprječava ona neugodna iznenađenja na mjesečnom računu.

GCP Spot VM: Evolucija od preemptible VM-ova

Google Cloud je značajno unaprijedio svoju ponudu spot instanci. Originalni preemptible VM-ovi imali su jedno prilično neugodno ograničenje — Google bi ih automatski terminirao nakon 24 sata, bez obzira na potražnju. Novi GCP Spot VM-ovi nemaju to ograničenje, što ih čini znatno praktičnijima za duže workloadove.

Kreiranje Spot VM-a na GCP-u

# gcloud CLI: Kreiranje Spot VM-a
gcloud compute instances create spot-worker-01 \
  --zone=europe-west1-b \
  --machine-type=e2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --maintenance-policy=TERMINATE \
  --labels=environment=production,cost-center=cc-4521,spot-managed=true

GCP nudi dva ponašanja pri terminaciji:

• STOP: VM se zaustavlja, ali se može ponovno pokrenuti. Disk i IP adresa ostaju — praktično za workloadove koji se trebaju nastaviti.
• DELETE: VM se potpuno briše. Koristite za batch poslove gdje stanje nije bitno.

Managed Instance Groups sa Spot VM-ovima

Za skalabilne workloadove na GCP-u, koristite Managed Instance Groups (MIG) s auto-healingom:

# Kreiranje instance template za Spot VM-ove
gcloud compute instance-templates create spot-template \
  --machine-type=e2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=50GB

# Kreiranje Managed Instance Group
gcloud compute instance-groups managed create spot-mig \
  --template=spot-template \
  --size=5 \
  --zone=europe-west1-b

# Konfiguracija autoscalinga
gcloud compute instance-groups managed set-autoscaling spot-mig \
  --zone=europe-west1-b \
  --min-num-replicas=3 \
  --max-num-replicas=20 \
  --target-cpu-utilization=0.65 \
  --cool-down-period=120

Kad Google Cloud preemptira Spot VM unutar MIG-a, grupa automatski kreira zamjenski VM prema specifikacijama instance template-a. To osigurava da vaš workload uvijek ima minimalni kapacitet, čak i tijekom perioda visokog prekida. Jednostavno — ali elegantno rješenje.

Kombinacija Spot VM-ova i Committed Use Discountova na GCP-u

GCP nudi Committed Use Discounts (CUD) za dugoročne obveze — popusti do 57% za 1-3 godine. Optimalna strategija (i ono što zapravo rade timovi koji znaju što rade) je koristiti CUD-ove za bazni kapacitet, dakle workloadove koji uvijek rade, a Spot VM-ove za burst kapacitet. Time kombinirate predvidljivost CUD-ova s fleksibilnošću i ekstremnim popustima spot instanci.

Upravljanje prekidima: Arhitektura otporna na greške

Evo ključne promjene u razmišljanju koja dijeli uspješne od neuspješnih spot implementacija: prekide morate tretirati kao očekivane događaje, a ne kao iznimke. Ako vaša arhitektura polazi od pretpostavke da će svaki čvor prije ili kasnije biti prekinut, spot instance postaju izuzetno moćan alat. Ako ne polazi — imat ćete problema.

Principi dizajna otpornog na prekide

1. Stateless dizajn: Aplikacija ne smije pohranjivati kritično stanje u memoriji ili na lokalnom disku. Koristite vanjske sustave za pohranu stanja — Redis, DynamoDB, Cloud Firestore.
2. Checkpointing: Za dugotrajne poslove (batch processing, ML trening), implementirajte periodičko spremanje stanja na trajnu pohranu (S3, Azure Blob, GCS). Ovo je nenegocijabilno.
3. Graceful shutdown: Svaka aplikacija mora imati handler za SIGTERM signal koji obavlja čišćenje, završava tekuće transakcije i sprema stanje.
4. Idempotentne operacije: Svaki zadatak mora biti siguran za ponovljeno izvršavanje. Ako se prekine na pola, ponovni pokretanje ne smije uzrokovati duplikate ili korupciju podataka.
5. Distribuirani red čekanja: Koristite SQS, Azure Queue ili Pub/Sub za koordinaciju posla. Ako worker nestane, poruka se automatski vraća u red i čeka sljedećeg dostupnog workera.

Implementacija graceful shutdown u kontejnerima

# Dockerfile s pravilnim signaling konfiguracijom
FROM python:3.12-slim

COPY app/ /app/
WORKDIR /app

# STOPSIGNAL osigurava da Docker salje SIGTERM
STOPSIGNAL SIGTERM

# Koristimo exec form da PID 1 bude nasa aplikacija
ENTRYPOINT ["python", "worker.py"]

# worker.py - Python worker s graceful shutdown podrskom
import signal
import sys
import time
import json

class SpotAwareWorker:
    def __init__(self):
        self.running = True
        self.current_job = None
        signal.signal(signal.SIGTERM, self.handle_shutdown)
        signal.signal(signal.SIGINT, self.handle_shutdown)

    def handle_shutdown(self, signum, frame):
        print(f"Primljen signal {signum}. Pokrecem graceful shutdown...")
        self.running = False

        if self.current_job:
            checkpoint = {
                "job_id": self.current_job["id"],
                "progress": self.current_job["progress"],
                "state": self.current_job["state"]
            }
            with open("/shared/checkpoint.json", "w") as f:
                json.dump(checkpoint, f)
            print(f"Checkpoint spremljen za posao {self.current_job['id']}")

        print("Graceful shutdown zavrsen.")
        sys.exit(0)

    def process_job(self, job):
        self.current_job = job
        for i in range(job["total_steps"]):
            if not self.running:
                return
            job["progress"] = i + 1
            job["state"] = f"step_{i+1}"
            time.sleep(1)
        self.current_job = None

    def run(self):
        print("Worker pokrenut. Cekam poslove...")
        while self.running:
            time.sleep(1)

if __name__ == "__main__":
    worker = SpotAwareWorker()
    worker.run()

Karpenter: Automatizacija spot instanci u Kubernetesu

Ako koristite Kubernetes (a hajde, recimo otvoreno — velike su šanse da koristite), Karpenter je alat koji jednostavno morate poznavati. Razvijen od strane AWS-a i doniran Cloud Native Computing Foundation (CNCF), Karpenter je promijenio način na koji Kubernetes klasteri upravljaju čvorovima — posebno kad su u pitanju spot instance.

Za razliku od tradicionalnog Cluster Autoscalera koji se oslanja na unaprijed definirane node grupe, Karpenter dinamički provisionira čvorove na temelju stvarnih potreba workloadova u stvarnom vremenu. Rezultat? Provisioniranje čvorova za 45-60 sekundi umjesto 3-5 minuta, smanjenje troškova od 15-20% i redukcija operativnog opterećenja od 80% prema iskustvima velikih korisnika poput Salesforcea. Brojke govore same za sebe.

Karpenter NodePool konfiguracija za spot instance

# Karpenter v1.0+ NodePool za spot workloadove
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    metadata:
      labels:
        node-type: spot
        team: platform
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["m", "c", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["4"]
        - key: karpenter.k8s.aws/instance-size
          operator: In
          values: ["large", "xlarge", "2xlarge"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: "100"
    memory: "400Gi"
  weight: 80
---
# NodePool za kriticne workloadove (On-Demand)
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: critical-workloads
spec:
  template:
    metadata:
      labels:
        node-type: on-demand
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["m", "r"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      taints:
        - key: workload-type
          value: critical
          effect: NoSchedule
  limits:
    cpu: "32"
    memory: "128Gi"
  weight: 20

Ova konfiguracija koristi dva NodePoola: jedan za spot workloadove s visokim prioritetom (weight: 80) i jedan za kritične workloadove na On-Demand instancama. Karpenter će automatski diversificirati preko kategorija instanci (m, c, r) i veličina, čime se smanjuje vjerojatnost prekida. Elegantno, zar ne?

Spot-to-Spot konsolidacija

Jedna od stvarno korisnih novijih Karpenter funkcionalnosti (od verzije v0.34.0) je spot-to-spot konsolidacija. Karpenter može zamijeniti postojeće spot čvorove jeftinijim spot instancama kada postanu dostupne, čime se dodatno optimiziraju troškovi bez ikakve manualne intervencije. Imajte na umu da za aktiviranje ove funkcionalnosti trebate minimalno 15 različitih tipova instanci u konfiguraciji.

Automatsko upravljanje prekidima u Karpenteru

Kad AWS pošalje obavijest o spot prekidu, Karpenter automatski izvršava sljedeći proces:

1. AWS šalje obavijest o prekidu u SQS red
2. Karpenter prima poruku iz SQS-a
3. Karpenter stavlja čvor u cordon stanje — novi podovi se više ne raspoređuju na njega
4. Karpenter provisionira zamjenski čvor
5. Podovi se preraspoređuju na novi čvor putem drain mehanizma
6. Prekinuti čvor se terminira

Cijeli proces se odvija unutar AWS-ovog 2-minutnog prozora za obavijest. U praksi to znači gotovo nulti downtime unatoč spot prekidima — što je zapravo prilično impresivno kad razmislite o tome.

Hibridne strategije: Kombiniranje spot instanci s drugim modelima plaćanja

Najučinkovitija strategija optimizacije troškova oblaka nikada se ne oslanja samo na jedan model plaćanja. To je kao da sve novce stavite na jednu dionicu — može proći, ali vjerojatno neće. Umjesto toga, vodeće organizacije koriste hibridni pristup koji kombinira prednosti svakog modela.

Troslojna strategija troškova

Optimalna raspodjela workloadova tipično slijedi ovaj obrazac:

1. Bazni sloj (Reserved / Savings Plans / CUD): 40-60% kapaciteta. To su workloadovi koji uvijek rade — baze podataka, core API servisi, monitoring. Za ove koristite Savings Plans (AWS), Reserved VM Instances (Azure) ili CUD-ove (GCP) za predvidljive popuste od 30-57%.
2. Varijabilni sloj (Spot instance): 30-50% kapaciteta. Stateless web serveri, batch procesiranje, CI/CD, data pipeline. Za ove koristite spot instance uz automatsku zamjenu i fallback na On-Demand.
3. Burst sloj (On-Demand): 5-15% kapaciteta. Privremeni kapacitet za vršna opterećenja i fallback kad spot kapacitet nije dostupan. Cilj je minimizirati ovaj postotak koliko god je moguće.

Primjer hibridne konfiguracije za web aplikaciju

# Terraform: Hibridna strategija za tipicnu web aplikaciju
# ============================================
# SLOJ 1: Bazni kapacitet (Savings Plans / Reserved)
# ============================================
resource "aws_autoscaling_group" "base_layer" {
  name                = "base-on-demand"
  min_size            = 3
  max_size            = 3
  desired_capacity    = 3
  vpc_zone_identifier = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.base.id
    version = "$Latest"
  }

  tag {
    key                 = "CostLayer"
    value               = "base-reserved"
    propagate_at_launch = true
  }
}

# ============================================
# SLOJ 2: Varijabilni kapacitet (Spot)
# ============================================
resource "aws_autoscaling_group" "spot_layer" {
  name                = "variable-spot"
  min_size            = 2
  max_size            = 15
  desired_capacity    = 5
  vpc_zone_identifier = var.private_subnet_ids
  capacity_rebalance  = true

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 0
      on_demand_percentage_above_base_capacity = 0
      spot_allocation_strategy                 = "price-capacity-optimized"
    }
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.spot.id
        version            = "$Latest"
      }
      override {
        instance_type = "m6i.xlarge"
      }
      override {
        instance_type = "m6a.xlarge"
      }
      override {
        instance_type = "m5.xlarge"
      }
      override {
        instance_type = "c6i.xlarge"
      }
      override {
        instance_type = "c6a.xlarge"
      }
      override {
        instance_type = "r6i.xlarge"
      }
    }
  }

  tag {
    key                 = "CostLayer"
    value               = "variable-spot"
    propagate_at_launch = true
  }
}

# ============================================
# SLOJ 3: Burst kapacitet (On-Demand fallback)
# ============================================
resource "aws_autoscaling_group" "burst_layer" {
  name                = "burst-ondemand"
  min_size            = 0
  max_size            = 10
  desired_capacity    = 0
  vpc_zone_identifier = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.burst.id
    version = "$Latest"
  }

  tag {
    key                 = "CostLayer"
    value               = "burst-ondemand"
    propagate_at_launch = true
  }
}

Praćenje i optimizacija spot troškova

Korištenje spot instanci bez adekvatnog praćenja je kao vožnja bez instrumenata — možda funkcionira neko vrijeme, ali prije ili kasnije ćete se sudariti s problemom. Vjerujte mi na riječ.

Ključne metrike za praćenje

• Spot Savings Rate: Postotak uštede u usporedbi s On-Demand cijenama. Cilj: iznad 60%.
• Interruption Rate: Stopa prekida po tipu instance i zoni dostupnosti. Pratite trendove — iznenadni skokovi često signaliziraju promjenu u potražnji.
• Spot Coverage: Postotak ukupnog compute kapaciteta koji radi na spot instancama. Cilj: 30-50% za većinu organizacija.
• Fallback Events: Koliko često se pokreće On-Demand fallback. Ako je prečesto, diversificirajte tipove instanci.
• Time-to-Replace: Koliko brzo se zamjenjuju prekinute instance. Cilj: ispod 3 minute.

CloudWatch dashboard za spot monitoring

# AWS CLI: Kreiranje CloudWatch alarma za spot prekide
aws cloudwatch put-metric-alarm \
  --alarm-name "HighSpotInterruptionRate" \
  --alarm-description "Alarm za visoku stopu spot prekida" \
  --metric-name "SpotInterruptionCount" \
  --namespace "Custom/SpotMonitoring" \
  --statistic Sum \
  --period 3600 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:eu-central-1:123456789:spot-alerts" \
  --dimensions Name=AutoScalingGroupName,Value=variable-spot

# EventBridge pravilo za hvatanje spot prekida
aws events put-rule \
  --name "SpotInterruptionRule" \
  --event-pattern '{"source": ["aws.ec2"], "detail-type": ["EC2 Spot Instance Interruption Warning"]}'

# Lambda target za automatsku reakciju na prekide
aws events put-targets \
  --rule "SpotInterruptionRule" \
  --targets Id=1,Arn=arn:aws:lambda:eu-central-1:123456789:function:handle-spot-interruption

Workloadovi idealni za spot instance — i oni koji to nisu

Ne postoji univerzalni odgovor na pitanje "trebam li koristiti spot instance?" Sve ovisi o karakteristikama vašeg workloada. Ali nakon godina rada s različitim tipovima workloadova, evo klasifikacije koja se pokazala pouzdanom.

Idealni kandidati za spot instance

• CI/CD pipeline: Build i test procesi su inherentno kratki i ponovljivi. Ako se prekinu, jednostavno se pokrenu ponovno. Tvrtka Tinybird je postigla uštedu do 90% na CI/CD workloadovima korištenjem spot instanci — i to bez značajnih kompromisa.
• Batch procesiranje podataka: ETL poslovi, data pipeline, MapReduce zadaci. S pravilnim checkpointingom, prekid znači samo kraće kašnjenje, ne gubitak posla.
• Web serveri bez stanja: Stateless API serveri iza load balancera su savršeni kandidati. Load balancer automatski preusmjerava promet kad instanca nestane — korisnici to niti ne primijete.
• Machine learning trening: S periodičkim checkpointingom modela, trening se može nastaviti od zadnjeg checkpointa nakon prekida.
• Renderiranje i transkripcija: Video rendering, obrada slika, audio transkripcija — tipično su paralelni poslovi koji se lako distribuiraju.
• Big data analitika: Spark, Flink, Hadoop workloadovi dizajnirani za distribuirano procesiranje prirodno podnose gubitak pojedinih čvorova.

Workloadovi koji NISU prikladni za spot instance

• Baze podataka: Relacijske i NoSQL baze zahtijevaju konzistentan uptime. Prekid može dovesti do korupcije podataka ili dugotrajnog oporavka. Nemojte štedjeti na ovome.
• Stateful servisi: Aplikacije koje pohranjuju sesije u memoriji, WebSocket konekcije, real-time gaming serveri — sve što gubi kritično stanje pri restartu.
• Single-point-of-failure servisi: Bilo koji servis koji nema redundanciju i čiji prekid znači potpuni ispad sustava.
• Dugoročni batch poslovi bez checkpointa: Ako posao traje satima i ne može se restartati od sredine, prekid znači potpuni gubitak obavljenog posla. Riješite checkpointing prije nego uopće razmišljate o spot instancama.

Stvarni primjeri ušteda iz 2025.-2026.

Da stavimo sve u kontekst, pogledajmo konkretne primjere organizacija koje su uspješno implementirale spot strategije. Ovo nisu teoretski izračuni — radi se o stvarnim brojkama:

• Salesforce: Migracija preko 1.000 EKS klastera na Karpenter dovela je do smanjenja operativnog opterećenja od 80% i inicijalnih ušteda od 5% u fiskalnoj godini 2026., s očekivanim dodatnim smanjenjem od 5-10% u 2027. kako Karpenterov bin-packing i spot optimizacija nastavljaju poboljšavati iskoristivost resursa.
• Tinybird: Korištenjem EKS-a, Karpentera i spot instanci postigli su ukupno smanjenje AWS računa od 20%, a za CI/CD workloadove čak do 90%. Impresivno.
• Coinbase: Prelazak na Karpenter za upravljanje složenim klasterima s varijabilnim zahtjevima rezultirao je poboljšanjem latencije skaliranja i efikasnijom iskoristivošću resursa.
• BMW Group: Usvajanje Karpentera na automobilskim platformama omogućilo je bolju upotrebu spot instanci i workload-aware scheduling, smanjujući troškove infrastrukture i ubrzavajući developer feedback loops.

Praktični koraci za početak

Ako ste tek na početku korištenja spot instanci, nemojte pokušavati sve odjednom. Evo preporučenog redoslijeda implementacije koji se pokazao djelotvornim:

1. Tjedan 1 — Analiza: Identificirajte workloadove kandidate. Pregledajte trenutnu On-Demand potrošnju i klasificirajte workloadove prema toleranciji na prekide.
2. Tjedan 2 — Dev/Test okruženje: Počnite sa spot instancama u razvojnom i testnom okruženju. To je najsigurniji način učenja bez rizika za produkciju.
3. Tjedan 3-4 — CI/CD migracija: Prebacite CI/CD pipeline na spot instance. Ovo je tipično najbrži ROI s minimalnim rizikom — i odlično mjesto za stjecanje povjerenja u spot pristup.
4. Tjedan 5-8 — Stateless produkcijski workloadovi: Postupno uvedite spot instance za stateless web servere i API endpointe uz On-Demand fallback.
5. Kontinuirano — Monitoring i optimizacija: Pratite metrike, prilagođavajte konfiguraciju i širite spot pokrivenost prema mogućnostima.

Zaključak: Spot instance kao temelj FinOps strategije

Spot instance nisu samo trik za smanjenje računa — one su fundamentalni dio svake ozbiljne FinOps strategije u 2026. godini. S potencijalnim uštedama do 90%, nijedna organizacija koja troši značajne iznose na cloud infrastrukturu ne može si priuštiti ignorirati ih.

Ključ uspjeha leži u tri stupa: arhitektura otporna na prekide, automatizacija upravljanja instancama (tu Karpenter stvarno blista) i hibridna strategija koja kombinira spot instance s reserved kapacitetom.

Započnite s malim koracima — CI/CD pipeline ili razvojno okruženje — i postupno širite spot pokrivenost kako stječete iskustvo i povjerenje. Rezultati će govoriti sami za sebe: organizacije koje koriste mješavinu spot i On-Demand instanci prosječno štede 59%, a one najhrabrije koje pokreću isključivo spot workloadove postižu smanjenje troškova od čak 77%.

U sljedećem članku u ovoj seriji detaljnije ćemo istražiti Savings Plans i Reserved Instance strategije za bazni kapacitet — drugu stranu optimalne hibridne strategije troškova oblaka.