Vérification de statut EC2 échouée (1/2 ou 2/2) : ce que chaque vérification signifie et comment récupérer

EC2 exécute deux vérifications de santé indépendantes sur chaque instance en marche, et « 1/2 checks passed » vous dit de quel côté de la ligne se trouve la panne. La vérification de statut système teste la couche AWS — l’hôte physique, son réseau, son alimentation. La vérification de statut d’instance teste votre couche — si le système d’exploitation démarre, répond sur le réseau, et n’est pas coincé dans une panique du noyau. La récupération diffère complètement : un échec de la vérification système se règle en déplaçant l’instance vers du nouveau matériel (arrêt/démarrage ou récupération automatique), tandis qu’un échec de la vérification d’instance signifie que quelque chose est cassé dans votre système d’exploitation, et aucune migration de matériel ne le réparera.

Ce qui se passe

Chaque minute, EC2 vérifie chaque instance de l’extérieur. La vérification de statut système confirme l’hôte sous-jacent : perte de connectivité réseau au niveau de l’hôte, perte d’alimentation, problèmes logiciels ou matériels sur le serveur physique. Vous ne pouvez pas réparer ça — seul AWS le peut, et votre levier est de déplacer votre instance sur un autre hôte. La vérification de statut d’instance confirme l’invité : elle échoue sur un système de fichiers corrompu, une mémoire épuisée, une panique du noyau, une configuration réseau brisée dans le système d’exploitation, ou un démarrage qui ne s’est jamais complété. Ceux-là, c’est à vous de les réparer.

Il existe une troisième surface, plus récente : les vérifications de statut EBS attaché, qui indiquent si les volumes attachés à l’instance sont joignables et complètent leurs E/S. Un volume EBS bloqué peut faire paraître une instance morte alors que les deux vérifications classiques disent encore la vérité sur l’emplacement de la faute.

Le fait opérationnel critique : un redémarrage garde l’instance sur le même hôte physique, tandis qu’un arrêt/démarrage la migre vers un nouveau. C’est pourquoi le redémarrage ne règle à peu près rien quand la vérification système échoue, et pourquoi l’arrêt/démarrage est la récupération standard. Notez qu’un arrêt/démarrage change une IP publique non élastique et efface les volumes d’instance store — voyez instance store vs EBS avant de tirer ce levier sur une instance avec des disques locaux.

Quoi vérifier en premier

Quelle vérification a échoué? EC2 > Instances > sélectionner l’instance > onglet Vérifications de statut. Échec système et échec d’instance mènent à des procédures différentes — ne devinez pas.
Y a-t-il un incident AWS en cours? Consultez https://health.aws.amazon.com/ et votre Personal Health Dashboard. Un événement au niveau de l’hôte vient parfois avec un avis de retrait planifié.
Est-ce une instance ou plusieurs? Plusieurs instances en échec dans une même zone pointent vers un événement côté AWS; une seule instance en échec pointe vers cette instance.
Quelque chose a-t-il changé récemment? Une mise à jour du noyau, une modification du fstab, un déploiement gourmand en mémoire — les échecs de vérification d’instance suivent habituellement un changement ou une fuite de ressources lente.
Avez-vous un instantané ou une AMI récente? Connaissez votre plan de repli avant de commencer la récupération, pas après.

Comment vérifier

Récupérez le statut des vérifications et leur historique :

aws ec2 describe-instance-status --instance-ids i-0123456789abcdef0 \
  --query 'InstanceStatuses[].[InstanceState.Name,SystemStatus.Status,InstanceStatus.Status]' \
  --output table

# Depuis quand l'échec dure-t-il?
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name StatusCheckFailed_System \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-07-03T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 300 --statistics Maximum

Remplacez StatusCheckFailed_System par StatusCheckFailed_Instance pour voir l’autre côté. Pour un échec de vérification d’instance, regardez le système d’exploitation sans SSH : EC2 > Instances > Actions > Surveiller et dépanner > Obtenir le journal système montre la sortie de démarrage, et Obtenir la capture d’écran de l’instance montre ce qu’un moniteur afficherait — une panique du noyau, une invite de vérification du système de fichiers, ou un écran de connexion (ce qui voudrait dire que le système est correct et que seul le réseau est brisé). Si l’instance est basée sur Nitro, la console série EC2 vous donne une session interactive qui ne dépend pas du réseau. La matrice de dépannage complète est dans la documentation EC2 à https://docs.aws.amazon.com/ec2/.

