Aller au contenu

AWS Mis à jour le 2026-07-04

Interruptions Spot EC2 : l'avertissement de deux minutes et comment y survivre

Les instances Spot EC2 reçoivent un avertissement de deux minutes avant qu'AWS les reprenne. Voici comment capter l'avis, drainer le travail à temps, et concevoir pour qu'une interruption soit un haussement d'épaules plutôt qu'une panne.

Quand AWS a besoin de récupérer sa capacité, une instance Spot reçoit un avertissement de deux minutes, livré de deux façons : un document instance-action dans le service de métadonnées de l’instance et un événement EC2 Spot Instance Interruption Warning sur EventBridge. Survivre aux interruptions, ce n’est pas les éviter — vous ne pouvez pas — c’est capter cet avis en quelques secondes, drainer le travail dans la fenêtre, et rouler assez de diversité de types d’instance pour que les remplacements se lancent plus vite que les reprises n’arrivent. Les équipes qui font ces trois choses roulent de grosses flottes Spot pendant des années; celles qui les sautent concluent que le Spot n’est pas fiable, au plein prix à la demande.

Ce qui se passe

La capacité Spot, c’est le matériel de réserve de chaque bassin d’instances, vendu à fort rabais (historiquement jusqu’à environ 90 % sous le prix à la demande, selon le bassin et le moment) à condition qu’EC2 puisse le reprendre quand les clients à la demande ou avec réservation en ont besoin. Une interruption a la portée d’un bassin de capacité — un type d’instance dans une zone — et c’est pourquoi la diversification fonctionne : les reprises frappent des bassins, pas toute votre flotte, sauf si toute votre flotte est un seul bassin.

Deux signaux précèdent une reprise. La recommandation de rééquilibrage arrive en premier (parfois de justesse) et signifie que le bassin est à risque élevé — c’est le signal du remplacement proactif, et c’est ce sur quoi agit la fonction Capacity Rebalancing de l’Auto Scaling. L’avis d’interruption est l’échéance ferme : deux minutes avant que l’instance soit terminée, arrêtée ou hibernée, selon le comportement spécifié dans la demande. Deux minutes, c’est ce qu’AWS émet; considérez-le comme le maximum de temps que vous aurez et gardez la charge tolérante aux pannes de toute façon — une flotte Spot n’est pas l’endroit pour la seule copie de quoi que ce soit, une leçon qui s’applique aussi aux volumes d’instance store.

Quoi vérifier en premier

  • Captez-vous vraiment l’avertissement? Si rien ne sonde l’IMDS et qu’aucune règle EventBridge n’existe, les deux minutes passent à ne rien faire.
  • À quel point vos bassins sont-ils concentrés? Un type d’instance dans une zone est la forme la plus fragile possible. Comptez vos combinaisons type-fois-zone.
  • Quel est le comportement d’interruption sur les demandes? Terminer est le défaut; arrêter et hiberner existent pour les charges qui reprennent.
  • À quoi ressemblent les taux d’interruption historiques? Le Spot Instance Advisor publie des fourchettes de fréquence par type et région — certains bassins restent sous 5 %, d’autres brassent constamment.
  • Y a-t-il de l’état sur la flotte? Sessions, files locales, fichiers à moitié écrits — inventoriez ce qui meurt avec une instance.

Comment vérifier

Sondez les deux signaux depuis l’instance (IMDSv2) :

TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Avis ferme de deux minutes : 404 = tranquille, JSON avec "action" et "time" = temps de drainage
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/spot/instance-action

# Recommandation de rééquilibrage, l'alerte précoce
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/events/recommendations/rebalance

Sondez toutes les cinq secondes — un intervalle de soixante secondes passe la moitié de l’avertissement endormi. Côté compte, une règle EventBridge attrape les interruptions à l’échelle de la flotte :

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

Pointez-la vers SNS ou une Lambda qui journalise quels bassins se font reprendre — cet historique vous dit quels types déprioriser. La mécanique Spot et les comportements d’interruption sont documentés à https://docs.aws.amazon.com/ec2/.

