EC2 Spot Instances 2026: Produktionsguide för 90 % besparing utan avbrott

Uppdaterad: 21 juni 2026

EC2 Spot Instances är reservkapacitet i AWS som du kan köra med upp till 90 % rabatt jämfört med On-Demand, mot att AWS kan ta tillbaka instansen med två minuters varsel. Under 2026 är det fullt möjligt att köra produktionsworkloads på Spot, inklusive stateful tjänster, Kubernetes-kontrollplan och batchjobb, om du designar för avbrott, blandar instansfamiljer och använder funktioner som Capacity Rebalancing och Spot Placement Score. Den här guiden är skriven från ett solutions engineer-perspektiv, där jag har migrerat över 40 kundkluster till Spot-first arkitektur de senaste två åren (och, ja, brännt mig några gånger på vägen).

• Spot Instances kostar i snitt 70–90 % mindre än On-Demand, beroende på instanstyp och region (juni 2026-data).
• Avbrottsfrekvensen ligger under 5 % för de flesta instansfamiljer enligt Spot Instance Advisor, men kan vara <1 % om du väljer rätt diversifiering.
• Mixed Instance Policies med minst 10 instanstyper över 3 AZ:er ger praktiskt taget noll kapacitetsavbrott.
• Capacity Rebalancing (CR) byter ut riskabla instanser innan avbrottet, inte efter. Använd det alltid i ASG och Karpenter.
• Karpenter v1.3 (april 2026) hanterar Spot bättre än EKS Managed Node Groups för de flesta produktionskluster.
• Stateful workloads (databaser, message brokers) kan köras Spot med checkpointing och tvåminutershanteraren, inte bara stateless web tier.

Hur fungerar EC2 Spot Instances 2026?

Spot Instances är oanvänd EC2-kapacitet som AWS säljer till ett marknadspris som typiskt ligger 70–90 % under On-Demand. Sedan 2017 fungerar prissättningen inte längre som en auktion utan justeras gradvis baserat på utbud och efterfrågan per instanstyp, storlek och Availability Zone (AZ). Du betalar det aktuella Spot-priset, oavsett vad du angav som maxpris (de flesta sätter idag max_price till On-Demand-priset, eller utelämnar fältet helt).

När AWS behöver kapaciteten tillbaka får du en två minuters förvarning via instansmetadata på endpointen /latest/meta-data/spot/instance-action, samt via en EventBridge-händelse EC2 Spot Instance Interruption Warning. Den nya Rebalance Recommendation-signalen, som kom 2020 och är default-aktiv 2026, varnar dig tidigare, ofta 5–15 minuter innan ett faktiskt avbrott, så att du hinner dränera trafik.

I produktion bör du betrakta Spot som en pool av fungibla instanser. Du ska aldrig binda ditt schedulingsbeslut till en specifik instans-id eller AZ. Tänk på det som spotpris för el: leverantören kan koppla bort dig, men din uppgift som arkitekt är att designa lasten så att det knappt märks.

Hur mycket kan du spara med Spot Instances?

I min senaste kundgenomgång (Q2 2026, eu-north-1 och eu-west-1) såg jag följande typiska rabatter mot On-Demand:

Instansfamilj	Användningsfall	Typisk rabatt	Avbrottsfrekvens
m7i.large / m7a.large	Generell compute, web tier	72–78 %	<5 %
c7g.xlarge (Graviton)	API-tjänster, microservices	78–86 %	<5 %
r7g.2xlarge	Cache, in-memory databaser	68–74 %	5–10 %
g6.xlarge (L4 GPU)	ML-inferens	55–70 %	10–15 %
p5.48xlarge (H100)	LLM-träning	30–50 %	15–20 %
i4i.2xlarge (NVMe)	Storage-intensiva DB	65–72 %	5–10 %

