Spot-instanssit AWS, Azure ja GCP: Näin säästät jopa 90 % pilvikustannuksista

Miksi spot-instanssit ovat pilvikustannusten tehokkain säästökeino?

Pilvipalveluntarjoajat myyvät käyttämätöntä laskentakapasiteettiaan merkittävällä alennuksella — puhutaan 60–90 prosentin säästöistä verrattuna normaaleihin on-demand-hintoihin. AWS kutsuu näitä Spot Instances -nimellä, Azuressa ne ovat Spot VMs ja GCP:ssä samoin Spot VMs (entinen Preemptible VMs).

Ajattele asiaa näin: se on vähän kuin lentoyhtiö myisi viimeiset tyhjät paikkansa murto-osalla normaalihinnasta juuri ennen lähtöä. Saat valtavan alennuksen, mutta vastineeksi palveluntarjoaja voi ottaa resurssin takaisin lyhyellä varoitusajalla. AWS antaa 2 minuuttia aikaa reagoida, kun taas Azure ja GCP antavat vain 30 sekuntia.

Tässä oppaassa käymme läpi kaikkien kolmen suuren pilvipalveluntarjoajan spot-hinnoittelun, keskeytyskäyttäytymisen ja parhaat käytännöt. Mukana on toimivia konfiguraatio- ja koodiesimerkkejä, joilla pääset alkuun tuotantokäytössä.

Hinnoittelu ja säästöpotentiaali palveluntarjoajittain

AWS Spot Instances

AWS:n spot-hinnoittelu on täysin dynaaminen — hinta päivittyy viiden minuutin välein tarjonnan ja kysynnän mukaan. Vanhaa tarjousmekanismia ei enää ole, vaan maksat aina kulloisenkin spot-markkinahinnan. Käytännössä säästöt pyörivät 60–90 prosentin haarukassa.

• Maksimisäästö: jopa 90 % on-demand-hinnasta
• Hintavaihtelut: keskimäärin 197 erillistä hinnanmuutosta kuukaudessa instanssityyppiä kohden
• Ilmainen taso: jos AWS keskeyttää instanssin ensimmäisen tunnin aikana, käyttöaikaa ei veloiteta
• Keskeytysvaroitus: 2 minuuttia + ennakkosignaali (rebalance recommendation)

Azure Spot VMs

Azuren spot-hinnoittelu on niin ikään dynaamista. Voit asettaa maksimihinnan, jonka olet valmis maksamaan — tai käyttää arvoa -1, jolloin instanssia ei poisteta hinnan perusteella vaan ainoastaan kapasiteettitarpeen vuoksi. Tämä on yleensä suositeltava vaihtoehto, koska se minimoi turhat poistot.

• Maksimisäästö: jopa 90 % pay-as-you-go-hinnasta
• Tyypilliset säästöt: 75–90 % useimmilla VM-tyypeillä
• Poistokäytäntö: Deallocate (oletusarvo) tai Delete
• Keskeytysvaroitus: 30 sekuntia

GCP Spot VMs

GCP:n spot-hinnoittelu on kolmikosta selkeästi yksinkertaisinta. Hinnat muuttuvat keskimäärin vain 0,35 kertaa kuukaudessa, mikä tekee budjetoinnista huomattavasti helpompaa kuin AWS:n kanssa. GCP:n Spot VMs korvasi aiemmat Preemptible VMs -instanssit ja poisti samalla ärsyttävän 24 tunnin aikarajan.

• Maksimisäästö: jopa 91 % standardihinnasta
• Minimisäästö: vähintään 60 % taattu
• Hintavakaus: ennustettavin kolmesta palveluntarjoajasta
• Keskeytysvaroitus: 30 sekuntia

Vertailutaulukko: AWS vs. Azure vs. GCP

Tässä kaikki oleellinen yhdellä silmäyksellä:

Ominaisuus	AWS Spot Instances	Azure Spot VMs	GCP Spot VMs
Maksimisäästö	90 %	90 %	91 %
Keskeytysvaroitus	2 min + rebalance	30 s	30 s
Hinnoittelumalli	Dynaaminen, 5 min päivitys	Dynaaminen, max-hinta	Kiinteämpi, harvat muutokset
Aikaraja	Ei rajaa	Ei rajaa	Ei rajaa
Keskeytystaajuus	Tyypillisesti < 5 %	Vaihtelee alueittain	Yleensä matala
GPU-tuki	Kyllä	Kyllä	Kyllä (+ TPU)
Autoskaalaus	ASG + Spot Fleet	VMSS	MIG

