Instances Spot AWS, Azure et GCP en 2026 : Économisez Jusqu'à 90 % sur le Compute Cloud

Pourquoi les Instances Spot Sont Devenues Incontournables en 2026

Bon, parlons chiffres. En 2026, les dépenses mondiales en cloud public dépassent les 830 milliards de dollars. Et les entreprises gaspillent en moyenne 32 % de leur budget cloud — c'est le rapport State of FinOps 2026 de la FinOps Foundation qui le dit. Face à ça, les instances spot restent l'un des leviers d'optimisation les plus puissants à disposition des équipes FinOps : on parle de réductions allant jusqu'à 90 % par rapport aux tarifs à la demande.

Le principe est simple. Les fournisseurs cloud disposent en permanence de capacité de calcul inutilisée. Plutôt que de laisser cette capacité dormir, ils la proposent à prix cassé sous forme d'instances spot. Le compromis ? Ces instances peuvent être reprises à tout moment, avec un préavis très court. C'est cette caractéristique interruptible qui justifie les remises massives.

Dans ce guide, on va passer en revue le fonctionnement des instances spot sur AWS, Azure et GCP, les stratégies d'architecture pour gérer les interruptions, et les bonnes pratiques pour intégrer tout ça dans une stratégie FinOps multi-cloud. Le tout avec des exemples Terraform et CLI prêts à copier-coller.

Fonctionnement des Instances Spot : Principes Communs aux Trois Fournisseurs

Avant de plonger dans les spécificités de chaque fournisseur, prenons un moment pour comprendre les mécanismes qui sont communs à toutes les instances spot.

Le Modèle de Capacité Excédentaire

Les trois grands — AWS, Azure et Google Cloud — gèrent des centres de données massifs dont la capacité est dimensionnée pour absorber les pics de demande. Entre ces pics, une bonne partie de la capacité reste inutilisée. Les instances spot exploitent justement cette capacité excédentaire en la proposant à des tarifs fortement réduits.

La contrepartie, c'est le risque d'interruption. Lorsque le fournisseur a besoin de récupérer cette capacité pour des clients à la demande ou des engagements réservés, les instances spot sont les premières à sauter. Ce modèle crée un compromis coût-fiabilité fondamental que toute architecture utilisant des instances spot doit prendre en compte.

Workloads Adaptés aux Instances Spot

Les instances spot conviennent particulièrement bien à certains types de charges de travail :

• Traitement par lots (batch processing) : pipelines de données, ETL, transformations massives
• CI/CD : builds, tests automatisés, déploiements de staging
• Entraînement ML : modèles avec checkpointing, jobs d'entraînement reproductibles
• Calcul haute performance (HPC) : simulations, rendu 3D, analyses génomiques
• Serveurs web stateless : derrière un load balancer avec auto-scaling
• Environnements de développement et de test

En revanche, évitez les instances spot pour les bases de données, les applications monolithiques stateful, et tout workload critique qui ne tolère aucune interruption. Honnêtement, j'ai vu des équipes essayer de faire tourner des bases Postgres sur du spot — ça se termine toujours mal.

AWS Spot Instances : Le Pionnier du Marché

AWS a introduit les Spot Instances dès 2009, ce qui en fait le mécanisme d'instances spot le plus mature du marché. En 2026, l'écosystème AWS offre un outillage vraiment complet pour exploiter cette capacité de manière fiable.

Tarification et Réductions

Les Spot Instances AWS offrent des réductions pouvant atteindre 90 % par rapport aux tarifs à la demande. Le prix spot est déterminé par AWS en fonction de l'offre et de la demande à long terme, et ajusté progressivement — fini le modèle d'enchères qui existait avant 2018.

Quelques repères de prix pour les familles Graviton populaires en 2026 :

• m7g.large (General Purpose, Graviton3) : environ 0,08 $/h à la demande, souvent disponible en spot à 0,02-0,03 $/h
• c7g.large (Compute Optimized, Graviton3) : environ 0,07 $/h à la demande, spot typiquement autour de 0,02 $/h
• c8g.large (Compute Optimized, Graviton4) : jusqu'à 30 % de performances en plus par rapport à c7g à un prix similaire