La procédure

  1. Déployez un gestionnaire d’interruption avant de déployer du Spot. Sur Kubernetes, c’est le AWS Node Termination Handler (ou la gestion native de Karpenter), qui isole et draine le nœud sur l’un ou l’autre signal. Sur des groupes Auto Scaling ordinaires, un petit sondeur sous systemd qui retire l’instance de la rotation et vide le travail suffit. Rien d’autre sur cette liste ne compte si personne n’entend l’avertissement.
  2. Faites que deux minutes suffisent. Désinscrivez du répartiteur de charge d’abord (le drainage de connexions mange le gros de la fenêtre — réglez le délai de désinscription en conséquence), cessez d’accepter du nouveau travail, sauvegardez ou remettez en file les tâches en cours, videz journaux et métriques. Les tâches plus longues que la fenêtre exigent des points de contrôle externes (S3, une file avec délais de visibilité) pour qu’un successeur reprenne au lieu de recommencer.
  3. Diversifiez les bassins agressivement. Six types d’instance ou plus sur trois zones est un plancher raisonnable pour une flotte sérieuse. Utilisez les instances mixtes de l’Auto Scaling ou la sélection par attributs avec la stratégie d’allocation price-capacity-optimized, qui vise les bassins les moins susceptibles d’être repris — le montage est couvert dans politiques d’instances mixtes.
  4. Activez le Capacity Rebalancing pour le Spot en Auto Scaling. Il réagit à la recommandation de rééquilibrage en lançant un remplacement avant que l’interruption tombe, pour que la taille de la flotte creuse moins. Acceptez le petit coût de chevauchement pendant que vieilles et nouvelles instances coexistent.
  5. Gardez une base à la demande comme plancher. Le patron qui fonctionne en production : assez de capacité à la demande (ou réservée) pour servir un trafic dégradé mais vivant, du Spot pour tout ce qui dépasse. La hauteur du plancher est une décision coût-risque, pesée avec RI et Savings Plans.
  6. Choisissez le comportement arrêt ou hibernation seulement quand la reprise est réelle. Les instances Spot arrêtées reprennent quand la capacité revient — utile pour les longues tâches par lots — mais vous continuez de payer l’EBS pendant qu’elles attendent, et rien ne promet quand le bassin se rétablit.

Quand c’est la mauvaise approche

Le Spot est le mauvais socle pour les singletons avec état, les membres de quorum (bases de données, ZooKeeper, etcd), et tout ce qui a un objectif de latence ferme qui ne tolère pas un creux de capacité. C’est aussi la mauvaise économie pour une charge de base stable 24/7 — les rabais d’engagement la couvrent plus prévisiblement. Et si une équipe n’a pas la bande passante pour bâtir la gestion d’interruption, les économies Spot s’évaporent au premier incident; roulez à la demande jusqu’à ce que l’ingénierie existe.

Erreurs courantes

  • Rouler du Spot sans gestionnaire et découvrir que l’avertissement de deux minutes existait seulement en lisant le post-mortem.
  • Un type d’instance, une zone — une seule reprise de bassin emporte toute la flotte d’un coup.
  • Sonder l’IMDS une fois par minute, aveugle pendant le gros de la fenêtre d’avertissement.
  • Traiter la recommandation de rééquilibrage comme une interruption et secouer la flotte — c’est un signal de risque, pas une échéance; agissez en pré-lançant, pas en paniquant.

Garder le contrôle

  • Suivez les interruptions par bassin via EventBridge et élaguez du mélange les types chroniquement repris.
  • Testez le chemin de drainage sous charge : tuez une instance avec le gestionnaire actif et mesurez si les requêtes se terminent vraiment.
  • Révisez le ratio Spot/à la demande de la flotte chaque trimestre contre l’historique réel d’interruptions, pas contre la peur.
  • Gardez les AMI et l’amorçage rapides; une flotte qui démarre en 90 secondes guérit plus vite que n’importe quelle fenêtre d’avertissement.
  • Mettez une alarme sur la capacité de flotte qui descend sous le plancher à la demande — c’est le signal que la diversification est à sec.

Bien gérées, les interruptions deviennent un rythme de fond — les instances partent poliment, les remplacements arrivent, et le tableau de bord des finances est le seul endroit où quelqu’un remarque le Spot. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.