Milloin spot-instanssit sopivat — ja milloin eivät?

Ideaaliset käyttökohteet

Spot-instanssit loistavat työkuormissa, jotka kestävät keskeytyksiä:

• Eräajot ja batch-prosessointi — työkuormat, jotka voidaan käynnistää uudelleen keskeytyksestä
• CI/CD-putket — build- ja testiajot, joissa yksittäisen ajon menetys ei kaada maailmaa
• Koneoppimisen harjoittelu — checkpointit mahdollistavat jatkamisen siitä mihin jäätiin
• Tilattomien palveluiden skaalaus — web-kerroksen horisontaalinen skaalaus kuormapiikeissä
• Big data -analytiikka — Spark-, Hadoop- ja Dataflow-työkuormat
• Renderöinti ja HPC — jaettavat laskentatehtävät

Vältä spot-instansseja näissä tilanteissa

Rehellisesti sanottuna, spot-instanssit eivät sovi kaikkeen. Näissä tilanteissa kannattaa pysyä on-demand- tai reserved-instansseissa:

• Tietokantapalvelimet — tilallinen, kirjoitusintensiivinen työkuorma kestää keskeytysten huonosti
• Yksittäiset kriittiset instanssit — jos sinulla on vain yksi instanssi ja se poistetaan, palvelusi on alhaalla
• Pitkäkestoiset ajot ilman checkpointteja — menetetty työ voi tulla kalliimmaksi kuin on-demand-hinta alun perinkin
• Latenssikriittiset sovellukset — 30 sekunnin varoitusaika ei välttämättä riitä kunnolliseen graceful shutdown -prosessiin

Käytännön toteutus: AWS Spot Instances

Auto Scaling Group spot-instansseilla

AWS suosittelee nykyään Auto Scaling Groupeja (ASG) vanhan Spot Fleetin sijaan — Spot Fleet on merkitty legacy-palveluksi. ASG tarjoaa paremman integraation muuhun AWS-ekosysteemiin ja automaattiset terveystarkistukset.

# Luo launch template spot-instansseille
aws ec2 create-launch-template   --launch-template-name spot-web-tier   --version-description "Spot web tier v1"   --launch-template-data '{
    "ImageId": "ami-0123456789abcdef0",
    "SecurityGroupIds": ["sg-0123456789abcdef0"],
    "InstanceMarketOptions": {
      "MarketType": "spot",
      "SpotOptions": {
        "SpotInstanceType": "persistent",
        "InstanceInterruptionBehavior": "stop"
      }
    },
    "TagSpecifications": [{
      "ResourceType": "instance",
      "Tags": [{"Key": "Environment", "Value": "production"},
               {"Key": "CostCenter", "Value": "spot-savings"}]
    }]
  }'

Seuraava Terraform-konfiguraatio yhdistää spot- ja on-demand-instanssit samassa ASG:ssä. Tämä on se lähestymistapa, jota itse suosittelisin tuotantoympäristöön — saat säästöjä ilman liiallista riskiä:

# Terraform: Mixed Instances ASG — spot + on-demand
resource "aws_autoscaling_group" "web_tier" {
  name                = "web-tier-mixed"
  desired_capacity    = 6
  min_size            = 2
  max_size            = 20
  vpc_zone_identifier = var.private_subnet_ids

  # Capacity rebalancing — korvaa spot-instanssit ennakoivasti
  capacity_rebalance = true

  mixed_instances_policy {
    instances_distribution {
      # 30 % on-demand, 70 % spot
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 30
      spot_allocation_strategy                 = "price-capacity-optimized"
    }

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

      # Monipuolista instanssityypit — vähentää keskeytyksiä
      override {
        instance_type = "m6i.large"
      }
      override {
        instance_type = "m6a.large"
      }
      override {
        instance_type = "m5.large"
      }
      override {
        instance_type = "m5a.large"
      }
      override {
        instance_type = "c6i.large"
      }
      override {
        instance_type = "c6a.large"
      }
    }
  }

  tag {
    key                 = "SpotStrategy"
    value               = "price-capacity-optimized"
    propagate_at_launch = true
  }
}