Notera att GPU-instanser har både lägre rabatt och högre avbrottsfrekvens. Efterfrågan på H100 och L40S är fortsatt extrem 2026, så Spot-poolen där är tunn även mitt på natten. Om du vill gräva djupare i hur du sänker GPU-räkningen för AI-laster har vi en separat guide om FinOps för AI och GPU-kostnader.

Jag rekommenderar att du alltid kontrollerar färska siffror i AWS Spot Instance Advisor innan du planerar. Verktyget visar både genomsnittlig rabatt och frekvens av avbrott (<5 %, 5–10 %, 10–15 %, 15–20 %, >20 %) per instans och region.

Hur hanterar du Spot-avbrott i produktion?

Bra avbrottshantering består av tre lager: detektion, dränering och återhämtning. Här är den minimala uppsättningen jag installerar på varje nytt Spot-kluster.

1. Lyssna på instansmetadata (IMDSv2)

Varje instans pollar sin egen metadataendpoint var 5:e sekund. Så fort /latest/meta-data/spot/instance-action returnerar 200 har du två minuter på dig. Inte mer.

#!/bin/bash
# /usr/local/bin/spot-watcher.sh — kör som systemd-tjänst
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 300")

while true; do
  HTTP_CODE=$(curl -s -o /tmp/spot-action -w "%{http_code}" \
    -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/spot/instance-action)

  if [ "$HTTP_CODE" = "200" ]; then
    logger -t spot-watcher "Interruption notice received: $(cat /tmp/spot-action)"
    # Dränera Kubernetes nod
    kubectl cordon $(hostname)
    kubectl drain $(hostname) --ignore-daemonsets --delete-emptydir-data --force --grace-period=90
    # Skicka SIGTERM till applikationsservice
    systemctl stop myapp.service
    exit 0
  fi
  sleep 5
done

2. Prenumerera på EventBridge för flottövergripande synlighet

EventBridge-regeln nedan triggar en Lambda som loggar varje avbrott till CloudWatch och kan justera Auto Scaling Group-storleken i realtid:

{
  "source": ["aws.ec2"],
  "detail-type": [
    "EC2 Spot Instance Interruption Warning",
    "EC2 Instance Rebalance Recommendation"
  ]
}

3. Använd AWS Node Termination Handler för EKS

För Kubernetes använder du aws-node-termination-handler v1.22 (mars 2026). Den kör som DaemonSet i IMDS-läge och hanterar både Spot- och scheduled maintenance-event automatiskt. Sätt enableRebalanceMonitoring=true och enableRebalanceDraining=true, så börjar den agera på Rebalance Recommendation, inte bara på det slutgiltiga avbrottet.

Mixed Instance Policies och diversifiering

Det enskilt största misstaget jag ser hos nya Spot-användare är att de bara kör en instanstyp. Då blir avbrottsfrekvensen i praktiken samma som AWS publicerar, ofta 5–10 %. Lösningen är diversifiering: be Auto Scaling Group om kapacitet från en pool av instanser och låt EC2 plocka det billigaste tillgängliga just nu.

En produktionsklar Mixed Instances-policy ser ut så här i Terraform:

resource "aws_autoscaling_group" "api" {
  name                = "api-spot"
  min_size            = 6
  max_size            = 60
  desired_capacity    = 12
  vpc_zone_identifier = data.aws_subnets.private.ids  # minst 3 AZ

  capacity_rebalance = true  # KRITISKT

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

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.api.id
        version            = "$Latest"
      }
      # Diversifiera över minst 10 typer, samma vCPU/RAM-storleksklass
      override { instance_type = "m7i.large" }
      override { instance_type = "m7a.large" }
      override { instance_type = "m6i.large" }
      override { instance_type = "m6a.large" }
      override { instance_type = "m5.large" }
      override { instance_type = "m5n.large" }
      override { instance_type = "m5a.large" }
      override { instance_type = "c7i.large" }
      override { instance_type = "c6i.large" }
      override { instance_type = "c5.large" }
    }
  }
}

