Vilka arbetsbelastningar passar för spot?

Inte alla tjänster klarar avbrott, och spot är inte ett universalmedel. Här är arbetsbelastningstyperna vi konsekvent rekommenderar — och de vi avråder från:

Idealiska spot-kandidater

CI/CD-byggen och testning. Byggagenter körs i minuter, är tillståndslösa och kan enkelt startas om. En avbruten build-agent innebär bara att jobbet körs om. Vid stor bygglast kan spot-baserade agenter sänka CI/CD-kostnaden dramatiskt.

Batchbearbetning och ETL. Datapipelines med checkpointing — Spark-jobb, EMR-kluster, Dataproc — är designade för nodfel. Jobbet fortsätter från senaste checkpoint, inte från noll. Nyckeln: aktivera checkpointing explicit, det är sällan påslaget som standard.

ML-träning. Träningsjobb som sparar modellvikter regelbundet kan återupptas vid avbrott. Med spot-instanser för GPU-kapacitet (t.ex. p4d eller g5 på AWS) handlar besparingen om tiotusentals kronor per träningskörning.

Utvecklings- och stagingmiljöer. Här är korta avbrott acceptabla per definition. Att köra dev/staging på on-demand när spot finns tillgängligt är i princip att slänga pengar.

Statslösa mikrotjänster med flera repliker. Om du kör 6 repliker av en API-tjänst och förlorar 1 till spot-avbrott, hanterar de återstående 5 trafiken medan en ersättning startar. Ingen användare märker något.

Arbetsbelastningar du inte bör köra på spot

• Databaser och andra tillståndstunga tjänster med lång återställningstid
• Singleton-tjänster utan repliker (enskilda felpunkter)
• Arbetsbelastningar med hårda latenskrav som inte tål omschemaläggning
• Licenskopplade instanser där omstart innebär licensproblem

Tre spot-strategier som fungerar i produktion

1. Instansdiversifiering — den viktigaste åtgärden

Den vanligaste nybörjarmissen är att begära en enda instanstyp i en enda tillgänglighetszon. Då är du helt exponerad mot kapacitetssvängningar i den specifika poolen.

Rätt strategi: begär kapacitet över 5–10 instanstyper i minst 2–3 tillgänglighetszoner. AWS Spot Fleet med capacity-optimized allokeringsstrategi väljer automatiskt de instanser som har störst tillgänglig kapacitet — och därmed lägst sannolikhet för avbrott.

Enligt AWS egen dokumentation sjunker avbrottsfrekvensen från 10–20 % (enskild instanstyp, enskild zon) till under 5 % vid god diversifiering. Det är skillnaden mellan en fungerande strategi och en frustrerande upplevelse.

Praktiskt tips: välj instanstyper med likvärdig CPU/minne-ratio. Om din applikation behöver 4 vCPU / 16 GB, funkar m5.xlarge, m5a.xlarge, m5d.xlarge, m6i.xlarge, m6a.xlarge och c5.2xlarge alla som kandidater.

2. Graciös avstängningshantering

Utan en korrekt avstängningshanterare är spot-instanser ett recept för dataförlust. Hanteraren måste göra följande inom varseltiden (2 minuter på AWS, 30 sekunder på Azure/GCP):

1. Avregistrera från lastbalanserare — sluta ta emot ny trafik

2. Dränera pågående anslutningar — låt aktiva requests slutföras

3. Checkpoint pågående arbete — spara batchjobbets progress till S3, Azure Blob eller GCS

4. Avregistrera från tjänsteupptäckt — ta bort instansen ur service discovery

5. Signalera orkestreringslagret — meddela Auto Scaling Group eller Kubernetes att kapacitet behövs