Les instances Graviton (ARM) coûtent déjà 10 à 20 % moins cher que les équivalents x86. Combinez ça avec le pricing spot, et les économies deviennent franchement impressionnantes.

Mécanisme d'Interruption AWS

Quand AWS a besoin de récupérer la capacité, les instances spot reçoivent un préavis de 2 minutes. Pendant ces 2 minutes, l'instance reçoit un signal SIGTERM et l'événement est visible via les métadonnées de l'instance et Amazon EventBridge.

En plus de l'avertissement d'interruption, AWS émet un signal de recommandation de rééquilibrage (rebalance recommendation) lorsqu'une instance spot présente un risque élevé d'interruption. Ce signal arrive généralement avant l'avis d'interruption lui-même — ce qui donne un peu plus de marge pour migrer les workloads.

Point important sur la facturation : si AWS interrompt votre instance spot, vous n'êtes pas facturé pour l'heure partielle d'utilisation. Si c'est vous qui terminez l'instance, l'heure complète est facturée. Un détail qui peut faire la différence sur la facture.

Configuration AWS avec Terraform

Voici un exemple complet de configuration d'un Auto Scaling Group utilisant des instances spot avec la stratégie d'allocation optimisée par capacité :

# Auto Scaling Group avec instances Spot multi-types
resource "aws_launch_template" "spot_workload" {
  name_prefix   = "spot-workload-"
  image_id      = data.aws_ami.al2023_arm.id
  instance_type = "m7g.large"

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "spot-workload"
      Environment = "production"
      CostCenter  = "data-engineering"
    }
  }

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    instance_metadata_tags      = "enabled"
  }
}

resource "aws_autoscaling_group" "spot_fleet" {
  name                = "spot-fleet-asg"
  desired_capacity    = 10
  min_size            = 5
  max_size            = 20
  vpc_zone_identifier = var.subnet_ids

  mixed_instances_policy {
    instances_distribution {
      # Utiliser 80% d'instances spot, 20% à la demande
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 20
      spot_allocation_strategy                 = "capacity-optimized"
    }

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

      # Diversifier les types d'instances pour réduire les interruptions
      override {
        instance_type = "m7g.large"
      }
      override {
        instance_type = "m7g.xlarge"
        weighted_capacity = "2"
      }
      override {
        instance_type = "c7g.large"
      }
      override {
        instance_type = "c7g.xlarge"
        weighted_capacity = "2"
      }
      override {
        instance_type = "m6g.large"
      }
      override {
        instance_type = "r7g.large"
      }
    }
  }

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

Les points clés de cette configuration :

• capacity-optimized : cette stratégie d'allocation sélectionne les pools spot ayant la plus grande disponibilité, ce qui réduit significativement le taux d'interruption
• Diversification des types d'instances : en incluant 6 types différents (m7g, c7g, m6g, r7g), on réduit la probabilité qu'un seul pool de capacité s'épuise
• Base à la demande : 2 instances à la demande garantissent une capacité minimale quoi qu'il arrive
• weighted_capacity : permet de gérer des instances de tailles différentes au sein du même groupe

Gestion des Interruptions avec EventBridge et Lambda

Pour automatiser la réponse aux interruptions, configurez une règle EventBridge qui déclenche une fonction Lambda :

