Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Récupération automatique des instances **Important** Cette section décrit comment configurer de manière proactive des mécanismes de récupération sur une instance EC2. Ces mécanismes de récupération sont conçus pour rétablir la disponibilité des instances lorsqu’ AWS détecte un problème matériel ou logiciel sous-jacent qui entraîne l’échec d’une vérification du statut du système. Si vous rencontrez actuellement des problèmes d’accès à votre instance, consultez la section [Résolution des problèmes liés aux instances EC2](ec2-instance-troubleshoot.md). S'il est AWS détecté qu'une instance n'est pas disponible en raison d'un problème matériel ou logiciel sous-jacent, deux mécanismes permettent de rétablir automatiquement la disponibilité de l'instance : la restauration [automatique simplifiée](instance-configuration-recovery.md) et la [restauration basée sur CloudWatch l'action Amazon](cloudwatch-recovery.md). La restauration de la disponibilité des instances est également appelée *restauration d’instance*. Au cours du processus de restauration de l'instance, AWS tentera de déplacer votre instance de l'hôte présentant le problème matériel ou logiciel sous-jacent vers un autre hôte. En cas de succès, le processus de récupération de l’instance sera perçu par l’instance comme un redémarrage non planifié. Vous pouvez [vérifier si la restauration de l’instance a eu lieu](verify-if-automatic-recovery-occurred.md). Si le processus de restauration échoue, l’instance peut continuer à fonctionner sur l’hôte avec le problème matériel ou logiciel sous-jacent. Dans ce cas, une intervention manuelle est requise. Si l’instance devient inaccessible ou si la vérification du statut du système continue d’échouer, nous vous recommandons [d’arrêter et de démarrer](Stop_Start.md) manuellement l’instance. Lorsque vous démarrez une instance, elle est généralement transférée vers un nouvel ordinateur hôte sous-jacent. Toutefois, contrairement à la restauration automatique d'instance, où l'instance conserve son IPv4 adresse publique, une instance redémarrée reçoit une nouvelle IPv4 adresse publique sauf si elle possède une adresse IP élastique. Pour bénéficier des mécanismes de restauration automatique, ceux-ci doivent être configurés à l’avance sur une instance avant qu’une vérification du statut du système échoue. Par défaut, la récupération automatique simplifiée est activée lors du lancement de l’instance. Vous pouvez éventuellement configurer la restauration basée sur CloudWatch l'action Amazon après le lancement. La configuration de l’un de ces mécanismes rend votre instance plus résiliente. La restauration automatique simplifiée et la restauration basée sur CloudWatch l'action Amazon ne sont disponibles que sur les instances prises en charge. Pour plus d’informations, consultez [Exigences relatives à l’activation de la récupération automatique simplifiée](instance-configuration-recovery.md#requirements-for-simplified-automatic-recovery) et [Exigences relatives à l'activation de la restauration basée sur l' CloudWatch action](cloudwatch-recovery.md#requirements-for-cloudwatch-action-based-recovery). **Avertissement** Lorsque AWS vous restaurez votre instance en raison d'un problème matériel ou logiciel sous-jacent, soyez conscient des conséquences suivantes : les données stockées dans la mémoire volatile (RAM) seront perdues et le temps de disponibilité du système d'exploitation recommencera à zéro. En outre, avec la restauration basée sur l' CloudWatch action, les données relatives aux volumes de stockage des instances seront également perdues. Pour vous protéger contre la perte de données, nous vous conseillons de créer régulièrement des sauvegardes de vos données essentielles. Pour plus d’informations sur les pratiques exemplaires en matière de sauvegarde et de récupération pour les instances Amazon EC2, consultez la section [Pratiques exemplaires pour Amazon EC2](ec2-best-practices.md). Les mécanismes de récupération automatique des instances sont conçus pour les *instances individuelles*. Pour obtenir des conseils sur la création d’un *système* résilient, consultez la section [Élaboration d’un système résilient](#instance-recovery-build-a-resilient-system). **Topics** + [Concepts clés de la récupération automatique des instances](#ec2-automatic-instance-recovery-key-concepts) + [Différences entre la restauration automatique simplifiée et la restauration basée sur CloudWatch l'action](#differences) + [Élaboration d’un système résilient](#instance-recovery-build-a-resilient-system) + [Vérification de l’occurrence d’une récupération automatique des instances](verify-if-automatic-recovery-occurred.md) + [Configuration de la restauration automatique simplifiée sur une instance Amazon EC2](instance-configuration-recovery.md) + [Configuration de la restauration basée sur l' CloudWatch action sur une instance EC2](cloudwatch-recovery.md) ## Concepts clés de la récupération automatique des instances La récupération automatique des instances est une fonctionnalité d’Amazon EC2 qui rétablit automatiquement la disponibilité des instances en cas de défaillance matérielle ou logicielle sous-jacente, améliorant ainsi la résilience et la fiabilité de vos instances EC2. Les concepts clés de la récupération automatique des instances sont les suivants : **Options de configuration** Deux mécanismes peuvent être configurés pour prendre en charge la récupération automatique des instances : + [Récupération automatique simplifiée](instance-configuration-recovery.md) : activée par défaut sur les instances prises en charge. + [CloudWatch restauration basée sur l'action](cloudwatch-recovery.md) : nécessite une configuration manuelle sur les instances prises en charge. **Contrôles de statut de système** Les vérifications de l'état du système surveillent automatiquement l' AWS infrastructure sur laquelle s'exécute votre instance EC2. + Si la vérification de l'état du système échoue, AWS lance la restauration automatique de l'instance, qui tente de migrer l'instance affectée vers un autre matériel. + L’échec de la vérification du statut du système indique un problème lié au matériel ou au logiciel de l’hôte, et non un problème lié à l’instance elle-même. La récupération automatique des instances permet de récupérer une instance qui échoue à une vérification du statut du système. Toutefois, la récupération automatique des instances ne fonctionne pas si seule la vérification du statut de l’instance échoue. + Pour connaître les différences entre les vérifications du statut de l’instance et les vérifications du statut du système, consultez la section [Types de vérifications du statut](monitoring-system-instance-status-check.md#types-of-instance-status-checks). **Exemples de problèmes matériels ou logiciels sous-jacents** Les problèmes matériels ou logiciels susceptibles d’entraîner l’échec d’une vérification du statut du système incluent la perte de connectivité réseau, la perte d’alimentation du système, les problèmes logiciels sur l’hôte physique et les problèmes matériels sur l’hôte physique qui ont une incidence sur l’accessibilité du réseau. **Caractéristiques des instances récupérées** Une instance récupérée est identique à l’instance d’origine, à l’exception des éléments perdus. Éléments préservés : + ID d’instance + Adresses IP publiques, privées et élasticité + Métadonnées de l’instance + Groupe de placement + Volumes EBS attachés + Zone de disponibilité Éléments perdus : + Données stockées dans la mémoire volatile (RAM) + Données stockées sur des volumes de stockage d'instance (applicable uniquement à la restauration basée sur l' CloudWatch action) + La durée de fonctionnement du système d’exploitation est remise à zéro **Surveillance des vérifications de l'état du système avec CloudWatch** La métrique [StatusCheckFailed\$1System](viewing_metrics_with_cloudwatch.md#status-check-metrics) présente CloudWatch indique si une vérification de l'état du système a réussi ou échoué. Valeurs de métriques : + **0** : la vérification du statut du système a réussi. + **1** : la vérification du statut du système a échoué. **Evénements à Tableau de bord Health** Lors des tentatives de restauration automatique d'une instance, vous AWS envoie des événements Tableau de bord Health en fonction du mécanisme de restauration configuré et de ses résultats : + Récupération automatique simplifiée + Événements de réussite : `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS` + Événement d’échec : `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE` + CloudWatch restauration basée sur l'action + Événements de réussite : `AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS` + Événement d’échec : `AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE` ## Différences entre la restauration automatique simplifiée et la restauration basée sur CloudWatch l'action Le tableau suivant compare les principales différences entre la restauration automatique simplifiée et la restauration basée sur CloudWatch l'action. | Point de comparaison | Récupération automatique simplifiée | CloudWatch restauration basée sur l'action | | --- | --- | --- | | Configuration | Activée par défaut sur les instances prises en charge | Nécessite une configuration manuelle des CloudWatch alarmes et des actions | | Flexibilité | Comportement de restauration fixe géré par AWS | Actions et conditions personnalisables | | Notification | Notifications de base via Tableau de bord Health | Notifications personnalisables via SNS | | Taille d’instance metal | Exclu | Inclus | | Volumes de stockage d’instances attachés au lancement | Non pris en charge pour les instances qui attachent des volumes de stockage d’instance au lancement | Pris en charge sur certains types d’instances. Veuillez noter que les données sur les volumes de stockage d’instance sont perdues lors de la récupération de l’instance. | | Temps de récupération | Tentative de récupération standard | Tentatives de restauration plus rapides qu’une restauration automatique simplifiée | | Problème de l’hôte résolu pendant la migration | La migration peut être annulée et l’instance reste sur l’hôte d’origine | La migration vers un nouvel hôte se poursuit | | Cost | Aucun coût supplémentaire | Peut entraîner des frais CloudWatch | ## Élaboration d’un système résilient Bien que la restauration automatique simplifiée et la restauration basée sur l' CloudWatch action soient efficaces pour maintenir la disponibilité des instances individuelles, il est AWS recommandé de mettre en œuvre une architecture de haute disponibilité permettant le basculement du trafic vers des instances saines. Pour ce faire, pensez à utiliser AWS des services tels que Elastic Load Balancing (qui distribue le trafic entrant sur plusieurs instances EC2) et Amazon EC2 Auto Scaling (qui ajuste automatiquement le nombre d'instances en fonction de la demande et de l'état de santé). Pour plus d’informations sur la création d’un système résilient et tolérant aux pannes avec des instances EC2, consultez les ressources suivantes : + [Retour à l'essentiel : concevoir en cas d'échec avec EC2](https://www.youtube.com/watch?v=5Hq5YxOrKYs) *sur le canal AWS YouTube* + [Architecture de reprise après sinistre (DR) AWS, partie I : stratégies de reprise dans le cloud sur le](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) site du *blog sur AWS l'architecture* + [Guide de l’utilisateur Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + [Guide de l'utilisateur Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [REL11- Passez BP02 à des ressources saines](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_failover2good.html) dans le cadre * AWS Well-Architected du pilier de fiabilité* # Vérification de l’occurrence d’une récupération automatique des instances Si votre instance semble avoir été déconnectée puis redémarrée de manière inattendue, il se peut qu’elle ait fait l’objet d’une [récupération automatique des instances](ec2-instance-recover.md#ec2-automatic-instance-recovery-key-concepts) en réponse à un problème matériel ou logiciel sous-jacent. Vous pouvez le vérifier en vérifiant les événements de récupération automatique des instances dans votre Tableau de bord Health. Vous pouvez également vérifier si un problème matériel ou logiciel sous-jacent a été détecté pour votre instance en consultant la CloudWatch métrique Amazon **StatusCheckFailed\$1System**. ## Vérifiez les événements à Tableau de bord Health Lorsqu'une tentative de restauration automatique d'une instance se produit, AWS envoie des événements à votre Tableau de bord Health. L’événement spécifique dépend du mécanisme de restauration configuré et de la réussite ou de l’échec de la tentative. **Pour vérifier les événements de restauration automatique des instances dans Tableau de bord Health** 1. Ouvrez le Tableau de bord Health at [https://phd.aws.amazon.com/phd/home\$1/](https://phd.aws.amazon.com/phd/). 1. Recherchez les événements associés à la récupération automatique des instances. La présence de ces événements peut confirmer si une tentative de récupération automatique des instances a eu lieu et son résultat. + Récupération automatique simplifiée + Événements de réussite : `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS` + Événement d’échec : `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE` + CloudWatch restauration basée sur l'action + Événements de réussite : `AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS` + Événement d’échec : `AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE` ## Surveillez les vérifications de l'état du système avec CloudWatch Vous pouvez vérifier si un problème matériel ou logiciel sous-jacent a été détecté pour votre instance en intégrant la métrique [StatusCheckFailed\$1System](viewing_metrics_with_cloudwatch.md#status-check-metrics). CloudWatch La valeur de métrique indique si une vérification du statut du système a réussi (aucun problème matériel ou logiciel) ou a échoué (problème matériel ou logiciel). **Pour vérifier si un problème matériel ou logiciel sous-jacent a été détecté** 1. Ouvrez la page **Metrics** de CloudWatch la console à la page [https://console.aws.amazon.com/cloudwatch/d'accueil ? ](https://console.aws.amazon.com/cloudwatch/home?#metricsV2)\$1metricsV2. 1. Vérifiez que vous êtes dans la même région que votre instance EC2. 1. Collez la métrique suivante dans le champ de recherche **Métriques** et appuyez sur Entrée. ``` StatusCheckFailed_System ``` 1. Choisissez **EC2 > Métriques par instance**. 1. Dans le tableau, cochez la case en regard de l’instance que vous souhaitez vérifier. 1. Modifiez la période de requête en fonction de l’heure à laquelle vous pensez que l’événement de restauration s’est produit. 1. Choisissez l'onglet **Graphed metrics**, puis pour **StatusCheckFailed\$1System, procédez** comme suit : 1. Pour **Statistiques**, sélectionnez **Moyenne**, **Maximum** ou **Minimum**. 1. Pour **Période**, choisissez **1 minute**. 1. Vérifiez la valeur de **StatusCheckFailed\$1System.** + Valeur de **0** : la vérification du statut du système a réussi, ce qui indique l’absence de problème matériel ou logiciel sous-jacent. + Valeur de **1** : la vérification du statut du système a échoué, ce qui indique un problème matériel ou logiciel sous-jacent. Pour de plus amples informations, veuillez consulter [Récupération automatique des instances](ec2-instance-recover.md). # Configuration de la restauration automatique simplifiée sur une instance Amazon EC2 **Important** Cette section décrit comment configurer de manière proactive des mécanismes de récupération sur une instance EC2. Ces mécanismes de récupération sont conçus pour rétablir la disponibilité des instances lorsqu’ AWS détecte un problème matériel ou logiciel sous-jacent qui entraîne l’échec d’une vérification du statut du système. Si vous rencontrez actuellement des problèmes d’accès à votre instance, consultez la section [Résolution des problèmes liés aux instances EC2](ec2-instance-troubleshoot.md). S'il est AWS détecté qu'une instance n'est pas disponible en raison d'un problème matériel ou logiciel sous-jacent, la *restauration automatique simplifiée* peut rétablir automatiquement la disponibilité de l'instance en déplaçant l'instance de l'hôte présentant le problème sous-jacent vers un autre hôte. En cas de restauration automatique simplifiée, AWS envoie l'un des événements suivants à votre Tableau de bord AWS Health attention, en fonction du résultat : + Événements de réussite : `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS` + Événement d’échec : `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE` Pour être informé de ces événements, vous pouvez configurer les notifications. Pour plus d’informations, consultez la section [Création de votre première configuration de notification Notifications des utilisateurs AWS](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) dans le *Guide de l’utilisateur Notifications des utilisateurs AWS *. Vous pouvez également utiliser [ EventBridge les règles d'Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) pour surveiller les événements de restauration automatique simplifiés. La récupération automatique simplifiée est activée par défaut sur toutes les instances prises en charge lors du lancement de l’instance. Toutefois, il ne peut fonctionner que si une instance est dans `running` cet état, si aucun événement de service n'est répertorié dans le Tableau de bord AWS Health et si la capacité est disponible pour le type d'instance. Dans certaines situations, telles que des pannes importantes, des contraintes de capacité peuvent entraîner l’échec des tentatives de récupération. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés aux défaillances de la récupération automatique simplifiée](#ec2-instance-recover-simplified-auto-recovery-troubleshooting). Vous pouvez désactiver la restauration automatique simplifiée pendant ou après le lancement, et la réactiver ultérieurement si nécessaire. **Avertissement** Lorsque AWS vous restaurez votre instance en raison d'un problème matériel ou logiciel sous-jacent, soyez conscient des conséquences suivantes : les données stockées dans la mémoire volatile (RAM) seront perdues et le temps de disponibilité du système d'exploitation recommencera à zéro. Pour vous protéger contre la perte de données, nous vous conseillons de créer régulièrement des sauvegardes de vos données essentielles. Pour plus d’informations sur les pratiques exemplaires en matière de sauvegarde et de récupération pour les instances Amazon EC2, consultez la section [Pratiques exemplaires pour Amazon EC2](ec2-best-practices.md). Les mécanismes de récupération automatique des instances sont conçus pour les *instances individuelles*. Pour obtenir des conseils sur la création d’un *système* résilient, consultez la section [Élaboration d’un système résilient](ec2-instance-recover.md#instance-recovery-build-a-resilient-system). **Topics** + [Exigences relatives à l’activation de la récupération automatique simplifiée](#requirements-for-simplified-automatic-recovery) + [Configurez la récupération automatique simplifiée](#set-recovery-behavior) + [Résolution des problèmes liés aux défaillances de la récupération automatique simplifiée](#ec2-instance-recover-simplified-auto-recovery-troubleshooting) ## Exigences relatives à l’activation de la récupération automatique simplifiée La récupération automatique simplifiée peut être activée sur les instances qui répondent aux critères suivants : **Types d’instances** + **Usage général :** A1, M3, M4, M5, M5a, M5n, M5zn, M6a, M6g, M6i, M6in, M7a, M7g, M7i, M7i-Flex, M8a, M8aZn, M8g, M8Gn, M8i, M8i-Flex, T1, T2, T3, T3a, T4 g + **Optimisé pour le calcul :** C3, C4, C5, C5a, C5n, C6a, C6g, C6gn, C6i, C6in, C7a, C7g, C7gN, C7i, C7i-Flex, C8a, C8g, C8gb, C8i, C8i-Flex + **Mémoire optimisée :** R3, R4, R5, R5a, R5b, R5n, R6a, R6g, R6i, R6in, R7a, R7g, R7i, R7iz, R8a, R8g, R8gb, R8gn, R8i, R8i-Flex, U-3TB1, U-6TB1, U-9TB1, U-9TB1, 12TB1, U-18TB1, U-24TB1, U7i-6TB, U7i-8TB, U7i-12TB, U7in-16TB, U7in-24TB, U7in-32TB, U7inh-32 To, X1, X1e, X2ieZN, X8g, X8i + **Calcul accéléré :** G3, G5g, Inf1, P3, VT1 + **Calcul à hautes performances :** hPC6a, hPC7a, hPC7g, hPC8a **Tenancy** + Partagé + Dedicated Instance Pour de plus amples informations, veuillez consulter [Instances EC2 dédiées Amazon](dedicated-instance.md). **Limites** La récupération automatique simplifiée n’est pas prise en charge pour les instances présentant les caractéristiques suivantes : + Taille de l’instance : instances `metal` + Location : hôte dédié. Pour les hôtes dédiés, utilisez plutôt la [récupération automatique de l’hôte dédié](dedicated-hosts-recovery.md). + Stockage : instances avec volumes de stockage d’instance + Mise en réseau : instances utilisant un adaptateur Elastic Fabric Adapter + Auto Scaling : instances qui font partie d’un groupe Auto Scaling + Maintenance : instances qui font actuellement l’objet d’une opération de maintenance programmée ## Configurez la récupération automatique simplifiée La récupération automatique simplifiée est activée par défaut lorsque vous lancez une instance prise en charge. Vous pouvez définir le comportement de récupération automatique sur `disabled` pendant ou après le lancement de l’instance. La configuration `default` ne permet pas la récupération automatique simplifiée pour une instance non prise en charge. ------ #### [ Console ] **Désactivation de la récupération automatique simplifiée au lancement** 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **Instances**, puis **Launch instance** (Lancer une instance). 1. Dans la section **Détails avancés**, pour **Récupération automatique de l’instance**, sélectionnez **Désactivé**. 1. Configurez les paramètres de lancement de l’instance restants selon les besoins, puis lancez l’instance. **Pour désactiver la récupération automatique simplifiée après le lancement** 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **Instances**. 1. Sélectionnez l’instance, puis choisissez **Actions**, **Instance Settings** (Paramètres de l’instance), **Change auto-recovery Behavior** (Changer le comportement de restauration automatique). 1. Choisissez **Off** (Désactiver), puis **Save** (Enregistrer). **Pour activer la récupération automatique simplifiée après le lancement** 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **Instances**. 1. Sélectionnez l’instance, puis choisissez **Actions**, **Instance Settings** (Paramètres de l’instance), **Change auto-recovery Behavior** (Changer le comportement de restauration automatique). 1. Choisissez **Par défaut (Activé)**, puis **Enregistrer**. ------ #### [ AWS CLI ] **Désactivation de la récupération automatique simplifiée au lancement** Utilisez la commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instance.html) avec l’option `--maintenance-options`. ``` --maintenance-options AutoRecovery=Disabled ``` **Pour désactiver la récupération automatique simplifiée après le lancement** Utilisez la commande [modify-instance-maintenance-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-maintenance-options.html). ``` aws ec2 modify-instance-maintenance-options \ --instance-id i-1234567890abcdef0 \ --auto-recovery disabled ``` **Pour activer la récupération automatique simplifiée après le lancement** Utilisez la commande [modify-instance-maintenance-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-maintenance-options.html). ``` aws ec2 modify-instance-maintenance-options \ --instance-id i-1234567890abcdef0 \ --auto-recovery default ``` ------ #### [ PowerShell ] **Désactivation de la récupération automatique simplifiée au lancement** Utilisez l’applet de commande [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html). ``` -MaintenanceOptions_AutoRecovery Disabled ``` **Pour désactiver la récupération automatique simplifiée après le lancement** Utilisez l’applet de commande [Edit-EC2InstanceMaintenanceOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMaintenanceOption.html). ``` Edit-EC2InstanceMaintenanceOption ` -InstanceId i-1234567890abcdef0 ` -AutoRecovery Disabled ``` **Pour activer la récupération automatique simplifiée après le lancement** Utilisez l’applet de commande [Edit-EC2InstanceMaintenanceOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMaintenanceOption.html). ``` Edit-EC2InstanceMaintenanceOption ` -InstanceId i-1234567890abcdef0 ` -AutoRecovery Enabled ``` ------ ## Résolution des problèmes liés aux défaillances de la récupération automatique simplifiée Si la récupération automatique simplifiée ne parvient pas à récupérer votre instance, envisagez les problèmes suivants : + AWS les événements de service sont en cours La récupération automatique simplifiée ne fonctionne pas lors d'événements de service dans le Tableau de bord AWS Health. Il se peut que vous ne receviez pas de notifications d’échec de récupération pour de tels événements. Pour obtenir les dernières informations sur la disponibilité des services, consultez la page état [de santé des services](https://health.aws.amazon.com/health/status). + Capacité insuffisante Le matériel de remplacement est temporairement insuffisant pour effectuer la migration de l’instance. + Le nombre maximal de tentatives de restauration quotidiennes est atteint L’instance a atteint l’autorisation quotidienne maximale de tentatives de récupération. Votre instance peut être mise hors service ultérieurement si la récupération automatique échoue et s’il est établi qu’une dégradation matérielle est à l’origine de l’échec de la vérification initiale du statut du système. Si l'échec de la vérification de l'état du système de l'instance persiste malgré plusieurs tentatives de récupération, consultez [Résoudre les problèmes des instances dont les vérifications d'état ont échoué](TroubleshootingInstances.md) pour obtenir des instructions supplémentaires. # Configuration de la restauration basée sur l' CloudWatch action sur une instance EC2 **Important** Cette section décrit comment configurer de manière proactive des mécanismes de récupération sur une instance EC2. Ces mécanismes de récupération sont conçus pour rétablir la disponibilité des instances lorsqu’ AWS détecte un problème matériel ou logiciel sous-jacent qui entraîne l’échec d’une vérification du statut du système. Si vous rencontrez actuellement des problèmes d’accès à votre instance, consultez la section [Résolution des problèmes liés aux instances EC2](ec2-instance-troubleshoot.md). S'il est AWS détecté qu'une instance n'est pas disponible en raison d'un problème matériel ou logiciel sous-jacent, la *restauration basée sur l'CloudWatch action* peut rétablir automatiquement la disponibilité de l'instance en déplaçant l'instance de l'hôte présentant le problème sous-jacent vers un autre hôte. En cas de restauration basée sur l' CloudWatch action, vous AWS envoie l'un des événements suivants Tableau de bord AWS Health, en fonction du résultat : + Événements de réussite : `AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS` + Événement d’échec : `AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE` Vous pouvez configurer la restauration basée sur CloudWatch l'action pour ajouter des actions de restauration aux CloudWatch alarmes Amazon. CloudWatch la restauration basée sur l'action fonctionne avec la `StatusCheckFailed_System` métrique. CloudWatchla restauration basée sur les actions fournit une granularité du temps de réponse et des notifications Amazon Simple Notification Service (Amazon SNS) concernant les actions de to-the-minute restauration et les résultats. Ces options de configuration permettent des tentatives de récupération plus rapides grâce à un contrôle plus précis de la réponse à l'échec de la vérification de l'état du système, par rapport à une récupération automatique simplifiée. Pour plus d'informations sur les CloudWatch options disponibles, consultez la section [Contrôles de statut de vos instances](monitoring-system-instance-status-check.md). Toutefois, la restauration basée sur l' CloudWatch action ne peut fonctionner que si une instance est dans `running` cet état, si aucun événement de service n'est répertorié dans le Tableau de bord AWS Health et si la capacité est disponible pour le type d'instance. Dans certaines situations, telles que des pannes importantes, des contraintes de capacité peuvent entraîner l’échec des tentatives de récupération. Pour de plus amples informations, veuillez consulter [Résoudre les défaillances de restauration basées sur l' CloudWatch action](#ec2-instance-recover-cloudwatch-troubleshooting). **Avertissement** Lorsque AWS vous restaurez votre instance en raison d'un problème matériel ou logiciel sous-jacent, soyez conscient des conséquences suivantes : les données stockées dans la mémoire volatile (RAM) et sur les volumes de stockage de l'instance seront perdues, et le temps de fonctionnement du système d'exploitation recommencera à zéro. Pour vous protéger contre la perte de données, nous vous conseillons de créer régulièrement des sauvegardes de vos données essentielles. Pour plus d’informations sur les pratiques exemplaires en matière de sauvegarde et de récupération pour les instances Amazon EC2, consultez la section [Pratiques exemplaires pour Amazon EC2](ec2-best-practices.md). Les mécanismes de récupération automatique des instances sont conçus pour les *instances individuelles*. Pour obtenir des conseils sur la création d’un *système* résilient, consultez la section [Élaboration d’un système résilient](ec2-instance-recover.md#instance-recovery-build-a-resilient-system). **Topics** + [Exigences relatives à l'activation de la restauration basée sur l' CloudWatch action](#requirements-for-cloudwatch-action-based-recovery) + [Configuration de la restauration basée sur l' CloudWatch action](#ec2-instance-recover-cloudwatch-configure) + [Résoudre les défaillances de restauration basées sur l' CloudWatch action](#ec2-instance-recover-cloudwatch-troubleshooting) ## Exigences relatives à l'activation de la restauration basée sur l' CloudWatch action CloudWatch la restauration basée sur l'action peut être activée sur les instances qui répondent aux critères suivants : **Types d’instances** + **Usage général :** A1, M3, M4, M5, M5a, M5n, M5zn, M6a, M6g, M6i, M6in, M7a, M7g, M7i, M7i-Flex, M8a, M8aZn, M8g, M8Gn, M8i, M8i-Flex, T1, T2, T3, T3a, T4 g + **Optimisé pour le calcul :** C3, C4, C5, C5a, C5n, C6a, C6g, C6gn, C6i, C6in, C7a, C7g, C7gN, C7i, C7i-Flex, C8a, C8g, C8gb, C8i, C8i-Flex + **Mémoire optimisée :** R3, R4, R5, R5a, R5b, R5n, R6a, R6g, R6i, R6in, R7a, R7g, R7i, R7iz, R8a, R8g, R8gb, R8gn, R8i, R8i-Flex, U-3TB1, U-6TB1, U-9TB1, U-9TB1, 12TB1, U-18TB1, U-24TB1, U7i-6TB, U7i-8TB, U7i-12TB, U7in-16TB, U7in-24TB, U7in-32TB, U7inh-32 To, X1, X1e, X2IDN, X2ieZn, X8g, X8i + **Calcul accéléré :** G3, G5g, Inf1, P3, VT1 + **Calcul à hautes performances :** hPC6a, hPC7a, hPC7g, hPC8a + **Instances metal :** n’importe lequel des types ci-dessus avec la taille de l’instance metal. + **Si des volumes de stockage d’instance sont ajoutés au lancement :** alors seuls les types d’instance suivants sont pris en charge : M3, C3, R3, X1, X1e, X2idn, X2iedn **Tenancy** + Partagé + Dedicated Instance Pour de plus amples informations, veuillez consulter [Instances EC2 dédiées Amazon](dedicated-instance.md). **Limites** CloudWatch la restauration basée sur l'action n'est pas prise en charge pour les instances présentant les caractéristiques suivantes : + Location : hôte dédié. Pour les hôtes dédiés, utilisez plutôt la [récupération automatique de l’hôte dédié](dedicated-hosts-recovery.md). + Mise en réseau : instances utilisant un adaptateur Elastic Fabric Adapter + Auto Scaling : instances qui font partie d’un groupe Auto Scaling + Maintenance : instances qui font actuellement l’objet d’une opération de maintenance programmée ### Recherche des types d’instances pris en charge Vous pouvez consulter les types d'instances qui prennent en charge la restauration basée sur CloudWatch l'action. ------ #### [ Console ] **Pour afficher les types d'instances qui prennent en charge la restauration basée sur CloudWatch l'action** 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation de gauche, choisissez **Instance Types** (Types d’instance). 1. Dans la barre de filtre, saisissez **Auto Recovery support = true**. Le tableau des **types d'instances** affiche tous les types d'instances qui prennent en charge la restauration basée sur CloudWatch l'action. 1. (Facultatif) Ajoutez des filtres pour affiner davantage la recherche à des types d’instances spécifiques qui vous intéressent. ------ #### [ AWS CLI ] **Pour afficher les types d'instances qui prennent en charge la restauration basée sur CloudWatch l'action** Utilisez la commande [describe-instance-types](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-types.html) avec le filtre `auto-recovery-supported`. ``` aws ec2 describe-instance-types \ --filters Name=auto-recovery-supported,Values=true \ --query "InstanceTypes[*].[InstanceType]" \ --output text | sort ``` ------ #### [ PowerShell ] **Pour afficher les types d'instances qui prennent en charge la restauration basée sur CloudWatch l'action** Utilisez l'[Get-EC2InstanceType](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceType.html)applet de commande avec le `auto-recovery-supported` filtre. ``` Get-EC2InstanceType ` -Filter @{Name="auto-recovery-supported";Values="true"} | ` Select InstanceType | Sort-Object InstanceType ``` ------ ## Configuration de la restauration basée sur l' CloudWatch action Pour configurer la restauration basée sur l' CloudWatch action pour une instance EC2, créez une CloudWatch alarme qui surveille la `StatusCheckFailed_System` métrique pour l'instance spécifiée. Réglez l’alarme pour qu’elle se déclenche lorsque la valeur de la métrique est égale à **1**, ce qui indique un échec de la vérification du statut du système. Configurez l’action d’alarme pour récupérer automatiquement l’instance lorsqu’elle est déclenchée. Vous pouvez configurer l'alarme à l'aide de la console Amazon EC2 ou de la CloudWatch console. Pour les instructions, consultez ce guide [Ajouter des actions de restauration aux CloudWatch alarmes Amazon](UsingAlarmActions.md#AddingRecoverActions) de l'utilisateur ou [Ajouter des actions de restauration aux CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingRecoverActions) dans le *guide de CloudWatch l'utilisateur Amazon*. ## Résoudre les défaillances de restauration basées sur l' CloudWatch action Si la restauration basée sur l' CloudWatch action ne parvient pas à récupérer votre instance, prenez en compte les problèmes suivants : + AWS les événements de service sont en cours CloudWatch la restauration basée sur l'action ne fonctionne pas lors d'événements de service dans le Tableau de bord AWS Health. Il se peut que vous ne receviez pas de notifications d’échec de récupération pour de tels événements. Pour obtenir les dernières informations sur la disponibilité des services, consultez la page état [de santé des services](https://health.aws.amazon.com/health/status). + Capacité insuffisante Le matériel de remplacement est temporairement insuffisant pour effectuer la migration de l’instance. + Le nombre maximal de tentatives de restauration quotidiennes est atteint L’instance a atteint l’autorisation quotidienne maximale de tentatives de récupération. Votre instance peut être mise hors service ultérieurement si la récupération automatique échoue et s’il est établi qu’une dégradation matérielle est à l’origine de l’échec de la vérification initiale du statut du système. Si l'échec de la vérification de l'état du système de l'instance persiste malgré plusieurs tentatives de récupération, consultez [Résoudre les problèmes des instances dont les vérifications d'état ont échoué](TroubleshootingInstances.md) pour obtenir des instructions supplémentaires.