Un site web de staging s'exécute sur une seule instance Amazon EC2 sauvegardée par EBS. L'entreprise souhaite une récupération rapide et une perte de données minimale si l'instance rencontre des problèmes de connectivité réseau ou une panne de courant de l'hôte. Quelle option répond à ces exigences ?

L'option correcte est de créer une alarme Amazon CloudWatch pour la métrique StatusCheckFailed System et de choisir l'action de récupération EC2. Cette approche est conçue pour les défaillances du système sous-jacent (comme les problèmes de connectivité réseau ou les pannes de courant de l'hôte) qui affectent l'instance EC2. L'action de récupération migre l'instance vers un nouvel hôte sain, préservant l'ID de l'instance, les adresses IP privées, les adresses IP élastiques associées et toutes les métadonnées de l'instance, y compris les volumes EBS. Cela garantit une récupération rapide avec une perte de données minimale. L'ajout de l'instance à un groupe Auto Scaling avec une capacité de 1 ne répond pas aux exigences de récupération rapide pour les défaillances du système, car il ne déclenchera pas de remplacement automatique pour les problèmes d'hôte sous-jacent sans configuration supplémentaire. L'utilisation d'un lifecycle hook pour détacher le volume EBS n'est pas pertinente pour la récupération après une défaillance du système et pourrait entraîner une perte de données. La métrique StatusCheckFailed Instance concerne les problèmes au niveau du système d'exploitation ou de l'application de l'instance, et une action de redémarrage EC2 ne résoudrait pas les problèmes d'hôte sous-jacent, ce qui pourrait entraîner un redémarrage sur le même hôte défectueux.