Perché le Istanze Spot Sono l'Arma Segreta del Risparmio Cloud
Nel mondo del cloud computing nel 2026, una cosa è chiara: chi non sta usando le istanze Spot sta letteralmente lasciando soldi sul tavolo. E non spiccioli, eh — parliamo di risparmi che arrivano fino al 90% rispetto ai prezzi on-demand. Eppure, la maggior parte delle aziende copre con istanze Spot meno del 20% dei propri workload idonei. Un dato che, onestamente, mi lascia perplesso ogni volta che lo leggo.
Il motivo? Il timore delle interruzioni. L'idea che il provider possa "revocare" la capacità in qualsiasi momento spaventa molti team di ingegneria. Ma ecco il punto: con le strategie giuste e gli strumenti di automazione disponibili oggi — da Karpenter su Kubernetes agli Auto Scaling Group di AWS, dalle VMSS di Azure ai Managed Instance Group di GCP — gestire le interruzioni non è più un problema insormontabile. È un problema risolto.
In questa guida vediamo tutto quello che serve per adottare le istanze Spot su larga scala nel 2026: come funzionano sui tre principali provider, quali workload sono adatti, come costruire una strategia di diversificazione che funzioni davvero, e come integrare il tutto in una strategia FinOps completa.
Come Funzionano le Istanze Spot: I Fondamentali
Prima di tuffarci nelle strategie avanzate, chiariamo il meccanismo di base. Le istanze Spot (o Spot VM, come le chiamano Azure e GCP) sono macchine virtuali create dalla capacità inutilizzata nei data center dei provider cloud. Siccome questa capacità rimarrebbe comunque inattiva, i provider la offrono a prezzi drasticamente ridotti — ma con una condizione: possono revocarla quando la domanda aumenta.
Semplice come concetto. I dettagli di implementazione, però, variano parecchio tra AWS, Azure e GCP.
Il Modello di Pricing
A differenza dei prezzi on-demand — fissi e prevedibili — i prezzi Spot sono variabili e dipendono dalla domanda e dall'offerta per ogni specifico pool di capacità (la combinazione di tipo di istanza, zona di disponibilità e regione). I tre provider gestiscono questa variabilità in modi abbastanza diversi:
- AWS: i prezzi Spot fluttuano continuamente, con una media di 197 variazioni di prezzo mensili per tipo di istanza. Sì, avete letto bene — quasi 200 variazioni al mese. Questo richiede strumenti di monitoraggio e automazione adeguati
- Azure: i prezzi cambiano meno frequentemente, con variazioni nell'ordine di poche volte al mese. Molto più tranquillo
- GCP: il pricing è il più stabile dei tre, con variazioni medie di circa una volta ogni tre mesi. Se cercate prevedibilità, GCP è il vostro alleato
Sconti Tipici per Provider
I risparmi effettivi dipendono dal tipo di istanza, dalla regione e dal momento, ma ecco le fasce tipiche:
- AWS EC2 Spot: fino al 90% di sconto rispetto all'on-demand
- Azure Spot VM: fino all'80% di sconto (con punte del 90% per alcuni tipi di VM)
- GCP Spot VM: fino al 91% di sconto — il più aggressivo dei tre
Secondo il Kubernetes Cost Benchmark Report 2025, i cluster con un mix di on-demand e Spot registrano un risparmio medio del 59%, mentre quelli interamente su Spot arrivano al 77%. Numeri che parlano da soli.
Confronto Dettagliato: Spot su AWS, Azure e GCP
Ogni provider ha costruito il proprio ecosistema attorno alle istanze Spot, con terminologie, meccanismi di interruzione e strumenti di gestione differenti. Vediamoli uno per uno.
AWS EC2 Spot Instances
AWS è il provider con il mercato Spot più maturo e articolato. Le EC2 Spot Instances offrono sconti fino al 90% sulla capacità inutilizzata di EC2.
Meccanismo di interruzione: quando AWS ha bisogno della capacità, invia un avviso con un preavviso di 2 minuti. L'istanza può essere terminata, fermata o ibernata, a seconda della configurazione. In più, AWS emette un segnale di EC2 Instance Rebalance Recommendation che avvisa quando un'istanza è a rischio elevato di interruzione — un po' come un "allarme giallo" che dà tempo extra per reagire.
Tassi di interruzione: storicamente, meno del 5% delle istanze Spot viene interrotto in un dato mese. Attenzione però: il tasso varia molto per tipo di istanza e zona di disponibilità. AWS è il provider con il tasso di interruzione complessivo più alto, e oltre la metà delle interruzioni avvengono nella prima ora di vita del nodo (una cosa da tenere a mente quando si progetta la propria strategia).
Novità 2026: a gennaio 2026, EC2 Capacity Manager ha introdotto metriche di interruzione Spot integrate, offrendo visibilità diretta dalla console EC2 sul comportamento delle istanze Spot. Un passo avanti significativo.
Strategie di allocazione:
- price-capacity-optimized (PCO): la strategia raccomandata da AWS. Considera prima la capacità disponibile per ridurre le interruzioni, poi il prezzo. È il miglior compromesso tra costo e stabilità
- capacity-optimized: alloca dalle pool con la capacità più profonda, prioritizzando la stabilità
- lowest-price: sceglie le istanze più economiche. Non raccomandata — il rischio di interruzione è troppo elevato
# Esempio: configurazione EC2 Auto Scaling Group con Spot
# usando attribute-based instance type selection
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-spot-asg \
--mixed-instances-policy '{
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-template",
"Version": "$Latest"
},
"Overrides": [{
"InstanceRequirements": {
"VCpuCount": {"Min": 4, "Max": 16},
"MemoryMiB": {"Min": 8192, "Max": 32768},
"CpuManufacturers": ["intel", "amd"],
"InstanceGenerations": ["current"],
"BurstablePerformance": "excluded"
}
}]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 2,
"OnDemandPercentageAboveBaseCapacity": 20,
"SpotAllocationStrategy": "price-capacity-optimized",
"SpotMaxPrice": ""
}
}' \
--min-size 4 \
--max-size 20 \
--desired-capacity 8 \
--vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc"Qualche nota su questa configurazione: la selezione basata sugli attributi (invece di tipi di istanza specifici) garantisce flessibilità automatica; OnDemandBaseCapacity a 2 assicura una base stabile; il 20% on-demand sopra la base offre un cuscinetto di affidabilità; e la strategia price-capacity-optimized bilancia costo e disponibilità. Un setup solido da cui partire.
Azure Spot VM
Azure offre Spot VM dalla propria capacità eccedente, con sconti fino all'80-90%. Rispetto ad AWS, Azure si distingue per una maggiore stabilità — i tassi di interruzione sono complessivamente più bassi, specialmente nelle prime 12 ore di vita della VM.
Meccanismo di interruzione: Azure offre due politiche di evizione:
- Deallocate: la VM viene fermata ma non eliminata. Può essere riavviata quando la capacità torna disponibile — nel frattempo si pagano solo i costi di storage
- Delete: la VM e il disco temporaneo vengono eliminati completamente
La politica Deallocate è particolarmente interessante: permette di preservare la configurazione e i dati persistenti senza costi di calcolo, riprendendo l'esecuzione non appena la capacità si libera. Un approccio più "morbido" rispetto alla terminazione secca.
Prezzo massimo: Azure permette di impostare un prezzo massimo per le Spot VM. Se il prezzo Spot supera la soglia, la VM viene evita. Un trucco utile: impostando il prezzo massimo a -1, la VM non verrà mai evita per ragioni di prezzo, ma solo per mancanza di capacità.
# Esempio: creazione di un Azure Spot VM con Azure CLI
az vm create \
--resource-group myResourceGroup \
--name mySpotVM \
--image Ubuntu2204 \
--size Standard_D4s_v5 \
--priority Spot \
--eviction-policy Deallocate \
--max-price 0.08 \
--generate-ssh-keys
# Esempio: configurazione VMSS con Spot
az vmss create \
--resource-group myResourceGroup \
--name mySpotVMSS \
--image Ubuntu2204 \
--priority Spot \
--eviction-policy Delete \
--max-price -1 \
--instance-count 10 \
--lb myLoadBalancer \
--upgrade-policy-mode automaticGCP Spot VM
Google Cloud ha unificato il precedente modello di Preemptible VM con le Spot VM nel 2022, creando un'offerta decisamente più flessibile. Le GCP Spot VM offrono gli sconti più aggressivi tra i tre provider — fino al 91% — e coprono non solo le VM di Compute Engine, ma anche GPU, TPU e Local SSD.
Meccanismo di interruzione: GCP invia un avviso di soli 30 secondi prima di revocare la capacità. Trenta secondi. È il preavviso più breve tra i tre provider (AWS ne dà 2 minuti, Azure generalmente offre più tempo). Questo richiede una gestione delle interruzioni particolarmente reattiva — ogni secondo conta.
Vantaggi unici di GCP:
- Nessun limite di durata: a differenza delle vecchie Preemptible VM (che avevano un limite di 24 ore), le Spot VM possono girare indefinitamente. Se la capacità lo permette, la vostra istanza resta su
- Prezzi stabili: con variazioni ogni tre mesi in media, la prevedibilità dei costi è molto superiore
- Integrazione con GKE Autopilot: le Spot VM sono supportate su GKE Autopilot tramite Spot Pods, con scheduling e gestione automatica
# Esempio: creazione Spot VM su GCP con gcloud
gcloud compute instances create my-spot-instance \
--zone=europe-west1-b \
--machine-type=n2-standard-4 \
--provisioning-model=SPOT \
--instance-termination-action=STOP \
--maintenance-policy=TERMINATE \
--no-restart-on-failure
# Esempio: creazione Managed Instance Group con Spot
gcloud compute instance-templates create spot-template \
--machine-type=n2-standard-4 \
--provisioning-model=SPOT \
--instance-termination-action=DELETE
gcloud compute instance-groups managed create spot-mig \
--template=spot-template \
--size=5 \
--zone=europe-west1-bQuali Workload Sono Adatti alle Istanze Spot?
Non tutto può girare su istanze Spot. La regola d'oro è semplice: un workload è adatto se può tollerare interruzioni senza compromettere il risultato finale o l'esperienza utente.
Detto questo, la lista dei workload compatibili è più lunga di quanto si possa pensare.
Workload Ideali
- Elaborazione batch e ETL: pipeline di dati, trasformazioni ETL, renderizzazione di immagini e video, modellazione scientifica. Questi workload sono intrinsecamente tolleranti ai guasti e possono riprendere dal punto in cui si sono interrotti tramite checkpoint
- Pipeline CI/CD: build automatizzate, test di carico, quality assurance. Sono progettate per essere ripetibili — se un'interruzione fa fallire una build, si rilancia e basta
- Training di modelli ML: caso d'uso eccellente, a condizione di implementare il checkpointing periodico. Framework come PyTorch e TensorFlow supportano nativamente il salvataggio e il ripristino dei checkpoint
- Ambienti di sviluppo e staging: ambienti non critici dove un'interruzione occasionale è perfettamente accettabile (e nessuno si accorge della differenza)
- Web crawler e data scraping: operazioni inherentemente parallelizzabili e tolleranti ai guasti
- Microservizi stateless: container e microservizi senza stato interno sono candidati naturali. Del resto, i container sono pensati per essere immutabili ed effimeri — esattamente la filosofia delle istanze Spot
Workload da Evitare
- Database primari: database di produzione che richiedono uptime continuo e consistenza dei dati. No, assolutamente no
- Applicazioni monolitiche stateful: se mantengono stato in memoria e non possono essere interrotte senza perdita di dati, lasciatele su on-demand
- Nodi master di Kubernetes: il piano di controllo deve rimanere stabile — usate sempre on-demand o reserved
- Applicazioni con SLA stringenti: servizi che garantiscono uptime del 99,99% non possono dipendere da capacità che potrebbe scomparire da un momento all'altro
La Strategia di Diversificazione: La Chiave del Successo
Se c'è un singolo concetto da portarsi a casa da questa guida, è questo: la diversificazione è tutto.
La causa principale dei problemi con le istanze Spot non è l'interruzione in sé — è l'incapacità di ottenere capacità sostitutiva. E questo si risolve con una diversificazione aggressiva dei pool di capacità. Lo ripeto perché è davvero il punto cruciale.
Cos'è un Pool di Capacità Spot?
Un pool di capacità Spot è definito dalla combinazione di tre variabili: tipo di istanza, zona di disponibilità e regione. Per esempio, m5.xlarge in eu-west-1a è un pool diverso da m5.xlarge in eu-west-1b o m6i.xlarge in eu-west-1a. Più pool avete nella configurazione, maggiore è la probabilità di avere sempre capacità disponibile.
Regola dei 10+ Tipi di Istanza
AWS raccomanda esplicitamente di configurare almeno 10 tipi di istanza diversi per ogni workload. La logica è semplice: se un pool si esaurisce, gli altri 9+ assorbono il carico. In pratica, le organizzazioni più mature usano 15-20 tipi di istanza per i workload critici.
Selezione Basata sugli Attributi
Una delle funzionalità più utili introdotte da AWS è la selezione basata sugli attributi (Attribute-Based Instance Type Selection). Invece di specificare a mano ogni tipo di istanza, si definiscono i requisiti — numero di vCPU, quantità di memoria, generazione dell'istanza, produttore della CPU — e l'Auto Scaling Group seleziona automaticamente tutte le istanze che soddisfano quei criteri.
Il vantaggio enorme? Quando AWS rilascia nuove famiglie di istanze, queste vengono incluse automaticamente nella selezione senza toccare la configurazione. Meno manutenzione, più capacità disponibile.
# Esempio di NodePool Karpenter con diversificazione Spot
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: spot-workloads
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"]
- key: kubernetes.io/arch
operator: In
values: ["amd64", "arm64"]
- key: node.kubernetes.io/instance-type
operator: In
values:
- m5.xlarge
- m5.2xlarge
- m5a.xlarge
- m5a.2xlarge
- m6i.xlarge
- m6i.2xlarge
- m6a.xlarge
- m6a.2xlarge
- m7i.xlarge
- m7i.2xlarge
- m7a.xlarge
- m7a.2xlarge
- c5.xlarge
- c5.2xlarge
- c6i.xlarge
- c6i.2xlarge
- r5.xlarge
- r6i.xlarge
- key: topology.kubernetes.io/zone
operator: In
values:
- eu-west-1a
- eu-west-1b
- eu-west-1c
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 30sNotate come questo NodePool include 18 tipi di istanza su 3 zone di disponibilità, con supporto per entrambe le architetture (amd64 e arm64). Questo genera un numero enorme di pool di capacità potenziali.
CPU Arm per Risparmi Aggiuntivi
Un aspetto che molti trascurano: le istanze basate su CPU Arm (come le AWS Graviton, Azure Ampere Altra e GCP Tau T2A) offrono prezzi inferiori sia in on-demand che in Spot rispetto alle equivalenti x86. Il divario è particolarmente significativo su Azure, dove la differenza tra x86 e Arm raggiunge il 65% per l'on-demand e il 69% per le Spot.
Includere architetture Arm nella strategia di diversificazione è un doppio vantaggio: più pool di capacità disponibili e prezzi unitari più bassi. Due piccioni con una fava.
Automazione della Gestione delle Interruzioni
La gestione manuale delle istanze Spot è impraticabile a scala — semplicemente non funziona. La chiave per un'adozione di successo è l'automazione completa del ciclo di vita: rilevamento dell'interruzione, sostituzione automatica e fallback trasparente.
Karpenter su AWS EKS
Karpenter è diventato lo standard de facto per la gestione dei nodi su Amazon EKS, e la sua integrazione con le istanze Spot è, francamente, eccellente. Ecco come funziona il flusso:
- AWS invia un avviso di interruzione a una coda Amazon SQS (configurata tramite EventBridge)
- Karpenter riceve il messaggio dalla coda
- Karpenter mette il nodo in cordon (nessun nuovo pod viene schedulato)
- In parallelo, Karpenter provisiona un nodo sostitutivo
- I pod vengono rischedulati sul nuovo nodo
- Il nodo interrotto viene terminato
Il risultato? Downtime quasi zero nonostante la revoca dell'istanza Spot. Il tempo medio di avvio di un nuovo nodo con Karpenter è generalmente sufficiente per completare il drenaggio e la migrazione dei pod entro la finestra di 2 minuti. Nella mia esperienza, il processo è così fluido che spesso gli utenti non si accorgono nemmeno che un'interruzione è avvenuta.
# Configurazione infrastruttura per interruption handling Karpenter
# CloudFormation template (estratto)
Resources:
KarpenterInterruptionQueue:
Type: AWS::SQS::Queue
Properties:
QueueName: karpenter-interruption-queue
MessageRetentionPeriod: 300
SpotInterruptionRule:
Type: AWS::Events::Rule
Properties:
EventPattern:
source:
- aws.ec2
detail-type:
- EC2 Spot Instance Interruption Warning
Targets:
- Id: KarpenterInterruptionTarget
Arn: !GetAtt KarpenterInterruptionQueue.Arn
RebalanceRecommendationRule:
Type: AWS::Events::Rule
Properties:
EventPattern:
source:
- aws.ec2
detail-type:
- EC2 Instance Rebalance Recommendation
Targets:
- Id: KarpenterRebalanceTarget
Arn: !GetAtt KarpenterInterruptionQueue.Arn
InstanceStateChangeRule:
Type: AWS::Events::Rule
Properties:
EventPattern:
source:
- aws.ec2
detail-type:
- EC2 Instance State-change Notification
Targets:
- Id: KarpenterStateChangeTarget
Arn: !GetAtt KarpenterInterruptionQueue.ArnConsolidamento Spot-to-Spot
Un'altra funzionalità di Karpenter che vale la pena conoscere è il consolidamento Spot-to-Spot: quando rileva che un'istanza Spot più economica e con maggiore disponibilità è diventata accessibile, Karpenter può migrare automaticamente i pod. Si abilita tramite il feature flag SpotToSpotConsolidation e usa la strategia price-capacity-optimized per la selezione. In sostanza, ottimizza continuamente anche mentre i workload girano.
Fallback Automatico su On-Demand
Una strategia Spot robusta deve prevedere un meccanismo di fallback su on-demand. Se l'API EC2 Fleet indica che la capacità Spot non è disponibile, Karpenter memorizza quel risultato nella cache per 3 minuti per quel tipo di istanza e zona. Se non ci sono altre opzioni Spot, passa automaticamente al provisioning di istanze on-demand — generalmente entro millisecondi.
Questo garantisce che i workload non rimangano mai senza capacità, anche durante periodi di alta domanda. Un'assicurazione che, secondo me, rende l'intera strategia Spot molto più digeribile anche per i team più conservativi.
Strategia Ibrida: Combinare Spot, Reserved e On-Demand
Le istanze Spot non vanno mai considerate in isolamento. La strategia ottimale combina tre livelli di pricing in quello che i professionisti FinOps chiamano il modello "a strati".
Il Modello a Tre Strati
Questo approccio si integra con la strategia di commitment discount:
- Strato base (40-50%) — Sconti a impegno: Savings Plans, Reserved Instances o CUD per il carico base prevedibile. Risparmio: 30-72% rispetto all'on-demand
- Strato intermedio (30-40%) — Istanze Spot: per i workload tolleranti alle interruzioni. Risparmio: 60-90% rispetto all'on-demand
- Strato flessibile (10-20%) — On-demand: per i carichi imprevedibili e mission-critical. Nessuno sconto, ma massima affidabilità
# Calcolo del risparmio con strategia ibrida a tre strati
# Spesa on-demand mensile di riferimento: 200.000 EUR
spesa_base_mensile = 200000 # EUR
# Strato 1: Commitment (45% della base, sconto medio 55%)
commitment_pct = 0.45
commitment_sconto = 0.55
costo_commitment = spesa_base_mensile * commitment_pct * (1 - commitment_sconto)
# Strato 2: Spot (35% della base, sconto medio 75%)
spot_pct = 0.35
spot_sconto = 0.75
costo_spot = spesa_base_mensile * spot_pct * (1 - spot_sconto)
# Strato 3: On-demand (20% della base, nessuno sconto)
ondemand_pct = 0.20
costo_ondemand = spesa_base_mensile * ondemand_pct
costo_totale = costo_commitment + costo_spot + costo_ondemand
risparmio = spesa_base_mensile - costo_totale
risparmio_pct = (risparmio / spesa_base_mensile) * 100
print(f"Costo commitment: {costo_commitment:>10,.2f} EUR")
print(f"Costo Spot: {costo_spot:>10,.2f} EUR")
print(f"Costo on-demand: {costo_ondemand:>10,.2f} EUR")
print(f"Costo totale: {costo_totale:>10,.2f} EUR")
print(f"Risparmio mensile: {risparmio:>10,.2f} EUR ({risparmio_pct:.1f}%)")
print(f"Risparmio annuo: {risparmio * 12:>10,.2f} EUR")
# Output:
# Costo commitment: 40,500.00 EUR
# Costo Spot: 17,500.00 EUR
# Costo on-demand: 40,000.00 EUR
# Costo totale: 98,000.00 EUR
# Risparmio mensile: 102,000.00 EUR (51.0%)
# Risparmio annuo: 1,224,000.00 EURI numeri sono eloquenti: una strategia ibrida ben calibrata riduce la spesa cloud del 51% — oltre un milione di euro all'anno su una base di 200.000 euro mensili. E la percentuale di Spot al 35% è conservativa: molte organizzazioni mature arrivano al 50% o oltre per i workload idonei.
Best Practice Operative per il 2026
Bene, dopo la teoria e la strategia, passiamo alle best practice operative. Ecco cosa fanno le organizzazioni che hanno davvero capito come sfruttare le istanze Spot.
1. Diversificare Aggressivamente i Pool di Capacità
Configurare almeno 10-15 tipi di istanza diversi per ogni workload. Usare la selezione basata sugli attributi quando possibile. Distribuire il carico su almeno 3 zone di disponibilità. Includere sia architetture x86 che Arm. Lo so, sembra tanto — ma è la base su cui tutto il resto si regge.
2. Implementare la Gestione Automatizzata delle Interruzioni
Usare Karpenter (per EKS), Node Auto Provisioner (per AKS) o GKE Autopilot con Spot Pods per automatizzare completamente il ciclo di vita dei nodi Spot. Configurare le code SQS e le regole EventBridge per la gestione nativa degli eventi di interruzione.
3. Implementare il Checkpointing per i Workload di Lunga Durata
Per workload come il training di modelli ML o elaborazioni batch di lunga durata, il checkpointing periodico non è opzionale — è obbligatorio. Questo permette di riprendere il lavoro dal punto di interruzione anziché ricominciare da zero (e credete, ricominciare un training di 12 ore dal principio è un'esperienza che si vuole evitare).
# Esempio: checkpointing in PyTorch per training su istanze Spot
import torch
import signal
import sys
import os
CHECKPOINT_PATH = "/mnt/efs/checkpoints/model_checkpoint.pt"
def save_checkpoint(model, optimizer, epoch, loss):
"""Salva checkpoint su storage persistente (EFS/S3)"""
checkpoint = {
'epoch': epoch,
'model_state_dict': model.state_dict(),
'optimizer_state_dict': optimizer.state_dict(),
'loss': loss,
}
torch.save(checkpoint, CHECKPOINT_PATH)
print(f"Checkpoint salvato: epoch {epoch}, loss {loss:.4f}")
def load_checkpoint(model, optimizer):
"""Carica checkpoint se disponibile"""
if os.path.exists(CHECKPOINT_PATH):
checkpoint = torch.load(CHECKPOINT_PATH)
model.load_state_dict(checkpoint['model_state_dict'])
optimizer.load_state_dict(checkpoint['optimizer_state_dict'])
start_epoch = checkpoint['epoch'] + 1
print(f"Checkpoint ripristinato: ripresa da epoch {start_epoch}")
return start_epoch
return 0
# Handler per il segnale di terminazione Spot
def spot_termination_handler(signum, frame):
print("Segnale di interruzione Spot ricevuto! Salvataggio checkpoint...")
save_checkpoint(model, optimizer, current_epoch, current_loss)
sys.exit(0)
signal.signal(signal.SIGTERM, spot_termination_handler)
# Training loop con checkpoint periodico
start_epoch = load_checkpoint(model, optimizer)
for epoch in range(start_epoch, num_epochs):
current_epoch = epoch
current_loss = train_one_epoch(model, optimizer, dataloader)
# Salva checkpoint ogni 5 epoche
if epoch % 5 == 0:
save_checkpoint(model, optimizer, epoch, current_loss)4. Monitorare e Analizzare i Pattern di Interruzione
Usare le metriche di EC2 Capacity Manager (novità 2026) per analizzare i tassi di interruzione storici per tipo di istanza e zona. Configurare dashboard Grafana con le metriche Prometheus emesse da Karpenter. Usare AWS Spot Placement Score per identificare le regioni con la maggiore capacità disponibile prima di deployare nuovi workload.
5. Testare la Resilienza con Fault Injection
Non aspettate un'interruzione reale per scoprire se la vostra architettura regge. Usate AWS Fault Injection Service (FIS) per simulare interruzioni Spot in modo controllato. I pod vengono rischedulati correttamente? Il fallback funziona? I checkpoint si salvano e si ripristinano? Meglio scoprirlo durante un test che durante un venerdì sera in produzione.
6. Separare la Contabilità Spot
Deployare le istanze Spot sotto progetti di fatturazione dedicati o con tag specifici. Questo permette di rispondere a domande fondamentali: quanto stiamo effettivamente risparmiando? Qual è il tasso di interruzione reale? Quanto ci costa il fallback su on-demand? Senza dati precisi, state navigando alla cieca.
7. Valutare il Risparmio Spot per Regione
I prezzi Spot variano parecchio per regione, e le dinamiche locali di domanda-offerta possono creare opportunità interessanti. Alcune regioni meno utilizzate offrono sconti più profondi e tassi di interruzione più bassi. Vale la pena fare un'analisi regionale prima di decidere dove posizionare i workload Spot-intensive.
Transizione da Spot Fleet a EC2 Auto Scaling Groups
Una nota per chi usa ancora AWS Spot Fleet: è stato classificato come servizio legacy. AWS non ci sta più investendo in termini di nuove funzionalità. La migrazione verso EC2 Auto Scaling Groups è la strada da seguire — e la buona notizia è che i concetti di base (pool di capacità, strategie di allocazione, fallback su on-demand) rimangono identici. Cambia l'API e la configurazione, che si allineano meglio con l'ecosistema Auto Scaling più ampio.
Caso d'Uso Reale: Spot Instance Arbitrage Multi-Cloud
Un approccio avanzato che merita menzione è l'arbitraggio Spot multi-cloud. Organizzazioni come Spotify hanno dimostrato che orchestrare workload tra più provider — sfruttando le differenze di prezzo e disponibilità Spot — può generare risparmi notevoli. Spotify ha ottenuto 8 milioni di dollari di risparmi annui combinando l'arbitraggio multi-cloud con l'ottimizzazione delle reserved instances.
Questo approccio non è per tutti: richiede workload portabili tra cloud (tipicamente tramite container e Kubernetes) e strumenti di orchestrazione capaci di monitorare prezzi e disponibilità su più provider. Ma per le organizzazioni con le competenze e l'infrastruttura giusta, i risultati possono essere davvero eccezionali.
Checklist Operativa: Iniziare con le Istanze Spot
Per chiudere, ecco una checklist pratica per iniziare. Tenetela a portata di mano:
- Inventario dei workload: identificate tutti i workload tolleranti alle interruzioni (batch, CI/CD, dev/staging, training ML, microservizi stateless)
- Proof of Concept: iniziate con un workload non critico — un ambiente di dev o una pipeline CI/CD sono l'ideale
- Diversificazione: configurate almeno 10 tipi di istanza e 3 zone di disponibilità
- Automazione: implementate la gestione automatica delle interruzioni (Karpenter, ASG, VMSS o MIG)
- Fallback: configurate il fallback automatico su on-demand
- Checkpointing: implementate il salvataggio dello stato per i workload di lunga durata
- Monitoraggio: configurate dashboard e alert per tassi di interruzione, costi e disponibilità
- Testing: simulate interruzioni regolarmente con FIS o strumenti equivalenti
- Espansione: una volta che il processo è solido, espandete a più workload
- Integrazione FinOps: integrate la strategia Spot nel modello di layering complessivo (commitment + Spot + on-demand)
Conclusioni
Le istanze Spot nel 2026 non sono più un esperimento per i coraggiosi — sono una componente essenziale di qualsiasi strategia FinOps seria. Con risparmi fino al 91%, tassi di interruzione storicamente bassi e strumenti come Karpenter che rendono la gestione delle interruzioni quasi trasparente, le ragioni per non adottarle si stanno esaurendo.
La chiave sta nella diversificazione, nell'automazione e nell'integrazione con una strategia di pricing più ampia. Non si tratta di scegliere tra Spot e commitment discount — si tratta di usarli insieme, in una strategia a strati che massimizzi il risparmio senza sacrificare l'affidabilità.
Iniziate dai workload più semplici, costruite competenza e espandete progressivamente. I risparmi vi convinceranno a continuare — è una di quelle cose che, una volta provate, non si torna più indietro.