Spot Instances i 2026: Spar Op til 90% på AWS, Azure og GCP

Hvorfor spot instances er skyens bedst gemte hemmelighed

Okay, lad mig starte med et tal, der ærligt talt burde få enhver CTO til at spærre øjnene op: op til 90% rabat på compute-ressourcer. Det er ikke en skrivefejl. Det er den reelle besparelse, du kan opnå ved at bruge spot instances i stedet for on-demand hos AWS, Azure og GCP.

Og alligevel — data fra 2026 viser, at kun omkring 15-20% af virksomheder aktivt bruger spot instances. Resten betaler fuld pris for workloads, der sagtens kunne køre på spot. Det er lidt som at tage en taxa i myldretiden, når der holder en næsten gratis bus lige foran dig.

Problemet er sjældent, at folk ikke kender til spot instances. Det er frygten. Tanken om, at din cloud-udbyder kan tage dine servere tilbage med kun 30 sekunders til 2 minutters varsel — ja, det lyder skræmmende. Og det kræver en helt anden tilgang end bare at spinne en EC2-instans op og glemme den.

Men her er den gode nyhed: med den rette arkitektur og de rigtige værktøjer kan du høste massive besparelser uden at gå på kompromis med pålideligheden. Det er præcis det, vi dykker ned i her.

Vi gennemgår alt fra grundlæggende koncepter til avancerede Kubernetes-opsætninger med Terraform-kode, du kan bruge direkte — uanset om du kører på AWS, Azure eller GCP.

Hvad er spot instances egentlig?

Alle de store cloud-udbydere har overskudskapacitet — compute-ressourcer, der bare står og samler støv, fordi on-demand- og reserved instance-kunder ikke bruger dem. I stedet for at lade den kapacitet gå til spilde, sælger de den til en kraftig rabat.

Det er spot instances i en nøddeskal.

Modellen er overraskende simpel: du får adgang til præcis den samme hardware og ydeevne som on-demand-instanser, men til en brøkdel af prisen. Til gengæld kan udbyderen tage instansen tilbage, når de har brug for kapaciteten til fuldpris-kunder. Fair nok, egentlig.

Hver udbyder kalder det noget lidt forskelligt og har deres egne regler:

AWS EC2 Spot Instances

AWS sælger overskudskapacitet som Spot Instances med besparelser på op til 90%. Priserne svinger baseret på udbud og efterspørgsel i hver Availability Zone og for hver instanstype. Du betaler den aktuelle spot-pris ved lancering — den gamle auktionsmodel er for længst droppet.

Når AWS har brug for kapaciteten, får du en 2-minutters advarsel via EC2 Instance Metadata Service eller Amazon EventBridge. To minutter lyder ikke af meget, men det er faktisk nok til at gemme state, flytte opgaver eller lave en graceful shutdown.

Azure Spot VMs

Microsofts version hedder Azure Spot VMs, og de tilbyder også op til 90% rabat sammenlignet med pay-as-you-go-priser. Azure kan eviktere din VM, enten når de mangler kapacitet, eller hvis spot-prisen overstiger din konfigurerede maksimumpris.

Evikteringsadvarslen er typisk 30 sekunder. Det er betydeligt kortere end AWS, og det stiller altså højere krav til din shutdown-logik.

GCP Spot VMs

Google Cloud erstattede de ældre Preemptible VMs med Spot VMs tilbage i 2022, og i 2026 er det den anbefalede model. Besparelser op til 91% — ja, en procent mere end de andre, for hvad det er værd.

Den vigtigste forskel fra de gamle preemptible VMs? Spot VMs har ikke en 24-timers maksimal levetid. De kan køre, så længe der er kapacitet. Advarselsperioden er dog kun 30 sekunder, ligesom Azure.

Prissammenligning: Spot vs. on-demand i 2026

Lad os se på de faktiske tal. Her er en oversigt over, hvad de tre udbydere tilbyder:

Funktion	AWS EC2 Spot	Azure Spot VMs	GCP Spot VMs
Maks. rabat	Op til 90%	Op til 90%	Op til 91%
Advarselsperiode	2 minutter	~30 sekunder	30 sekunder
Prismodel	Dynamisk (udbud/efterspørgsel)	Dynamisk + maks. pris	Dynamisk
Kubernetes-support	EKS Managed Node Groups	AKS Spot Node Pools	GKE Spot Node Pools
Maks. levetid	Ingen grænse	Ingen grænse	Ingen grænse
Automatisk rabat	Nej	Nej	Nej (SUDs gælder separat)

