

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.

# Modifications de l'état de l' EC2 instance Amazon
<a name="ec2-instance-lifecycle"></a>

Une EC2 instance Amazon passe par différents états à partir du moment où vous la lancez et jusqu'à son arrêt.

L’illustration suivante représente les transitions entre les états de l’instance.

![\[Cycle de vie d’une instance.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/instance_lifecycle.png)


Vous pouvez recevoir des notifications lorsque vos instances changent d'état. Pour de plus amples informations, veuillez consulter [Événements de changement de statut pour les instances Amazon EC2](monitoring-instance-state-changes.md).

## Facturation par état de l'instance
<a name="instance-billing-by-state"></a>

Le tableau suivant fournit une brève description de chaque état d'instance et indique si l'utilisation de l'instance est facturée. Certaines AWS ressources, telles que les volumes Amazon EBS et les adresses IP Elastic, sont facturées quel que soit l'état de l'instance. Pour plus d’informations, consultez [Éviter les frais inattendus](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html) dans le * Guide de l’utilisateur AWS Billing *.


| État de l’instance | Description | Facturation de l’utilisation de l’instance | 
| --- | --- | --- | 
|  `pending`  |  L’instance se prépare à passer à l’état `running`. Une instance passe à l’état `pending` lorsqu’elle est lancée ou lorsqu’elle est démarrée après avoir été à l’état `stopped`.  |  Non facturé  | 
|  `running`  |  L’instance est en cours d’exécution et prête à être utilisée.  |  Facturé  | 
|  `stopping`  |  L’instance se prépare à être arrêtée.  |  Non facturé  Si vous mettez une instance en veille prolongée, vous serez facturé pendant que l'instance est à l'état `stopping`.   | 
|  `stopped`  |  L’instance est arrêtée et ne peut pas être utilisée. L’instance peut être démarrée à tout moment.  |  Non facturé  | 
|  `shutting-down`  |  L’instance se prépare à être supprimée.  |  Non facturé  | 
|  `terminated`  |  L’instance a été définitivement supprimée et ne peut pas être démarrée.  |  Non facturé  Les instances réservées appliquées aux instances résiliées sont facturées jusqu’à la fin de leur période de validité, selon l’option de paiement. Pour de plus amples informations, consultez [Aperçu des instances réservées pour Amazon EC2](ec2-reserved-instances.md).   | 

## Instances en attente
<a name="instance-launch"></a>

Lorsque vous lancez une instance, elle entre dans l’état `pending`. Le type d’instance que vous avez spécifié au lancement détermine les capacités matérielles de l’ordinateur hôte de votre instance. Nous utilisons l’Amazon Machine Image (AMI) que vous avez spécifié au lancement pour démarrer l’instance. Une fois que l’instance est prête, elle entre dans l’état `running`. Vous pouvez vous connecter à votre instance en cours d’exécution et l’utiliser comme vous le feriez d’un ordinateur devant lequel vous êtes assis.

Dès que votre instance passe à l’état `running`, vous êtes facturé pour chaque seconde d’exécution de l’instance, avec un minimum d’une minute, même si l’instance demeure inactive et que vous ne vous y connectez pas.

## Instances arrêtées
<a name="instance-stop-start"></a>

Si votre instance ne passe pas avec succès un contrôle de statut ou n’exécute pas vos applications comme escompté, et que le volume racine de votre instance est un volume Amazon EBS, vous pouvez arrêter et démarrer votre instance pour tenter de corriger le problème.

Lorsque vous arrêtez votre instance, elle entre dans l’état `stopping`, puis dans l’état `stopped`. Aucuns frais d’utilisation ou de transfert de données ne vous sont facturés pour votre instance lorsqu’elle est `stopped`. Des frais sont facturés pour le stockage de tous les volumes Amazon EBS. Lorsque votre instance se trouve dans l’état `stopped`, vous pouvez modifier certains attributs de l’instance, y compris le type d’instance.

Lorsque vous démarrez votre instance, elle passe à l’état `pending` et elle est déplacée vers un nouvel ordinateur hôte (même si, dans la plupart des cas, elle reste sur l’hôte actuel). Lorsque vous arrêtez et démarrez votre instance, vous perdez toutes les données des volumes de stockage d’instances attachés à l’ordinateur hôte précédent.

Votre instance conserve son IPv4 adresse privée, ce qui signifie qu'une adresse IP élastique associée à l' IPv4 adresse privée ou à l'interface réseau reste associée à votre instance. Si votre instance possède une IPv6 adresse, elle la IPv6 conserve.

Chaque fois que vous opérez la transition d’une instance de l’état `stopped` à l’état `running`, vous êtes facturé par seconde d’exécution de l’instance, avec un minimum d’une minute par instance démarrée.

Pour plus d’informations sur l’arrêt et le redémarrage d’une instance, consultez [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md).

## Instances mises en veille prolongée
<a name="instance-hibernate"></a>

Lorsque vous mettez une instance en veille prolongée, nous signalons au système d'exploitation d'exécuter hibernation (suspend-to-disk), qui enregistre le contenu de la mémoire de l'instance (RAM) sur votre volume racine Amazon EBS. Nous conservons le volume racine Amazon EBS de l’instance et les volumes de données Amazon EBS attachés. Lorsque vous démarrez votre instance, le volume racine Amazon EBS est restauré à son état précédent et le contenu de la mémoire RAM est rechargé. Les volumes de données précédemment attachés sont attachés à nouveau et l’instance conserve son ID d’instance.

Lorsque vous mettez votre instance en veille prolongée, elle entre dans l’état `stopping`, puis dans l’état `stopped`. Nous ne facturons pas l’utilisation d’une instance en veille prolongée à l’état `stopped`, mais nous la facturons quand elle est à l’état `stopping`, contrairement à ce qui se produit quand vous [arrêtez une instance](#instance-stop-start) sans la mettre en veille prolongée. Nous ne facturons pas de frais de transfert de données pour l’utilisation. En revanche, nous facturons le stockage des volumes Amazon EBS, y compris le stockage des données de la mémoire RAM.

Lorsque vous démarrez votre instance mise en veille prolongée, elle passe à l’état `pending` et nous déplaçons l’instance vers un nouvel ordinateur hôte (même si, dans la plupart des cas, elle reste sur l’hôte actuel).

Votre instance conserve son IPv4 adresse privée, ce qui signifie qu'une adresse IP élastique associée à l' IPv4 adresse privée ou à l'interface réseau est toujours associée à votre instance. Si votre instance possède une IPv6 adresse, elle la conserve IPv6 .

Pour de plus amples informations, veuillez consulter [Mettez en veille prolongée votre instance Amazon EC2](Hibernate.md).

## Redémarrage des instances
<a name="instance-reboot"></a>

Vous pouvez redémarrer votre instance à l'aide de la EC2 console Amazon, d'un outil de ligne de commande et de l' EC2API Amazon. Nous vous recommandons d'utiliser Amazon EC2 pour redémarrer votre instance au lieu d'exécuter la commande de redémarrage du système d'exploitation depuis votre instance.

Le redémarrage d’une instance est similaire à celui d’un système d’exploitation. L’instance demeure sur le même ordinateur hôte et conserve son nom DNS public, son adresse IP privée et les données de ses volumes de stockage d’instances. Le redémarrage nécessite généralement quelques minutes pour s’exécuter, mais le temps réel dépend de la configuration de l’instance.

Le redémarrage d’une instance ne déclenche pas de nouvelle période de facturation ; la facturation par seconde se poursuit, sans frais minimum d’une minute.

Pour de plus amples informations, veuillez consulter [Redémarrez votre EC2 instance Amazon](ec2-instance-reboot.md).

## Instances résiliées
<a name="instance-termination"></a>

Si vous jugez que vous n’avez plus besoin d’une instance, vous pouvez la mettre hors service. Dès que l’état d’une instance passe à `shutting-down` ou `terminated`, l’instance ne vous est plus facturée.

Si vous activez la protection de la résiliation, il ne vous est pas possible de résilier l’instance à l’aide de la console, de la CLI ou de l’API.

Une fois que vous avez mis une instance hors service, elle demeure visible sur la console pendant un court instant, puis l’entrée est supprimée automatiquement. Vous pouvez aussi décrire une instance terminée à l’aide de la CLI ou de l’API. Les ressources (telles que les balises) sont progressivement dissociées de l’instance résiliées. Par conséquent, elles ne seront plus visibles dans l’instance terminée après un certain temps. Vous ne pouvez pas vous connecter à une instance terminée, ni la récupérer. 

Chaque instance basée sur Amazon EBS prend en charge l'attribut `InstanceInitiatedShutdownBehavior`, qui permet de déterminer si l'instance s'arrête ou se termine lorsque vous lancez l'arrêt à partir de l'instance elle-même (par exemple, à l'aide de la commande **shutdown** sur Linux). Le comportement par défaut est celui de l’arrêt de l’instance. Vous pouvez modifier la valeur de cet attribut tandis que l’instance est en cours d’exécution ou arrêtée.

Chaque volume Amazon EBS prend en charge l’attribut `DeleteOnTermination`, qui contrôle si le volume est supprimé ou conservé lorsque vous terminez l’instance à laquelle il est attaché. Le comportement par défaut est la suppression du volume racine et la conservation de tous les autres volumes EBS.

Pour de plus amples informations, veuillez consulter [Terminez l'instance Amazon EC2](terminating-instances.md).

## Différences entre les états d'instance
<a name="lifecycle-differences"></a>

Le tableau suivant résume les principales différences entre le redémarrage, l’arrêt, la mise en veille prolongée et la résiliation d’une instance.


| Caractéristiques | Redémarrer | Arrêt/démarrage (instances basées sur les volumes Amazon EBS uniquement) | Mise en veille prolongée (instances basées sur Amazon EBS uniquement) | Terminer | 
| --- | --- | --- | --- | --- | 
|  Ordinateur hôte  |  L’instance demeure sur le même ordinateur hôte.  |  Nous déplaçons l’instance vers un nouvel ordinateur hôte (même si, dans certains cas, elle reste sur l’hôte actuel).  |  Nous déplaçons l’instance vers un nouvel ordinateur hôte (même si, dans certains cas, elle reste sur l’hôte actuel).  |  Aucune  | 
|   IPv4 Adresse privée  |  L'instance conserve son IPv4 adresse privée.  |  L'instance conserve son IPv4 adresse privée.  |  L'instance conserve son IPv4 adresse privée.  |  Aucune  | 
|   IPv4 Adresse publique  |  L'instance conserve son IPv4 adresse publique.  |  L'instance obtient une nouvelle IPv4 adresse publique, sauf si elle possède une interface réseau secondaire ou une IPv4 adresse privée secondaire associée à une adresse IP élastique.  |  L'instance obtient une nouvelle IPv4 adresse publique, sauf si elle possède une interface réseau secondaire ou une IPv4 adresse privée secondaire associée à une adresse IP élastique.  |  Aucune  | 
|  Adresse IP élastique (IPv4)  |  L’adresse IP Elastic reste associée à l’instance  |  L’adresse IP Elastic reste associée à l’instance  |  L’adresse IP Elastic reste associée à l’instance  |  L’adresse IP Elastic est dissociée de l’instance.  | 
|  IPv6 adresse  |  L'instance conserve son IPv6 adresse  |  L'instance conserve son IPv6 adresse  |  L'instance conserve son IPv6 adresse  |  Aucune  | 
|  Volumes de stockage d’instances  |  Les données sont conservées.  |  Les données sont effacées.  |  Les données sont effacées.  |  Les données sont effacées.  | 
|  Volume racine  |  Le volume est conservé  |  Le volume est conservé  |  Le volume est conservé  |  Le volume est supprimé par défaut.  | 
|  RAM (contenu de la mémoire)  |  Les données de la mémoire RAM sont effacées.  |  Les données de la mémoire RAM sont effacées.  |  La mémoire RAM est enregistrée dans un fichier sur le volume racine.  |  Les données de la mémoire RAM sont effacées.  | 
|  Facturation  |  L'heure de facturation de l'instance ne change pas  |  Vous cessez d’être facturé aussitôt que l’état d’une instance devient `stopping`. Chaque fois qu’une instance passe de l’état `stopped` à l’état `running`, nous commençons une nouvelle période de facturation, en facturant un minimum d’une minute à chaque démarrage de l’instance.  |  Des frais vous sont facturés lorsque l’instance est à l’état `stopping`, mais ne le sont plus lorsque l’instance passe à l’état `stopped`. Chaque fois qu’une instance passe de l’état `stopped` à l’état `running`, nous commençons une nouvelle période de facturation, en facturant un minimum d’une minute à chaque démarrage de l’instance.  |  Vous cessez d’être facturé aussitôt que l’état d’une instance devient `shutting-down`  | 

Les commandes d’arrêt du système d’exploitation résilient toujours une instance basée sur le stockage d’instances. Vous pouvez contrôler si les commandes d’arrêt du système d’exploitation arrêtent ou résilient une instance dotée d’un volume racine EBS. Pour de plus amples informations, veuillez consulter [Modifier le comportement de l’arrêt initié par l’instance](Using_ChangingInstanceInitiatedShutdownBehavior.md).

# Arrêtez et démarrez des instances Amazon EC2
<a name="Stop_Start"></a>

Vous pouvez arrêter et démarrer votre instance si elle comporte un volume Amazon EBS comme volume racine. Lorsque vous arrêtez une instance, elle se ferme. Lorsque vous démarrez une instance, celle-ci est généralement migrée vers un nouvel ordinateur hôte sous-jacent et une nouvelle IPv4 adresse publique lui est attribuée.

Un arrêt d'instance peut être initié par l'utilisateur (où vous arrêtez manuellement l'instance) ou initié par AWS (en réponse à un événement d'arrêt planifié lorsqu'une défaillance irréparable de l'hôte sous-jacent de votre instance est AWS détectée).

Pour les arrêts initiés par l’utilisateur, nous vous recommandons d’utiliser la console, la CLI ou l’API Amazon EC2 au lieu d’exécuter la commande d’arrêt du système d’exploitation à partir de votre instance. Lorsque vous utilisez Amazon EC2, si l’instance ne s’arrête pas proprement au bout de quelques minutes, Amazon EC2 procède à un arrêt matériel. En outre, AWS CloudTrail crée un enregistrement API indiquant le moment où votre instance a été arrêtée.

Cette rubrique décrit comment effectuer un arrêt initié par l’utilisateur. Pour plus d'informations sur un arrêt effectué par AWS, voir[Gestion des instances Amazon EC2 dont l’arrêt ou la mise hors service est planifié](schedevents_actions_retire.md).

Lorsque vous arrêtez une instance, elle n’est pas supprimée. Si vous jugez que vous n’avez plus besoin d’une instance, vous pouvez y mettre fin. Pour de plus amples informations, veuillez consulter [Terminez l'instance Amazon EC2](terminating-instances.md). Si vous souhaitez mettre une instance en veille prolongée pour enregistrer le contenu de la mémoire de l’instance (RAM), consultez [Mettez en veille prolongée votre instance Amazon EC2](Hibernate.md). Pour connaître les différences entre les actions du cycle de vie des instances, consultez [Différences entre les états d'instance](ec2-instance-lifecycle.md#lifecycle-differences).

**Topics**
+ [Comment ça marche](how-ec2-instance-stop-start-works.md)
+ [Méthodes d’arrêt d’une instance](instance-stop-methods.md)
+ [Arrêter et démarrer manuellement](#starting-stopping-instances)
+ [Arrêter et démarrer automatiquement](#stop-start-ec2-instances-on-a-schedule)
+ [Trouver les instances en cours d’exécution et arrêtées](#find-running-and-stopped-instances-in-globalview)
+ [Identifiez les heures de lancement initiales et les plus récentes](#find-initial-launch-time)
+ [Activer la protection contre l’arrêt](ec2-stop-protection.md)

# Comment fonctionne l'arrêt et le démarrage d'une instance EC2
<a name="how-ec2-instance-stop-start-works"></a>

Lorsque vous arrêtez une instance Amazon EC2, les changements sont enregistrés au niveau du système d’exploitation (OS) de l’instance, certaines ressources sont perdues et d’autres perdurent. Lorsque vous démarrez une instance, les modifications sont enregistrées au niveau de l’instance.

**Topics**
+ [Ce qui se passe lorsque vous arrêtez une instance](#what-happens-stop)
+ [Ce qui se passe lorsque vous lancer une instance](#what-happens-start)
+ [Tester la réponse de l’application pour l’arrêt et le démarrage](#test-stop-start-instance)
+ [Coûts liés à l'arrêt et au démarrage de l'instance](#ec2-stop-start-costs)

## Ce qui se passe lorsque vous arrêtez une instance
<a name="what-happens-stop"></a>

Ce qui suit décrit ce qui se produit généralement lorsque vous arrêtez une instance à l’aide de la méthode d’arrêt par défaut. Notez que certains aspects peuvent varier en fonction de la [méthode d’arrêt](instance-stop-methods.md) que vous utilisez.

**Changements enregistrés au niveau du système d'exploitation**
+ La demande d’API envoie un événement d’appui sur un bouton à l’invité.
+ Divers services système sont arrêtés à la suite de l’événement d’appui sur le bouton. L’arrêt progressif du système d’exploitation est déclenché par l’appui sur le bouton d’arrêt ACPI de l’hyperviseur.
+ L’arrêt ACPI est lancé.
+ L’instance s’arrête lorsque le processus d’arrêt progressif du système d’exploitation se termine. L’heure d’arrêt du système d’exploitation n’est pas configurable.
+ Si le système d’exploitation d’instance ne s’arrête pas proprement en quelques minutes, un arrêt dur est effectué.
+ L’instance cesse de s’exécuter.
+ L’état de l’instance passe à `stopping`, puis à `stopped`.
+ [Auto Scaling] Si votre instance est un groupe Auto Scaling, lorsque l’instance se trouve dans un état Amazon EC2 autre que `running`, ou si son état pour les vérifications d’état passe à `impaired`, Amazon EC2 Auto Scaling considère que l’instance est défectueuse et la remplace. Pour plus d’informations, consultez [Surveillance de l’état pour les instances dans le groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
+ [Instances Windows] Lorsque vous arrêtez et démarrez une instance Windows, l’agent de lancement exécute des tâches sur l’instance, telles que la modification des lettres de lecteur pour les volumes Amazon EBS attachés. Pour plus d'informations sur ces valeurs par défaut et sur la manière de les modifier, consultez [Utiliser l’agent EC2Launch v2 pour effectuer des tâches lors du lancement d’une instance EC2 Windows](ec2launch-v2.md).

**Ressources perdues**
+ Les données stockées dans la RAM.
+ Les données stockées sur les volumes de stockage d’instances.
+ L’adresse IPv4 publique qu’Amazon EC2 a automatiquement attribuée à l’instance au lancement ou au démarrage. Pour conserver une IPv4 adresse publique qui ne change jamais, vous pouvez associer une [adresse IP élastique](elastic-ip-addresses-eip.md) à votre instance.

**Des ressources qui perdurent**
+ Tous les volumes de données et les volumes racines Amazon EBS attachés.
+ Les données stockées sur les volumes Amazon EBS.
+ Toutes les [interfaces réseau](using-eni.md) connectées.

  Une interface réseau comprend les ressources suivantes, qui persistent également :
  +  IPv4 Adresses privées.
  + IPv6 adresses.
  + Les adresses IP élastiques associées à l’instance. Veuillez noter que lorsque l’instance est arrêtée, nous [commençons à vous facturer les adresses IP Elastic associées](elastic-ip-addresses-eip.md#eip-pricing).

Le diagramme suivant illustre ce qui persiste et ce qui est perdu lorsqu’une instance EC2 est arrêtée. Le diagramme est divisé en trois parties : la première partie, intitulée **Instance EC2 en cours d’exécution**, montre l’instance dans l’état `running` avec ses ressources. La deuxième partie, intitulée **Instance EC2 arrêtée**, montre l’instance dans l’état `stopped` avec les ressources qui persistent. La troisième partie, intitulée **Perdu**, montre les ressources perdues lorsque l’instance est arrêtée.

![\[L' IPv4 adresse publique, la RAM et les données de stockage de l'instance sont perdues lorsqu'une instance est arrêtée.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/stop-instance.png)


Pour plus d'informations relatives à ce qui se passe lorsque vous arrêtez une instance Mac, consultez [Arrêtez ou mettez fin à votre instance Amazon EC2 Mac](mac-instance-stop.md).

## Ce qui se passe lorsque vous lancer une instance
<a name="what-happens-start"></a>
+ L’instance est généralement migrée vers un nouvel ordinateur hôte sous-jacent (même si, dans certains cas, comme lorsqu’une instance est allouée à un hôte dans une configuration [Hôte dédié](dedicated-hosts-understanding.md), elle reste sur l’hôte actuel).
+ Les volumes EBS et les interfaces réseau associés sont rattachés à l’instance.
+ Amazon EC2 attribue une nouvelle IPv4 adresse publique à l'instance si celle-ci est configurée pour recevoir une IPv4 adresse publique, sauf si elle possède une interface réseau secondaire ou une IPv4 adresse privée secondaire associée à une adresse IP élastique.
+ Si vous arrêtez une instance dans un groupe de placement, puis que vous la relancez, elle s’exécute encore au sein de celui-ci. Par contre, le démarrage échoue si la capacité est insuffisante pour l’instance. Si vous recevez une erreur de capacité lors du démarrage d'une instance dans un groupe de placement qui possède déjà des instances en cours d'exécution, arrêtez toutes les instances du groupe de placement et redémarrez-les toutes. Le redémarrage des instances peut entraîner leur migration vers un matériel qui dispose d’une capacité suffisante pour toutes les instances demandées.

## Tester la réponse de l’application pour l’arrêt et le démarrage
<a name="test-stop-start-instance"></a>

Vous pouvez l'utiliser AWS Fault Injection Service pour tester la façon dont votre application répond lorsque votre instance est arrêtée et démarrée. Pour plus d’informations, consultez le [Guide de l’utilisateur AWS Fault Injection Service](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html).

## Coûts liés à l'arrêt et au démarrage de l'instance
<a name="ec2-stop-start-costs"></a>

Les coûts suivants sont associés à l’arrêt et au démarrage d’une instance.

**Arrêt en cours** : dès que l’état d’une instance passe à `shutting-down` ou `terminated`, l’instance ne vous est plus facturée. Aucuns frais d’utilisation ou de transfert de données ne vous sont facturés pour une instance arrêtée. Des frais sont facturés pour stocker les volumes de stockage Amazon EBS. 

**Démarrage** : chaque fois que vous démarrez une instance arrêtée, nous facturons au minimum une minute d’utilisation. Après une minute, seules les secondes que vous utilisez vous sont facturées. Si, par exemple, vous exécutez une instance pendant 20 secondes, puis que vous l’arrêtez, nous vous facturons une minute complète. Si vous exécutez une instance pendant 3 minutes et 40 secondes, nous vous facturons exactement 3 minutes et 40 secondes d’utilisation.

# Méthodes d’arrêt d’une instance
<a name="instance-stop-methods"></a>

Il existe quatre méthodes pour effectuer un arrêt initié par l’utilisateur : l’arrêt par défaut, l’arrêt en ignorant l’arrêt du système d’exploitation, l’arrêt forcé et l’arrêt forcé en ignorant l’arrêt du système d’exploitation. Le tableau suivant compare les différences entre les deux options.


| Méthode d’arrêt | Objectif clé | Cas d’utilisation | Commande de la CLI | 
| --- | --- | --- | --- | 
| Arrêt par défaut | Arrêt normal de l’instance avec tentative d’arrêt progressif du système d’exploitation. | Arrêt d’instance typique. |  <pre>aws ec2 stop-instances \<br />--instance-id i-1234567890abcdef0</pre>  | 
| Arrêt en ignorant l’arrêt du système d’exploitation | Contourne l’arrêt progressif du système d’exploitation lors de l’arrêt d’une instance. | Lorsque le contournement de l’arrêt progressif du système d’exploitation est nécessaire. | <pre>aws ec2 stop-instances \<br />--instance-id i-1234567890abcdef0 \<br />--skip-os-shutdown</pre> | 
| Forcer l'arrêt | Gère les instances bloquées. Tente d’abord un arrêt par défaut ; si l’instance ne s’arrête pas, elle est arrêtée de force. | Lorsque l’instance est bloquée dans l’état stopping. | <pre>aws ec2 stop-instances \<br />--instance-id i-1234567890abcdef0 \<br />--force</pre> | 
| Arrêt forcé en ignorant l’arrêt du système d’exploitation | Arrêt forcé et contournement de l’arrêt progressif du système d’exploitation lors de l’arrêt d’une instance. | Lorsque l’arrêt forcé et le contournement de l’arrêt progressif du système d’exploitation sont nécessaires. | <pre>aws ec2 stop-instances \<br />--instance-id i-1234567890abcdef0 \<br />--force \<br />--skip-os-shutdown</pre> | 

Pour obtenir des instructions sur l’utilisation de chaque méthode, consultez les sections suivantes :
+ [Arrêt d’une instance avec un arrêt progressif du système d’exploitation](Stop_Start.md#stop-instance-with-graceful-os-shutdown)
+ [Arrêt d’une instance et contournement de l’arrêt progressif du système d’exploitation](Stop_Start.md#stop-instance-bypass-graceful-os-shutdown)
+ [Forcer l’arrêt d’une instance](TroubleshootingInstancesStopping.md#force-stop-instance)

**Topics**
+ [Arrêt par défaut](#ec2-instance-default-stop)
+ [Arrêt en ignorant l’arrêt du système d’exploitation](#ec2-instance-stop-with-skip-os-shutdown)
+ [Forcer l'arrêt](#ec2-instance-force-stop)
+ [Arrêt forcé en ignorant l’arrêt du système d’exploitation](#ec2-instance-force-stop-with-skip-os-shutdown)

Les sections suivantes fournissent des informations plus détaillées sur les quatre différentes méthodes d’arrêt initiées par l’utilisateur.

## Arrêt par défaut
<a name="ec2-instance-default-stop"></a>

La méthode d’arrêt par défaut est la méthode standard pour arrêter une instance. Lorsque vous émettez la StopInstances commande, l'instance passe de l'`running`état à`stopping`, puis enfin à`stopped`, comme l'illustre le schéma suivant :

![\[Flux de l’arrêt par défaut\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/stop-instance-flow-1.png)


**Objectif :** arrêt normal de l’instance avec tentative d’arrêt progressif du système d’exploitation.

**Impact sur les données :** préserve les données sur le volume racine et les volumes de données EBS. Perd les données sur le volume du stockage d’instances.

**Quand utiliser :** première tentative d’arrêt pour les arrêts habituels.

**Note**  
Si vous avez déjà tenté un arrêt en ignorant l’arrêt du système d’exploitation, une nouvelle tentative d’arrêt par défaut au cours de la même session de transition d’état n’entraînera pas d’arrêt progressif du système d’exploitation. Le contournement de l’arrêt progressif du système d’exploitation est irréversible pour la session en cours de l’instance.

## Arrêt en ignorant l’arrêt du système d’exploitation
<a name="ec2-instance-stop-with-skip-os-shutdown"></a>

Lorsqu’il est nécessaire de contourner l’arrêt progressif du système d’exploitation, la méthode d’arrêt en ignorant l’arrêt du système d’exploitation peut être utilisée pour arrêter une instance et contourner l’arrêt progressif du système d’exploitation, comme illustré dans le schéma suivant :

![\[Flux de l’arrêt en ignorant l’arrêt du système d’exploitation\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/stop-instance-flow-3.png)


**Avertissement**  
Le contournement de l'arrêt progressif du système d'exploitation peut entraîner une perte ou une corruption de données (par exemple, le contenu de la mémoire n'est pas transféré sur le disque ou une perte de mémoire en cours de vol IOs) ou l'omission de scripts d'arrêt.

**Objectif :** contourner l’arrêt progressif du système d’exploitation lors de l’arrêt d’une instance.

**Impact sur les données :** peut entraîner une perte ou une corruption des données. Il est possible que le contenu de la mémoire ne soit pas vidé sur le disque et qu'il IOs soit perdu en cours de vol. Les scripts d’arrêt peuvent être ignorés.

**Quand utiliser :** lorsque le contournement de l’arrêt progressif du système d’exploitation est nécessaire. S’il est utilisé alors qu’un arrêt par défaut avec arrêt progressif du système d’exploitation est en cours, l’arrêt progressif du système d’exploitation sera contourné.

**Note**  
Le contournement de l’arrêt progressif du système d’exploitation est irréversible pour la session de transition d’état actuelle de l’instance. Une tentative d’arrêt par défaut ultérieure au cours de cette session ne provoquera pas un arrêt progressif du système d’exploitation. 

## Forcer l'arrêt
<a name="ec2-instance-force-stop"></a>

La méthode d’arrêt forcé est utilisée pour gérer les instances bloquées dans l’état `stopping`. Une instance est généralement bloquée en raison d’un problème matériel sous-jacent (indiqué par un échec de la [vérification du statut du système](monitoring-system-instance-status-check.md#system-status-checks)).

La méthode d’arrêt forcé tente d’abord un arrêt par défaut. Si l’instance reste bloquée dans l’état `stopping`, le paramètre `force` arrête de force l’instance et fait passer l’instance à l’état `stopped`, comme indiqué dans le schéma suivant :

![\[Flux de l’arrêt forcé\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/stop-instance-flow-2.png)


**Objectif :** gère les instances bloquées dans l’état `stopping`. Tente d’abord un arrêt par défaut. Si l’instance ne parvient pas à s’arrêter, elle est arrêtée de force.

**Impact sur les données :** tente d’abord d’effectuer un arrêt par défaut, mais si l’arrêt forcé est effectué, cela peut entraîner une perte ou une corruption des données. Dans de rares cas, cela entraîne des écritures postérieures à l’arrêt sur des volumes EBS ou d’autres ressources partagées.

**Quand utiliser :** deuxième tentative d’arrêt lorsqu’une instance reste bloquée après un arrêt par défaut. Pour de plus amples informations, veuillez consulter [Résoudre les problèmes d'arrêt des EC2 instances Amazon](TroubleshootingInstancesStopping.md).

## Arrêt forcé en ignorant l’arrêt du système d’exploitation
<a name="ec2-instance-force-stop-with-skip-os-shutdown"></a>

Lorsque l’arrêt forcé et le contournement de l’arrêt progressif du système d’exploitation sont nécessaires, la méthode d’arrêt forcé en ignorant l’arrêt du système d’exploitation peut être utilisée pour amener une instance à l’état `stopped`, comme illustré dans le diagramme suivant :

![\[Flux de l’arrêt forcé en ignorant l’arrêt du système d’exploitation\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/stop-instance-flow-4.png)


**Objectif :** combine un arrêt forcé avec le contournement de l’arrêt progressif du système d’exploitation lors de l’arrêt d’une instance.

**Impact sur les données :** le contournement de l’arrêt du système d’exploitation peut entraîner la perte ou la corruption de données. Il est possible que le contenu de la mémoire ne soit pas vidé sur le disque et qu'il IOs soit perdu en cours de vol. Les scripts d’arrêt peuvent être ignorés. Si l’arrêt forcé se poursuit, cela peut entraîner une perte ou une corruption de données supplémentaires. Dans de rares cas, cela entraîne des écritures postérieures à l’arrêt sur les volumes EBS ou d’autres ressources partagées.

**Quand utiliser :** lorsque vous voulez être sûr que votre instance s’arrêtera et que vous souhaitez contourner l’arrêt progressif du système d’exploitation. S’il est utilisé alors qu’un arrêt par défaut avec arrêt progressif du système d’exploitation est en cours, l’arrêt progressif du système d’exploitation sera contourné.

## Arrêtez et démarrez manuellement vos instances
<a name="starting-stopping-instances"></a>

Vous pouvez arrêter et démarrer vos instances Amazon EBS (instances avec volumes racine EBS). Vous ne pouvez pas arrêter et démarrer les instances avec le volume racine de stockage d’instances.

Lorsque vous utilisez la méthode par défaut pour arrêter une instance, un arrêt progressif du système d’exploitation (OS) est tenté. Vous pouvez contourner l’arrêt progressif du système d’exploitation ; toutefois, cela peut mettre en danger l’intégrité des données. 

**Avertissement**  
Lorsque vous arrêtez une instance, les données contenues sur les volumes de stockage d’instance sont effacées. Avant d’arrêter une instance, vérifiez que vous avez copié toutes les données dont vous avez besoin à partir des volumes de stockage d’instance vers un stockage persistant, tel que Amazon EBS ou Amazon S3.

[Instances Linux] L’utilisation de la commande du système d’exploitation **halt** d’une instance ne déclenche pas un arrêt. Si vous utilisez la commande **halt**, l’instance n’est pas résiliée. Au lieu de cela, elle place le CPU à l’état `HLT`, ce qui suspend le fonctionnement du CPU. L’instance reste en cours d’exécution.

Vous pouvez déclencher un arrêt à l’aide des commandes **shutdown** ou **poweroff** du système d’exploitation. Lorsque vous utilisez une commande du système d’exploitation, l’instance s’arrête par défaut. Vous pouvez modifier ce comportement. Pour de plus amples informations, veuillez consulter [Modifier le comportement de l’arrêt initié par l’instance](Using_ChangingInstanceInitiatedShutdownBehavior.md).

**Note**  
Si vous avez arrêté une instance basée sur Amazon EBS et que celle-ci semble « bloquée » à l’état `stopping`, vous pouvez forcer son arrêt. Pour de plus amples informations, veuillez consulter [Résoudre les problèmes d'arrêt des EC2 instances Amazon](TroubleshootingInstancesStopping.md).

**Topics**
+ [Arrêt d’une instance avec un arrêt progressif du système d’exploitation](#stop-instance-with-graceful-os-shutdown)
+ [Arrêt d’une instance et contournement de l’arrêt progressif du système d’exploitation](#stop-instance-bypass-graceful-os-shutdown)
+ [Démarrer une instance](#start-ec2-instance)

### Arrêt d’une instance avec un arrêt progressif du système d’exploitation
<a name="stop-instance-with-graceful-os-shutdown"></a>

Vous pouvez arrêter une instance à l’aide de la méthode d’arrêt par défaut, qui inclut une tentative d’arrêt progressif du système d’exploitation. Pour de plus amples informations, veuillez consulter [Arrêt par défaut](instance-stop-methods.md#ec2-instance-default-stop).

------
#### [ Console ]

**Pour arrêter une instance à l’aide de la méthode d’arrêt par défaut**

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 **Instances**, puis sélectionnez l’instance.

1. Choisissez **État de l’instance**, **Arrêter l’instance**. Si cette option est désactivée, l’instance est déjà arrêtée ou son volume racine est un volume de stockage d’instances.

1. Lorsque vous êtes invité à confirmer l’opération, choisissez **Arrêter**. L’arrêt de l’instance peut prendre quelques minutes.

------
#### [ AWS CLI ]

**Pour arrêter une instance à l’aide de la méthode d’arrêt par défaut**  
Utilisez la commande [stop-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html).

```
aws ec2 stop-instances --instance-ids i-1234567890abcdef0
```

------
#### [ PowerShell ]

**Pour arrêter une instance à l’aide de la méthode d’arrêt par défaut**  
Utiliser l'[Stop-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Stop-EC2Instance.html)applet de commande 

```
Stop-EC2Instance -InstanceId i-1234567890abcdef0
```

------

### Arrêt d’une instance et contournement de l’arrêt progressif du système d’exploitation
<a name="stop-instance-bypass-graceful-os-shutdown"></a>

Vous pouvez contourner l’arrêt progressif du système d’exploitation lors de l’arrêt d’une instance. Pour de plus amples informations, veuillez consulter [Arrêt en ignorant l’arrêt du système d’exploitation](instance-stop-methods.md#ec2-instance-stop-with-skip-os-shutdown).

**Avertissement**  
Le contournement de l'arrêt progressif du système d'exploitation peut entraîner une perte ou une corruption de données (par exemple, le contenu de la mémoire n'est pas transféré sur le disque ou une perte de mémoire en cours de vol IOs) ou l'omission de scripts d'arrêt.

------
#### [ Console ]

**Pour arrêter une instance et contourner l’arrêt progressif du système d’exploitation**

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, sélectionnez **Instances**, puis choisissez l'instance.

1. Choisissez **État de l'instance**, **Arrêter l'instance**.

1. Sous **Ignorer l’arrêt du système d’exploitation**, cochez la case **Ignorer l’arrêt du système d’exploitation**. Si vous ne voyez pas cette option dans la console, c’est qu’elle n’est pas encore disponible dans la console dans la région actuelle. Vous pouvez toutefois accéder à cette fonctionnalité à l’aide du kit SDK AWS CLI ou essayer une autre région dans la console.

1. Choisissez **Arrêter**.

------
#### [ AWS CLI ]

**Pour arrêter une instance et contourner l’arrêt progressif du système d’exploitation**  
Utilisez la commande [stop-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html) avec `--skip-os-shutdown`.

```
aws ec2 stop-instances \
    --instance-ids i-1234567890abcdef0 \
    --skip-os-shutdown
```

------
#### [ PowerShell ]

**Pour arrêter une instance et contourner l’arrêt progressif du système d’exploitation**  
Utilisez l'[Stop-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Stop-EC2Instance.html)applet de commande avec. `-SkipOsShutdown $true`

```
Stop-EC2Instance `
    -InstanceId i-1234567890abcdef0 `
    -SkipOsShutdown $true
```

------

### Démarrer une instance
<a name="start-ec2-instance"></a>

Vous pouvez démarrer une instance arrêtée.

------
#### [ Console ]

**Pour démarrer une instance**

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, sélectionnez **Instances**.

1. Sélectionnez l’instance et choisissez **État de l’instance**, **Démarrer l’instance**.

   Il peut s’écouler quelques minutes avant que l’instance ne passe à l’état `running`.

------
#### [ AWS CLI ]

**Pour démarrer une instance**  
Utilisez la commande [start-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html).

```
aws ec2 start-instances --instance-ids i-1234567890abcdef0
```

------
#### [ PowerShell ]

**Pour démarrer une instance**  
Utilisez l’applet de commande [Start-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Start-EC2Instance.html).

```
Start-EC2Instance -InstanceId i-1234567890abcdef0
```

------

## Arrêter et démarrer automatiquement vos instances
<a name="stop-start-ec2-instances-on-a-schedule"></a>

Vous pouvez automatiser l’arrêt et le démarrage de vos instances à l’aide des services suivants : 

**Planificateur d'instance activé AWS**  
Vous pouvez utiliser le planificateur d'instance activé AWS pour automatiser le démarrage et l'arrêt des instances EC2. Pour plus d'informations, consultez [Comment utiliser le planificateur d'instance CloudFormation pour planifier des instances EC2](https://repost.aws/knowledge-center/stop-start-instance-scheduler) ? Notez que [des frais supplémentaires sont facturés](https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/cost.html). 

**AWS Lambda et une EventBridge règle Amazon**  
Vous pouvez utiliser Lambda et une EventBridge règle pour arrêter et démarrer vos instances selon un calendrier. Pour plus d’informations, consultez [Comment utiliser Lambda pour arrêter et démarrer des instances Amazon EC2 à intervalles réguliers ?](https://repost.aws/knowledge-center/start-stop-lambda-eventbridge)

**Amazon EC2 Auto Scaling**  
Pour vous assurer que vous disposez du bon nombre d’instances Amazon EC2 disponibles pour gérer la charge d’une application, créez des groupes Auto Scaling. Amazon EC2 Auto Scaling garantit que votre application dispose toujours de la bonne capacité pour gérer la demande de trafic et permet de réduire les coûts en lançant des instances uniquement lorsqu’elles sont nécessaires. Veuillez noter que Amazon EC2 Auto Scaling résilie les instances inutiles plutôt que de les arrêter. Pour configurer des groupes Auto Scaling, consultez [Commencer avec Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/get-started-with-ec2-auto-scaling.html) (français non garanti).

## Trouver toutes les instances en cours d’exécution et arrêtées
<a name="find-running-and-stopped-instances-in-globalview"></a>

Vous pouvez trouver toutes vos instances en cours d'exécution et arrêtées Régions AWS sur une seule page à l'aide d'[Amazon EC2 Global View](https://console.aws.amazon.com/ec2globalview/home). Cette capacité est particulièrement utile pour faire l’inventaire et rechercher les instances oubliées. Pour plus d’informations sur l’utilisation de Global View, consultez [Afficher les ressources dans toutes les régions à l'aide de AWS Global View](global-view.md).

Vous pouvez également exécuter une commande ou un applet de commande dans chaque région où vous avez des instances.

------
#### [ AWS CLI ]

**Pour obtenir le nombre d’instances EC2 dans une région**  
Utilisez la commande [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) suivante pour compter les instances dans la région actuelle. Vous devez exécuter cette commande dans chaque région où vous avez des instances.

```
aws ec2 describe-instances \
    --region us-east-2 \
    --query "length(Reservations[].Instances[])"
```

Voici un exemple de sortie.

```
27
```

**Pour obtenir des informations récapitulatives sur vos instances EC2 dans une région**  
Utilisez la commande [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) suivante. Vous devez exécuter cette commande dans chaque région où vous avez des instances.

```
aws ec2 describe-instances \
    --region us-east-2 \
    --query "Reservations[].Instances[].[InstanceId,InstanceType,PrivateIpAddress]" \
    --output table
```

Voici un exemple de sortie.

```
---------------------------------------------------------
|                   DescribeInstances                   |
+---------------------+---------------+-----------------+
|  i-0e3e777f4362f1bf7|  t2.micro     |  10.0.12.9      |
|  i-09453945dcf1529e9|  t2.micro     |  10.0.143.213   |
|  i-08fd74f3f1595fdbd|  m7i.4xlarge  |  10.0.1.103     |
+---------------------+---------------+-----------------+
```

------
#### [ PowerShell ]

**Pour obtenir le nombre d’instances EC2 dans une région**  
Utilisez l’applet de commande [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).

```
(Get-EC2Instance -Region us-east-2).Instances.Length
```

Voici un exemple de sortie.

```
27
```

**Pour obtenir des informations récapitulatives sur vos instances EC2 dans une région**  
Utilisez l’applet de commande [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html). Vous devez exécuter cette commande dans chaque région où vous avez des instances.

```
(Get-EC2Instance).Instances | Select InstanceId, InstanceType, PrivateIpAddress
```

Voici un exemple de sortie.

```
InstanceId          InstanceType PrivateIpAddress
----------          ------------ ----------------
i-0e3e777f4362f1bf7 t2.micro     10.0.12.9
i-09453945dcf1529e9 t2.micro     10.0.143.213
i-08fd74f3f1595fdbd m7i.4xlarge  10.0.1.103
```

------

## Identifiez les heures de lancement initiales et les plus récentes
<a name="find-initial-launch-time"></a>

Lorsque vous décrivez une instance, l'heure de lancement de l'instance est son heure de lancement la plus récente. Après avoir arrêté et démarré une instance, l'heure de lancement reflète l'heure de démarrage de la nouvelle instance. Pour connaître l'heure de lancement initial d'une instance, même après l'avoir arrêtée et démarrée, affichez l'heure à laquelle l'interface réseau principale a été attachée à l'instance.

------
#### [ Console ]

**Pour recherche l’heure de lancement la plus récente**  
Sélectionnez l’instance et recherchez **Heure de lancement** sous **Détails de l’instance** dans l’onglet **Détails**.

**Pour rechercher l’heure de lancement initiale**  
Sélectionnez l’instance et recherchez l’interface réseau principale (l’index du périphérique est 0) sous **Interfaces réseau** dans l’onglet **Mise en réseau**.

------
#### [ AWS CLI ]

**Pour rechercher l’heure de lancement initiale et l’heure de lancement la plus récente**  
Utilisez la commande [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) suivante pour afficher l’heure de lancement initiale et l’heure de lancement la plus récente de l’instance spécifiée.

```
aws ec2 describe-instances \
    --instance-id i-1234567890abcdef0 \
    --query 'Reservations[].Instances[].{InstanceID:InstanceId,InitialLaunch:NetworkInterfaces[0].Attachment.AttachTime,LastLaunch:LaunchTime}'
```

Voici un exemple de sortie.

```
[
    {
        "InstanceID": "i-1234567890abcdef0",
        "InitialLaunch": "2024-04-19T00:47:08+00:00",
        "LastLaunch": "2024-05-27T06:24:06+00:00"
    }
]
```

------
#### [ PowerShell ]

**Pour recherche l’heure de lancement la plus récente**  
Utilisez l’applet de commande [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).

```
(Get-EC2Instance -InstanceId i-1234567890abcdef0).Instances.LaunchTime
```

Voici un exemple de sortie.

```
Monday, May 27, 2024 6:24:06 AM
```

**Pour rechercher l’heure de lancement initiale**  
Utilisez l’applet de commande [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).

```
(Get-EC2Instance -InstanceId i-1234567890abcdef0).Instances.NetworkInterfaces.Attachment.AttachTime
```

Voici un exemple de sortie.

```
Friday, April 19, 2024 12:47:08 AM
```

------

# Activez la protection contre l'arrêt de vos instances EC2
<a name="ec2-stop-protection"></a>

Pour éviter qu’une instance ne soit arrêtée accidentellement, vous pouvez activer la protection contre l’arrêt de l’instance. La protection contre l’arrêt protège également votre instance contre la résiliation accidentelle. 

L'`DisableApiStop`attribut de l'[https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html)API Amazon EC2 détermine si l'instance peut être arrêtée à l'aide de la console Amazon EC2, de l'API Amazon EC2 ou de AWS CLI l'API Amazon EC2. Vous pouvez définir la valeur de cet attribut lorsque vous lancez l’instance, pendant l’exécution de l’instance ou une fois l’instance arrêtée.

**Considérations**
+ L’activation de la protection contre les arrêts ne vous empêche pas d’arrêter accidentellement une instance en déclenchant un arrêt à partir de l’instance à l’aide d’une commande du système d’exploitation telle que **shutdown** ou **poweroff**.
+ L'activation de la protection d'arrêt n' AWS empêche pas l'arrêt de l'instance lorsqu'un [événement planifié](monitoring-instances-status-check_sched.md) est prévu pour arrêter l'instance.
+ L’activation de la protection contre l’arrêt n’empêche pas Amazon EC2 Auto Scaling de résilier une instance lorsque celle-ci n’est pas saine ou pendant des événements de mise à l’échelle horizontale. Vous pouvez contrôler si un groupe Auto Scaling peut résilier une instance en particulier lors de la diminution de la taille en utilisant la [protection contre la diminution de la taille d’instance](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html). 
+ La protection anti-arrêt empêche non seulement l'arrêt accidentel de votre instance, mais également son arrêt accidentel lors de l'utilisation de la console ou de l'API. AWS CLI Cependant, cela ne définit pas automatiquement l’attribut `DisableApiTermination`. Notez que lorsque l'`DisableApiStop`attribut est défini sur`false`, le paramètre `DisableApiTermination` d'attribut détermine si l'instance peut être interrompue à l'aide de la console ou de l'API. AWS CLI Pour de plus amples informations, veuillez consulter [Terminez l'instance Amazon EC2](terminating-instances.md).
+ Vous ne pouvez pas activer la protection contre l’arrêt pour une instance avec un volume racine de stockage d’instance.
+ Vous ne pouvez pas activer la protection contre l’arrêt pour les instances Spot.
+ L’API Amazon EC2 suit un modèle de cohérence éventuel lorsque vous activez ou désactivez la protection contre l’arrêt. Cela signifie que le résultat de l’exécution de commandes pour définir l’attribut de protection contre l’arrêt peut ne pas être immédiatement visible pour toutes les commandes suivantes que vous exécuterez. Pour plus d’informations, consultez la section [Garantir l’idempotence](https://docs.aws.amazon.com/ec2/latest/devguide/eventual-consistency.html) dans le *Guide du développeur Amazon EC2*.

**Topics**
+ [Activer la protection contre l’arrêt d’une instance lors du lancement](#enable-stop-protection-at-launch)
+ [Activer la protection contre l’arrêt d’une instance en cours d’exécution ou arrêtée](#enable-stop-protection-on-running-or-stopped-instance)
+ [Désactivez la protection contre l’arrêt d’une instance en cours d’exécution ou arrêtée](#disable-stop-protection-on-running-or-stopped-instance)

## Activer la protection contre l’arrêt d’une instance lors du lancement
<a name="enable-stop-protection-at-launch"></a>

Vous pouvez activer la protection contre l’arrêt d’une instance au lancement de l’instance.

------
#### [ Console ]

**Pour activer la protection contre l’arrêt d’une instance lors du lancement**

1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Sur le tableau de bord, choisissez **Lancer une instance**.

1. Configurez votre instance dans le [nouvel assistant de lancement d’instance](ec2-launch-instance-wizard.md).

1. Dans l’assistant, activez la protection contre l’arrêt en choisissant **Activer** pour **Protection contre l’arrêt** sous **Détails avancés**.

------
#### [ AWS CLI ]

**Pour activer la protection contre l’arrêt d’une instance lors du lancement**  
Utilisez la commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) pour lancer une instance. Ajoutez le paramètre suivant.

```
--disable-api-stop
```

------
#### [ PowerShell ]

**Pour activer la protection contre l’arrêt d’une instance lors du lancement**  
Utilisez l'[New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)applet de commande pour lancer l'instance. Ajoutez le paramètre suivant.

```
-DisableApiStop $true
```

------

## Activer la protection contre l’arrêt d’une instance en cours d’exécution ou arrêtée
<a name="enable-stop-protection-on-running-or-stopped-instance"></a>

Vous pouvez activer la protection contre l’arrêt d’une instance lorsque l’instance est en cours d’exécution ou est arrêtée.

------
#### [ Console ]

**Pour activer la protection contre l’arrêt d’une instance**

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, sélectionnez **Instances**.

1. Sélectionnez l’instance, puis cliquez sur **Actions**>**Paramètres de l’instance**>**Modifier la protection contre l’arrêt**.

1. Cochez la case **Activer**, puis choisissez **Enregistrer**.

------
#### [ AWS CLI ]

**Pour activer la protection contre l’arrêt d’une instance**  
Utilisez la commande [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html).

```
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --disable-api-stop
```

------
#### [ PowerShell ]

**Pour activer la protection contre l’arrêt d’une instance**  
Utilisez l’applet de commande [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

```
Edit-EC2InstanceAttribute `
    -InstanceId i-1234567890abcdef0 `
    -DisableApiStop $true
```

------

## Désactivez la protection contre l’arrêt d’une instance en cours d’exécution ou arrêtée
<a name="disable-stop-protection-on-running-or-stopped-instance"></a>

Vous pouvez désactiver la protection contre l’arrêt d’une instance pour une instance en cours d’exécution ou arrêtée à l’aide d’une des méthodes suivantes.

------
#### [ Console ]

**Pour désactiver la protection contre l’arrêt d’une instance en cours d’exécution ou arrêtée**

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, sélectionnez **Instances**.

1. Sélectionnez l’instance, puis cliquez sur **Actions**, **Instance Settings (Paramètres de l’instance)** et **Change stop protection** (Modifier la protection contre l’arrêt).

1. Décochez la case **Activer**, puis choisissez **Enregistrer**.

------
#### [ AWS CLI ]

**Pour désactiver la protection contre l’arrêt d’une instance en cours d’exécution ou arrêtée**  
Utilisez la commande [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html).

```
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --no-disable-api-stop
```

------
#### [ PowerShell ]

**Pour désactiver la protection contre l’arrêt d’une instance**  
Utilisez l’applet de commande [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

```
Edit-EC2InstanceAttribute `
    -InstanceId i-1234567890abcdef0 `
    -DisableApiStop $false
```

------

# Mettez en veille prolongée votre instance Amazon EC2
<a name="Hibernate"></a>

Lorsque vous mettez une instance en veille prolongée, Amazon EC2 indique au système d'exploitation de procéder à l'hibernation (). suspend-to-disk La mise en veille prolongée enregistre le contenu de la mémoire (RAM) de l’instance sur votre volume racine Amazon Elastic Block Store (Amazon EBS). Amazon EC2 conserve le volume racine EBS de l’instance et les volumes de données EBS attachés. Lorsque votre instance est démarrée :
+ Le volume racine EBS est restauré à l’état précédent.
+ Le contenu de la mémoire RAM est chargé à nouveau.
+ Les processus qui s’exécutaient précédemment sur l’instance reprennent.
+ Les volumes de données précédemment attachés sont attachés à nouveau et l’instance conserve son ID d’instance.

Vous pouvez mettre une instance en veille prolongée uniquement si celle-ci est [activée pour la mise en veille prolongée](enabling-hibernation.md) et si elle répond aux [prérequis de mise en veille prolongée](hibernating-prerequisites.md).

Si les actions d’amorçage d’une instance ou d’une application et de création d’une empreinte mémoire afin de devenir complètement productive prennent du temps, vous pouvez utiliser la mise en veille prolongée pour préchauffer l’instance. Pour préchauffer l’instance, vous :

1. La lancez avec la mise en veille prolongée activée.

1. La placez dans l’état souhaité.

1. Mettez-la en veille prolongée afin qu’elle soit prête à reprendre à l’état désiré lorsque cela est nécessaire.

Vous ne payez ni l’utilisation d’une instance mise en veille de manière prolongée lorsque cette dernière est à l’état `stopped`, ni le transfert de données lorsque le contenu de la mémoire RAM est transféré vers le volume racine EBS. Vous payez le stockage de tout volume EBS, y compris le stockage du contenu de la mémoire RAM.

Si vous n’avez plus besoin d’une instance, vous pouvez la résilier à tout moment, y compris quand elle est à un état `stopped` (en veille prolongée). Pour de plus amples informations, veuillez consulter [Terminez l'instance Amazon EC2](terminating-instances.md).

**Topics**
+ [Comment ça marche](instance-hibernate-overview.md)
+ [Conditions préalables](hibernating-prerequisites.md)
+ [Configurer une AMI Linux pour qu'elle prenne en charge la mise en veille prolongée](hibernation-enabled-AMI.md)
+ [Activer la mise en veille prolongée de l’instance](enabling-hibernation.md)
+ [Désactiver KASLR sur une instance (Ubuntu uniquement)](hibernation-disable-kaslr.md)
+ [Mettre une instance en veille prolongée](hibernating-instances.md)
+ [Démarrer une instance mise en veille prolongée](hibernating-resuming.md)
+ [Dépannage](troubleshoot-instance-hibernate.md)

# Fonctionnement de la mise en veille prolongée des instances Amazon EC2
<a name="instance-hibernate-overview"></a>

Le diagramme suivant présente une vue d’ensemble du processus de mise en veille prolongée des instances EC2.

![\[Présentation du flux de la mise en veille prolongée.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/hibernation-flow.png)


## Que se passe-t-il lorsque vous mettez une instance en veille prolongée
<a name="how-instance-hibernation-works"></a>

Lorsque vous mettez en veille prolongée une instance en cours d’exécution, voici ce qui se produit :
+ L’instance passe à l’état `stopping`. Amazon EC2 indique au système d'exploitation de mettre en veille prolongée (). suspend-to-disk La mise en veille prolongée fige tous les processus, enregistre le contenu de la mémoire RAM sur le volume racine EBS, puis exécute un arrêt normal.
+ Lorsque l’arrêt est terminé, l’instance passe à l’état `stopped`.
+ Les volumes EBS restent attachés à l’instance et leurs données persistent, y compris le contenu enregistré de la mémoire RAM.
+ Tous les volumes de stockage d'instance Amazon EC2 restent attachés à l'instance, mais les données des volumes de stockage d'instances sont perdues.
+ L'instance est généralement migrée vers un nouvel ordinateur hôte sous-jacent lorsqu'elle démarre. Cela se produit également lorsque vous arrêtez et démarrez une instance.
+ Lorsque l’instance est démarrée, celle-ci démarre et le système d’exploitation lit le contenu de la mémoire RAM depuis le volume racine EBS avant de « défiger » les processus pour qu’ils reprennent leur état.
+ L'instance conserve ses IPv4 adresses privées et toutes IPv6 les adresses. Lorsque l'instance est démarrée, elle continue de conserver ses IPv4 adresses privées et toutes IPv6 les adresses.
+ Amazon EC2 publie l’adresse IPv4 publique. Lorsque l'instance est démarrée, Amazon EC2 lui attribue une nouvelle IPv4 adresse publique.
+ L’instance conserve les adresses IP Elastic qui lui sont associées. Les adresses IP Elastic qui sont associées à une instance mise en veille prolongée vous seront facturées.

Pour plus d’informations sur les différences entre la mise en veille prolongée, et le redémarrage, l’arrêt et la résiliation, consultez [Différences entre les états d'instance](ec2-instance-lifecycle.md#lifecycle-differences).

## Limitations
<a name="instance-hibernate-limitations"></a>
+ Lorsque vous mettez en veille une instance, les données contenues sur les volumes de stockage d’instances sont perdues.
+ (Instances Linux) Vous ne pouvez pas mettre en veille prolongée une instance Linux qui dispose de plus de 150 Gio de RAM.
+ (Instances Windows) Vous ne pouvez pas mettre en veille prolongée une instance Windows qui dispose de plus de 16 Gio de RAM.
+ Lorsque votre instance est en veille prolongée, vous ne pouvez pas la modifier. Cela se distingue d’une instance arrêtée qui n’est pas mise en veille prolongée, dans laquelle vous pouvez modifier certains attributs, tels que le type ou la taille d’instance.
+ Si vous créez un instantané ou une AMI à partir d’une instance qui est mise en veille prolongée ou dont la mise en veille prolongée est activée, il se peut que vous ne puissiez pas vous connecter à l’instance qui est lancée à partir de l’AMI ou d’une AMI créée à partir de l’instantané
+ (Instances Spot uniquement) Si Amazon EC2 met votre instance Spot en veille prolongée, seul Amazon EC2 peut relancer votre instance. Si vous mettez votre instance Spot en veille prolongée ([mise en veille prolongée à l’initiative de l’utilisateur](hibernating-instances.md)), vous pouvez la relancer. Une instance Spot mise en veille prolongée ne peut être relancée que si la capacité est disponible et si le prix Spot est inférieur ou égal au prix maximum spécifié.
+ Vous ne pouvez pas mettre en veille prolongée une instance faisant partie d’un groupe Auto Scaling ou utilisée par Amazon ECS. Si votre instance est dans un groupe Auto Scaling et que vous essayez de la mettre en veille prolongée, le service Amazon EC2 Auto Scaling marque l’instance arrêtée comme étant non saine, et peut la résilier et lancer une instance de remplacement. Pour plus d’informations, consultez la section [Surveillance de l’état pour les instances d’un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
+ Vous ne pouvez pas mettre en veille prolongée une instance configurée pour démarrer en mode UEFI avec l'option [UEFI Secure Boot](uefi-secure-boot.md) activée.
+ Si vous mettez en veille prolongée une instance qui a été lancée dans une Réservation de capacité, la Réservation de capacité ne garantit pas que l’instance mise en veille prolongée peut reprendre après avoir essayé de la démarrer.
+ Vous ne pouvez pas mettre en veille prolongée une instance qui utilise une version du noyau inférieure à 5.10 si le mode FIPS (Federal Information Processing Standard) est activé.
+ Nous ne prenons pas en charge la conservation d’une instance mise en veille prolongée au-delà de 60 jours. Pour conserver l’instance mise en veille prolongée au-delà de 60 jours, vous devez la démarrer, l’arrêter, puis la démarrer.
+ Nous mettons à jour en permanence notre plateforme avec des mises à niveau et des correctifs de sécurité qui peuvent être en conflit avec des instances mises en veille prolongée existantes. Nous vous avertissons des mises à niveau critiques qui nécessitent un démarrage des instances mises en veille prolongée pour que nous puissions effectuer un arrêt ou un redémarrage afin d’appliquer les mises à niveau et les correctifs de sécurité requis.

## Considérations relatives à la mise en veille prolongée d’une instance Spot
<a name="spot-hibernation-considerations"></a>
+ Si *vous* mettez votre instance Spot en veille prolongée, vous pouvez la redémarrer à condition que la capacité soit disponible et que le prix Spot soit inférieur ou égal au prix maximum spécifié.
+ Si *Amazon EC2* met en veille prolongée votre instance Spot : 
  + Seul Amazon EC2 peut relancer votre instance.
  + Amazon EC2 relance l’instance Spot mise en veille prolongée lorsque la capacité est disponible, avec un prix Spot inférieur ou égal au prix maximum spécifié.
  + Avant qu’Amazon EC2 ne mette en veille prolongée votre instance Spot, vous recevrez un avis d’interruption deux minutes avant le début de la mise en veille prolongée.

  Pour de plus amples informations, veuillez consulter [Interruptions d’instance Spot](spot-interruptions.md).

# Conditions préalables à la mise en veille prolongée des instances Amazon EC2
<a name="hibernating-prerequisites"></a>

Vous pouvez activer le support d’hibernation pour une instance à la demande ou une instance ponctuelle lorsque vous la lancez. Vous ne pouvez pas activer la mise en veille prolongée sur une instance existante, qu’elle soit en cours d’exécution ou arrêtée. Pour de plus amples informations, veuillez consulter [Activer la mise en veille prolongée de l’instance](enabling-hibernation.md).

**Topics**
+ [Régions AWS](#hibernation-prereqs-regions)
+ [AMIs](#hibernation-prereqs-supported-amis)
+ [Familles d’instances](#hibernation-prereqs-supported-instance-families)
+ [Taille de mémoire RAM d’instance](#instance-ram-size)
+ [Type de volume racine](#hibernation-prereqs-root-volume-type)
+ [Taille du volume racine](#hibernation-prereqs-ebs-root-volume-size)
+ [Chiffrement du volume racine](#hibernation-prereqs-ebs-root-volume-encryption)
+ [Type de volume EBS](#hibernation-prereqs-ebs-volume-types)
+ [Demandes d’instance Spot](#hibernation-prereqs-spot-request)

## Régions AWS
<a name="hibernation-prereqs-regions"></a>

Vous pouvez utiliser l'hibernation avec toutes Régions AWS les instances.

## AMIs
<a name="hibernation-prereqs-supported-amis"></a>

Vous devez utiliser une AMI HVM prenant en charge la mise en veille prolongée. Les options suivantes AMIs prennent en charge l'hibernation :

### Linux AMIs
<a name="hibernation-prereqs-supported-amis-linux"></a>

**AMIs pour les types d'instances Intel et AMD**
+ AL2023 AMI publié le 2023.09.20 ou version ultérieure ¹
+ AMI Amazon Linux 2 publiée le 29 août 2019 ou version ultérieure
+ AMI Amazon Linux de mars 2018 publiée le 16 novembre 2018 ou version ultérieure
+ AMI CentOS version 8\$1 ² ([Configuration supplémentaire](hibernation-enabled-AMI.md#configure-centos-for-hibernation) obligatoire)
+ AMI Fedora version 34 ou ultérieure ² ([Configuration supplémentaire](hibernation-enabled-AMI.md#configure-fedora-for-hibernation) obligatoire)
+ AMI Red Hat Enterprise Linux (RHEL) 9 ² ([Configuration supplémentaire](hibernation-enabled-AMI.md#configure-RHEL-for-hibernation) obligatoire)
+ AMI Red Hat Enterprise Linux (RHEL) 8 ² ([Configuration supplémentaire](hibernation-enabled-AMI.md#configure-RHEL-for-hibernation) obligatoire)
+ AMI Ubuntu 22.04.2 LTS (Jammy Jellyfish) publiée avec le numéro de série 20230303 ou une version ultérieure ³
+ AMI Ubuntu 20.04 LTS (Focal Fossa) publiée avec le numéro de série 20210820 ou une version ultérieure ³
+ AMI Ubuntu 18.04 LTS (Bionic Beaver) publiée avec le numéro de série 20190722.1 ou une version ultérieure ³ ⁵
+ AMI Ubuntu 16.04 LTS (Xenial Xerus) ³ ⁴ ⁵ ([Configuration supplémentaire](hibernation-enabled-AMI.md#configure-ubuntu1604-for-hibernation) obligatoire)

**AMIs pour les types d'instances Graviton**
+ AL2023 AMI (Arm 64 bits) publiée le 2024.07.01 ou version ultérieure ¹
+ AMI Amazon Linux 2 (Arm 64 bits) publiée le 20 juin 2024 ou une version ultérieure
+ Ubuntu 22.04.2 LTS (Arm 64 bits) (Jammy Jellyfish) AMI publiée avec le numéro de série 20240701 ou une version ultérieure ³
+ Ubuntu 20.04 LTS (Arm 64 bits) (Focal Fossa) AMI publiée avec le numéro de série 20240701 ou une version ultérieure ³

 

¹ Pour AL2023 une AMI minimale, [une configuration supplémentaire est requise](hibernation-enabled-AMI.md#configure-AL2023-minimal-for-hibernation).

² Pour CentOS, Fedora et Red Hat Enterprise Linux, la mise en veille prolongée n’est prise en charge que sur les instances Nitro.

³ Nous recommandons de désactiver KASLR sur les instances exécutant Ubuntu 22.04.2 LTS (Jammy Jellyfish), Ubuntu 20.04 LTS (Focal Fossa), Ubuntu 18.04 LTS (Bionic Beaver) et Ubuntu 16.04 LTS (Xenial Xerus). Pour de plus amples informations, veuillez consulter [Désactiver KASLR sur une instance (Ubuntu uniquement)](hibernation-disable-kaslr.md).

⁴ Pour l’AMI Ubuntu 16.04 LTS (Xenial Xerus), la mise en veille prolongée n’est pas prise en charge sur les types d’instance `t3.nano`. Aucun correctif ne sera disponible, car Ubuntu (Xenial Xerus) a mis fin au support en avril 2021. Si vous voulez utiliser les types d’instance `t3.nano`, nous vous recommandons une mise à niveau vers l’AMI Ubuntu 22.04.2 LTS (Jammy Jellyfish), Ubuntu 20.04 LTS (Focal Fossa) ou l’AMI Ubuntu 18.04 LTS (Bionic Beaver).

⁵ La prise en charge d’Ubuntu 18.04 LTS (Bionic Beaver) et Ubuntu 16.04 LTS (Xenial Xerus) est arrivée à son terme.

Pour configurer votre propre AMI afin de prendre en charge la mise en veille prolongée, consultez [Configurer une AMI Linux pour qu'elle prenne en charge la mise en veille prolongée](hibernation-enabled-AMI.md).

La prise en charge d’autres versions d’Ubuntu et d’autres systèmes d’exploitation sera bientôt disponible.

### Fenêtres AMIs
<a name="hibernation-prereqs-supported-amis-windows"></a>
+ AMI Windows Server 2022 publiée le 13/09/2023 ou version ultérieure
+ AMI Windows Server 2019 publiée le 11 septembre 2019 ou version ultérieure.
+ AMI Windows Server 2016 publiée le 11 septembre 2019 ou version ultérieure.
+ AMI Windows Server 2012 R2 publiée le 11 septembre 2019 ou version ultérieure.
+ AMI Windows Server 2012 publiée le 11 septembre 2019 ou version ultérieure.

## Familles d’instances
<a name="hibernation-prereqs-supported-instance-families"></a>

Vous devez utiliser une famille d’instances qui prend en charge l’hibernation. Les instances matériel nu ne sont pas prises en charge.
+ Usage général : M3, M4, M5, M5a, M5ad, M6d, M6a, M6g, M6gD, M6i, M6id, M6idn, M6in, M7a, M7g, M7GD, M7i, M7i-Flex, M8A, M8aZN, M8g, M8GB, M8Gd, M8GN, M8i, M8i-Flex, T2, T3, T3a, T4
+ Optimisé pour le calcul : C3, C4, C5, C5d, C6a, C6g, C6gD, C6gn, C6i, C6id, C6in, C7a, C7g, C7gd, C7gn, C7i, C7i-Flex, C8a, C8g, C8gD, C8gn, C8i, C8i-Flex
+ Mémoire optimisée : R3, R4, R5, R5a, R5d, R6a, R6g, R6gd, R6idn, R6in, R7a, R7g, R7gd, R7i, R7iz, R8a, R8g, R8GB, R8gD, R8gn, R8i, R8i-Flex, X2GD, X8aEDZ, X8i
+ Optimisées pour le stockage : I3, I3en, I4g, I7i, I7ie, I8g, I8ge, Im4gn, Is4gen

------
#### [ Console ]

**Pour obtenir les types d’instance qui prennent en charge la mise en veille prolongée**

1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Dans le volet de navigation, choisissez **Types d’instances**.

1. Ajoutez le filtre **On-Demand Hibernation support = true**.

1. (Facultatif) Ajoutez des filtres pour affiner davantage la recherche à des types d’instances spécifiques qui vous intéressent.

------
#### [ AWS CLI ]

**Pour obtenir les types d’instance qui prennent en charge la mise en veille prolongée**  
Utilisez la commande [describe-instance-types](https://docs.aws.amazon.com/cli/latest/reference/describe-instance-types/.html). Notez que les types d’instance disponibles varient selon la région.

```
aws ec2 describe-instance-types \
    --filters Name=hibernation-supported,Values=true \
    --query "InstanceTypes[*].[InstanceType]" \
    --output text | sort
```

------
#### [ PowerShell ]

**Pour obtenir les types d’instance qui prennent en charge la mise en veille prolongée**  
Utilisez l’applet de commande [Get-EC2InstanceType](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceType.html). Notez que les types d’instance disponibles varient selon la région.

```
(Get-EC2InstanceType `
    -Filter @{Name="hibernation-supported"; Values="true"}).InstanceType | Sort-Object
```

------

## Taille de mémoire RAM d’instance
<a name="instance-ram-size"></a>

**Instances Linux** : doit être inférieure à 150 Gio.

**Instances Windows** : doit être inférieure ou égale à 16 Gio. Pour la mise en veille prolongée d’une instance Windows T3 ou T3a, nous recommandons au moins 1 Gio de RAM.

## Type de volume racine
<a name="hibernation-prereqs-root-volume-type"></a>

Le volume racine doit être un volume EBS, et non un volume de stockage d’instance.

## Taille du volume racine
<a name="hibernation-prereqs-ebs-root-volume-size"></a>

Le volume racine doit être suffisamment grand pour stocker le contenu de la mémoire vive et s’adapter à l’utilisation prévue, par exemple le système d’exploitation ou les applications. Si vous activez la mise en veille prolongée, un espace est alloué sur le volume racine au lancement pour stocker la mémoire RAM.

## Chiffrement du volume racine
<a name="hibernation-prereqs-ebs-root-volume-encryption"></a>

Le volume racine doit être chiffré pour assurer la protection du contenu sensible qui se trouve en mémoire au moment de la mise en veille prolongée. Lorsque les données de la mémoire RAM sont transférées vers le volume racine EBS, celui-ci est toujours chiffré. Le chiffrement du volume racine est appliqué au lancement de l’instance.

L’une des trois options suivantes permet de s’assurer que le volume racine est une volume EBS chiffré :
+ **Chiffrement EBS par défaut** — Vous pouvez activer le chiffrement EBS par défaut pour vous assurer que tous les nouveaux volumes EBS créés dans votre AWS compte sont chiffrés. De cette façon, vous pouvez activer l’hibernation pour vos instances sans spécifier d’intention de chiffrement au moment du lancement de l’instance. Pour plus d’informations, consultez la section [Activer le chiffrement par défaut](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html).
+ **EBS "single-step" encryption** (Chiffrement EBS « en une étape »)  : vous pouvez lancer des instances EC2 chiffrées basées sur EBS depuis une AMI non chiffrée et activer la mise en veille prolongée en même temps. Pour plus d’informations, consultez [Utilisez le chiffrement avec EBS Backed AMIs](AMIEncryption.md).
+ **Encrypted AMI** (AMI chiffrée)  : vous pouvez activer le chiffrement EBS en utilisant une AMI chiffrée pour lancer votre instance. Si votre AMI ne dispose d’aucun volume racine chiffré, vous pouvez le copier sur le nouvel AMI et demander son chiffrement. Pour plus d’informations, consultez [Chiffrement d’une image non chiffrée pendant la copie](AMIEncryption.md#copy-unencrypted-to-encrypted) et [Copier une AMI](CopyingAMIs.md#ami-copy-steps).

## Type de volume EBS
<a name="hibernation-prereqs-ebs-volume-types"></a>

Les volumes EBS doivent utiliser l’un des types de volumes EBS suivants :
+ SSD à usage général (`gp2` et `gp3`)
+ SSD à IOPS provisionnés (`io1` et `io2`)

Si vous choisissez un type de volume SSD à IOPS provisionnés, vous devez provisionner le volume EBS avec les IOPS appropriées pour obtenir des performances optimales pour la mise en veille prolongée,. Pour plus d’informations, consultez [Types de volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) dans le *Guide de l’utilisateur Amazon EC2*.

## Demandes d’instance Spot
<a name="hibernation-prereqs-spot-request"></a>

Les exigences suivantes s’appliquent aux instances Spot :
+ Le type de la demande d’instance Spot doit être `persistent`.
+ Vous ne pouvez pas spécifier de groupe de lancement dans la demande d’instance Spot.

# Configurer une AMI Linux pour qu'elle prenne en charge la mise en veille prolongée
<a name="hibernation-enabled-AMI"></a>

Les AMI Linux suivantes peuvent prendre en charge la mise en veille prolongée d’une instance Amazon EC2, à condition que vous suiviez les étapes de configuration supplémentaires décrites dans cette section.

**Topics**
+ [AL2023 AMI minimale publiée le 2023.09.20 ou version ultérieure](#configure-AL2023-minimal-for-hibernation)
+ [AMI minimale Amazon Linux 2 publiée le 29 août 2019 ou version ultérieure](#configure-AL2-minimal-for-hibernation)
+ [Amazon Linux 2 publiées avant le 29.08.2019](#configure-AL2-for-hibernation)
+ [Amazon Linux 2 publiées avant le 16.11.2018](#configure-AL-for-hibernation)
+ [CentOS version 8 ou ultérieure](#configure-centos-for-hibernation)
+ [Fedora version 34 ou ultérieure](#configure-fedora-for-hibernation)
+ [Red Hat Enterprise Linux version 8 ou 9](#configure-RHEL-for-hibernation)
+ [Ubuntu 20.04 LTS (Focal Fossa) publié avant le numéro de série 20210820](#configure-ubuntu2004-for-hibernation)
+ [Ubuntu 18.04 (Bionic Beaver) publié avant le numéro de série 20190722.1](#configure-ubuntu1804-for-hibernation)
+ [Ubuntu 16.04 (Xenial Xenus)](#configure-ubuntu1604-for-hibernation)

Pour les systèmes Linux et Windows AMIs qui prennent en charge l'hibernation et pour lesquels *aucune configuration supplémentaire n'*est requise, consultez[AMIs](hibernating-prerequisites.md#hibernation-prereqs-supported-amis).

Pour plus d’informations, consultez la section [Mettre à jour le logiciel de l’instance sur votre instance Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/install-updates.html).

## AL2023 AMI minimale publiée le 2023.09.20 ou version ultérieure
<a name="configure-AL2023-minimal-for-hibernation"></a>

**Pour configurer une AMI AL2023 minimale publiée le 2023.09.20 ou une version ultérieure afin de prendre en charge l'hibernation**

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo dnf install ec2-hibinit-agent
   ```

1. Redémarrez le service .

   ```
   [ec2-user ~]$ sudo systemctl start hibinit-agent
   ```

## AMI minimale Amazon Linux 2 publiée le 29 août 2019 ou version ultérieure
<a name="configure-AL2-minimal-for-hibernation"></a>

**Pour configurer une AMI minimale Amazon Linux 2 publiée le 20 août 2019 ou ultérieurement afin de prendre en charge la mise en veille prolongée**

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo yum install ec2-hibinit-agent
   ```

1. Redémarrez le service .

   ```
   [ec2-user ~]$ sudo systemctl start hibinit-agent
   ```

## Amazon Linux 2 publiées avant le 29.08.2019
<a name="configure-AL2-for-hibernation"></a>

**Pour configurer une AMI Amazon Linux 2 publiée avant le 29.08.2019 afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `4.14.138-114.102` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo yum update kernel
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo yum install ec2-hibinit-agent
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `4.14.138-114.102` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

1. Arrêtez l’instance et créez une AMI. Pour de plus amples informations, veuillez consulter [Créer une AMI basée sur Amazon EBS](creating-an-ami-ebs.md).

## Amazon Linux 2 publiées avant le 16.11.2018
<a name="configure-AL-for-hibernation"></a>

**Pour configurer une AMI Amazon Linux 2 publiée avant le 16.11.2018 afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `4.14.77-70.59` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo yum update kernel
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo yum install ec2-hibinit-agent
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau est mise à jour vers `4.14.77-70.59` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

1. Arrêtez l’instance et créez une AMI. Pour de plus amples informations, veuillez consulter [Créer une AMI basée sur Amazon EBS](creating-an-ami-ebs.md).

## CentOS version 8 ou ultérieure
<a name="configure-centos-for-hibernation"></a>

**Pour configurer une AMI CentOS version 8 ou ultérieure afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `4.18.0-305.7.1.el8_4.x86_64` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo yum update kernel
   ```

1. Installez le référentiel Fedora Extra Packages for Enterprise Linux (EPEL).

   ```
   [ec2-user ~]$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo yum install ec2-hibinit-agent
   ```

1. Activez l’agent de mise en veille prolongée pour démarrer au démarrage.

   ```
   [ec2-user ~]$ sudo systemctl enable hibinit-agent.service
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `4.18.0-305.7.1.el8_4.x86_64` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

## Fedora version 34 ou ultérieure
<a name="configure-fedora-for-hibernation"></a>

**Pour configurer une AMI Fedora version 34 ou ultérieure afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `5.12.10-300.fc34.x86_64` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo yum update kernel
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo dnf install ec2-hibinit-agent
   ```

1. Activez l’agent de mise en veille prolongée pour démarrer au démarrage.

   ```
   [ec2-user ~]$ sudo systemctl enable hibinit-agent.service
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `5.12.10-300.fc34.x86_64` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

## Red Hat Enterprise Linux version 8 ou 9
<a name="configure-RHEL-for-hibernation"></a>

**Pour configurer une AMI Red Hat Enterprise Linux version 8 ou 9 afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `4.18.0-305.7.1.el8_4.x86_64` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo yum update kernel
   ```

1. Installez le référentiel Fedora Extra Packages for Enterprise Linux (EPEL).

   RHEL version 8 :

   ```
   [ec2-user ~]$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
   ```

   RHEL version 9 :

   ```
   [ec2-user ~]$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo yum install ec2-hibinit-agent
   ```

1. Activez l’agent de mise en veille prolongée pour démarrer au démarrage.

   ```
   [ec2-user ~]$ sudo systemctl enable hibinit-agent.service
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `4.18.0-305.7.1.el8_4.x86_64` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

## Ubuntu 20.04 LTS (Focal Fossa) publié avant le numéro de série 20210820
<a name="configure-ubuntu2004-for-hibernation"></a>

**Pour configurer une AMI Ubuntu LTS 20.04 (Focal Fossa) publiée avant le numéro de série 20210820 afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le linux-aws-kernel vers `5.8.0-1038.40` ou une version ultérieure, et grub2 vers `2.04-1ubuntu26.13` ou une version ultérieure.

   ```
   [ec2-user ~]$ sudo apt update
   [ec2-user ~]$ sudo apt dist-upgrade
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `5.8.0-1038.40` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

1. Vérifiez que la version de grub2 a été mise à jour vers `2.04-1ubuntu26.13` ou une version ultérieure.

   ```
   [ec2-user ~]$ dpkg --list | grep grub2-common
   ```

## Ubuntu 18.04 (Bionic Beaver) publié avant le numéro de série 20190722.1
<a name="configure-ubuntu1804-for-hibernation"></a>

**Pour configurer une AMI Ubuntu LTS 18.04 publiée avant le numéro de série 20190722.1 afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `4.15.0-1044` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo apt update
   [ec2-user ~]$ sudo apt dist-upgrade
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo apt install ec2-hibinit-agent
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `4.15.0-1044` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

## Ubuntu 16.04 (Xenial Xenus)
<a name="configure-ubuntu1604-for-hibernation"></a>

Pour configurer Ubuntu 16.04 LTS afin de prendre en charge l'hibernation, vous devez installer le package du linux-aws-hwe noyau version 4.15.0-1058-aws ou ultérieure et l'agent ec2-hibinit-agent.

**Important**  
Le package noyau `linux-aws-hwe` est pris en charge par Canonical. La prise en charge standard d’Ubuntu 16.04 LTS a pris fin en avril 2021 et le package ne reçoit plus de mises à jour régulières. Il recevra toutefois des mises à jour de sécurité supplémentaires jusqu’à ce que la prise en charge de la maintenance de sécurité étendue prenne fin en 2024. Pour plus d’informations, consultez [Amazon EC2 Hibernation for Ubuntu 16.04 LTS now available](https://ubuntu.com/blog/amazon-ec2-hibernation-for-ubuntu-16-04-lts-now-available) sur le blog Canonical Ubuntu.  
Nous vous recommandons une mise à niveau vers l’AMI Ubuntu 20.04 LTS (Focal Fossa) ou l’AMI Ubuntu 18.04 LTS (Bionic Beaver).

**Pour configurer une AMI Ubuntu 16.04 LTS afin de prendre en charge la mise en veille prolongée**

1. Mettez à jour le noyau vers `4.15.0-1058-aws` ou version ultérieure.

   ```
   [ec2-user ~]$ sudo apt update
   [ec2-user ~]$ sudo apt install linux-aws-hwe
   ```

1. Installez le package `ec2-hibinit-agent` à partir des référentiels.

   ```
   [ec2-user ~]$ sudo apt install ec2-hibinit-agent
   ```

1. Redémarrez l’instance.

   ```
   [ec2-user ~]$ sudo reboot
   ```

1. Vérifiez que la version du noyau a été mise à jour vers `4.15.0-1058-aws` ou une version ultérieure.

   ```
   [ec2-user ~]$ uname -a
   ```

# Activer la mise en veille prolongée pour une instance Amazon EC2
<a name="enabling-hibernation"></a>

Pour mettre en veille prolongée une instance, vous devez d’abord l’activer pour la mise en veille prolongée lors du lancement de l’instance.

**Important**  
Vous ne pouvez pas activer ou désactiver la mise en veille prolongée pour une instance après son lancement.

**Topics**
+ [Activer la mise en veille prolongée pour les instances à la demande](#enable-hibernation-for-on-demand-instances)
+ [Activer la mise en veille prolongée pour les instances Spot](#enable-hibernation-for-spot-instances)
+ [Voir si une instance est activée pour la mise en veille prolongée](#view-if-instance-is-enabled-for-hibernation)

## Activer la mise en veille prolongée pour les instances à la demande
<a name="enable-hibernation-for-on-demand-instances"></a>

Vous pouvez activer la mise en veille prolongée pour vos instances à la demande.

------
#### [ Console ]

**Pour activer la mise en veille prolongée pour une instance à la demande**

1. Suivez la procédure pour [lancer une instance](ec2-launch-instance-wizard.md), mais ne lancez l’instance qu’après avoir effectué les étapes suivantes pour activer l’hibernation.

1. Pour activer l’hibernation, configurez les champs suivants dans l’assistant de lancement de l’instance :

   1. Sous **Application and OS Images (Amazon Machine Image)** (Images d’applications et de systèmes d’exploitation), sélectionnez une AMI qui prend en charge la mise en veille prolongée. Pour de plus amples informations, veuillez consulter [AMIs](hibernating-prerequisites.md#hibernation-prereqs-supported-amis).

   1. Pour **Instance type** (Type d’Instance), sélectionnez un type d’instance pris en charge. Pour de plus amples informations, veuillez consulter [Familles d’instances](hibernating-prerequisites.md#hibernation-prereqs-supported-instance-families).

   1. Sous **Configure storage** (Configurer le stockage), choisissez **Advanced** (Avancé) (à droite), et spécifiez les informations suivantes pour le volume racine :
      + Pour **Taille (Go)**, saisissez la taille du volume EBS racine. Le volume doit être suffisamment grand pour stocker le contenu de la mémoire RAM et prendre en compte l’utilisation que vous prévoyez.
      + Sous **Volume type** (Type de volume), sélectionnez un type de volume EBS pris en charge : SSD à usage général (`gp2` et `gp3`) ou SSD IOPS provisionnés (`io1` et `io2`).
      + Pour **Encrypted** (Chiffré), choisissez **Yes** (Oui). Si vous avez activé le chiffrement par défaut dans cette AWS région, l'option **Oui** est sélectionnée.
      + Pour **KMS key** (Clé KMS), sélectionnez la clé de chiffrement pour le volume. Si vous avez activé le chiffrement par défaut dans cette AWS région, la clé de chiffrement par défaut est sélectionnée.

      Pour plus d’informations sur les prérequis relatifs au volume racine, consultez [Conditions préalables à la mise en veille prolongée des instances Amazon EC2](hibernating-prerequisites.md).

   1. Développez **Advanced details** (Détails avancés), et pour **Stop - Hibernate behavior** (Arrêt – Comportement de mise en veille prolongée), choisissez **Enable** (Activer).

1. Dans le panneau **Summary** (Résumé), vérifiez la configuration de votre instance, puis choisissez **Launch instance** (Lancer l’instance). Pour de plus amples informations, veuillez consulter [Lancez une instance EC2 à l’aide de l’assistant de lancement d’instance de la console](ec2-launch-instance-wizard.md).

------
#### [ AWS CLI ]

**Pour activer la mise en veille prolongée pour une instance à la demande**  
Utilisez la commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) pour lancer une instance. Spécifiez les paramètres du volume racine EBS à l’aide du paramètre `--block-device-mappings file://mapping.json` et activez la mise en veille prolongée à l’aide du paramètre `--hibernation-options Configured=true`.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type m5.large \
    --block-device-mappings file://mapping.json \
    --hibernation-options Configured=true \
    --count 1 \
    --key-name MyKeyPair
```

Spécifiez les éléments suivants dans `mapping.json`.

```
[
    {
        "DeviceName": "/dev/xvda",
        "Ebs": {
            "VolumeSize": 30,
            "VolumeType": "gp2",
            "Encrypted": true
        }
    }
]
```

La valeur de `DeviceName` doit correspondre au nom du périphérique racine associé à l’AMI. Pour trouver le nom du périphérique racine, utilisez la commande [describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) (décrire les images).

```
aws ec2 describe-images --image-id ami-0abcdef1234567890
```

Si vous avez activé le chiffrement par défaut dans cette AWS région, vous pouvez l'omettre`"Encrypted": true`.

------
#### [ PowerShell ]

**Pour activer la mise en veille prolongée pour une instance à la demande**  
Utilisez la [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)commande pour lancer une instance. Spécifiez le volume racine EBS en définissant d’abord le mappage au périphérique de stockage en mode bloc, puis en l’ajoutant à la commande à l’aide du paramètre `-BlockDeviceMappings`. Activez la mise en veille prolongée à l’aide du paramètre `-HibernationOptions_Configured $true`.

```
$ebs_encrypt = New-Object Amazon.EC2.Model.BlockDeviceMapping
$ebs_encrypt.DeviceName = "/dev/xvda"
$ebs_encrypt.Ebs = New-Object Amazon.EC2.Model.EbsBlockDevice
$ebs_encrypt.Ebs.VolumeSize = 30
$ebs_encrypt.Ebs.VolumeType = "gp2"
$ebs_encrypt.Ebs.Encrypted = $true

New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType m5.large `
    -BlockDeviceMappings $ebs_encrypt `
    -HibernationOptions_Configured $true `
    -MinCount 1 `
    -MaxCount 1 `
    -KeyName MyKeyPair
```

La valeur de `DeviceName` doit correspondre au nom du périphérique racine associé à l’AMI. Pour trouver le nom du périphérique racine, utilisez la [Get-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Image.html)commande.

```
Get-EC2Image -ImageId ami-0abcdef1234567890
```

Si vous avez activé le chiffrement par défaut dans cette AWS région, vous pouvez omettre le mappage `Encrypted = $true` des périphériques par blocs.

------

## Activer la mise en veille prolongée pour les instances Spot
<a name="enable-hibernation-for-spot-instances"></a>

Vous pouvez activer la mise en veille prolongée pour vos instances Spot. Pour plus d’informations sur la mise en veille prolongée des instances Spot en cas d’interruption, consultez la rubrique [Interruptions d’instance Spot](spot-interruptions.md).

------
#### [ Console ]

**Pour activer la mise en veille prolongée pour une instance Spot**

1. Suivez la procédure pour [demande une instance Spot à l’aide de l’assistant de lancement d’instance](using-spot-instances-request.md), mais ne lancez l’instance qu’après avoir effectué les étapes suivantes pour activer la mise en veille prolongée.

1. Pour activer l’hibernation, configurez les champs suivants dans l’assistant de lancement de l’instance :

   1. Sous **Application and OS Images (Amazon Machine Image)** (Images d’applications et de systèmes d’exploitation), sélectionnez une AMI qui prend en charge la mise en veille prolongée. Pour de plus amples informations, veuillez consulter [AMIs](hibernating-prerequisites.md#hibernation-prereqs-supported-amis).

   1. Pour **Instance type** (Type d’Instance), sélectionnez un type d’instance pris en charge. Pour de plus amples informations, veuillez consulter [Familles d’instances](hibernating-prerequisites.md#hibernation-prereqs-supported-instance-families).

   1. Sous **Configure storage** (Configurer le stockage), choisissez **Advanced** (Avancé) (à droite), et spécifiez les informations suivantes pour le volume racine :
      + Pour **Taille (Go)**, saisissez la taille du volume EBS racine. Le volume doit être suffisamment grand pour stocker le contenu de la mémoire RAM et prendre en compte l’utilisation que vous prévoyez.
      + Sous **Volume type** (Type de volume), sélectionnez un type de volume EBS pris en charge : SSD à usage général (`gp2` et `gp3`) ou SSD IOPS provisionnés (`io1` et `io2`).
      + Pour **Encrypted** (Chiffré), choisissez **Yes** (Oui). Si vous avez activé le chiffrement par défaut dans cette AWS région, l'option **Oui** est sélectionnée.
      + Pour **KMS key** (Clé KMS), sélectionnez la clé de chiffrement pour le volume. Si vous avez activé le chiffrement par défaut dans cette AWS région, la clé de chiffrement par défaut est sélectionnée.

      Pour plus d’informations sur les prérequis relatifs au volume racine, consultez [Conditions préalables à la mise en veille prolongée des instances Amazon EC2](hibernating-prerequisites.md).

   1. Développez **Détails avancés** et, en plus des champs de configuration d’une instance Spot, procédez comme suit :

      1. Pour **Type de demande**, choisissez **Persistente**.

      1. Pour **Comportement d’interruption**, choisissez **Mise en veille prolongée**. Sinon, pour **Comportement d’arrêt - mise en veille prolongée**, choisissez **Activer**. Les deux champs activent la mise en veille prolongée sur votre instance Spot. Vous devez uniquement configurer l’un de ces champs.

1. Dans le panneau **Summary** (Résumé), vérifiez la configuration de votre instance, puis choisissez **Launch instance** (Lancer l’instance). Pour de plus amples informations, veuillez consulter [Lancez une instance EC2 à l’aide de l’assistant de lancement d’instance de la console](ec2-launch-instance-wizard.md).

------
#### [ AWS CLI ]

**Pour activer la mise en veille prolongée pour une instance Spot**  
Utilisez la commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) pour demander une instance Spot. Spécifiez les paramètres du volume racine EBS à l’aide du paramètre `--block-device-mappings file://mapping.json` et activez la mise en veille prolongée à l’aide du paramètre `--hibernation-options Configured=true`. Le type de la demande Spot (`SpotInstanceType`) doit être `persistent`.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c4.xlarge \
    --block-device-mappings file://mapping.json \
    --hibernation-options Configured=true \
    --count 1 \
    --key-name MyKeyPair
    --instance-market-options
        {
           "MarketType":"spot",
           "SpotOptions":{
              "MaxPrice":"1",
              "SpotInstanceType":"persistent"
            }
        }
```

Spécifiez les paramètres du volume racine EBS dans `mapping.json` comme suit.

```
[
    {
        "DeviceName": "/dev/xvda",
        "Ebs": {
            "VolumeSize": 30,
            "VolumeType": "gp2",
            "Encrypted": true
        }
    }
]
```

La valeur de `DeviceName` doit correspondre au nom du périphérique racine associé à l’AMI. Pour trouver le nom du périphérique racine, utilisez la commande [describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) (décrire les images).

```
aws ec2 describe-images --image-id ami-0abcdef1234567890
```

Si vous avez activé le chiffrement par défaut dans cette AWS région, vous pouvez l'omettre`"Encrypted": true`.

------
#### [ PowerShell ]

**Pour activer la mise en veille prolongée pour une instance Spot**  
Utilisez la [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)commande pour demander une instance Spot. Spécifiez le volume racine EBS en définissant d’abord le mappage au périphérique de stockage en mode bloc, puis en l’ajoutant à la commande à l’aide du paramètre `-BlockDeviceMappings`. Activez la mise en veille prolongée à l’aide du paramètre `-HibernationOptions_Configured $true`.

```
$ebs_encrypt = New-Object Amazon.EC2.Model.BlockDeviceMapping
$ebs_encrypt.DeviceName = "/dev/xvda"
$ebs_encrypt.Ebs = New-Object Amazon.EC2.Model.EbsBlockDevice
$ebs_encrypt.Ebs.VolumeSize = 30
$ebs_encrypt.Ebs.VolumeType = "gp2"
$ebs_encrypt.Ebs.Encrypted = $true

New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType m5.large `
    -BlockDeviceMappings $ebs_encrypt `
    -HibernationOptions_Configured $true `
    -MinCount 1 `
    -MaxCount 1 `
    -KeyName MyKeyPair `
    -InstanceMarketOption @(
        MarketType = spot;
        SpotOptions @{
        MaxPrice = 1;
        SpotInstanceType = persistent}
    )
```

La valeur de `DeviceName` doit correspondre au nom du périphérique racine associé à l’AMI. Pour trouver le nom du périphérique racine, utilisez la [Get-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Image.html)commande.

```
Get-EC2Image -ImageId ami-0abcdef1234567890
```

Si vous avez activé le chiffrement par défaut dans cette AWS région, vous pouvez omettre le mappage `Encrypted = $true` des périphériques par blocs.

------

## Voir si une instance est activée pour la mise en veille prolongée
<a name="view-if-instance-is-enabled-for-hibernation"></a>

Vous pouvez vérifier si la mise en veille prolongée est activée pour une instance.

------
#### [ Console ]

**Pour voir si une instance est activée pour la mise en veille prolongée**

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 et, sous l’onglet **Détails** de la section **Détails de l’instance**, inspectez le **comportement Stop-hibernate**. La valeur **Enabled (Activé)** indique que l’instance est activée pour la mise en veille prolongée.

------
#### [ AWS CLI ]

**Pour voir si une instance est activée pour la mise en veille prolongée**  
Utilisez la commande [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) et spécifiez le paramètre `--filters "Name=hibernation-options.configured,Values=true"` pour filtrer les instances qui sont activées pour la mise en veille prolongée.

```
aws ec2 describe-instances \
    --filters "Name=hibernation-options.configured,Values=true"
```

Le champ suivant dans le résultat indique que l’instance est activée pour la mise en veille prolongée.

```
"HibernationOptions": {
    "Configured": true
}
```

------
#### [ PowerShell ]

**Pour voir si une instance est activée pour la mise en veille prolongée**  
Utilisez les instances d'[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html)applet de commande et de filtre activées pour l'hibernation.

```
(Get-EC2Instance `
    -Filter @{Name="hibernation-options.configured"; Values="true"}).Instances
```

------

# Désactiver KASLR sur une instance (Ubuntu uniquement)
<a name="hibernation-disable-kaslr"></a>

Pour exécuter une mise en veille prolongée sur une instance récemment lancée avec Ubuntu 16.04 LTS (Xenial Xerus), Ubuntu 18.04 LTS (Bionic Beaver) publiée avec le numéro de série 20190722.1 ou ultérieur ou Ubuntu 20.04 LTS (Focal Fossa) publiée avec le numéro de série 20210820 ou ultérieur, il est recommandé de désactiver KASLR (Kernel Address Space Layout Randomization). Sur Ubuntu 16.04 LTS, Ubuntu 18.04 LTS ou Ubuntu 20.04 LTS, KASLR est activé par défaut.

KASLR est une fonction de sécurité du noyau Linux standard qui permet d’atténuer l’exposition aux vulnérabilités d’accès à la mémoire pas encore découvertes, et leurs ramifications, en randomisant la valeur de l’adresse de base du noyau. En activant KASLR, il est possible que l’instance ne reprenne pas son exécution après sa mise en veille prolongée.

Pour en savoir plus sur KASLR, consultez la page relative aux [fonctionnalités d’Ubuntu](https://wiki.ubuntu.com/Security/Features).

**Pour désactiver KASLR sur une instance lancée avec Ubuntu**

1. Connectez-vous à votre instance à l’aide de SSH. Pour de plus amples informations, veuillez consulter [Se connecter à votre instance Linux à l’aide de SSH](connect-to-linux-instance.md).

1. Ouvrez le fichier `/etc/default/grub.d/50-cloudimg-settings.cfg` dans l’éditeur de votre choix. Éditez la ligne `GRUB_CMDLINE_LINUX_DEFAULT` de sorte à ajouter l’option `nokaslr` à la fin de la ligne, comme illustré dans l’exemple suivant.

   ```
   GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 nokaslr"
   ```

1. Enregistrez le fichier et quittez votre éditeur.

1. Exécutez la commande suivante pour recréer la configuration Grub.

   ```
   sudo update-grub
   ```

1. Redémarrez l’instance.

   ```
   sudo reboot
   ```

1. Exécutez la commande suivante pour confirmer que `nokaslr` a été ajouté.

   ```
   cat /proc/cmdline
   ```

   Le résultat de la commande doit inclure l’option `nokaslr`.

# Mettre en veille prolongée d’une instance Amazon EC2
<a name="hibernating-instances"></a>

Vous pouvez lancer la mise en veille prolongée sur une instance à la demande ou une instance Spot si l’instance est une instance basée sur EBS, si elle est [activée pour la mise en veille prolongée](enabling-hibernation.md) et si elle répond aux [prérequis de la mise en veille prolongée](hibernating-prerequisites.md). Si une instance ne peut pas être mise en veille prolongée, un arrêt normal a lieu.

------
#### [ Console ]

**Pour mettre une instance en veille prolongée**

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 une instance et choisissez **État de l’instance**, **Mettre en veille prolongée les instances**. Si **Mettre l’instance en veille prolongée** est désactivé, l’instance est déjà en veille prolongée ou arrêtée, ou elle ne peut pas être mise en veille prolongée. Pour plus d’informations, consultez [Conditions préalables à la mise en veille prolongée des instances Amazon EC2](hibernating-prerequisites.md).

1. Lorsque vous êtes invité à confirmer l’opération, choisissez **Mettre en veille prolongée**. La mise en veille prolongée de l’instance peut prendre quelques minutes. L’état de l’instance passe d’abord à **Stopping**(En cours d’arrêt), puis passe à **Stopped** (Arrêté(e)) lorsque l’instance est mise en veille prolongée.

------
#### [ AWS CLI ]

**Pour mettre une instance en veille prolongée**  
Utilisez la commande [stop-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html) et spécifiez le paramètre `--hibernate`.

```
aws ec2 stop-instances \
    --instance-ids i-1234567890abcdef0 \
    --hibernate
```

------
#### [ PowerShell ]

**Pour mettre une instance en veille prolongée**  
Utilisez l’applet de commande [Stop-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Stop-EC2Instance.html).

```
Stop-EC2Instance `
    -InstanceId i-1234567890abcdef0 `
    -Hibernate $true
```

------

Vous pouvez vérifier si la mise en veille prolongée a été initiée sur une instance.

------
#### [ Console ]

**Pour voir si la mise en veille prolongée est initiée sur une instance**

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 et, sous l’onglet **Détails** de la section **Détails de l’instance**, vérifiez la valeur du champ **Message de transition d’état**.

   **Cliente. UserInitiatedHibernate: La mise en veille prolongée initiée par l'utilisateur** indique que vous avez lancé l'hibernation sur l'instance à la demande ou l'instance ponctuelle.

------
#### [ AWS CLI ]

**Pour voir si la mise en veille prolongée est initiée sur une instance**  
Utilisez la commande [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) et spécifiez le filtre `state-reason-code` pour afficher les instances sur lesquelles la mise en veille prolongée est initiée.

```
aws ec2 describe-instances \
    --filters "Name=state-reason-code,Values=Client.UserInitiatedHibernate"
```

Le champ suivant dans le résultat indique que la mise en veille prolongée a été initiée sur l’instance à la demande ou sur l’instance Spot.

```
"StateReason": {
    "Code": "Client.UserInitiatedHibernate"
}
```

------
#### [ PowerShell ]

**Pour voir si la mise en veille prolongée est initiée sur une instance**  
Utilisez l'[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html)applet de commande et spécifiez le `state-reason-code` filtre pour voir les instances sur lesquelles l'hibernation a été initiée.

```
Get-EC2Instance `
    -Filter @{Name="state-reason-code";Value="Client.UserInitiatedHibernate"}
```

------

# Démarrer une instance Amazon EC2 mise en veille prolongée
<a name="hibernating-resuming"></a>

Démarrez une instance mise en veille prolongée comme vous le feriez pour une instance arrêtée.

Pour les instances Spot, si Amazon EC2 a mis l’instance en veille prolongée, seul Amazon EC2 peut la relancer. Vous ne pouvez relancer une instance Spot mise en veille prolongée que si *vous* êtes à l’origine de la mise en veille prolongée. Les instances Spot ne peuvent être relancées que si la capacité est disponible et si le prix Spot est inférieur ou égal au prix maximum spécifié.

------
#### [ Console ]

**Pour démarrer une instance mise en veille prolongée**

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 une instance mise en veille prolongée et choisissez **État de l’instance**, **Démarrer l’instance**. Il peut s’écouler quelques minutes avant que l’instance ne passe à l’état `running`. Pendant ce temps, les [contrôles de statut](monitoring-system-instance-status-check.md#types-of-instance-status-checks) de l’instance montrent l’instance à un état d’échec jusqu’à ce que l’instance ait démarré.

------
#### [ AWS CLI ]

**Pour démarrer une instance mise en veille prolongée**  
Utilisez la commande [start-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html).

```
aws ec2 start-instances --instance-ids i-1234567890abcdef0
```

------
#### [ PowerShell ]

**Pour démarrer une instance mise en veille prolongée**  
Utilisez l’applet de commande [Start-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Start-EC2Instance.html).

```
Start-EC2Instance -InstanceId i-1234567890abcdef0
```

------

# Résoudre les problèmes d’Mise en veille prolongée d’une instance Amazon EC2
<a name="troubleshoot-instance-hibernate"></a>

Utilisez ces informations pour diagnostiquer et résoudre les problèmes courants que vous pourriez rencontrer lors de la mise en veille prolongée d’une instance.

**Topics**
+ [Impossible d’effectuer une mise en veille prolongée immédiatement après le lancement](#hibernate-troubleshooting-1)
+ [Le passage de stopping à stopped prend du temps et l’état de la mémoire n’est pas restauré après le démarrage](#hibernate-troubleshooting-2)
+ [Instance « bloquée » à l’état stopping](#hibernate-troubleshooting-3)
+ [Impossible de démarrer l’instance Spot immédiatement après la mise en veille prolongée](#hibernate-troubleshooting-4)
+ [Échec de la reprise des instances Spot](#hibernate-troubleshooting-5)

## Impossible d’effectuer une mise en veille prolongée immédiatement après le lancement
<a name="hibernate-troubleshooting-1"></a>

Si vous essayez de mettre en veille prolongée une instance trop rapidement après l’avoir lancée, vous obtiendrez une erreur.

Vous devez patienter environ deux minutes pour les instances Linux et environ cinq minutes pour les instances Windows après le lancement avant de la mettre en veille prolongée.

## Le passage de stopping à stopped prend du temps et l’état de la mémoire n’est pas restauré après le démarrage
<a name="hibernate-troubleshooting-2"></a>

Si votre instance mise en veille prolongée prend du temps pour passer de l’état `stopping` à `stopped`, et si l’état de la mémoire n’est pas restauré après que vous avez démarré, cela peut indiquer que la mise en veille prolongée n’a pas été configurée correctement.

**Instances Linux**

Consultez le journal système de l’instance et recherchez les messages liés à la mise en veille prolongée. Pour accéder au journal système, [connectez-vous](connect-to-linux-instance.md) à l'instance ou utilisez la [get-console-output](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-console-output.html)commande. Recherchez les lignes de journal de l’agent `hibinit-agent`. Si les lignes de journal indiquent un échec ou si les lignes de journal sont manquantes, il est probable qu’un échec de la configuration de la mise en veille prolongée au lancement ait eu lieu.

Par exemple, le message suivant indique que le volume racine de l’instance n’est pas suffisamment grand : `hibinit-agent: Insufficient disk space. Cannot create setup for hibernation. Please allocate a larger root device.`

Si la dernière ligne de journal de `hibinit-agent` est `hibinit-agent: Running: swapoff /swap`, la mise en veille prolongée a été configurée avec succès.

Si vous ne voyez aucun journal issu de ces processus, votre AMI ne prend pas en charge la mise en veille prolongée. Pour plus d'informations sur la prise en charge AMIs, consultez[Conditions préalables à la mise en veille prolongée des instances Amazon EC2](hibernating-prerequisites.md). Si vous avez utilisé votre propre AMI Linux, assurez-vous d’avoir suivi les instructions pour [Configurer une AMI Linux pour qu'elle prenne en charge la mise en veille prolongée](hibernation-enabled-AMI.md).

**Windows Server 2016 et versions ultérieures**  
Consultez le journal de lancement de l’instance EC2 et recherchez les messages liés à la mise en veille prolongée. Pour accéder au journal de lancement de l’instance EC2, [connectez-vous](connecting_to_windows_instance.md) à l’instance et ouvrez le fichier `C:\ProgramData\Amazon\EC2-Windows\Launch\Log\Ec2Launch.log` dans un éditeur de texte. Si vous utilisez EC2 Launch v2, ouvrez`C:\ProgramData\Amazon\EC2Launch\log\agent.log`.

**Note**  
Par défaut, Windows masque les fichiers et les dossiers qui se trouvent sous `C:\ProgramData`. Pour afficher les fichiers et les répertoires de lancement de l’instance EC2, vous devez tapez le chemin d’accès dans l’Explorateur Windows ou modifier les propriétés de dossier afin d’afficher les fichiers et les dossiers masqués.

Recherchez les lignes de journal pour la mise en veille prolongée. Si les lignes de journal indiquent un échec ou si les lignes de journal sont manquantes, il est probable qu’un échec de la configuration de la mise en veille prolongée au lancement ait eu lieu.

Par exemple, le message suivant indique que la mise en veille prolongée n’a pas pu être configurée : `Message: Failed to enable hibernation.` si le message d’erreur inclut des valeurs ASCII décimales, vous pouvez convertir les valeurs ASCII en texte brut afin de lire le message d’erreur complet.

Si la ligne de journal contient `HibernationEnabled: true`, la mise en veille prolongée a été configurée avec succès.

**Windows Server 2012 R2 et versions antérieures**  
Consultez le journal de configuration de l’instance EC2 et recherchez les messages liés à la mise en veille prolongée. Pour accéder au journal de configuration de l’instance EC2, [connectez-vous](connecting_to_windows_instance.md) à l’instance et ouvrez le fichier `C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt` dans un éditeur de texte. Recherchez les lignes de journal pour `SetHibernateOnSleep`. Si les lignes de journal indiquent un échec ou si les lignes de journal sont manquantes, il est probable qu’un échec de la configuration de la mise en veille prolongée au lancement ait eu lieu.

Par exemple, le message suivant indique que le volume racine de l’instance n’est pas suffisamment grand : `SetHibernateOnSleep: Failed to enable hibernation: Hibernation failed with the following error: There is not enough space on the disk.`

Si la ligne de journal est `SetHibernateOnSleep: HibernationEnabled: true`, la mise en veille prolongée a été configurée avec succès.

**Taille de l’instance Windows**  
Si vous utilisez une instance Windows T3 ou T3a avec moins de 1 Gio de RAM, essayez de passer à une instance disposant d’au moins 1 Gio de RAM.

## Instance « bloquée » à l’état stopping
<a name="hibernate-troubleshooting-3"></a>

Si vous avez mis votre instance en veille prolongée que celle-ci semble « bloquée » à l’état `stopping`, vous pouvez forcer son arrêt. Pour de plus amples informations, veuillez consulter [Résoudre les problèmes d'arrêt des EC2 instances Amazon](TroubleshootingInstancesStopping.md).

## Impossible de démarrer l’instance Spot immédiatement après la mise en veille prolongée
<a name="hibernate-troubleshooting-4"></a>

Si vous essayez de démarrer une instance Spot dans les deux minutes suivant sa mise en veille prolongée, le message d’erreur suivant peut s’afficher :

`You failed to start the Spot Instance because the associated Spot Instance request is not in an appropriate state to support start.`

Attendez environ deux minutes pour les instances Linux et environ cinq minutes pour les instances Windows, puis réessayez de la démarrer.

## Échec de la reprise des instances Spot
<a name="hibernate-troubleshooting-5"></a>

Si votre instance Spot a été mise en veille prolongée avec succès, mais qu’elle n’a pas pu reprendre, et qu’elle a été redémarrée (un nouveau redémarrage où l’état de mise en veille prolongée n’est pas conservé), cela peut être dû au fait que les données utilisateur contenaient le script suivant :

```
/usr/bin/enable-ec2-spot-hibernation
```

Supprimez ce script du champ **Données utilisateur** du modèle de lancement, puis demandez une nouvelle instance Spot.

Notez que même si l’instance n’a pas pu reprendre, si l’état de mise en veille prolongée n’est pas préservé, l’instance peut toujours être démarrée de la même manière qu’en partant de l’état `stopped`.

# Redémarrez votre EC2 instance Amazon
<a name="ec2-instance-reboot"></a>

Le redémarrage d’une instance est similaire à celui d’un système d’exploitation. Dans la plupart des cas, il suffit de quelques minutes pour redémarrer votre instance.

Lorsque vous redémarrez une instance, elle conserve les éléments suivants :
+ Nom DNS public (IPv4)
+  IPv4 Adresse privée
+  IPv4 Adresse publique
+ IPv6 adresse (le cas échéant)
+ Toutes les données présentes sur ses volumes de stockage d’instance

Le redémarrage d’une instance ne démarre pas une nouvelle période de facturation de l’instance, contrairement à l’arrêt et au démarrage d’une instance (qui démarre une nouvelle période de facturation avec une facturation minimale d’une minute).[Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md)

Le redémarrage d'une instance peut être initié par l'utilisateur (lorsque vous redémarrez l'instance manuellement) ou par AWS (pour la restauration automatique de l'instance, ou en réponse à un événement de redémarrage planifié pour une maintenance nécessaire, par exemple pour appliquer des mises à jour nécessitant un redémarrage).

Pour les redémarrages initiés par l'utilisateur, nous recommandons d'utiliser EC2 la console, la CLI ou l'API Amazon au lieu d'exécuter la commande de redémarrage du système d'exploitation depuis votre instance. Lorsque vous utilisez Amazon EC2, si l'instance ne s'arrête pas correctement au bout de quelques minutes, Amazon EC2 effectue un redémarrage brutal. En outre, AWS CloudTrail crée un enregistrement API indiquant le moment où votre instance a été redémarrée.

Cette rubrique décrit comment effectuer un redémarrage initié par l’utilisateur. Pour plus d'informations sur les redémarrages effectués par AWS, reportez-vous aux sections [Récupération automatique des instances](ec2-instance-recover.md) et[Gestion des instances Amazon EC2 dont le redémarrage est planifié](schedevents_actions_reboot.md).

**Important**  
Si des mises à jour sont installées sur votre instance, nous vous recommandons de ne pas redémarrer ou arrêter votre instance à l'aide de la EC2 console Amazon ou de la ligne de commande tant que toutes les mises à jour ne sont pas installées. Lorsque vous utilisez la EC2 console Amazon ou la ligne de commande pour redémarrer ou arrêter votre instance, celle-ci risque d'être redémarrée de manière définitive. Un redémarrage matériel pendant l’installation de mises à jour peut entraîner l’instabilité de votre instance.

------
#### [ Console ]

**Pour redémarrer une instance**

1. Ouvrez la EC2 console Amazon à 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 et choisissez **Instance state** (État de l’instance), **Reboot instance** (Redémarrer l’instance).

1. Lorsque vous êtes invité à confirmer l’opération, sélectionnez **Redémarrer**.

   L’instance reste dans l’état `running`.

------
#### [ AWS CLI ]

**Pour redémarrer une instance**  
Utilisez la commande [reboot-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/reboot-instances.html).

```
aws ec2 reboot-instances --instance-ids i-1234567890abcdef0
```

------
#### [ PowerShell ]

**Pour redémarrer une instance**  
Utilisez l’applet de commande [Restart-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Restart-EC2Instance.html).

```
Restart-EC2Instance -InstanceId i-1234567890abcdef0
```

------

**Pour exécuter une expérience d’injection de défauts contrôlés**  
Vous pouvez l'utiliser AWS Fault Injection Service pour tester la façon dont votre application répond lorsque votre instance est redémarrée. Pour de plus amples informations, veuillez consulter le [Guide de l'utilisateur AWS Fault Injection Service](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html).

# Terminez l'instance Amazon EC2
<a name="terminating-instances"></a>

**Avertissement**  
**La résiliation d’une instance est définitive et irréversible.**  
Une fois que vous avez résilié une instance, vous ne pouvez plus vous y connecter et elle ne peut pas être récupérée. Tous les volumes Amazon EBS attachés qui sont configurés pour être supprimés à la résiliation sont également supprimés de manière définitive et ne peuvent pas être récupérés. L’intégralité des données stockées sur les volumes de stockage d’instance est définitivement perdue. Pour de plus amples informations, veuillez consulter [Comment fonctionne la résiliation d'une instance](how-ec2-instance-termination-works.md).  
Avant de résilier à une instance, assurez-vous d’avoir sauvegardé toutes les données que vous devez conserver après la résiliation dans un stockage persistant.

Vous pouvez supprimer votre instance lorsque vous n’en avez plus besoin. Cette opération est appelée *mise hors service* (ou résiliation) de votre instance. Dès que l’état d’une instance passe à `shutting-down` ou `terminated`, l’instance ne vous est plus facturée.

Vous ne pouvez pas vous connecter à une instance mise hors service, ni la démarrer. Toutefois, vous pouvez lancer de nouvelles instances à l’aide de la même AMI.

Si vous préférez arrêter votre instance ou la mettre en veille prolongée, consultez la section [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md) ou [Mettez en veille prolongée votre instance Amazon EC2](Hibernate.md). Pour de plus amples informations, veuillez consulter [Différences entre les états d'instance](ec2-instance-lifecycle.md#lifecycle-differences).

**Topics**
+ [Comment fonctionne la résiliation d'une instance](how-ec2-instance-termination-works.md)
+ [Méthodes de résiliation d’une instance](instance-terminate-methods.md)
+ [Résiliation d’une instance avec arrêt progressif du système d’exploitation](#terminating-instances-console)
+ [Résiliation d’une instance et contournement de l’arrêt progressif du système d’exploitation](#terminating-instances-bypass-graceful-os-shutdown)
+ [Résoudre les problèmes de résiliation d’instance](#troubleshoot-instance-terminate)
+ [Modification de la protection contre la résiliation d’instance](Using_ChangingDisableAPITermination.md)
+ [Modifier le comportement de l’arrêt initié par l’instance](Using_ChangingInstanceInitiatedShutdownBehavior.md)
+ [Conservation des données lors de la résiliation d’une instance](preserving-volumes-on-termination.md)

# Comment fonctionne la résiliation d'une instance
<a name="how-ec2-instance-termination-works"></a>

Lorsque vous résiliez une instance, les changements sont enregistrés au niveau du système d’exploitation (OS) de l’instance, certaines ressources sont perdues et d’autres perdurent.

Le schéma suivant montre ce qui est perdu et ce qui persiste lorsqu’une instance Amazon EC2 est résiliée. Lorsqu’une instance est résiliée, les données présentes sur les volumes de stockage d’instance et les données stockées dans la RAM d’instance sont effacées. Toutes les adresses IP élastiques associées à l'instance sont supprimées. Pour les volumes racine et les volumes de données Amazon EBS, le résultat dépend du paramètre **Supprimer à la résiliation** de chaque volume.

![\[Les adresses IP, la RAM, les volumes de stockage d'instance et le volume racine EBS sont perdus lorsqu'une instance est résiliée.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/terminate-instance.png)


## Considérations
<a name="terminate-instance-overview"></a>
+ **Persistance des données**
  + Volumes de stockage d’instance : toutes les données sont définitivement supprimées lorsque l’instance est résiliée. 
  + Volume racine EBS :
    + Si attaché lors du lancement, supprimé par défaut lorsque l’instance est résiliée.
    + Si attaché après le lancement, persiste par défaut lorsque l’instance est résiliée.
  + Volumes de données EBS :
    + Si attaché au lancement à l’aide de la console : persiste par défaut lorsque l’instance est résiliée.
    + Si attaché au lancement à l’aide de la CLI : supprimé par défaut lorsque l’instance est résiliée.
    + Si attaché après le lancement à l’aide de la console ou de la CLI : persiste par défaut lorsque l’instance est résiliée.
**Note**  
Tous les volumes qui ne sont pas supprimés lors de la résiliation de l’instance continuent de générer des frais. Vous pouvez modifier le paramètre pour qu’un volume soit supprimé ou qu’il soit conservé lors de la fermeture de l’instance. Pour de plus amples informations, veuillez consulter [Conservation des données lors de la résiliation d’une instance](preserving-volumes-on-termination.md).
+ **Protection contre les interruptions accidentelles**
  + Pour éviter qu'une instance ne soit accidentellement arrêtée par quelqu'un, [activer la protection contre la résiliation](Using_ChangingDisableAPITermination.md) pour l’instance.
  + Pour déterminer si une instance s'arrête ou est résiliée lorsque l'arrêt est initié depuis l'instance, modifier l'instance [comportement d'arrêt lancé par l'instance](Using_ChangingInstanceInitiatedShutdownBehavior.md).
+ **Scripts d’arrêt** : si vous exécutez un script à la résiliation de l’instance, la résiliation de votre instance risque d’être anormale, car il n’existe aucun moyen de s’assurer que les scripts d’arrêt s’exécutent. Amazon EC2 tente d’arrêter proprement une instance et d’exécuter tous les scripts d’arrêt du système ; cependant, certains événements (tels qu’une défaillance matérielle) peuvent empêcher l’exécution de ces scripts d’arrêt du système.
+ **Instances matériel nu** : les instances matériel nu x86 ne prennent pas en charge l’arrêt coopératif.

## Ce qui se passe lorsque vous résiliez une instance
<a name="what-happens-terminate"></a>

**Changements enregistrés au niveau du système d'exploitation**
+ La demande d’API envoie un événement d’appui sur un bouton à l’invité.
+ Divers services système sont arrêtés à la suite de l’événement d’appui sur le bouton. L'arrêt progressif du système est assuré par **systemd** (Linux) ou par le processus système (Windows). L’arrêt normal est déclenché par l’événement d’appui sur un bouton d’arrêt ACPI à partir de l’hyperviseur.
+ L’arrêt ACPI est lancé.
+ L’instance s’arrête après la fin du processus d’arrêt progressif. L’heure d’arrêt du système d’exploitation n’est pas configurable. L’instance reste visible dans la console pendant une courte période, puis l’entrée est automatiquement supprimée.

**Ressources perdues**
+ Les données stockées sur les volumes de stockage d’instances.
+ Volume racine EBS si l’attribut `DeleteOnTermination` est défini sur `true`.
+ Volumes de données EBS (attachés au lancement ou après) si l’attribut `DeleteOnTermination` est défini sur `true`.

**Des ressources qui perdurent**
+ Volume racine EBS si l’attribut `DeleteOnTermination` est défini sur `false`.
+ Volumes de données EBS (attachés au lancement ou après) si l’attribut `DeleteOnTermination` est défini sur `false`.

## Test de la réponse de l’application à la résiliation d’instance
<a name="test-terminate-instance"></a>

Vous pouvez l'utiliser AWS Fault Injection Service pour tester la façon dont votre application réagit lorsque votre instance est arrêtée. Pour plus d’informations, consultez le [Guide de l’utilisateur AWS Fault Injection Service](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html).

# Méthodes de résiliation d’une instance
<a name="instance-terminate-methods"></a>

**Avertissement**  
**La résiliation d’une instance est définitive et irréversible.**  
Une fois que vous avez résilié une instance, vous ne pouvez plus vous y connecter et elle ne peut pas être récupérée. Tous les volumes Amazon EBS attachés qui sont configurés pour être supprimés à la résiliation sont également supprimés de manière définitive et ne peuvent pas être récupérés. L’intégralité des données stockées sur les volumes de stockage d’instance est définitivement perdue. Pour de plus amples informations, veuillez consulter [Comment fonctionne la résiliation d'une instance](how-ec2-instance-termination-works.md).  
Avant de résilier à une instance, assurez-vous d’avoir sauvegardé toutes les données que vous devez conserver après la résiliation dans un stockage persistant.

Il existe quatre méthodes pour résilier une instance initiée par l’utilisateur : résiliation par défaut, résiliation en ignorant l’arrêt du système d’exploitation, résiliation forcée et résiliation forcée en ignorant l’arrêt du système d’exploitation. Le tableau suivant compare les principales différences entre les méthodes de résiliation :

**Note**  
Vous ne pouvez pas résilier une instance si la protection contre la résiliation est activée. Pour plus d’informations, consulter la section [Modification de la protection contre la résiliation d’instance](Using_ChangingDisableAPITermination.md).


| Méthode de résiliation | Objectif clé | Cas d’utilisation | Commande de la CLI | 
| --- | --- | --- | --- | 
| Résiliation par défaut | Arrêt normal de l’instance avec tentative d’arrêt progressif du système d’exploitation. | Résiliation d’instance typique | <pre>aws ec2 terminate-instances \<br />--instance-id i-1234567890abcdef0</pre> | 
| Résiliation en ignorant l’arrêt du système d’exploitation | Contourne l’arrêt progressif du système d’exploitation lors de la résiliation d’une instance. | Lorsque le contournement de l’arrêt progressif du système d’exploitation est nécessaire. | <pre>aws ec2 terminate-instances \<br />--instance-id i-1234567890abcdef0 \<br />--skip-os-shutdown</pre> | 
| Résiliation forcée | Gère les instances bloquées. Tente d’abord de résilier l’instance par défaut ; si l’instance ne parvient pas à s’arrêter, elle est résiliée de force. | Lorsque l’instance est bloquée dans l’état shutting-down. | <pre>aws ec2 terminate-instances \<br />--instance-id i-1234567890abcdef0 \<br />--force</pre> | 
| Résiliation forcée en ignorant l’arrêt du système d’exploitation | Force la résiliation et contourne l’arrêt progressif du système d’exploitation lors de la résiliation d’une instance. | Lorsque la résiliation forcée et le contournement de l’arrêt progressif du système d’exploitation sont nécessaires. | <pre>aws ec2 terminate-instances \<br />--instance-id i-1234567890abcdef0 \<br />--force \<br />--skip-os-shutdown</pre> | 

Pour obtenir des instructions sur l’utilisation de chaque méthode, consultez les sections suivantes :
+ [Résiliation d’une instance avec arrêt progressif du système d’exploitation](terminating-instances.md#terminating-instances-console)
+ [Résiliation d’une instance et contournement de l’arrêt progressif du système d’exploitation](terminating-instances.md#terminating-instances-bypass-graceful-os-shutdown)
+ [Résiliation forcée d’une instance](TroubleshootingInstancesShuttingDown.md#force-terminate-ec2-instance)

## Résiliation d’une instance avec arrêt progressif du système d’exploitation
<a name="terminating-instances-console"></a>

Vous pouvez résilier une instance à l’aide de la méthode de résiliation par défaut, qui inclut une tentative d’arrêt progressif du système d’exploitation. Pour de plus amples informations, veuillez consulter [Méthodes de résiliation d’une instance](instance-terminate-methods.md).

------
#### [ Console ]

**Pour résilier une instance à l’aide de la méthode de résiliation par défaut**

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, et choisissez **État de l’instance**, **Résilier (supprimer) l’instance**.

1. Lorsque vous êtes invité à confirmer, choisissez **Résilier (supprimer)**.

1. Après avoir résilié une instance, celle-ci reste visible pendant un court laps de temps, avec un état de `terminated`.

   Si la résiliation échoue ou si une instance interrompue est visible pendant plus de quelques heures, consultez [Instance terminée toujours affichée](TroubleshootingInstancesShuttingDown.md#terminated-instance-still-displaying).

------
#### [ AWS CLI ]

**Pour résilier une instance à l’aide de la méthode de résiliation par défaut**  
Utilisez la commande [terminate-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/terminate-instances.html).

```
aws ec2 terminate-instances --instance-ids i-1234567890abcdef0
```

------
#### [ PowerShell ]

**Pour résilier une instance à l’aide de la méthode de résiliation par défaut**  
Utilisez l’applet de commande [Remove-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2Instance.html).

```
Remove-EC2Instance -InstanceId i-1234567890abcdef0
```

------

## Résiliation d’une instance et contournement de l’arrêt progressif du système d’exploitation
<a name="terminating-instances-bypass-graceful-os-shutdown"></a>

Vous pouvez contourner l’arrêt progressif du système d’exploitation lors de la résiliation d’une instance. Pour de plus amples informations, veuillez consulter [Méthodes de résiliation d’une instance](instance-terminate-methods.md).

------
#### [ Console ]

**Pour résilier une instance et contourner l’arrêt progressif du système d’exploitation**

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, et choisissez **État de l’instance**, **Résilier (supprimer) l’instance**.

1. Sous **Ignorer l’arrêt du système d’exploitation**, cochez la case **Ignorer l’arrêt du système d’exploitation**. Si vous ne voyez pas cette option dans la console, c’est qu’elle n’est pas encore disponible dans la console dans la région actuelle. Vous pouvez toutefois accéder à cette fonctionnalité à l'aide du SDK AWS CLI ou essayer une autre région dans la console.

1. Choisissez **Résilier (supprimer)**.

1. Après avoir résilié une instance, celle-ci reste visible pendant un court laps de temps, avec un état de `terminated`.

   Si la résiliation échoue ou si une instance interrompue est visible pendant plus de quelques heures, consultez [Instance terminée toujours affichée](TroubleshootingInstancesShuttingDown.md#terminated-instance-still-displaying).

------
#### [ AWS CLI ]

**Pour résilier une instance et contourner l’arrêt progressif du système d’exploitation**  
Pour ce faire, utilisez la commande [terminate-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/terminate-instances.html) avec `--skip-os-shutdown`.

```
aws ec2 terminate-instances \
    --instance-ids i-1234567890abcdef0 \
    --skip-os-shutdown
```

------
#### [ PowerShell ]

**Pour résilier une instance et contourner l’arrêt progressif du système d’exploitation**  
Utilisez l'[Remove-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2Instance.html)applet de commande avec... `-SkipOsShutdown $true`

```
Remove-EC2Instance `
    -InstanceId i-1234567890abcdef0 `
    -SkipOsShutdown $true
```

------

## Résoudre les problèmes de résiliation d’instance
<a name="troubleshoot-instance-terminate"></a>

Le demandeur doit être autorisé à appeler `ec2:TerminateInstances`. Pour plus d'informations, consultez [Exemples de politiques pour travailler avec les instances](ExamplePolicies_EC2.md#iam-example-instances).

Si vous arrêtez votre instance et qu’une autre instance démarre, vous avez probablement configuré la mise à l’échelle automatique via une fonctionnalité comme flotte EC2 ou Amazon EC2 Auto Scaling. Pour de plus amples informations, veuillez consulter [instances lancées ou terminées automatiquement](TroubleshootingInstancesShuttingDown.md#automatic-instance-create-or-delete).

**Note**  
Vous ne pouvez pas résilier une instance si la protection contre la résiliation est activée. Pour plus d’informations, consulter la section [Modification de la protection contre la résiliation d’instance](Using_ChangingDisableAPITermination.md).

Si votre instance reste dans l’état `shutting-down` plus longtemps que d’habitude, vous pouvez essayer de la résilier de force. Si elle reste dans l’état `shutting-down`, elle doit être nettoyée (résiliée) par des processus automatisés au sein du service Amazon EC2. Pour de plus amples informations, veuillez consulter [Mise à fin d'instance retardée](TroubleshootingInstancesShuttingDown.md#instance-stuck-terminating).

# Modification de la protection contre la résiliation d’instance
<a name="Using_ChangingDisableAPITermination"></a>

Pour éviter que votre instance ne soit accidentellement résiliée à l’aide de l’API Amazon EC2, que vous appeliez `TerminateInstances` directement ou que vous utilisiez une autre interface telle que la console Amazon EC2, activez la *protection contre le résiliation* pour l’instance. L’attribut `DisableApiTermination` détermine si l’instance peut être résiliée. Par défaut, la protection contre la résiliation est désactivée pour votre instance. Vous pouvez définir la valeur de cet attribut lorsque vous lancez une instance, ou lorsque l’instance est en cours d’exécution ou arrêtée.

L’attribut `DisableApiTermination` ne vous empêche pas de résilier une instance en déclenchant l’arrêt à partir de l’instance (par exemple, à l’aide d’une commande du système d’exploitation pour l’arrêt système) lorsque l’attribut `InstanceInitiatedShutdownBehavior` est défini sur `terminate`. Pour de plus amples informations, veuillez consulter [Modifier le comportement de l’arrêt initié par l’instance](Using_ChangingInstanceInitiatedShutdownBehavior.md).

**Considérations**
+ L'activation de la protection contre la résiliation n' AWS empêche pas de mettre fin à l'instance lorsqu'un [événement planifié est prévu](monitoring-instances-status-check_sched.md) pour mettre fin à l'instance.
+ L’activation de la protection contre la résiliation n’empêche pas Amazon EC2 Auto Scaling de résilier une instance lorsque celle-ci est défectueuse ou pendant des événements de mise à l’échelle horizontale. Vous pouvez contrôler si un groupe Auto Scaling peut résilier une instance en particulier lors de la mise à l’échelle en utilisant la [protection contre la mise à l’échelle horizontale de l’instance](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html). Vous pouvez contrôler si un groupe Auto Scaling peut résilier des instances défectueuses en [suspendant le processus de mise à l’échelle ReplaceUnhealthy](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-suspend-resume-processes.html).
+ Vous ne pouvez pas activer la protection de la résiliation pour les instances Spot.

------
#### [ Console ]

**Pour activer la protection contre la résiliation d’une instance lors du lancement**

1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Sur le tableau de bord, choisissez **Lancer une instance**.

1. Développez **Advanced Details** (Détails avancés). Pour **Protection contre la résiliation**, sélectionnez **Activer**.

1. Lorsque vous avez fini de spécifier les détails de votre instance, choisissez **Démarrer l’instance**.

**Pour modifier la protection contre la résiliation d’une instance**

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, sélectionnez **Instances**.

1. Sélectionnez l’instance.

1. Sélectionnez **Actions**, **Paramètres de l’instance** et **Modifier la protection contre la résiliation**.

1. Pour **Protection contre la résiliation**, sélectionnez ou désélectionnez **Activer**.

1. Choisissez **Enregistrer**.

------
#### [ AWS CLI ]

**Pour activer la protection contre la résiliation d’une instance**  
Utilisez la commande [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html).

```
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --disable-api-termination
```

**Pour désactiver la protection contre la résiliation d’une instance**  
Utilisez la commande [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html).

```
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --no-disable-api-termination
```

------
#### [ PowerShell ]

**Pour activer la protection contre la résiliation d’une instance**  
Utilisez l’applet de commande [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

```
Edit-EC2InstanceAttribute `
    -InstanceId i-1234567890abcdef0 `
    -DisableApiTermination $true
```

**Pour désactiver la protection contre la résiliation d’une instance**  
Utilisez l’applet de commande [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

```
Edit-EC2InstanceAttribute `
    -InstanceId i-1234567890abcdef0 `
    -DisableApiTermination $false
```

------

## Résiliez plusieurs instances à l’aide de la protection contre la résiliation
<a name="terminate-multiple"></a>

Si vous résiliez plusieurs instances à travers plusieurs zones de disponibilité dans la même requête, et qu'une ou plusieurs des instances précisées sont activées pour la protection contre la résiliation, la requête échoue avec les résultats suivants :
+ Les instances spécifiées qui se trouvent dans la même zone de disponibilité que l’instance protégée ne sont pas résiliées.
+ Les instances spécifiées qui se trouvent dans des zones de disponibilité différentes, où aucune autre instance spécifiée n’est protégée, sont résiliées avec succès.

**Exemple**  
Supposons que vous ayez les quatre instances suivantes réparties sur deux zones de disponibilité.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/Using_ChangingDisableAPITermination.html)

Si vous tentez de résilier toutes ces instances dans la même demande, la demande signale un échec avec les résultats suivants :
+ L'**instance 1** et l'**instance 2** sont résiliées avec succès car aucune des deux instances n'est activée pour la protection contre la résiliation.
+ L'**instance 3** et l'**instance 4** ne parviennent pas à se résilier car l'**instance 3** est activée pour la protection contre la résiliation.

# Modifier le comportement de l’arrêt initié par l’instance
<a name="Using_ChangingInstanceInitiatedShutdownBehavior"></a>

**Avertissement**  
**La résiliation d’une instance est définitive et irréversible.**  
Une fois que vous avez résilié une instance, vous ne pouvez plus vous y connecter et elle ne peut pas être récupérée. Tous les volumes Amazon EBS attachés qui sont configurés pour être supprimés à la résiliation sont également supprimés de manière définitive et ne peuvent pas être récupérés. L’intégralité des données stockées sur les volumes de stockage d’instance est définitivement perdue. Pour de plus amples informations, veuillez consulter [Comment fonctionne la résiliation d'une instance](how-ec2-instance-termination-works.md).  
Avant de résilier à une instance, assurez-vous d’avoir sauvegardé toutes les données que vous devez conserver après la résiliation dans un stockage persistant.

Par défaut, lorsque vous déclenchez un arrêt à partir d’une instance basée sur Amazon EBS (à l’aide d’une commande telle que **shutdown** ou **poweroff**), l’instance s’arrête. Vous pouvez modifier ce comportement pour que l’instance soit résiliée à la place en modifiant l’attribut `InstanceInitiatedShutdownBehavior` de l’instance. Vous pouvez modifier cet attribut tandis que l’instance est en cours d’exécution ou arrêtée.

La commande **halt** ne déclenche pas un arrêt. Si elle est utilisée, l’instance n’est pas résiliée. Au lieu de cela, elle place l’UC à l’état `HLT` et l’instance continue de s’exécuter.

**Note**  
L’attribut `InstanceInitiatedShutdownBehavior` n’est applicable que si vous procédez à l’arrêt du système d’exploitation ou de l’instance elle-même. Cela ne s’applique pas lorsque vous arrêtez une instance à l’aide de l’API `StopInstances` ou de la console Amazon EC2.

------
#### [ Console ]

**Pour modifier le comportement d’arrêt lancé de l’instance**

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.

1. Choisissez **Actions**, **Paramètres d’instance**, **Modifier le comportement d’arrêt**.

   **Comportement d’arrêt** affiche le comportement actuel.

1. Pour modifier le comportement, pour **Comportement d’arrêt**, choisissez **Arrêter** ou **Résilier**. 

1. Choisissez **Enregistrer**.

------
#### [ AWS CLI ]

**Pour modifier le comportement d’arrêt lancé de l’instance**  
Utilisez la commande [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html).

```
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --instance-initiated-shutdown-behavior terminate
```

------
#### [ PowerShell ]

**Pour modifier le comportement d’arrêt lancé de l’instance**  
Utilisez l’applet de commande [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

```
Edit-EC2InstanceAttribute `
    -InstanceId i-1234567890abcdef0 `
    -InstanceInitiatedShutdownBehavior terminate
```

------

# Conservation des données lors de la résiliation d’une instance
<a name="preserving-volumes-on-termination"></a>

Lorsqu’une instance Amazon EC2 est résiliée, vous pouvez conserver les données stockées sur vos volumes de stockage d’instance ou vos volumes Amazon EBS. Cette rubrique explique comment garantir la conservation de vos données au-delà de la résiliation de l’instance.

## Comment la résiliation d’une instance affecte les volumes racine et de données
<a name="how-instance-termination-affects-root-and-data-volumes"></a>

**Volumes de stockage d’instances**  
Lorsqu’une instance est résiliée, les volumes de stockage d’instance sont automatiquement supprimés et les données sont perdues. Pour préserver ces données au-delà de la durée de vie de l’instance, avant de résilier l’instance, copiez manuellement les données sur un stockage persistant, tel qu’un volume Amazon EBS, un compartiment Amazon S3 ou un système de fichiers Amazon EFS. Pour de plus amples informations, veuillez consulter [Options de stockage pour vos EC2 instances Amazon](Storage.md).

**Volumes Amazon EBS**  
Lorsqu’une instance est résiliée, les volumes EBS sont soit supprimés, soit conservés, en fonction de la valeur de l’attribut `DeleteOnTermination` pour chaque volume :
+ **Oui** (console)/`true` (CLI) : le volume est supprimé lorsque l’instance est résiliée.
+ **Non** (console)/`false` (CLI) : le volume est préservé lorsque l’instance est résiliée. Les volumes conservés continuent de générer des frais.
**Note**  
Une fois l’instance résiliée, vous pouvez prendre un instantané du volume conservé ou attacher celui-ci à une autre instance. Pour éviter les frais, vous devez supprimer le volume.

## Comportement de suppression par défaut pour les volumes EBS
<a name="default-deletion-behavior-for-ebs-volumes"></a>

La valeur `DeleteOnTermination` par défaut varie en fonction du type de volume, du fait que le volume ait été attaché au lancement ou après, et de la méthode (console ou CLI) utilisée pour attacher le volume :


| Type de volume | Attaché à quel moment | Méthode utilisée pour l’attachement | Comportement par défaut lors de la résiliation de l’instance | 
| --- | --- | --- | --- | 
| Volume racine | Au lancement : | Console ou CLI | Suppression | 
| Volume racine | After launch | Console ou CLI | Préserver | 
| Volume de données | Au lancement : | Console | Préserver | 
| Volume de données | Au lancement : | INTERFACE DE LIGNE DE COMMANDE (CLI) | Suppression | 
| Volume de données | After launch | Console et CLI | Préserver | 

## Vérification des paramètres de persistance du volume
<a name="check-ebs-volume-persistence-settings"></a>

La valeur par défaut au lancement d’un volume EBS est déterminée par l’attribut `DeleteOnTermination` défini sur l’AMI. Vous pouvez modifier la valeur au lancement de l’instance, en remplaçant le paramètre AMI. Nous vous recommandons de vérifier le paramètre par défaut de l’attribut `DeleteOnTermination` après avoir lancé une instance.

**Pour vérifier si un volume Amazon EBS sera supprimé lors de la résiliation de l’instance**

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.

1. Choisissez l'onglet **Stockage**.

1. Sous **Bloquer les périphériques**, faites défiler l’écran vers la droite pour vérifier la colonne **Supprimer à la résiliation**.
   + Si la réponse est **Oui**, le volume est supprimé lors de la résiliation de l’instance.
   + Si la réponse est **Non**, le volume n’est pas supprimé lors de la résiliation de l’instance. Les volumes non supprimés continuent de générer des frais.

## Modification du volume racine en vue de sa persistance lors du lancement
<a name="delete-on-termination-ebs-volume"></a>

Vous pouvez modifier l’attribut `DeleteOnTermination` d’un volume racine EBS lorsque vous lancez une instance. Vous pouvez également utiliser la procédure suivante pour un volume de données.

------
#### [ Console ]

**Pour modifier le volume racine d’une instance afin qu’il persiste au démarrage**

1. Suivez la procédure pour [lancer une instance](ec2-launch-instance-wizard.md), mais ne la lancez qu’après avoir effectué les étapes suivantes pour modifier le volume racine afin qu’il persiste.

1. Dans le volet **Configurer le stockage**, sélectionnez **Avancé**.

1. Sous **Stockage EBS**, développez les informations du volume racine.

1. Pour **Supprimer à la résiliation**, choisissez **Non**.

1. Dans le panneau **Summary** (Résumé), vérifiez la configuration de votre instance, puis choisissez **Launch instance** (Lancer l’instance). Pour de plus amples informations, veuillez consulter [Lancez une instance EC2 à l’aide de l’assistant de lancement d’instance de la console](ec2-launch-instance-wizard.md).

------
#### [ AWS CLI ]

**Pour modifier le volume racine d’une instance afin qu’il persiste au démarrage**  
Utilisez la commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) pour modifier la valeur de `DeleteOnTermination` dans le mappage de périphérique de stockage en mode bloc.

Ajoutez l’option `--block-device-mappings` :

```
--block-device-mappings file://mapping.json
```

Dans `mapping.json`, indiquez le nom du périphérique, par exemple `/dev/sda1` ou `/dev/xvda`, et pour `DeleteOnTermination`, indiquez `false`.

```
[
  {
    "DeviceName": "device_name",
    "Ebs": {
      "DeleteOnTermination": false
    }
  }
]
```

------
#### [ PowerShell ]

**Pour modifier le volume racine d’une instance afin qu’il persiste au démarrage**  
Utilisez l'[New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)applet de commande pour modifier la valeur de `DeleteOnTermination` dans le mappage des périphériques en mode bloc.

Ajoutez l’option `-BlockDeviceMapping` :

```
-BlockDeviceMapping $bdm
```

Dans `bdm`, indiquez le nom du périphérique, par exemple `/dev/sda1` ou `/dev/xvda`, et pour `DeleteOnTermination`, indiquez `false`.

```
$ebd = New-Object -TypeName Amazon.EC2.Model.EbsBlockDevice
$ebd.DeleteOnTermination = false
$bdm = New-Object -TypeName Amazon.EC2.Model.BlockDeviceMapping
$bdm.DeviceName = "/dev/sda1"
$bdm.Ebs = $ebd
```

------

## Modifier le volume racine d’une instance en cours d’exécution afin qu’il persiste
<a name="delete-on-termination-running-instance"></a>

Vous pouvez modifier le volume racine d’une instance en cours d’exécution afin qu’il persiste Vous pouvez également utiliser la procédure suivante pour un volume de données.

------
#### [ AWS CLI ]

**Pour modifier le volume racine afin qu’il persiste**  
Utilisez la commande [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html).

```
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0  \
    --block-device-mappings file://mapping.json
```

Dans `mapping.json`, indiquez le nom du périphérique, par exemple `/dev/sda1` ou `/dev/xvda`, et pour `--DeleteOnTermination`, indiquez `false`.

```
[
  {
    "DeviceName": "device_name",
    "Ebs": {
      "DeleteOnTermination": false
    }
  }
]
```

------
#### [ PowerShell ]

**Pour modifier le volume racine afin qu’il persiste**  
Utilisez l’applet de commande [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

Ajoutez l’option `-BlockDeviceMapping` :

```
-BlockDeviceMapping $bdm
```

Dans `bdm`, indiquez le nom du périphérique, par exemple `/dev/sda1` ou `/dev/xvda`, et pour `DeleteOnTermination`, indiquez `false`.

```
$ebd = New-Object -TypeName Amazon.EC2.Model.EbsBlockDevice
$ebd.DeleteOnTermination = false
$bdm = New-Object -TypeName Amazon.EC2.Model.BlockDeviceMapping
$bdm.DeviceName = "/dev/sda1"
$bdm.Ebs = $ebd
```

------

# Mise hors service d’instance
<a name="instance-retirement"></a>

La mise hors service d'une instance est planifiée lorsqu'une défaillance irréparable du matériel sous-jacent hébergeant l'instance est AWS détectée. Le volume racine de l’instance détermine le comportement de la mise hors service de celle-ci :
+ Si le volume racine de votre instance est un volume Amazon EBS, l’instance est arrêtée et vous pouvez la redémarrer à tout moment. Le démarrage de l’instance arrêtée la migre vers un nouveau matériel.
+ Si le volume racine de votre instance est un volume de stockage d’instance, l’instance est résiliée et ne peut plus être utilisée.

Pour plus d’informations sur les types d’événements d’instance, consultez [Événements programmés pour les instances Amazon EC2](monitoring-instances-status-check_sched.md).

**Topics**
+ [Identifier des instances prévues pour une mise hors service](#instance-retirement-identify)
+ [Mesures à prendre sur les instances basées sur EBS dont la mise hors service est prévue](#instance-retirement-actions-EBS)
+ [Mesures à prendre pour les instances sauvegardées dans le stockage d’instances dont la mise hors service est prévue](#instance-retirement-actions-instance-store)

## Identifier des instances prévues pour une mise hors service
<a name="instance-retirement-identify"></a>

Si votre instance est planifiée pour une mise hors service, vous recevez un courrier électronique préalable à l’événement avec l’ID d’instance et la date de mise hors service. Vous pouvez également rechercher les instances planifiées pour une mise hors service.

**Important**  
Si une instance est programmée pour une mise hors service, nous vous recommandons de prendre des mesures dès que possible, car elle peut déjà être inaccessible. Pour de plus amples informations, veuillez consulter [Check if your instance is reachable](#check-instance).

**Topics**
+ [Surveillance de l’e-mail des contacts du compte](#identify-by-email)
+ [Vérification de vos instances](#identify-in-console-cli)

### Surveillance de l’e-mail des contacts du compte
<a name="identify-by-email"></a>

Si la mise hors service d’une instance est planifiée, le contact principal du compte et le contact des opérations reçoivent un e-mail avant l’événement. Cet e-mail contient l’ID de l’instance et la date de mise hors service planifiée. Pour plus d'informations, voir [Mettre à jour le contact principal de votre AWS compte](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) et [Mettre à jour les contacts secondaires de votre AWS compte](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html) dans le *Guide de Gestion de compte AWS référence*.

### Vérification de vos instances
<a name="identify-in-console-cli"></a>

Si vous utilisez un compte e-mail que vous ne consultez pas régulièrement, vous risquez de manquer une notification de mise hors service d’instance. Vous pouvez vérifier à tout moment si la mise hors service de l’une de vos instances est planifiée.<a name="identify-retiring-instances"></a>

------
#### [ Console ]

**Pour identifier les instances dont la mise hors service est planifiée**

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 **Tableau de bord du EC2**. Sous **Événements planifiés**, vous pouvez voir les événements associés à vos instances et volumes Amazon EC2, organisés par région.  
![\[Événements planifiés\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/dashboard-scheduled-events.png)

1. Si vous avez une instance avec un événement planifié affiché, sélectionnez le lien sous le nom de la région pour accéder à la page **Événements**.

1. La page **Events** répertorie toutes les ressources qui ont des événements associés. Pour afficher les instances planifiées pour une mise hors service, sélectionnez **Instance resources** dans la première liste de filtres, puis **Instance stop or retirement** dans la deuxième liste de filtres.

1. Si les résultats du filtre affichent une instance planifiée pour une mise hors service, sélectionnez-la et notez les date et heure dans le champ **Start time** du volet des détails. Il s’agit de la date de mise hors service de votre instance.

------
#### [ AWS CLI ]

**Pour rechercher des instances dont la mise hors service est planifiée**  
Utilisez la commande [describe-instance-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-status.html) suivante. Répétez l’opération dans chaque région où vous disposez d’instances en cours d’exécution.

```
aws ec2 describe-instance-status --filters Name=event.code,Values=instance-retirement
```

------
#### [ PowerShell ]

**Pour rechercher des instances dont la mise hors service est planifiée**  
Utilisez l’applet de commande [Get-EC2InstanceStatus](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceStatus.html). Répétez l’opération dans chaque région où vous disposez d’instances en cours d’exécution.

```
Get-EC2InstanceStatus -Filter @{Name="event.code"; Values="instance-retirement"}
```

------

## Mesures à prendre sur les instances basées sur EBS dont la mise hors service est prévue
<a name="instance-retirement-actions-EBS"></a>

Pour conserver les données de votre instance mise hors service, vous pouvez effectuer l’une des actions suivantes. Il est important que vous preniez cette action avant la date de mise hors service de l’instance, afin de prévenir tout arrêt et perte de données imprévus.

Pour les instances Linux, si vous ne savez pas si votre instance est sauvegardée par EBS ou par le stockage d'instance, consultez [Volumes racine de vos instances Amazon EC2](RootDeviceStorage.md).

**Vérifier si votre instance est accessible**

Lorsque vous êtes averti que votre instance est programmée pour une mise hors service, nous vous recommandons de prendre les mesures suivantes dès que possible :
+ Vérifiez si votre instance est accessible en vous [connectant](connect.md) ou en envoyant une demande ping à celle-ci.
+ Si votre instance est accessible, vous devez la planifier à stop/start un moment approprié avant la date de mise hors service prévue, lorsque l'impact est minime. Pour plus d’informations sur l’arrêt et le redémarrage de votre instance, et sur ce que vous devez escompter quand votre instance est arrêtée, comme les conséquences sur les adresses publiques, privées et IP Elastic associées à votre instance, consultez [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md). Veuillez noter que les données sur les volumes de stockage d’instances sont perdues lorsque vous arrêtez et démarrez votre instance.
+ Si votre instance est inaccessible, vous devez prendre des mesures immédiates et effectuer un [arrêt/démarrage](Stop_Start.md) pour la récupérer.
+ Sinon, si vous souhaitez [mettre fin](terminating-instances.md) à votre instance, prévoyez de le faire dès que possible, afin de cesser d’engager des frais pour cette dernière.

**Créez une sauvegarde de votre instance**  
Pour disposer d’une sauvegarde, créez une AMI basée sur EBS à partir de votre instance. Pour garantir l’intégrité des données, arrêtez l’instance avant de créer l’AMI. Vous pouvez attendre la date de mise hors service planifiée quand l’instance est arrêtée ou arrêtez l’instance vous-même avant la date de mise hors service. Vous pouvez redémarrer l’instance à tout moment. Pour de plus amples informations, veuillez consulter [Créer une AMI basée sur Amazon EBS](creating-an-ami-ebs.md).

**Lancement d’une instance de remplacement**  
Après avoir créé une AMI à partir de votre instance, vous pouvez utiliser l’AMI pour lancer une instance de remplacement. Dans la console Amazon EC2, sélectionnez votre nouvelle AMI, puis choisissez **Lancer une instance à partir de l'AMI**. Configurez les paramètres de votre instance, puis choisissez **Lancer une instance**. Pour plus d'informations concernant chaque champ, consultez [Lancez une instance EC2 à l’aide de l’assistant de lancement d’instance de la console](ec2-launch-instance-wizard.md).

## Mesures à prendre pour les instances sauvegardées dans le stockage d’instances dont la mise hors service est prévue
<a name="instance-retirement-actions-instance-store"></a>

Pour conserver les données de votre instance mise hors service, vous pouvez effectuer l’une des actions suivantes. Il est important que vous preniez cette action avant la date de mise hors service de l’instance, afin de prévenir tout arrêt et perte de données imprévus.

**Avertissement**  
Si votre instance basée sur le stockage d’instances dépasse sa date de mise hors service, elle est résiliée et vous ne pouvez pas récupérer l’instance ou les données qui y étaient stockées. Quel que soit le volume racine de votre instance, les données des volumes de stockage d’instances sont perdues quand l’instance est mise hors service, même si les volumes sont attachés à une instance basée sur EBS.

**Vérifier si votre instance est accessible**

Lorsque vous êtes averti que votre instance est programmée pour une mise hors service, nous vous recommandons de prendre les mesures suivantes dès que possible :
+ Vérifiez si votre instance est accessible en vous [connectant](connect-to-linux-instance.md) ou en envoyant une demande ping à celle-ci.
+ Si votre instance est inaccessible, les chances de la récupérer sont vraiment très réduites. Pour plus d'informations, consultez[Résoudre les problèmes liés à une instance Amazon EC2 inaccessible](troubleshoot-unreachable-instance.md). AWS mettra fin à votre instance à la date de mise hors service prévue. Ainsi, dans le cas d'une instance inaccessible, vous pouvez immédiatement [résilier](terminating-instances.md) l'instance vous-même.

**Lancement d’une instance de remplacement**  
Créez une AMI basée sur Amazon S3 à partir de votre instance à l’aide des outils AMI, comme décrit dans la section [Création d’une AMI basée sur Amazon S3](creating-an-ami-instance-store.md). Dans la console Amazon EC2, sélectionnez votre nouvelle AMI, puis choisissez **Lancer une instance à partir de l'AMI**. Configurez les paramètres de votre instance, puis choisissez **Lancer une instance**. Pour plus d'informations concernant chaque champ, consultez [Lancez une instance EC2 à l’aide de l’assistant de lancement d’instance de la console](ec2-launch-instance-wizard.md).

**Convertir votre instance en instance basée sur EBS**  
Transférez vos données vers un volume EBS, prenez un instantané du volume, puis créez une AMI à partir de l’instantané. Vous pouvez lancer une instance de remplacement à partir de votre nouvel AMI. Pour de plus amples informations, veuillez consulter [Conversion de votre AMI basée sur Amazon S3 en AMI basée sur Amazon EBS](Using_ConvertingS3toEBS.md).