AWS levererar avbrottsvarningen via instansens metadatatjänst (http://169.254.169.254/latest/meta-data/spot/termination-time) samt som EventBridge-event. Vi rekommenderar att lyssna på båda — metadatatjänsten som primär källa, EventBridge som backup.

3. Blandade instansgrupper — spot plus on-demand

Kör aldrig 100 % av en produktionstjänst på spot. Strategin vi implementerar hos Opsio ser ut så här:

• Baslinje: 2–3 on-demand-instanser (eller Reserved Instances / Savings Plans) som garanterar minimikapacitet
• Variabel kapacitet: 0–N spot-instanser som skalas upp vid behov och ner vid avbrott
• Nödfallback: On-demand auto scaling som triggas om spot-kapaciteten försvinner helt

AWS Auto Scaling Groups stöder detta via mixed instances policy. Du anger en baslinje av on-demand-instanser som alltid är aktiv, plus spot-instanser som läggs till vid skalning. Om spot-poolen töms bibehåller on-demand-basen minimikapacitet.

Spot och Kubernetes: en naturlig kombination

Kubernetes är den bästa plattformen för spot-instanser, eftersom orkestreringslagret redan är byggt för nodfel. Så här konfigurerar vi det:

Dedikerade spot-nodpooler. Separera spot- och on-demand-noder i olika nodpooler. Använd taints på spot-noderna (spot=true:NoSchedule) och tolerations på de pods som får schemaläggas där.

Pod Disruption Budgets (PDB). Konfigurera PDB:er som garanterar att Kubernetes aldrig tar ner för många repliker samtidigt. Exempel: minAvailable: 3 för en tjänst med 5 repliker.

AWS Karpenter eller Cluster Autoscaler. Karpenter (AWS) hanterar spot-diversifiering och automatisk ersättning snabbare och mer flexibelt än den klassiska Cluster Autoscaler. Vid spot-avbrott provisionerar Karpenter automatiskt ersättningsnoder — ofta inom 30–60 sekunder.

Topologi-spridning. Använd topologySpreadConstraints för att sprida repliker över tillgänglighetszoner, så att ett spot-avbrott i en zon inte tar ner alla repliker.

Managerad Kubernetes-drift

Så implementerar Opsio spot-strategier

Vi ser spot-optimering som en del av en bredare Cloud FinOps-strategi. Processen vi följer:

Arbetsbelastningsbedömning. Vi kartlägger alla beräkningsarbetsbelastningar och klassificerar dem efter avbrottstolerans, tillståndshantering och repliker. Typiskt är 30–50 % av en organisations arbetsbelastningar spot-kandidater.

Arkitekturdesign. Vi designar blandade instansgrupper, implementerar avstängningshanterare, konfigurerar diversifieringsstrategier och sätter upp fallback-mekanismer. Inget lämnas åt slumpen.

Kontinuerlig övervakning. Via Opsios NOC övervakar vi spot-besparingar, avbrottsfrekvenser och påverkan på arbetsbelastningar dygnet runt. Vi justerar instanstypsmix och allokeringsstrategier baserat på faktiska avbrottsmönster — inte gissningar.

Kubernetes-integration. För containeriserade miljöer konfigurerar vi nodpooler, taints, tolerations, PDB:er och Karpenter. Vi ser till att spot-noder fungerar transparent i klustret.

Managerade molntjänster

Kostnadsmodellen i praktiken: ett räkneexempel

En organisation som kör 20 instanser (m6i.xlarge) i eu-north-1 betalar ungefär 0,192 USD/timme per instans on-demand. Med spot sjunker priset typiskt till 0,06–0,08 USD/timme — runt 60–70 % besparing.

Om 12 av 20 instanser körs på spot (60 % spot-andel) och 8 på on-demand (baslinje), ser månadskalkylen ut ungefär så här:

• On-demand (8 st): 8 × 0,192 × 730 ≈ 1 121 USD/månad
• Spot (12 st): 12 × 0,07 × 730 ≈ 613 USD/månad
• Totalt: ~1 734 USD/månad
• Jämfört med 100 % on-demand: 20 × 0,192 × 730 ≈ 2 803 USD/månad
• Besparing: ~38 % totalt — och det är med en konservativ spot-andel

Med högre spot-andel och aggressivare diversifiering har vi sett organisationer komma ner mot 50–60 % total besparing på sin beräkningskapacitet.

Vanliga frågor

Kan spot-instanser användas i produktion?

Ja, men enbart för statslösa tjänster med flera repliker och automatisk ersättning. Kombination med on-demand-baslinje och graciös avstängningshantering är absoluta krav. Stora aktörer som Netflix och Lyft kör betydande produktionstrafik på spot — men med sofistikerad infrastruktur för att hantera avbrott.

Hur hög är avbrottsfrekvensen i praktiken?

AWS har historiskt rapporterat att färre än 5 % av spot-instanser avbryts per månad vid god diversifiering. Med bara en instanstyp i en zon kan frekvensen stiga till 10–20 %. Diversifiering över instansfamiljer och zoner är den enskilt viktigaste åtgärden.

Vad händer med pågående arbete vid ett avbrott?

AWS ger 2 minuters varning via instansens metadatatjänst, Azure och GCP ger 30 sekunder. Under den tiden bör din avstängningshanterare dränera anslutningar, spara tillstånd till beständig lagring och avregistrera instansen. Utan checkpointing förlorar du allt arbete sedan senaste sparning.

Hur fungerar spot-instanser med Kubernetes?

Du skapar dedikerade nodpooler med spot-instanser och använder taints samt tolerations för att styra vilka pods som schemaläggs där. Pod Disruption Budgets säkerställer att Kubernetes inte tappar för många repliker samtidigt. AWS Karpenter och Azure Karpenter hanterar automatisk ersättning.

Går det att kombinera spot med Reserved Instances eller Savings Plans?

Absolut — och det bör du göra. Reserved Instances eller Savings Plans täcker din förutsägbara baslinje, on-demand hanterar plötsliga toppar, och spot ger billig kapacitet för arbetsbelastningar som tål avbrott. Den tredelade modellen ger ofta den bästa totala kostnadsbilden.