La procédure

Vérification système échouée : arrêtez et redémarrez l’instance. Pas un reboot — un arrêt, attendez l’état stopped, puis démarrez. Le démarrage atterrit sur du matériel sain et la vérification se rétablit en quelques minutes. Avant d’arrêter : confirmez qu’aucun volume d’instance store ne contient de données non répliquées, et attendez-vous à ce que l’IP publique change sauf si vous utilisez une IP élastique.
Vérification système échouée et vous ne pouvez pas décider manuellement des arrêts : fiez-vous à la récupération automatique simplifiée ou à une alarme de récupération. La plupart des types d’instance récents récupèrent automatiquement lors d’une panne d’hôte; vous pouvez aussi créer une alarme CloudWatch sur StatusCheckFailed_System avec l’action recover, qui migre l’instance en conservant l’ID d’instance, l’IP privée et l’IP élastique. La récupération ne fonctionne pas sur les instances avec volumes d’instance store.
Vérification d’instance échouée : lisez d’abord le journal système. Panique du noyau, fsck en attente d’entrée, processus tués par manque de mémoire, ou une mauvaise entrée /etc/fstab apparaissent clairement dans la sortie console. Réparez ce que le journal nomme : un redémarrage règle temporairement un noyau coincé ou une condition de mémoire épuisée; une mauvaise entrée fstab exige une modification en mode secours.
Vérification d’instance échouée et le système ne démarre pas : secours par échange de volume. Arrêtez l’instance, détachez le volume EBS racine, attachez-le à une instance saine comme volume secondaire, montez-le, réparez (corrigez le fstab, retirez le noyau brisé de la configuration de démarrage, lancez une vérification du système de fichiers), démontez, rattachez comme volume racine, démarrez. La console série peut vous épargner toute cette danse sur les instances Nitro quand le problème est un fichier de configuration.
Vérification EBS attaché échouée : traitez ça comme un événement de volume, pas d’instance. Vérifiez le statut du volume dans EC2 > Volumes, et si les E/S sont désactivées après un événement de volume, réactivez-les après avoir évalué la cohérence. Restaurer depuis un instantané est le plan de repli honnête pour un volume endommagé.

Quand c’est la mauvaise approche

Si l’instance fait partie d’un groupe Auto Scaling derrière un répartiteur de charge, ne la soignez pas à la main — terminez-la et laissez le groupe la remplacer. La récupération manuelle est pour les animaux de compagnie : bases de données, singletons avec état, tout ce qui n’est pas trivialement reconstructible. Aussi, si les vérifications passent mais que l’application est en panne, cette procédure ne s’applique pas — les vérifications testent la santé de l’hôte et du système d’exploitation, pas votre application; ce trou est exactement ce que les vérifications de santé ELB et une base d’alarmes CloudWatch bien faite existent pour couvrir.

Erreurs courantes

Redémarrer en boucle sur un échec de vérification système — le reboot reste sur le même hôte brisé; c’est l’arrêt/démarrage qui vous déplace.
Arrêter une instance avec des données en instance store avant de les copier ailleurs, et apprendre la leçon de l’éphémère à la dure.
Attendre des heures qu’AWS répare un hôte défaillant sous vos pieds alors qu’un arrêt/démarrage aurait rétabli le service en quelques minutes.
Considérer un 2/2 réussi comme preuve que l’application fonctionne — les vérifications s’arrêtent au système d’exploitation.

Prévention

Créez des alarmes CloudWatch sur StatusCheckFailed_System (avec l’action de récupération où c’est pris en charge) et sur StatusCheckFailed_Instance pour entendre parler des pannes avant vos utilisateurs.
Gardez des AMI ou des instantanés testés de tout ce que vous détesteriez reconstruire — les décisions de récupération sont plus calmes avec un repli connu.
Exécutez les charges avec état sur EBS, et traitez l’instance store comme de l’espace de travail temporaire seulement.
Abonnez-vous aux notifications du Personal Health Dashboard; les retraits d’hôtes planifiés vous donnent une fenêtre de maintenance au lieu d’un appel à 3 h du matin.
Placez tout ce qui est remplaçable dans un groupe Auto Scaling pour que la récupération soit une terminaison, pas une chirurgie.

Les échecs de vérification de statut sont l’un des rares problèmes AWS où la console vous dit littéralement à qui la faute — lisez quelle vérification a échoué et le chemin est court. 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.