Et konkret eksempel: en m4.xlarge-instans på AWS koster typisk omkring $0,10/time on-demand. Spot-prisen svinger mellem $0,02 og $0,03/time — en besparelse på 70-80%. For en workload der kører 24/7, er det forskellen mellem ~$876/år og ~$175-$263/år. Per instans.

Multiplicér det med 20 eller 50 instanser, og du begynder at tale om rigtig mange penge.

Hvilke workloads passer til spot instances?

Spot instances er ikke til alt. Men de er til langt mere, end de fleste tror — og det er her, mange organisationer går glip af besparelser.

Ideelle workloads

• Batch-processing: Data-pipelines, ETL-jobs, billedbehandling, videokonvertering — alt der kan køre som diskrete opgaver og genstartes ved afbrydelse
• CI/CD-pipelines: Build- og testjobs er kortvarige og stateless. Fejler en node, genstarter pipelinen bare jobbet
• Machine learning-træning: ML-jobs kører ofte parallelt og kan håndtere afbrydelser via checkpointing. Og givet GPU-priserne er besparelserne her virkelig mærkbare
• Big data og analytics: Frameworks som Apache Spark og Hadoop er designet til at håndtere nodefejl — det er nærmest som om de blev lavet til spot
• Rendering og HPC: 3D-rendering, videnskabelige simuleringer og andre compute-tunge opgaver der kan paralleliseres
• Stateless webservere: Med load balancing og auto scaling kan stateless web-tiers sagtens køre på spot
• Udviklings- og testmiljøer: Ærligt talt, der er ingen grund til at betale fuld pris for dev/test-miljøer

Workloads du bør holde dig fra

• Stateful applikationer: Hvis din app gemmer sessionsdata eller cache i hukommelsen, kan en pludselig afbrydelse betyde datatab
• Primære databaser: At køre din primære database på spot er en opskrift på katastrofe (medmindre du har fuld replikering og failover, men selv da — hvorfor tage risikoen?)
• Kundekritiske tjenester uden redundans: Har du ikke replicas eller failover-strategier? Så bør disse køre on-demand. Ingen diskussion.

Praktisk opsætning: Spot instances med Terraform

Nok teori. Lad os se noget kode.

Her er Terraform-konfigurationer til spot instances på alle tre cloud-udbydere, som du kan tilpasse og bruge direkte.

AWS: EC2 Spot Fleet med mixed instances

Den bedste praksis på AWS er at bruge flere instanstyper for at øge tilgængeligheden. Hvis én type er knap, kan systemet automatisk vælge en anden:

# aws-spot-fleet.tf
resource "aws_launch_template" "spot_template" {
  name_prefix   = "spot-worker-"
  image_id      = var.ami_id
  instance_type = "m5.large"

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "spot-worker"
      Environment = var.environment
      ManagedBy   = "terraform"
    }
  }

  user_data = base64encode(<<-EOF
    #!/bin/bash
    # Opsæt spot interruption handler
    cat > /usr/local/bin/spot-handler.sh << 'SCRIPT'
    #!/bin/bash
    TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
      -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

    while true; do
      STATUS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
        http://169.254.169.254/latest/meta-data/spot/instance-action)
      if [ "$STATUS" != "404" ]; then
        echo "Spot interruption modtaget. Starter graceful shutdown..."
        # Gem state, afslut opgaver, notificér
        systemctl stop my-worker-service
        break
      fi
      sleep 5
    done
    SCRIPT
    chmod +x /usr/local/bin/spot-handler.sh
    nohup /usr/local/bin/spot-handler.sh &
  EOF
  )
}

resource "aws_autoscaling_group" "spot_workers" {
  name                = "spot-workers-asg"
  desired_capacity    = 5
  max_size            = 20
  min_size            = 2
  vpc_zone_identifier = var.subnet_ids

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 0
      spot_allocation_strategy                 = "capacity-optimized"
    }

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

      override {
        instance_type = "m5.large"
      }
      override {
        instance_type = "m5a.large"
      }
      override {
        instance_type = "m5d.large"
      }
      override {
        instance_type = "m6i.large"
      }
      override {
        instance_type = "m6a.large"
      }
    }
  }

  tag {
    key                 = "Name"
    value               = "spot-worker"
    propagate_at_launch = true
  }
}