# Règle EventBridge pour capturer les interruptions spot
resource "aws_cloudwatch_event_rule" "spot_interruption" {
  name        = "spot-interruption-handler"
  description = "Capture les avertissements d interruption spot EC2"

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

resource "aws_cloudwatch_event_target" "lambda_handler" {
  rule      = aws_cloudwatch_event_rule.spot_interruption.name
  target_id = "SpotInterruptionHandler"
  arn       = aws_lambda_function.spot_handler.arn
}

# Règle pour les recommandations de rééquilibrage
resource "aws_cloudwatch_event_rule" "spot_rebalance" {
  name        = "spot-rebalance-handler"
  description = "Capture les recommandations de reequilibrage spot"

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

resource "aws_cloudwatch_event_target" "rebalance_handler" {
  rule      = aws_cloudwatch_event_rule.spot_rebalance.name
  target_id = "SpotRebalanceHandler"
  arn       = aws_lambda_function.spot_handler.arn
}

Azure Spot Virtual Machines : Flexibilité et Politiques d'Éviction

Azure propose ses instances spot sous le nom d'Azure Spot Virtual Machines, avec des mécanismes de contrôle spécifiques qui les distinguent pas mal de l'offre AWS.

Tarification et Remises Azure

Les Azure Spot VMs offrent des réductions allant jusqu'à 90 % par rapport aux tarifs pay-as-you-go. En pratique, la plupart se situent entre 75 % et 90 % de réduction — mais attention, certaines configurations peuvent n'offrir que 30 à 40 % d'économies selon la région et le type de VM.

Une particularité intéressante d'Azure : la tarification spot est variable et basée sur la région et le SKU. Vous pouvez définir un prix maximum en dollars (USD) avec jusqu'à cinq décimales, ce qui donne un contrôle assez granulaire sur vos coûts.

Politiques d'Éviction : Deallocate vs Delete

Azure offre deux politiques d'éviction (et c'est unique, les autres fournisseurs ne proposent pas ça) :

• Deallocate (par défaut) : la VM est arrêtée et désallouée, mais conservée. Vous pouvez tenter de la redéployer plus tard. Attention cependant : les VMs désallouées comptent toujours dans votre quota et les disques sous-jacents continuent d'être facturés.
• Delete : la VM et ses disques sont supprimés à l'éviction. Zéro frais de stockage résiduel, mais les données sont perdues.

Types de Déclencheurs d'Éviction

Azure propose deux types de déclencheurs d'éviction :

• Capacity-only : l'éviction ne se déclenche que lorsque Azure a besoin de récupérer la capacité. Le prix est plafonné au tarif pay-as-you-go. C'est l'option la plus simple.
• Price or capacity : l'éviction se déclenche si la capacité est insuffisante OU si le prix spot dépasse votre prix maximum. Cette option permet de définir un plafond de prix strict.

Le préavis d'éviction Azure est de 30 secondes seulement. Oui, vous avez bien lu — 30 secondes. C'est significativement plus court que les 2 minutes d'AWS, et ça impose des architectures encore plus résilientes.

Déploiement Azure Spot VM avec Terraform

# Azure Spot VM avec politique d'éviction Deallocate
resource "azurerm_linux_virtual_machine" "spot_worker" {
  name                = "spot-worker-01"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_D4as_v5"
  admin_username      = "azureadmin"

  # Configuration Spot
  priority        = "Spot"
  eviction_policy = "Deallocate"
  max_bid_price   = -1  # Payer jusqu'au tarif pay-as-you-go

  admin_ssh_key {
    username   = "azureadmin"
    public_key = file("~/.ssh/id_rsa.pub")
  }

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

  source_image_reference {
    publisher = "Canonical"
    offer     = "ubuntu-24_04-lts"
    sku       = "server"
    version   = "latest"
  }

  tags = {
    Environment = "production"
    CostCenter  = "data-processing"
    SpotVM      = "true"
  }
}

# Scale Set avec Spot VMs pour les workloads distribués
resource "azurerm_linux_virtual_machine_scale_set" "spot_fleet" {
  name                = "spot-fleet-vmss"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  sku                 = "Standard_D4as_v5"
  instances           = 10

  priority        = "Spot"
  eviction_policy = "Delete"
  max_bid_price   = 0.08  # Plafond de prix strict

  admin_username = "azureadmin"

  admin_ssh_key {
    username   = "azureadmin"
    public_key = file("~/.ssh/id_rsa.pub")
  }

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

  source_image_reference {
    publisher = "Canonical"
    offer     = "ubuntu-24_04-lts"
    sku       = "server"
    version   = "latest"
  }

  automatic_instance_repair {
    enabled      = true
    grace_period = "PT10M"
  }

  tags = {
    Environment = "production"
    SpotFleet   = "true"
  }
}

Notez l'utilisation de max_bid_price = -1 sur la VM individuelle : ça veut dire que vous acceptez de payer jusqu'au tarif pay-as-you-go, éliminant les évictions liées au prix. Sur le Scale Set en revanche, un plafond strict de 0,08 $/h est défini pour un contrôle budgétaire plus serré.

GCP Spot VMs : La Transition Depuis les VM Préemptibles

Google Cloud a fait évoluer son modèle en remplaçant progressivement les VM préemptibles par les Spot VMs. Ces dernières offrent des fonctionnalités supplémentaires tout en conservant le même modèle tarifaire agressif.

Spot VMs vs VM Préemptibles

Google recommande désormais les Spot VMs plutôt que les VM préemptibles. Et pour cause — les principales différences parlent d'elles-mêmes :

• Durée de vie : les VM préemptibles ont une durée maximale de 24 heures, après quoi elles sont automatiquement arrêtées. Les Spot VMs n'ont pas de durée de vie maximale — c'est un vrai game changer.
• Tarification : identique pour les deux — jusqu'à 91 % de réduction par rapport aux instances standard.
• Fonctionnalités : les Spot VMs supportent des fonctionnalités additionnelles comme des options de provisioning dynamique.

Tarification GCP Spot

Les Spot VMs GCP offrent des réductions de 60 à 91 % selon le type de machine et la région. Un point distinctif de GCP : le prix spot ne change pas plus d'une fois par mois. Ça offre une prévisibilité nettement supérieure à celle d'AWS et Azure, et c'est un argument qui pèse pour les équipes FinOps qui doivent forecaster leurs budgets.

Point crucial à ne pas oublier : les Spot VMs et les Committed Use Discounts (CUDs) sont mutuellement exclusifs sur GCP. On ne peut pas combiner les deux types de remise sur les mêmes ressources. Les Sustained Use Discounts (SUDs), qui offrent jusqu'à 30 % de remise automatique, ne s'appliquent pas non plus aux Spot VMs.

Déploiement GCP Spot VM avec Terraform

# Instance GCP Spot VM
resource "google_compute_instance" "spot_worker" {
  name         = "spot-worker-01"
  machine_type = "n2d-standard-4"
  zone         = "europe-west1-b"

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

  boot_disk {
    initialize_params {
      image = "ubuntu-os-cloud/ubuntu-2404-lts-amd64"
      size  = 50
      type  = "pd-balanced"
    }
  }

  network_interface {
    network    = "default"
    subnetwork = "default"
  }

  labels = {
    environment = "production"
    cost-center = "data-processing"
    spot-vm     = "true"
  }
}

# Managed Instance Group avec Spot VMs
resource "google_compute_instance_template" "spot_template" {
  name_prefix  = "spot-fleet-"
  machine_type = "n2d-standard-4"
  region       = "europe-west1"

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

  disk {
    source_image = "ubuntu-os-cloud/ubuntu-2404-lts-amd64"
    auto_delete  = true
    boot         = true
    disk_size_gb = 50
    disk_type    = "pd-balanced"
  }

  network_interface {
    network    = "default"
    subnetwork = "default"
  }

  labels = {
    spot-fleet = "true"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_region_instance_group_manager" "spot_fleet" {
  name               = "spot-fleet-mig"
  base_instance_name = "spot-worker"
  region             = "europe-west1"
  target_size        = 10

  version {
    instance_template = google_compute_instance_template.spot_template.self_link_unique
  }

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

Notez l'utilisation de provisioning_model = "SPOT" avec instance_termination_action = "STOP". L'action STOP conserve la VM et ses disques, tandis que DELETE supprime tout. Sur GCP, le préavis d'interruption est de 30 secondes, identique à Azure.

Comparatif Multi-Cloud des Instances Spot

Voici un tableau récapitulatif qui met en regard les différences clés entre les trois fournisseurs. C'est le genre de tableau qu'on garde sous la main quand on fait du multi-cloud :

Critère	AWS Spot Instances	Azure Spot VMs	GCP Spot VMs
Réduction maximale	Jusqu'à 90 %	Jusqu'à 90 %	Jusqu'à 91 %
Préavis d'interruption	2 minutes	30 secondes	30 secondes
Signal anticipé	Rebalance Recommendation	Scheduled Events	Metadata polling
Contrôle du prix max	Non (prix marché)	Oui (5 décimales)	Non (prix fixe mensuel)
Politique d'éviction	Terminate / Stop / Hibernate	Deallocate / Delete	Stop / Delete
Variabilité du prix	Ajustement progressif continu	Variable par région/SKU	Max 1 changement / mois
Compatibilité engagements	Non cumulable avec RI/SP	Non cumulable avec RI/SP	Non cumulable avec CUD/SUD
Durée de vie maximale	Illimitée	Illimitée	Illimitée (Spot) / 24h (Préemptible)

Architectures Résilientes pour les Instances Spot

Utiliser des instances spot en production, c'est tout à fait possible — mais ça nécessite une architecture pensée pour la résilience. Voici les patterns qui font vraiment la différence.

Pattern 1 : Statelessness Radical

Le premier principe est de ne jamais stocker d'état localement sur une instance spot. Toute donnée persistante doit être externalisée :

• Logs envoyés immédiatement vers un service centralisé (CloudWatch, Azure Monitor, Cloud Logging)
• Sessions utilisateur dans un cache distribué (Redis, Memcached)
• Fichiers temporaires dans un stockage objet (S3, Blob Storage, GCS)
• État applicatif dans une base de données externe

Ça paraît évident dit comme ça, mais vous seriez surpris du nombre d'équipes qui stockent encore des fichiers de session en local sur leurs instances.

Pattern 2 : Checkpointing pour les Jobs Longs

Pour les workloads de longue durée — entraînement ML, simulations HPC, traitement de données massif — le checkpointing est absolument essentiel. L'idée : sauvegarder régulièrement l'état d'avancement dans un stockage durable, de sorte qu'en cas d'interruption, le job puisse reprendre au dernier checkpoint plutôt que de repartir de zéro.

#!/bin/bash
# Script de checkpointing pour un job batch sur instance spot
CHECKPOINT_BUCKET="s3://my-checkpoints/job-${JOB_ID}"
CHECKPOINT_INTERVAL=300  # Sauvegarder toutes les 5 minutes

# Fonction de sauvegarde du checkpoint
save_checkpoint() {
  echo "Sauvegarde du checkpoint en cours..."
  aws s3 cp /tmp/job-state.json "${CHECKPOINT_BUCKET}/latest.json"
  aws s3 cp /tmp/job-progress.dat "${CHECKPOINT_BUCKET}/progress.dat"
  echo "Checkpoint sauvegardé à $(date -u +%Y-%m-%dT%H:%M:%SZ)"
}

# Gestionnaire de signal SIGTERM (interruption spot)
handle_termination() {
  echo "Signal d'interruption spot reçu !"
  save_checkpoint
  # Notifier le système d'orchestration
  curl -X POST "${ORCHESTRATOR_URL}/api/jobs/${JOB_ID}/interrupted"
  exit 0
}

trap handle_termination SIGTERM

# Restaurer depuis le dernier checkpoint si disponible
if aws s3 ls "${CHECKPOINT_BUCKET}/latest.json" 2>/dev/null; then
  echo "Restauration depuis le checkpoint précédent..."
  aws s3 cp "${CHECKPOINT_BUCKET}/latest.json" /tmp/job-state.json
  aws s3 cp "${CHECKPOINT_BUCKET}/progress.dat" /tmp/job-progress.dat
fi

# Boucle principale du job avec checkpoints périodiques
LAST_CHECKPOINT=$(date +%s)
while true; do
  # Exécuter le travail...
  process_next_batch

  # Checkpoint périodique
  NOW=$(date +%s)
  if (( NOW - LAST_CHECKPOINT >= CHECKPOINT_INTERVAL )); then
    save_checkpoint
    LAST_CHECKPOINT=$NOW
  fi
done

Pattern 3 : Diversification Multi-Pool

Les interruptions spot se produisent souvent par lot. Si une instance m5.large dans une zone de disponibilité donnée est interrompue, il est probable que d'autres instances du même type dans la même zone le soient aussi. Pour atténuer ce risque :

• Utilisez au minimum 6 types d'instances différents
• Répartissez-vous sur au moins 3 zones de disponibilité
• Mélangez les familles (general purpose, compute optimized, memory optimized)
• Maintenez une base minimale d'instances à la demande — entre 20 et 30 % de la flotte, c'est un bon ratio

Pattern 4 : Gestion des Interruptions Kubernetes

Pour les clusters Kubernetes utilisant des nœuds spot, le AWS Node Termination Handler (NTH) et des solutions équivalentes sur Azure et GCP sont indispensables. Sur AWS avec EKS :

# Installation du Node Termination Handler via Helm
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

Ce handler surveille les signaux d'interruption et marque automatiquement les nœuds comme non-programmables (NoSchedule), permettant à Kubernetes de migrer les pods vers d'autres nœuds avant l'interruption effective. En production, c'est vraiment un must-have.

Stratégie de Tarification en Couches : Combiner Spot, RI et Savings Plans

Les instances spot ne doivent pas être utilisées en isolation. La stratégie FinOps optimale en 2026 consiste à superposer plusieurs modèles de tarification — et c'est là que les économies deviennent vraiment significatives.

La Pyramide de Tarification Recommandée

1. Base stable (40-50 % de la flotte) : Savings Plans (AWS) / Reserved Instances (Azure) / CUDs (GCP) pour les workloads prévisibles et constants. Économies de 37 à 72 % selon l'engagement.
2. Couche variable (30-40 %) : Instances spot pour les workloads tolérants aux interruptions. Économies de 60 à 91 %.
3. Coussin de sécurité (10-20 %) : Instances à la demande pour absorber les pics et garantir la disponibilité en cas d'interruption massive des instances spot.

Calcul d'Économies Réel

Prenons un exemple concret avec une flotte de 100 instances m7g.large sur AWS en us-east-1 :

• Tarif à la demande : 0,0816 $/h × 100 × 730 h/mois = 5 957 $/mois
• Avec la stratégie en couches (45 % SP à -60 %, 35 % Spot à -75 %, 20 % On-Demand) :
  • 45 instances SP : 0,0326 $/h × 45 × 730 = 1 071 $
  • 35 instances Spot : 0,0204 $/h × 35 × 730 = 521 $
  • 20 instances OD : 0,0816 $/h × 20 × 730 = 1 191 $
  • Total : 2 783 $/mois — soit 53 % d'économies

Et ce n'est qu'un point de départ. En ciblant des types d'instances moins populaires avec des taux d'interruption plus faibles, les économies peuvent facilement dépasser 60 %.

Outils de Monitoring et d'Optimisation Spot

Plusieurs outils facilitent la gestion des instances spot en 2026. En voici les plus pertinents :

• AWS Spot Instance Advisor : affiche les taux d'interruption historiques et les économies par type d'instance. C'est vraiment le premier endroit où aller pour choisir les bons pools.
• Azure Spot Advisor : données de prix historiques sur 90 jours et taux d'éviction sur 28 jours par SKU et région.
• Spot by NetApp (multi-cloud) : utilise le machine learning pour automatiser la gestion des instances spot en temps réel, avec basculement automatique entre les pools.
• Karpenter (Kubernetes/AWS) : provisionneur de nœuds qui gère automatiquement les instances spot et le basculement vers les instances à la demande.
• CAST AI (multi-cloud) : optimisation autonome qui sélectionne dynamiquement les meilleures combinaisons d'instances spot sur AWS, Azure et GCP.

Erreurs Courantes à Éviter

Après avoir accompagné plusieurs équipes dans leur migration vers les instances spot, voici les pièges les plus fréquents (et croyez-moi, on les voit encore régulièrement) :

• Ne pas diversifier les types d'instances : se limiter à un seul type dans une seule zone de disponibilité, c'est maximiser le risque d'interruption groupée. Diversifiez toujours.
• Ignorer le checkpointing : lancer des jobs de plusieurs heures sans sauvegardes intermédiaires signifie potentiellement perdre tout le travail à chaque interruption. C'est du gaspillage pur.
• Utiliser des instances spot pour des bases de données : même avec des réplicas, le risque d'interruption est incompatible avec les garanties de durabilité nécessaires. Ne le faites pas.
• Négliger le préavis de 30 secondes : sur Azure et GCP, 30 secondes c'est très court. Votre application doit pouvoir s'arrêter proprement en moins de 25 secondes.
• Oublier les coûts cachés : disques conservés après éviction (avec Azure Deallocate), trafic réseau de migration, surcoût de l'orchestration de failover — tout ça s'additionne.
• Sur-optimiser : mettre 100 % de la flotte en spot pour maximiser les économies expose à des indisponibilités catastrophiques lors des pics de demande cloud. Gardez toujours un coussin on-demand.

FAQ : Questions Fréquentes sur les Instances Spot

Les instances spot sont-elles adaptées à la production ?

Oui, absolument — à condition que l'architecture soit conçue pour la résilience. Les workloads stateless derrière des load balancers, les jobs batch avec checkpointing et les pipelines CI/CD fonctionnent très bien sur des instances spot en production. La clé, c'est de ne jamais dépendre d'une seule instance et de maintenir un coussin de capacité à la demande. Pour vous donner une idée, plus de 90 % des Spot VMs Azure sont arrêtées normalement par l'utilisateur plutôt qu'évincées.

Combien peut-on réellement économiser avec les instances spot ?

Les économies vont de 60 à 91 % selon le fournisseur, le type d'instance et la région. En pratique, avec une stratégie en couches combinant instances spot (35 %), engagements réservés (45 %) et à la demande (20 %), les entreprises réalisent entre 50 et 60 % d'économies sur leur facture compute totale. Le rapport State of FinOps 2026 confirme que les engagements tarifaires (incluant les instances spot) restent le levier d'optimisation numéro un.

Quelle est la différence entre Spot VMs et VM préemptibles sur GCP ?

Les Spot VMs sont la version moderne des VM préemptibles sur Google Cloud. La différence principale : les VM préemptibles ont une durée de vie maximale de 24 heures (après quoi elles sont automatiquement arrêtées), tandis que les Spot VMs n'ont aucune limite de durée. La tarification est identique — jusqu'à 91 % de réduction — mais les Spot VMs offrent des fonctionnalités supplémentaires. Google recommande de migrer vers les Spot VMs.

Comment gérer les interruptions sur Kubernetes ?

Sur AWS EKS, déployez le Node Termination Handler qui surveille les signaux d'interruption et draine automatiquement les nœuds. Sur Azure AKS, utilisez le Virtual Machine Scale Set avec des Spot VMs et des priorités de pods (PodDisruptionBudgets). Sur GKE, activez le mode Spot pour les node pools. Dans tous les cas, configurez des PodDisruptionBudgets pour garantir qu'un nombre minimum de réplicas reste disponible pendant les interruptions.

Peut-on combiner instances spot et Savings Plans ou instances réservées ?

Les remises ne sont pas cumulables sur la même instance : une instance spot ne peut pas bénéficier en plus d'une réduction Savings Plan ou Reserved Instance. En revanche, la stratégie recommandée est de superposer ces modèles au niveau de la flotte : des engagements réservés pour la base stable, des instances spot pour la capacité variable, et des instances à la demande comme filet de sécurité. C'est cette approche en couches qui maximise les économies globales.