Tre saker som gör eller bryter den här konfigurationen:

• price-capacity-optimized är default-strategin sedan 2023 och nästan alltid rätt val. Den balanserar lägsta pris mot lägsta avbrottsrisk, inte bara billigast.
• capacity_rebalance = true låter ASG starta en ersättningsinstans när Rebalance Recommendation kommer, inte efter avbrottet. Det ger dig 5–15 minuter att flytta last.
• on_demand_base_capacity håller en liten On-Demand-bas (här 2 instanser) som garanti om hela Spot-poolen kollapsar samtidigt. För kritiska tjänster, sätt detta till minst 20 % av basbehovet.

Spot Placement Score, välj rätt AZ

Spot Placement Score (SPS) är en relativt okänd funktion som svarar på frågan: "Hur sannolikt är det att jag får N vCPU av instanstyp X i region Y under nästa timme?" Poängen går från 1 (osannolikt) till 10 (mycket sannolikt). Du frågar API:et via get-spot-placement-scores:

aws ec2 get-spot-placement-scores \
  --region-names eu-north-1 eu-west-1 eu-central-1 \
  --instance-requirements-with-metadata '{
    "ArchitectureTypes": ["x86_64", "arm64"],
    "VirtualizationTypes": ["hvm"],
    "InstanceRequirements": {
      "VCpuCount": {"Min": 2, "Max": 4},
      "MemoryMiB": {"Min": 4096, "Max": 16384},
      "AllowedInstanceTypes": ["m*.large", "c*.large", "m*.xlarge"]
    }
  }' \
  --target-capacity 200 \
  --target-capacity-unit-type vcpu \
  --single-availability-zone

I praktiken: kör SPS som ett nattligt jobb och låt resultatet styra vilken region nya kluster placeras i. Skillnaden mellan en SPS 9 och SPS 4 kan vara hundratals avbrott per dag i ett stort kluster. Detaljerna kring API:et finns dokumenterade i AWS EC2 User Guide för Spot Placement Score.

Karpenter och EKS på Spot