Læg mærke til on_demand_base_capacity = 2 — det sikrer, at du altid har mindst 2 on-demand-instanser som et sikkerhedsnet, mens resten kører på spot. Og spot_allocation_strategy = "capacity-optimized"? Den vælger automatisk de instanstyper og AZ'er med mest ledig kapacitet. Det er ærligt talt den vigtigste indstilling for at minimere afbrydelser.

Azure: Spot VMs med Terraform

# azure-spot-vm.tf
resource "azurerm_linux_virtual_machine_scale_set" "spot_workers" {
  name                = "spot-workers-vmss"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  sku                 = "Standard_D4s_v3"
  instances           = 5

  priority        = "Spot"
  eviction_policy = "Delete"
  max_bid_price   = -1  # Betal op til on-demand-pris

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

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

  admin_ssh_key {
    username   = "azureuser"
    public_key = var.ssh_public_key
  }

  admin_username = "azureuser"

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

Ved at sætte max_bid_price = -1 sikrer du, at instansen kun evikteres på grund af kapacitetsmangel — ikke prisændringer. Og eviction_policy = "Delete" fjerner VM'en helt ved eviktering, hvilket giver et renere auto-scaling-setup.

GCP: Spot VMs med Terraform

# gcp-spot-vm.tf
resource "google_compute_instance_template" "spot_template" {
  name_prefix  = "spot-worker-"
  machine_type = "n2-standard-4"
  region       = var.gcp_region

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

  disk {
    source_image = "ubuntu-os-cloud/ubuntu-2204-lts"
    auto_delete  = true
    boot         = true
    disk_size_gb = 50
  }

  network_interface {
    network    = var.network_name
    subnetwork = var.subnet_name
  }

  labels = {
    environment = var.environment
    managed-by  = "terraform"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_instance_group_manager" "spot_workers" {
  name               = "spot-workers-mig"
  base_instance_name = "spot-worker"
  zone               = var.gcp_zone
  target_size        = 5

  version {
    instance_template = google_compute_instance_template.spot_template.id
  }

  auto_healing_policies {
    health_check      = google_compute_health_check.spot_health.id
    initial_delay_sec = 120
  }
}

Nøglen her er provisioning_model = "SPOT" og automatic_restart = false. Spot VMs på GCP kan ikke automatisk genstartes, så auto-healing i Managed Instance Groups tager sig af at erstatte terminerede instanser i stedet.

Spot instances i Kubernetes: EKS, AKS og GKE

Her bliver det virkelig interessant. Kubernetes og spot instances er faktisk en fantastisk kombination — Kubernetes er allerede designet til at håndtere nodefejl og flytte pods mellem noder. Så spot-afbrydelser er bare endnu en type nodefejl, som Kubernetes kan håndtere.

AWS EKS: Spot Node Group med eksctl

# eks-spot-nodegroup.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production-cluster
  region: eu-west-1
managedNodeGroups:
  - name: on-demand-baseline
    instanceType: m5.large
    minSize: 2
    maxSize: 4
    desiredCapacity: 2
    labels:
      node-lifecycle: on-demand
  - name: spot-workers
    instanceTypes:
      - m5.large
      - m5a.large
      - m5d.large
      - m6i.large
      - m6a.large
      - m5.xlarge
    spot: true
    minSize: 3
    maxSize: 30
    desiredCapacity: 6
    labels:
      node-lifecycle: spot
    taints:
      - key: spot-instance
        value: "true"
        effect: NoSchedule

Anvend med:

eksctl create nodegroup -f eks-spot-nodegroup.yaml

AWS Node Termination Handler

For at håndtere spot-afbrydelser gracefully i EKS skal du installere AWS Node Termination Handler. Den overvåger EC2 Instance Metadata og drainer noder automatisk ved afbrydelse:

helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-node-termination-handler eks/aws-node-termination-handler \
  --namespace kube-system \
  --set enableSpotInterruptionDraining=true \
  --set enableRebalanceMonitoring=true \
  --set enableScheduledEventDraining=true

Handleren kører som en DaemonSet på hver node og reagerer på spot-interruption-notifikationer ved at cordone og draine noden, så pods flyttes til andre noder inden terminering. Virksomheder der implementerer NTH rapporterer typisk en 80% reduktion i nedetid ved node-terminering — og det er et tal, der er svært at ignorere.

Azure AKS: Spot Node Pool

az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name spotpool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-count 3 \
  --node-vm-size Standard_D4s_v3 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 15 \
  --labels node-lifecycle=spot

En vigtig ting at huske: en spot node pool kan ikke være default node pool i AKS. Du skal altid have mindst én on-demand node pool som baseline. Men det er egentlig ikke en begrænsning — det er sund fornuft.

Google GKE: Spot Node Pool

gcloud container node-pools create spot-pool \
  --cluster=production-cluster \
  --zone=europe-west1-b \
  --machine-type=n2-standard-4 \
  --spot \
  --num-nodes=3 \
  --min-nodes=0 \
  --max-nodes=20 \
  --enable-autoscaling \
  --node-taints=cloud.google.com/gke-spot=true:NoSchedule

Kubernetes pod-konfiguration med tolerations

For at lade specifikke pods køre på spot-noder skal du tilføje tolerations i din pod-spec. Her er et komplet eksempel:

# deployment-spot.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
  namespace: production
spec:
  replicas: 6
  selector:
    matchLabels:
      app: batch-processor
  template:
    metadata:
      labels:
        app: batch-processor
    spec:
      tolerations:
        - key: "spot-instance"
          operator: "Equal"
          value: "true"
          effect: "NoSchedule"
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 90
              preference:
                matchExpressions:
                  - key: node-lifecycle
                    operator: In
                    values:
                      - spot
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - batch-processor
                topologyKey: kubernetes.io/hostname
      terminationGracePeriodSeconds: 90
      containers:
        - name: processor
          image: my-registry/batch-processor:latest
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi
          lifecycle:
            preStop:
              exec:
                command:
                  - /bin/sh
                  - -c
                  - "echo 'Modtaget shutdown-signal' && /app/graceful-shutdown.sh"

De vigtigste ting at bide mærke i her:

• tolerations: Tillader pods at køre på spot-noder (de har en taint, som andre pods ikke tolererer)
• podAntiAffinity: Spreder replicas på tværs af noder — så en enkelt spot-afbrydelse kun rammer én pod ad gangen
• terminationGracePeriodSeconds: 90: Giver pods op til 90 sekunder til at lukke pænt ned
• preStop hook: Kører et cleanup-script inden containeren stoppes. Det her er afgørende.

Den optimale prisstrategi: Bland spot, reserved og on-demand

Spot instances er fantastiske, men de bør ikke stå alene. Den mest effektive tilgang — og den, vi ser hos de bedst optimerede organisationer — er en blandet prisstrategi:

Prislag	Andel af kapacitet	Workload-type	Typisk besparelse
Reserved Instances / Savings Plans	60-70% af baseline	Stabil produktion, databaser, kernesystemer	30-72%
On-demand	15-20%	Forudsigelig variabel last	0% (referencepris)
Spot Instances	15-25%	Batch, CI/CD, test, burst-kapacitet	60-90%

Med denne fordeling kan en typisk organisation opnå en samlet besparelse på 40-60% på compute-omkostninger. Det er ikke et teoretisk tal — det er, hvad veloptimerede FinOps-teams faktisk rapporterer i 2026.

Den praktiske tilgang? Start med at analysere dine workloads. Brug AWS Cost Explorer, Azure Cost Management eller GCP Billing Reports til at gennemgå de seneste 3-6 måneders forbrug. Find ud af, hvilke workloads der er stabile (kandidater til RI/SP), og hvilke der er burst-agtige eller fejltolerante (kandidater til spot). Det lyder simpelt, men det er her de fleste besparelser starter.

Overvågning og metrics for din spot-strategi

At sætte spot instances op er kun halvdelen af arbejdet. Løbende overvågning er mindst lige så vigtigt. Her er de metrics, du bør holde øje med:

• Spot Interruption Rate: Hvor ofte dine instanser afbrydes. En stigende rate er et klart signal om, at du bør diversificere dine instanstyper eller skifte Availability Zone
• Fulfilled Spot Capacity: Hvor stor en del af din anmodede spot-kapacitet der faktisk kører. Falder dette tal, kan det betyde lav kapacitet i dine valgte pools
• Spot vs. On-Demand Cost Ratio: Brug Cost Explorer til at filtrere efter purchase type og sammenligne dine effektive spot-rater med on-demand. Det giver dig det reelle billede af dine besparelser
• Fallback-frekvens: Hvor ofte dit system falder tilbage til on-demand. En høj frekvens kan betyde, at du ikke diversificerer nok på tværs af instanstyper

På AWS er Spot Instance Advisor et uvurderligt værktøj — det viser afbrydelsesfrekvenser og besparelses-procenter for hver instanstype, så du kan træffe datadrevne valg i stedet for at gætte.

5 fejl du skal undgå med spot instances

Vi har set mange organisationer forsøge at adoptere spot instances og løbe ind i de samme faldgruber igen og igen. Her er de fem mest almindelige (og hvordan du undgår dem):

1. Kun bruge én instanstype: Det er den mest almindelige fejl. Diversificér på tværs af mindst 5-10 instanstyper, og brug capacity-optimized allocation strategy i stedet for lowest-price
2. Ignorere graceful shutdown: Sørg for, at dine applikationer håndterer SIGTERM-signaler og kan afslutte igangværende opgaver inden for advarselsperioden. Det her glemmer folk overraskende ofte
3. Ingen fallback-strategi: Hav altid en on-demand fallback. Brug mixed instances policies med en on-demand base capacity — det er dit sikkerhedsnet
4. Overcommitte til spot: Kør aldrig mere end 80% af din samlede kapacitet på spot. Bevar en on-demand baseline for de kritiske workloads
5. Glemme at overvåge: Spot-priser og tilgængelighed ændrer sig hele tiden. Opsæt CloudWatch-alarmer (eller tilsvarende) for interruption rates og kapacitetsproblemer

FAQ: Ofte stillede spørgsmål om spot instances

Kan jeg bruge spot instances til produktionsworkloads?

Ja — men med forbehold. Stateless produktions-workloads med tilstrækkelig redundans kan sagtens køre på spot. Nøglen er nok replicas, ordentlig health checking og automatisk failover. Mange virksomheder kører succesfuldt 50-70% af deres Kubernetes-produktion på spot-noder. Det kræver bare, at kritiske tjenester også har on-demand-noder som fallback.

Hvad sker der med mine data ved en spot-afbrydelse?

Det afhænger af din konfiguration. Data på ephemeral storage (instance store) går tabt — det er der ingen vej udenom. Data på EBS-volumes (AWS) eller persistent disks (GCP/Azure) bevares, forudsat du bruger stop (ikke terminate) som eviction policy, eller at diskene er konfigureret til at overleve instansens levetid.

Best practice er altid at gemme vigtige data eksternt (S3, Cloud Storage, Blob Storage) og aldrig stole på lokal storage. Det gælder i øvrigt uanset om du bruger spot eller ej.

Hvor meget sparer jeg reelt?

De typiske besparelser ligger mellem 60-90% sammenlignet med on-demand-priser, afhængigt af instanstype, region og tidspunkt. I praksis rapporterer organisationer med en blandet strategi (spot + reserved + on-demand) samlede besparelser på 40-60% på compute-omkostninger. En case study fra 2026 viste en besparelse på $380.000 om måneden — en 52% reduktion — ved at kombinere spot instances med andre optimeringstiltag.

Hvad er forskellen på spot instances og reserved instances?

Reserved instances kræver en 1- eller 3-årig forpligtelse og giver 30-72% rabat uden risiko for afbrydelse. Spot instances kræver ingen forpligtelse og giver op til 90% rabat, men kan altså afbrydes med kort varsel.

De bedste resultater opnås ved at kombinere begge: reserved instances til stabil baseline-kapacitet og spot instances til variable, fejltolerante workloads. Det er ikke et enten-eller.

Hvordan håndterer jeg spot-afbrydelser i Kubernetes?

Brug dedikerede termination handlers: AWS Node Termination Handler for EKS, indbygget eviction-håndtering i AKS, og GKE's native spot-support. Disse værktøjer cordoner automatisk noden og drainer pods, så de flyttes til andre noder inden terminering. Kombinér det med podAntiAffinity for at sprede replicas, og sæt terminationGracePeriodSeconds til 60-90 sekunder for at give pods tid til at lukke ned ordentligt.