Keskeytysten hallinta EventBridgellä

Tämä on se kohta, jonka monet ohittavat (ja katuvat myöhemmin). EventBridge mahdollistaa automaattisen reagoinnin spot-keskeytyksiin. Seuraava konfiguraatio kuuntelee sekä rebalance-suosituksia että varsinaisia keskeytyksiä:

# Terraform: EventBridge-sääntö spot-keskeytyksille
resource "aws_cloudwatch_event_rule" "spot_interruption" {
  name        = "spot-interruption-handler"
  description = "Reagoi spot-instanssien keskeytyksiin"

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

resource "aws_cloudwatch_event_target" "spot_lambda" {
  rule      = aws_cloudwatch_event_rule.spot_interruption.name
  target_id = "spot-handler"
  arn       = aws_lambda_function.spot_handler.arn
}

# Lambda joka käsittelee keskeytyksen
resource "aws_lambda_function" "spot_handler" {
  filename         = "spot_handler.zip"
  function_name    = "spot-interruption-handler"
  role             = aws_iam_role.lambda_role.arn
  handler          = "index.handler"
  runtime          = "python3.12"
  timeout          = 60
}

Ja tässä itse Lambda-funktio, joka käsittelee keskeytykset:

import boto3
import json

ec2 = boto3.client('ec2')
asg = boto3.client('autoscaling')

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

    print(f"Spot-tapahtuma: {detail_type} instanssille {instance_id}")

    if detail_type == "EC2 Instance Rebalance Recommendation":
        # Rebalance-suositus — instanssi on kohonneessa keskeytysvaarassa
        # ASG capacity rebalance hoitaa korvaavan instanssin käynnistyksen
        print(f"Rebalance-suositus vastaanotettu: {instance_id}")

        # Aloita graceful drain — poista kuormantasaajasta
        try:
            response = ec2.describe_instances(InstanceIds=[instance_id])
            tags = response['Reservations'][0]['Instances'][0].get('Tags', [])
            asg_name = next(
                (t['Value'] for t in tags if t['Key'] == 'aws:autoscaling:groupName'),
                None
            )
            if asg_name:
                print(f"Instanssi {instance_id} kuuluu ASG:hen {asg_name}")
        except Exception as e:
            print(f"Virhe: {e}")

    elif detail_type == "EC2 Spot Instance Interruption Warning":
        # 2 minuuttia aikaa — tallenna tila ja valmistaudu sammutukseen
        action = event['detail'].get('instance-action', 'terminate')
        print(f"Keskeytysvaroitus: {instance_id}, toiminto: {action}")

    return {'statusCode': 200, 'body': json.dumps('Käsitelty')}

Käytännön toteutus: Azure Spot VMs

Virtual Machine Scale Set spot-instansseilla

Azuressa suosituin tapa pyörittää spot-instansseja on Virtual Machine Scale Set (VMSS). Se korvaa poistetut instanssit automaattisesti, joten sinun ei tarvitse itse valvoa tilannetta jatkuvasti.

# Azure CLI: Luo VMSS spot-instansseilla
az vmss create   --resource-group myResourceGroup   --name mySpotScaleSet   --image Ubuntu2204   --vm-sku Standard_D2s_v5   --instance-count 5   --priority Spot   --eviction-policy Delete   --max-price -1   --single-placement-group false   --admin-username azureuser   --generate-ssh-keys   --tags Environment=production CostCenter=spot-savings

Poistokäytäntönä Delete tarkoittaa, että poistetut instanssit ja niiden levyt poistetaan kokonaan — et maksa turhasta tallennustilasta. Arvo --max-price -1 estää hintaperusteisen poiston, jolloin instanssi poistetaan vain kapasiteettitarpeen vuoksi. Tämä on käytännössä aina järkevä valinta.

Poistotapahtumien kuuntelu Azuressa

Azure tarjoaa Scheduled Events -palvelun, jonka kautta sovelluksesi voi kuunnella tulevia poistoja. Seuraava skripti tarkistaa tilanteen 5 sekunnin välein:

#!/bin/bash
# Kuuntele Azure Scheduled Events -ilmoituksia
# Tämä skripti tarkistaa 5 sekunnin välein
METADATA_URL="http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

while true; do
  EVENTS=$(curl -s -H "Metadata:true" "$METADATA_URL")
  EVENT_TYPE=$(echo "$EVENTS" | jq -r '.Events[0].EventType // empty')

  if [ "$EVENT_TYPE" = "Preempt" ]; then
    echo "$(date): Spot-poisto havaittu — aloitetaan graceful shutdown"

    # Tallenna sovelluksen tila
    /opt/app/save-checkpoint.sh

    # Poista instanssi kuormantasaajasta
    /opt/app/deregister-from-lb.sh

    # Ilmoita monitorointiin
    curl -X POST "$WEBHOOK_URL"       -H "Content-Type: application/json"       -d '{"text": "Azure Spot VM poistettu — checkpoint tallennettu"}'

    break
  fi

  sleep 5
done

Käytännön toteutus: GCP Spot VMs

Managed Instance Group spot-instansseilla

GCP:ssä vastaava ratkaisu on Managed Instance Group (MIG). Se ylläpitää haluttua instanssimäärää automaattisesti ja käynnistää uusia, jos vanhoja poistetaan.

# Luo instance template spot-instansseille
gcloud compute instance-templates create spot-web-template   --machine-type=e2-standard-4   --provisioning-model=SPOT   --instance-termination-action=STOP   --image-family=debian-12   --image-project=debian-cloud   --boot-disk-size=20GB   --metadata=enable-oslogin=true   --tags=http-server,https-server   --labels=environment=production,cost-center=spot

# Luo managed instance group
gcloud compute instance-groups managed create spot-web-mig   --template=spot-web-template   --size=5   --zone=europe-north1-a

# Aseta autoskaalaus
gcloud compute instance-groups managed set-autoscaling spot-web-mig   --zone=europe-north1-a   --min-num-replicas=2   --max-num-replicas=20   --target-cpu-utilization=0.65   --cool-down-period=120

Shutdown-skripti GCP:ssä

GCP tukee shutdown-skriptejä, jotka suoritetaan automaattisesti instanssin poistuessa — tämä on kätevin tapa hoitaa tilan tallennus ennen keskeytystä.

#!/bin/bash
# GCP Spot VM shutdown -skripti
# Lisää instance templateen: --metadata=shutdown-script-url=gs://my-bucket/shutdown.sh

echo "$(date): Spot VM sammumassa — tallennetaan tila"

# Tallenna checkpoint Cloud Storageen
INSTANCE_NAME=$(curl -s -H "Metadata-Flavor: Google"   http://metadata.google.internal/computeMetadata/v1/instance/name)
ZONE=$(curl -s -H "Metadata-Flavor: Google"   http://metadata.google.internal/computeMetadata/v1/instance/zone | cut -d'/' -f4)

# Tallenna sovelluksen tila
tar czf /tmp/checkpoint.tar.gz /var/app/state/
gsutil cp /tmp/checkpoint.tar.gz   "gs://my-checkpoints/${INSTANCE_NAME}-$(date +%Y%m%d-%H%M%S).tar.gz"

# Poista instanssi kuormantasaajasta
gcloud compute backend-services remove-backend web-backend   --instance-group=spot-web-mig   --instance-group-zone=$ZONE   --quiet 2>/dev/null || true

echo "$(date): Checkpoint tallennettu — sammutus valmis"

Kubernetes ja spot-instanssit

Spot-instanssit yhdistettynä Kubernetesiin on rehellisesti sanottuna aika loistava yhdistelmä. Kubernetes osaa jo valmiiksi hallita podien siirtoja ja uudelleenajoitusta, joten spot-keskeytysten käsittely hoituu luontevasti.

AWS EKS: Managed Node Group spot-instansseilla

# eksctl: Managed node group spot-instansseilla
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production-cluster
  region: eu-north-1

managedNodeGroups:
  # On-demand baseline kriittisille palveluille
  - name: on-demand-baseline
    instanceType: m6i.large
    desiredCapacity: 3
    minSize: 2
    maxSize: 5
    labels:
      node-type: on-demand
    taints:
      - key: workload-type
        value: critical
        effect: NoSchedule

  # Spot-instanssit skaalautuville työkuormille
  - name: spot-workers
    instanceTypes:
      - m6i.large
      - m6a.large
      - m5.large
      - m5a.large
      - c6i.large
      - c6a.large
    spot: true
    desiredCapacity: 6
    minSize: 0
    maxSize: 30
    labels:
      node-type: spot
    taints:
      - key: spot-instance
        value: "true"
        effect: PreferNoSchedule

Pod-konfiguraatio spot-toleranssilla

Näin konfiguroit podin, joka suosii spot-nodeja mutta osaa myös sammua siististi keskeytyksen sattuessa:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 10
  selector:
    matchLabels:
      app: batch-processor
  template:
    metadata:
      labels:
        app: batch-processor
    spec:
      # Salli ajaminen spot-nodeissa
      tolerations:
        - key: spot-instance
          operator: Equal
          value: "true"
          effect: PreferNoSchedule
      # Suosi spot-nodeja kustannussyistä
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 90
              preference:
                matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                      - spot
      # Graceful shutdown
      terminationGracePeriodSeconds: 90
      containers:
        - name: processor
          image: my-app/batch-processor:latest
          lifecycle:
            preStop:
              exec:
                command:
                  - /bin/sh
                  - -c
                  - "/app/save-checkpoint.sh && sleep 10"
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1000m"
              memory: "1Gi"

Kustannusten seuranta ja optimointi

Spot-instanssien todellisen säästön mittaaminen vaatii järjestelmällistä seurantaa — ilman dataa on mahdotonta tietää, saatko rahoillesi vastinetta. Tässä muutama hyödyllinen komento alkuun pääsemiseksi:

# AWS: Tarkista spot-instanssien säästöt Cost Explorerilla
aws ce get-cost-and-usage   --time-period Start=2026-02-01,End=2026-03-01   --granularity MONTHLY   --metrics "BlendedCost" "UnblendedCost"   --filter '{
    "Dimensions": {
      "Key": "PURCHASE_TYPE",
      "Values": ["Spot"]
    }
  }'   --group-by Type=DIMENSION,Key=INSTANCE_TYPE

# AWS: Spot-instanssien hinnoitteluhistoria viimeiseltä viikolta
aws ec2 describe-spot-price-history   --instance-types m6i.large m6a.large c6i.large   --product-descriptions "Linux/UNIX"   --start-time $(date -u -d "7 days ago" +%Y-%m-%dT%H:%M:%S)   --query 'SpotPriceHistory[*].{Type:InstanceType,AZ:AvailabilityZone,Price:SpotPrice,Time:Timestamp}'   --output table

# GCP: Spot-instanssien kustannusten vienti BigQueryyn
# Ota ensin käyttöön billing export BigQueryyn GCP Consolesta
# Sen jälkeen voit analysoida spot-kustannuksia:
SELECT
  service.description AS palvelu,
  sku.description AS tuote,
  SUM(cost) AS kokonaiskustannus,
  SUM(credits.amount) AS spot_alennus,
  SUM(cost) + SUM(credits.amount) AS nettokustannus
FROM `project.dataset.gcp_billing_export_v1_XXXXX`
LEFT JOIN UNNEST(credits) AS credits
WHERE
  invoice.month = "202603"
  AND sku.description LIKE "%Spot%"
GROUP BY 1, 2
ORDER BY kokonaiskustannus DESC;

Kerroksellinen säästöstrategia: spot + sitoumukset + on-demand

Spot-instanssit toimivat parhaiten osana laajempaa strategiaa, jossa eri hinnoittelumallit palvelevat eri tarpeita. Tämä on se kohta, jossa monet tekevät virheen — kaikki munat samaan koriin ei toimi pilvikustannustenkaan kanssa.

Kerros	Hinnoittelumalli	Osuus	Käyttökohde
1. Peruskuorma	Savings Plans / Reserved	50–60 %	Vakaat, ennustettavat työkuormat
2. Joustava kuorma	Spot Instances	30–40 %	Tilattomien palveluiden skaalaus, batch-ajot
3. Puskurikapasiteetti	On-Demand	10–20 %	Yllättävät kuormapiikit, spot-korvaavuus

Organisaatiot, jotka ajavat 30–40 prosenttia laskentakapasiteetistaan spot-instansseilla, raportoivat tyypillisesti 25–35 prosentin kokonaissäästön EC2-kustannuksissa. Yhdistettynä Savings Plans -sitoumuksiin peruskuormalle, kokonaissäästö voi hyvinkin ylittää 50 prosenttia verrattuna puhtaaseen on-demand-käyttöön.

Viisi virhettä, joita kannattaa välttää

Näitä sudenkuoppia näkee valitettavan usein:

1. Yhden instanssityypin käyttö — hajauta vähintään kuuteen instanssityyppiin ja kaikkiin saatavuusvyöhykkeisiin. Tämä yksittäinen muutos pienentää keskeytysriskiä merkittävästi.
2. Spot Fleetin käyttö uusissa toteutuksissa — AWS on merkinnyt Spot Fleetin legacy-palveluksi. Käytä Auto Scaling Groupeja sen sijaan.
3. Checkpointien puuttuminen — pitkäkestoinen ajo ilman checkpoint-tallennusta voi menettää tuntien työn yhdessä keskeytyksessä. Tämä on ehkä kaikkein yleisin virhe.
4. Keskeytysten huomiotta jättäminen — EventBridge-sääntöjen ja shutdown-skriptien puuttuminen johtaa datahävikkiin ja palvelukatkoksiin.
5. Spot-osuuden yliarviointi — aloita 20–30 prosentilla ja kasvata asteittain. 100 prosentin spot-ympäristö on yksinkertaisesti liian riskialtis useimmille tuotantotyökuormille.

Usein kysytyt kysymykset

Kuinka paljon spot-instansseilla voi todellisuudessa säästää?

Tyypilliset säästöt ovat 60–90 prosenttia on-demand-hinnoista. AWS tarjoaa jopa 90 prosentin alennuksia, Azure 75–90 prosenttia ja GCP 60–91 prosenttia. Todellinen säästö riippuu tietysti instanssityypistä, alueesta ja ajankohdasta. Organisaatiot, jotka käyttävät spot-instansseja 30–40 prosentissa kapasiteetistaan, saavuttavat tyypillisesti 25–35 prosentin kokonaissäästön laskentakustannuksissa.

Mitä tapahtuu kun spot-instanssi keskeytetään?

AWS antaa 2 minuutin varoitusajan ja sitä edeltävän rebalance-suosituksen. Azure ja GCP antavat 30 sekuntia. Tuon varoituksen aikana sovellus voi tallentaa tilansa, poistua kuormantasaajasta ja sammua hallitusti. Auto Scaling -ryhmät käynnistävät korvaavan instanssin automaattisesti, kunhan kapasiteettia on saatavilla.

Voiko spot-instansseja käyttää tuotantoympäristössä?

Kyllä — mutta vain vikasietoisille ja tilattomille työkuormille. Yhdistä spot-instanssit on-demand-peruskuormaan, käytä vähintään kuutta eri instanssityyppiä, ota käyttöön capacity rebalancing ja toteuta checkpoint-mekanismit. Tietokannat ja yksittäiset kriittiset instanssit eivät kerta kaikkiaan sovellu spot-käyttöön.

Kumpi on parempi: AWS Spot, Azure Spot vai GCP Spot?

Se riippuu tarpeistasi. AWS tarjoaa pisimmän varoitusajan (2 minuuttia) ja laajimman instanssivalikoiman. GCP tarjoaa ennustettavimman hinnoittelun ja vähintään 60 prosentin taatun alennuksen. Azure sopii parhaiten organisaatioille, jotka ovat jo valmiiksi Microsoft-ekosysteemissä. Jos teet koneoppimista, GCP:n TPU-tuki on merkittävä etu.

Miten aloitan spot-instanssien käytön turvallisesti?

Aloita kehitys- ja testiympäristöistä, joissa keskeytyksen vaikutus on pieni. Toteuta keskeytysten hallinta (EventBridge AWS:ssä, Scheduled Events Azuressa, shutdown-skriptit GCP:ssä) ennen kuin edes harkitset tuotantokäyttöä. Kasvata spot-osuutta asteittain — aloita vaikkapa 20 prosentista ja nosta 30–40 prosenttiin kokemusten karttuessa.