Om du kör Kubernetes är Karpenter i de flesta fall ett bättre val för Spot än EKS Managed Node Groups (MNG). Sedan v1.0 (augusti 2024) och nu v1.3 (april 2026) hanterar Karpenter Spot-avbrott via inbyggd interruption queue som lyssnar på SQS. Inget separat DaemonSet behövs.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["m", "c", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["5"]
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["eu-north-1a", "eu-north-1b", "eu-north-1c"]
      expireAfter: 24h  # rotera dagligen för att fånga billigare kapacitet
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Karpenter använder också consolidation: om en nod är underutnyttjad och en billigare instanstyp finns tillgänglig, flyttas poddarna automatiskt. Det är en av de största skillnaderna mot MNG och kan ge 15–25 % extra besparing utöver själva Spot-rabatten. För djupare resurseffektivitet inom själva poddarna, se vår guide om Kubernetes right-sizing med VPA och Goldilocks.

Vilka workloads passar (och inte) för Spot?

Den gamla regeln "bara stateless batch" gäller inte längre 2026. Det jag ser i produktion:

• Utmärkt fit: Webfrontend, API-gateways, stateless microservices, CI/CD-runners, ML-inferens med autoscaling, dataprocessing (Spark, Flink), rendering, Kubernetes worker nodes.
• OK med arbete: Caches (Redis med replikering), message brokers (Kafka med MinISR ≥ 2), backend för spel, sökindex.
• Hör hemma på On-Demand eller Savings Plans: Single-instance RDBMS-primärer, license-bundna instanser (BYOL Windows), Active Directory, betalningstjänster med <1 s SLA på enskild request.

Min tumregel: om workloaden tål en omstart om en timme på torsdag eftermiddag, tål den Spot.

Spot vs Savings Plans, kan jag kombinera?

Absolut, och det är så jag rekommenderar att alla större konton struktureras. Tänk i tre lager:

1. Basbelastning på Compute Savings Plans (1- eller 3-årig, no upfront): täcker de timmar du vet att du körs 24/7. Cirka 50–66 % rabatt mot On-Demand.
2. Variabel last på Spot: ovanpå basen, med Mixed Instance Policies eller Karpenter. Cirka 70–90 % rabatt.
3. Spike-buffer på On-Demand: liten andel (5–10 %) som faller in om Spot-pool slut OCH SP-täckning utnyttjad.

För djupdykning i hur SP själv fungerar och hur de skiljer sig från RI, se vår jämförelse AWS Savings Plans vs Reserved Instances. Och ja, Savings Plans gäller bara för On-Demand-fakturering, så de och Spot konkurrerar inte om samma timmar.

Vanliga misstag som äter upp besparingarna

De fem fel jag ser oftast i kundgranskningar:

1. Bara en instanstyp i ASG. Ger 5–10 % avbrott, ingen diversifiering. Lös med Mixed Instance Policies (minst 10 typer).
2. Capacity Rebalance avstängd. Defaulten är false i många äldre Terraform-moduler. Sätt capacity_rebalance = true överallt.
3. Ingen graceful drain. Pods dödas hårt efter två minuter, och användare ser 5xx. Installera node-termination-handler eller använd Karpenter.
4. För hög terminationGracePeriodSeconds. Sätter du 300 sekunder hinner inte dräneringen. Sätt max 90.
5. Spot för "allt". Att tvinga RDS-primären på Spot är ett självmål. Behåll On-Demand där state inte kan rekonstrueras.

Vanliga frågor

Hur mycket kan man verkligen spara med EC2 Spot Instances 2026?

Realistiskt 60–80 % över hela arbetsbelastningen, jämfört med ren On-Demand. De "upp till 90 %" AWS marknadsför gäller enskilda instanstyper i låga efterfrågetider. En väl diversifierad mix av m-, c- och r-familjer på Graviton ger oftast runt 75 % i praktiken.

Är Spot Instances tillförlitliga för produktion?

Ja, om du designar för avbrott. Stora SaaS-företag (inklusive Pinterest, Lyft och Skyscanner) kör majoriteten av sin compute på Spot. Nyckeln är Mixed Instance Policies, Capacity Rebalancing och korrekt graceful shutdown, inte att hoppas på att avbrott inte sker.

Vad är skillnaden mellan Spot Instances och Reserved Instances?

RI är ett 1- eller 3-årigt åtagande mot betalning i förskott eller månadsvis, med 30–72 % rabatt och garanterad kapacitet. Spot är reservkapacitet utan åtagande, med 60–90 % rabatt men kan tas tillbaka med två minuters varsel. RI och Savings Plans används för basbelastning, Spot för variabel last.

Kan jag köra Kubernetes-kontrollplan på Spot?

EKS kontrollplan körs av AWS och är inte Spot-kompatibelt. Däremot kan worker nodes köras till 100 % på Spot om du har Karpenter eller node-termination-handler installerat. Kritiska systempods (CoreDNS, kube-proxy, ingress controller) bör spridas över flera Spot-noder med Pod Disruption Budgets.

Hur ofta avbryts Spot Instances?

Enligt AWS Spot Instance Advisor (juni 2026) har de flesta m-, c- och r-familjer under 5 % avbrottsfrekvens per månad. Med 10+ instanstyper i en Mixed Instance Policy ser jag i praktiken under 1 % effektiv avbrottsfrekvens på klusternivå.

Vad händer om hela Spot-poolen är slut?

Då skalar ASG inte upp och kapaciteten stannar på nuvarande nivå tills Spot blir tillgängligt igen. Skydda dig genom att sätta on_demand_base_capacity till en miniminivå (t.ex. 20 % av baslast) och övervaka CloudWatch-måttet GroupTotalCapacity mot GroupDesiredCapacity.