

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Résoudre les problèmes liés aux instances Amazon EC2
<a name="ec2-instance-troubleshoot"></a>

Les procédures et conseils suivants peuvent vous aider à résoudre les problèmes que vous pouvez rencontrer avec vos instances Amazon EC2.

**Topics**
+ [Problèmes de lancement d'instance](troubleshooting-launch.md)
+ [Problèmes d’arrêt d’instance](TroubleshootingInstancesStopping.md)
+ [Problèmes liés à la résiliation de l'instance](TroubleshootingInstancesShuttingDown.md)
+ [Instances inaccessible](troubleshoot-unreachable-instance.md)
+ [Problèmes liés au SSH de l'instance Linux](TroubleshootingInstancesConnecting.md)
+ [Les vérifications du statut de l'instance Linux ont échoué](TroubleshootingInstances.md)
+ [L'instance Linux démarre à partir du mauvais volume](instance-booting-from-wrong-volume.md)
+ [Problèmes RDP liés à l'instance Windows](troubleshoot-connect-windows-instance.md)
+ [Problèmes de démarrage de l'instance Windows](common-messages.md)
+ [Problèmes liés à l’instance Windows](win-ts-common-issues.md)
+ [Débogage du noyau d'une instance Windows sur le réseau](troubleshoot-windows-with-kdnet.md)
+ [Réinitialiser le mot de passe de l’administrateur Windows](ResettingAdminPassword.md)
+ [Résolution des problèmes liés à Sysprep](sysprep-troubleshoot.md)
+ [EC2Rescue pour les instances Linux](Linux-Server-EC2Rescue.md)
+ [EC2Rescue pour les instances Windows](Windows-Server-EC2Rescue.md)
+ [EC2 Serial Console](ec2-serial-console.md)
+ [Envoyez une interruption de diagnostic](diagnostic-interrupt.md)

# Résoudre les problèmes liés au lancement d'une instance Amazon EC2
<a name="troubleshooting-launch"></a>

Voici des conseils de dépannage pour vous aider à résoudre les problèmes de lancement d'une instance Amazon EC2.

**Topics**
+ [Nom de périphérique non valide](#troubleshooting-launch-devicename)
+ [Dépassement de la limite d'instance](#troubleshooting-launch-limit)
+ [Capacité d'instance insuffisante](#troubleshooting-launch-capacity)
+ [La configuration demandée n'est actuellement pas prise en charge. Consultez la documentation pour voir les configurations prises en charge.](#troubleshooting-instance-configuration)
+ [Mise hors service immédiate de l'instance](#troubleshooting-launch-internal)
+ [Autorisations insuffisantes](#troubleshooting-launch-permissions)
+ [Utilisation élevée de l'UC peu après le démarrage de Windows (instances Windows uniquement)](#high-cpu-issue)
+ [Le lancement d'une instance IMDSv1 activée échoue](#launching-an-imdsv1-enabled-instance-fails)

## Nom de périphérique non valide
<a name="troubleshooting-launch-devicename"></a>

### Description
<a name="troubleshooting-launch-devicename-description"></a>

Vous obtenez l'erreur `Invalid device name device_name` lorsque vous essayez de lancer une nouvelle instance.

### Cause
<a name="troubleshooting-launch-devicename-cause"></a>

Si vous obtenez cette erreur lorsque vous essayez de lancer une instance, le nom de périphérique spécifié pour un ou plusieurs volumes dans la demande comporte un nom de périphérique non valide. Les causes possibles incluent :
+ Le nom de périphérique est peut-être déjà utilisé par l'AMI sélectionnée.
+ Le nom de périphérique peut être réservé aux volumes racine.
+ Le nom de périphérique peut être utilisé pour un autre volume dans la demande.
+ Le nom de périphérique peut ne pas être valide pour le système d'exploitation.

### Solution
<a name="troubleshooting-launch-devicename-solution"></a>

Pour résoudre le problème :
+ Assurez-vous que le nom de périphérique n'est pas utilisé dans l'AMI que vous avez sélectionnée. Exécutez la commande suivante pour afficher les noms de périphériques utilisés par l'AMI.

  ```
  aws ec2 describe-images --image-id ami-0abcdef1234567890 --query 'Images[*].BlockDeviceMappings[].DeviceName'
  ```
+ Assurez-vous que vous n'utilisez pas un nom de périphérique qui est réservé aux volumes racine. Pour de plus amples informations, veuillez consulter [Noms d’appareil disponibles](device_naming.md#available-ec2-device-names).
+ Assurez-vous que chaque volume spécifié dans votre demande possède un nom de périphérique unique.
+ Assurez-vous que les noms de périphériques que vous avez spécifiés sont au format correct. Pour de plus amples informations, veuillez consulter [Noms d’appareil disponibles](device_naming.md#available-ec2-device-names).

## Dépassement de la limite d'instance
<a name="troubleshooting-launch-limit"></a>

### Description
<a name="troubleshooting-launch-limit-description"></a>

Vous obtenez l'erreur `InstanceLimitExceeded` lorsque vous essayez de lancer une nouvelle instance ou de redémarrer une instance arrêtée.

### Cause
<a name="troubleshooting-launch-limit-cause"></a>

Si vous obtenez une erreur `InstanceLimitExceeded` lorsque vous essayez de lancer une nouvelle instance ou de redémarrer une instance arrêté, vous avez atteint la limite du nombre d'instances que vous pouvez lancer dans une région. Lorsque vous créez votre AWS compte, nous fixons des limites par défaut quant au nombre d'instances que vous pouvez exécuter par région.

### Solution
<a name="troubleshooting-launch-limit-solution"></a>

Vous pouvez demander une augmentation de la limite d'instance par région. Pour de plus amples informations, veuillez consulter [Quotas EC2 de service Amazon](ec2-resource-limits.md).

## Capacité d'instance insuffisante
<a name="troubleshooting-launch-capacity"></a>

### Description
<a name="troubleshooting-launch-capacity-description"></a>

Vous obtenez l'erreur `InsufficientInstanceCapacity` lorsque vous essayez de lancer une nouvelle instance ou de redémarrer une instance arrêtée.

### Cause
<a name="troubleshooting-launch-capacity-description"></a>

Si vous obtenez cette erreur lorsque vous essayez de lancer une instance ou de redémarrer une instance arrêtée, AWS n'a actuellement pas assez de capacité à la demande disponible pour répondre à votre demande.

### Solution
<a name="troubleshooting-launch-capacity-description"></a>

Pour résoudre ce problème, essayez ce qui suit :
+ Attendez quelques minutes, puis renvoyez votre demande. La capacité peut changer fréquemment.
+ Envoyez une nouvelle demande avec un nombre réduit d'instances. Par exemple, si vous faites une demande simple pour lancer 15 instances, essayez de faire 3 demandes pour 5 instances ou 15 demandes pour 1 instance à la place.
+ Si vous lancez une instance, soumettez une nouvelle demande sans spécifier de zone de disponibilité.
+ Si vous lancez une instance, envoyez une nouvelle demande en utilisant un type d'instance différent (que vous pouvez redimensionner à un stade ultérieur). Pour de plus amples informations, veuillez consulter [Changements de type d'instance Amazon EC2](ec2-instance-resize.md).
+ Si vous lancez des instances dans un groupe de placement du cluster, vous pouvez recevoir une erreur de capacité insuffisante.

## La configuration demandée n'est actuellement pas prise en charge. Consultez la documentation pour voir les configurations prises en charge.
<a name="troubleshooting-instance-configuration"></a>

### Description
<a name="troubleshooting-instance-configuration-description"></a>

Vous obtenez l'erreur `Unsupported` lorsque vous essayez de lancer une nouvelle instance, car la configuration de l'instance n'est pas prise en charge.

### Cause
<a name="troubleshooting-instance-configuration-cause"></a>

Le message d'erreur fournit des informations supplémentaires. Par exemple, un type d'instance ou une option d'achat d'instance peut ne pas être prise en charge dans la région ou la zone de disponibilité spécifiée.

### Solution
<a name="troubleshooting-instance-configuration-solution"></a>

Essayez une autre configuration d'instance. Pour rechercher un type d'instance qui répond à vos besoins, consultez [Rechercher un type d' EC2 instance Amazon](instance-discovery.md).

## Mise hors service immédiate de l'instance
<a name="troubleshooting-launch-internal"></a>

### Description
<a name="troubleshooting-launch-internal-description"></a>

Votre instance passe de l'état `pending` à l'état `terminated`.

### Cause
<a name="troubleshooting-launch-internal-cause"></a>

Voici quelques raisons qui expliquent pourquoi une instance peut se terminer immédiatement :
+ Vous avez dépassé vos limites de volumes EBS. Pour de plus amples informations, veuillez consulter [Limites de volume Amazon EBS pour les instances Amazon EC2](volume_limits.md).
+ Un instantané EBS est corrompu.
+ Le volume EBS racine est chiffré et vous n'êtes pas autorisé à accéder à la clé KMS pour le déchiffrement.
+ Un instantané spécifié dans le mappage de périphérique de stockage en mode bloc pour l'AMI est chiffré et vous ne disposez pas des autorisations nécessaires pour accéder à la clé KMS pour la déchiffrer, ou vous n'avez pas accès à la clé KMS pour chiffrer les volumes restaurés.
+ L’AMI basée sur Amazon S3 que vous avez utilisée pour lancer l’instance ne possède par une partie obligatoire (un fichier image.part.*xx*).

Pour de plus amples informations, veuillez récupérer le motif de résiliation à l'aide de l'une des méthodes suivantes.

**Pour obtenir la cause de la résiliation à l'aide de la console Amazon EC2**

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. Dans le premier onglet, recherchez le motif en regard de **State transition reason (Motif de transition de l'état)**.

**Pour obtenir le motif du licenciement à l'aide du AWS CLI**

1. Utilisez la commande [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) et spécifiez l'ID de l'instance.

   ```
   aws ec2 describe-instances --instance-id i-1234567890abcdef0
   ```

1. Vérifiez la réponse JSON renvoyée par la commande et notez les valeurs de l'élément de réponse `StateReason`.

   Le bloc de code suivant présente un exemple d'élément de réponse `StateReason`.

   ```
   "StateReason": {
     "Message": "Client.VolumeLimitExceeded: Volume limit exceeded", 
     "Code": "Server.InternalError"
   },
   ```

**Pour obtenir le motif du licenciement en utilisant AWS CloudTrail**  
Pour plus d'informations, consultez la section [Affichage des événements avec l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) dans le *Guide de AWS CloudTrail l'utilisateur*.

### Solution
<a name="troubleshooting-launch-internal-solution"></a>

En fonction de la cause de la résiliation, exécutez l'une des actions suivantes :
+ **`Client.VolumeLimitExceeded: Volume limit exceeded`** — Supprimez les volumes inutilisés. Vous pouvez [envoyer une demande](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-ebs) d'augmentation de votre limite de volumes.
+ **`Client.InternalError: Client error on launch`**— Assurez-vous que vous disposez des autorisations requises pour accéder aux volumes AWS KMS keys utilisés pour déchiffrer et chiffrer. Pour de plus amples informations, veuillez consulter [Utilisation des politiques de clé AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dans le *AWS Key Management Service Guide du développeur*.

## Autorisations insuffisantes
<a name="troubleshooting-launch-permissions"></a>

### Description
<a name="troubleshooting-launch-permissions-description"></a>

Vous obtenez l'erreur `"errorMessage": "You are not authorized to perform this operation."` lorsque vous essayez de lancer une nouvelle instance et que le lancement échoue.

### Cause
<a name="troubleshooting-launch-permissions-cause"></a>

Si cette erreur s'affiche lorsque vous essayez de lancer une instance, cela signifie que vous ne disposez pas des autorisations IAM requises pour lancer l'instance.

Les autorisations manquantes possibles incluent :
+ `ec2:RunInstances`
+ `iam:PassRole`

D'autres autorisations peuvent également être manquantes. Pour obtenir la liste des autorisations requises pour lancer une instance, consultez les exemples de politiques IAM sous [Exemple : utiliser l’assistant de lancement d’instances d’EC2](iam-policies-ec2-console.md#ex-launch-wizard) et [Instances de lancement (RunInstances)](ExamplePolicies_EC2.md#iam-example-runinstances).

### Solution
<a name="troubleshooting-launch-permissions-solution"></a>

Pour résoudre le problème :
+ Si vous faites des demandes en tant qu'utilisateur IAM, vérifiez que vous avez les autorisation suivantes :
  + `ec2:RunInstances` avec une ressource générique (« \$1 »)
  + `iam:PassRole` avec la ressource correspondant à l'ARN du rôle (par exemple, `arn:aws:iam::999999999999:role/ExampleRoleName`)
+ Si vous ne disposez pas des autorisations précédentes, [modifiez la politique IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) associée au rôle ou à l'utilisateur IAM pour ajouter les autorisations requises manquantes.

Si votre problème persiste et que vous recevez toujours un message d'erreur d'échec de lancement, vous pouvez décoder le message d'échec d'autorisation inclus dans l'erreur. Le message décodé inclut les autorisations qui ne figurent pas dans la politique IAM. Pour plus d'informations, consultez [Comment décoder un message d'échec d'autorisation après avoir reçu une erreur « UnauthorizedOperation » lors du lancement d'une instance EC2](https://repost.aws/knowledge-center/ec2-not-auth-launch) ?

## Utilisation élevée de l'UC peu après le démarrage de Windows (instances Windows uniquement)
<a name="high-cpu-issue"></a>

**Note**  
Ce conseil de résolution des problèmes concerne uniquement les instances Windows.

Si Windows Update est défini sur **Rechercher des mises à jour mais me laisser choisir s'il convient de les télécharger et de les installer** (paramètre de l'instance par défaut), cette vérification peut consommer entre 50 % et 99 % des ressources d'UC sur l'instance. Si cette consommation de l'UC est problématique pour vos applications, vous pouvez modifier manuellement les paramètres de Windows dans le **Panneau de configuration** ou vous pouvez utiliser le script suivant dans le champ des données utilisateur Amazon EC2 :

```
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUOptions /t REG_DWORD /d 3 /f net stop wuauserv net start wuauserv
```

Lorsque vous exécutez ce script, spécifiez une valeur pour /d. La valeur par défaut est 3. Les valeurs possibles sont notamment les suivantes : 

1. Ne jamais rechercher des mises à jour

1. Rechercher des mises à jour mais me laisser choisir s'il convient de les télécharger et de les installer

1. Télécharger des mises à jour mais me laisser choisir s'il convient de les installer

1. Installer les mises à jour automatiquement

Après avoir modifié les données utilisateur de votre instance, vous pouvez exécuter celle-ci. Pour plus d'informations, consultez la section [Exécuter des commandes sur votre instance Windows au lancement](user-data.md).

## Le lancement d'une instance IMDSv1 activée échoue
<a name="launching-an-imdsv1-enabled-instance-fails"></a>

### Description
<a name="launching-an-imdsv1-enabled-instance-fails-description"></a>

Vous obtenez une `UnsupportedOperation` exception avec le message suivant :

`You can't launch instances with IMDSv1 because httpTokensEnforced is enabled for this account. Either launch the instance with httpTokens=required or contact your account owner to disable httpTokensEnforced using the ModifyInstanceMetadataDefaults API or the account settings in the EC2 console.`

### Cause
<a name="launching-an-imdsv1-enabled-instance-fails-cause"></a>

Cette erreur est générée lorsque vous tentez de lancer une nouvelle instance à IMDSv1 activer (`httpTokens = optional`) dans un compte où les paramètres du compte EC2 ou une politique déclarative de AWS l'organisation imposent l'utilisation de IMDSv2 (). `httpTokensEnforced = enabled` 

### Solution
<a name="launching-an-imdsv1-enabled-instance-fails-solution"></a>

Si vous êtes prêt à l'utiliser IMDSv2 uniquement, lancez votre instance avec IMDSv1 disabled (`httpTokens = required`). Pour vérifier si vous êtes prêt, consultez[Passer à l’utilisation de Service des métadonnées d’instance Version 2](instance-metadata-transition-to-version-2.md).

Si vous avez toujours besoin d' IMDSv1 assistance sur des instances nouvelles ou existantes, vous devrez désactiver IMDSv2 l'application pour le compte dans la Région. Pour désactiver IMDSv2 l'application, définissez `HttpTokensEnforced` sur`disabled`. Pour plus d'informations, consultez [ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html)le manuel Amazon EC2 API Reference. Si vous préférez configurer ce paramètre à l'aide de la console, consultez[Appliquer IMDSv2 au niveau du compte](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

 

# Résoudre les problèmes d'arrêt des EC2 instances Amazon
<a name="TroubleshootingInstancesStopping"></a>

Si votre instance soutenue par Amazon EBS semble bloquée dans l’état `stopping`, le problème peut provenir de l’ordinateur hôte sous-jacent.

Pour résoudre le problème, suivez les étapes suivantes :

1. **Forcer l’arrêt de l’instance**

   Utilisez la EC2 console Amazon ou le AWS CLI pour forcer l'arrêt de l'instance. Pour les étapes, consultez [Forcer l’arrêt d’une instance](#force-stop-instance).

   L’instance tentera d’abord un arrêt progressif, qui comprend la purge des caches du système de fichiers et des métadonnées (bien que vous puissiez choisir de contourner l’arrêt progressif). Si l’arrêt progressif ne parvient pas à se terminer dans le délai imparti, l’instance s’arrête de force sans vider les caches et les métadonnées du système de fichiers.

1. **Après l’arrêt forcé**

   Réaliser des procédures de contrôle et de réparation du système de fichiers.
**Important**  
L’exécution de ces procédures est cruciale car un arrêt forcé empêche le vidage des caches et des métadonnées du système de fichiers.

1. **En cas d’échec de l’arrêt forcé**

   Si l’instance ne s’est pas arrêtée après 10 minutes, procédez comme suit :

   1. Publiez une demande d’aide sur [AWS re:Post](https://repost.aws/). Pour contribuer à une résolution rapide du problème, incluez l’ID d’instance et décrivez les étapes que vous avez déjà effectuées.

   1. Sinon, si vous disposez d’un plan de support, créez une demande d’assistance technique dans le [Centre de support](https://console.aws.amazon.com/support/home#/).

   1. En attendant l’assistance, vous pouvez créer une instance de remplacement si nécessaire. Pour les étapes, consultez [(Facultatif) Créer une instance de remplacement](#Creating_Replacement_Instance).

L’utilisation d’une instance est gratuite tant que l’instance est à l’état `stopping` ou à n’importe quel autre état, sauf `running`. L’utilisation d’une instance est payante uniquement lorsqu’elle est à l’état `running`.

**Topics**
+ [Forcer l’arrêt d’une instance](#force-stop-instance)
+ [(Facultatif) Créer une instance de remplacement](#Creating_Replacement_Instance)

## Forcer l’arrêt d’une instance
<a name="force-stop-instance"></a>

Vous pouvez forcer l’arrêt d’une instance. Si l’instance ne s’est pas arrêtée après 10 minutes, publiez une demande d’aide sur le [AWS re:Post](https://repost.aws/). Pour contribuer à une résolution rapide du problème, incluez l’ID d’instance et décrivez les étapes que vous avez déjà effectuées. Sinon, si vous disposez d’un plan de support, créez une demande d’assistance technique dans le [Centre de support](https://console.aws.amazon.com/support/home#/).

**Note**  
À l’aide de la console, vous ne pouvez forcer l’arrêt d’une instance que lorsque celle-ci est dans l’état `stopping`. À l’aide de l’ AWS CLI, vous pouvez forcer l’arrêt d’une instance alors qu’elle se trouve dans l’état `pending`, `running` ou `stopping`.

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

**Pour forcer l’arrêt d’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, sélectionnez **instances** et choisissez l’instance bloquée.

1. Sélectionnez **État de l’instance**, **Forcer l’arrêt de l’instance**.

   Notez que **Forcer l’arrêt de l’instance** n’est disponible dans la console que si votre instance se trouve dans l’état `stopping`. Si votre instance est dans un autre état (sauf `shutting-down` et`terminated`), vous pouvez utiliser le AWS CLI pour forcer l'arrêt de votre instance.

1. (Facultatif) Pour contourner l’arrêt progressif du système d’exploitation lors de l’arrêt forcé, cochez la case **Ignorer l’arrêt du système d’exploitation**.

1. Choisissez **Forcer l’arrêt**.

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

**Pour forcer l’arrêt d’une instance**  
Utilisez la commande [stop-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html) avec l’option `--force`.

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

Pour contourner l’arrêt progressif du système d’exploitation lors d’un arrêt forcé, incluez l’option `--skip-os-shutdown`.

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

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

**Pour forcer l’arrêt d’une instance**  
Utilisez l'[Stop-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Stop-EC2Instance.html)applet de commande et définissez sur`-Enforce`. `true`

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

Pour contourner l’arrêt progressif du système d’exploitation lors d’un arrêt forcé, incluez `-SkipOsShutdown $true`.

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

------

## (Facultatif) Créer une instance de remplacement
<a name="Creating_Replacement_Instance"></a>

Pendant que vous attendez l’aide de [AWS re:Post](https://repost.aws/) ou du [Centre d’assistance](https://console.aws.amazon.com/support/home#/), vous pouvez créer une instance de remplacement si nécessaire. Créez une AMI à partir de l’instance bloquée et lancez une nouvelle instance en utilisant la nouvelle AMI.

**Important**  
Vous pouvez créer une instance de remplacement si l’instance bloquée produit uniquement des [contrôles d’état du système](monitoring-instances-status-check.md), car les contrôles d’état des instances obligeront l’AMI à copier un réplica exact du système d’exploitation en panne. Après avoir confirmé le message d’état, créez l’AMI et lancez une nouvelle instance à l’aide de la nouvelle AMI.

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

**Pour créer une instance de remplacement**

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, sélectionnez **instances** et choisissez l’instance bloquée.

1. Choisissez **Actions**, **Image and templates (Image et modèles)**, **Create image (Créer une image)**.

1. Sur la page **Créer une image**, procédez comme suit :

   1. Saisissez un nom et une description pour l’AMI.

   1. Effacez l’**instance de redémarrage**.

   1. Choisissez **Create image (Créer une image)**.

   Pour de plus amples informations, veuillez consulter [Créer une AMI à partir d’une instance](creating-an-ami-ebs.md#how-to-create-ebs-ami).

1. Lancez une nouvelle instance à partir de l’AMI et vérifiez qu’elle fonctionne.

1. Sélectionnez l’instance bloquée, puis **Actions**, **État de l’instance** et **Terminer (supprimer) l’instance**. Si l'instance est également bloquée en cours de résiliation, Amazon l'oblige EC2 automatiquement à se terminer en quelques heures.

Si vous ne pouvez pas créer une AMI à partir de l’instance comme décrit dans la procédure précédente, vous pouvez configurer une instance de remplacement de la façon suivante :

**(Alternative) Pour créer une instance de remplacement à l’aide de la console**

1. Sélectionnez l’instance et choisissez **Description**, **Périphériques de stockage en mode bloc**. Sélectionnez chaque volume et notez leur ID de volume. Assurez-vous de noter quel volume correspond au volume racine.

1. Dans le panneau de navigation, choisissez **Volumes**. Sélectionnez chaque volume pour l’instance et sélectionnez **Actions**, **Créer un instantané**.

1. Dans le panneau de navigation, choisissez **Snapshots**. Sélectionnez l’instantané que vous venez de créer et choisissez **Actions**, **Créer un volume**.

1. Lancez une instance avec le même système d’exploitation que l’instance bloqué. Notez l’ID du volume et le nom de périphérique de son volume racine.

1. Dans le panneau de navigation, sélectionnez **instances**, puis l’instance que vous venez de lancer, et **État de l’instance**, **Arrêter l’instance**.

1. Dans le panneau de navigation, sélectionnez **Volumes**, choisissez le volume racine de l’instance arrêtée, et sélectionnez **Actions**, **Détacher un volume**.

1. Sélectionnez le volume racine que vous avez créé à partir de l’instance bloquée, puis **Actions**, **Attacher un volume** et attachez-le à la nouvelle instance comme volume racine (en utilisant le nom de périphérique que vous avez noté). Attachez n’importe quel volume non-racine supplémentaire à l’instance.

1. Dans le panneau de navigation, sélectionnez **instances** et choisissez l’instance de remplacement. Choisissez **État de l’instance**, **Démarrer l’instance**. Vérifiez que l’instance fonctionne.

1. Sélectionnez l’instance bloquée, choisissez **État de l’instance**, **Terminer (supprimer) l’instance**. Si l'instance est également bloquée en cours de résiliation, Amazon l'oblige EC2 automatiquement à se terminer en quelques heures.

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

**Pour créer une instance de remplacement**

1. Créez une AMI à partir de l’instance bloquée, en utilisant la commande [create-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-image.html) avec l’option `--no-reboot`.

   ```
   aws ec2 create-image \
       --instance-id i-1234567890abcdef0 \
       --name "my-replacement-ami" \
       --description ""AMI for replacement instance" \
       --no-reboot
   ```

1. Lancez une nouvelle instance à partir de l’AMI que vous venez de créer, à l’aide de la commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html).

1. Vérifiez que la nouvelle instance fonctionne.

1. (Facultatif) Résiliez l’instance bloquée en utilisant la commande [terminate-instance](https://docs.aws.amazon.com/cli/latest/reference/ec2/terminate-instances.html).

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

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

**Pour créer une instance de remplacement**

1. Créez une AMI à partir de l'instance bloquée à l'aide de l'[New-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Image.html)applet de commande et définissez sur`-NoReboot`. `true`

   ```
   New-EC2Image `
       -InstanceId i-1234567890abcdef0 `
       -Name "my-replacement-ami" `
       -Description "AMI for replacement instance" `
       -NoReboot $true
   ```

1. Lancez une nouvelle instance à partir de l'AMI que vous venez de créer à l'aide de l'[New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)applet de commande.

1. Vérifiez que la nouvelle instance fonctionne.

1. (Facultatif) Mettez fin à l'instance bloquée à l'aide de l'[Remove-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2Instance.html)applet de commande.

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

------

# Résoudre les problèmes de résiliation des instances Amazon EC2
<a name="TroubleshootingInstancesShuttingDown"></a>

L'arrêt ou la suppression de votre instance s'appelle la résiliation de l'instance. Les informations suivantes peuvent vous aider à résoudre les problèmes lorsque vous mettez fin à votre instance.

Vous n'êtes pas facturé pour l'utilisation d'une instance tant que l'instance n'est pas à l'état `running`. En d'autres termes, lorsque vous mettez fin à une instance, l'instance ne vous est plus facturée dès que son état passe à `shutting-down`.

## Mise hors service immédiate de l'instance
<a name="instance-terminates-immediately"></a>

Plusieurs problèmes peuvent entraîner la résiliation immédiate de votre instance au démarrage. Pour plus d'informations, consultez [Mise hors service immédiate de l'instance](troubleshooting-launch.md#troubleshooting-launch-internal).

## Mise à fin d'instance retardée
<a name="instance-stuck-terminating"></a>

Si votre instance reste à l’état `shutting-down` pendant plus que quelques minutes, cela peut être dû à l’une des raisons suivantes :
+ L’instance exécute des scripts d’arrêt.
+ Il y a un problème avec l’ordinateur hôte sous-jacent.

Après plusieurs heures dans l’état `shutting-down`, Amazon EC2 considère l’instance comme bloquée et la résilie de force.

Pour résoudre vous-même un problème d’instance bloquée :

1. **Résiliation forcée de l’instance**

   Utilisez la console Amazon EC2 ou le AWS CLI pour forcer la mise hors service de l'instance. Pour les étapes, consultez [Résiliation forcée d’une instance](#force-terminate-ec2-instance).

   L’instance tentera d’abord un arrêt progressif, qui comprend la purge des caches du système de fichiers et des métadonnées (bien que vous puissiez choisir de contourner l’arrêt progressif). Si l’arrêt progressif ne parvient pas à se terminer dans le délai imparti, l’instance s’arrête de force sans vider les caches et les métadonnées du système de fichiers.

1. **En cas d’échec de la résiliation forcée**

   Si, après plusieurs heures, l’instance n’a pas été résiliée et semble bloquée, procédez comme suit :

   1. Publiez une demande d’aide sur [AWS re:Post](https://repost.aws/). Pour contribuer à une résolution rapide du problème, incluez l’ID d’instance et décrivez les étapes que vous avez déjà effectuées.

   1. Sinon, si vous disposez d’un plan de support, créez une demande d’assistance technique dans le [Centre de support](https://console.aws.amazon.com/support/home#/).

### Résiliation forcée d’une instance
<a name="force-terminate-ec2-instance"></a>

Si la résiliation de votre instance semble bloquée, vous pouvez forcer sa résiliation. Si, après plusieurs heures, l’instance n’a pas été résiliée, publiez une demande d’aide sur [AWS Re:post](https://repost.aws/). Pour aider à accélérer la résolution d'un problème, incluez l'ID d'instance et décrivez les étapes que vous avez déjà effectuées. Sinon, si vous disposez d'un plan de support, créez une demande d'assistance technique dans le [Centre de support](https://console.aws.amazon.com/support/home#/).

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

**Pour forcer 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** et choisissez l’instance bloquée.

1. Choisissez **État de l’instance**, **Résilier de force l’instance**.

   Notez que **Résilier de force l’instance** n’est disponible dans la console que si votre instance se trouve dans l’état `stopping`. Si votre instance se trouve dans un autre état (sauf `shutting-down` et`terminated`), vous pouvez utiliser le AWS CLI pour forcer la mise hors service de votre instance.

1. (Facultatif) Pour contourner l’arrêt progressif du système d’exploitation lors de la résiliation forcée, cochez la case **Ignorer l’arrêt du système d’exploitation**.

1. Choisissez **Forcer la résiliation**.

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

**Pour forcer la résiliation d’une instance**  
Utilisez la commande [terminate-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/terminate-instances.html) avec l’option `--force`.

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

Pour contourner l’arrêt progressif du système d’exploitation lors d’une résiliation forcée, incluez l’option `--skip-os-shutdown`.

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

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

**Pour forcer la résiliation d’une instance**  
Utilisez l'[Remove-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2Instance.html)applet de commande et définissez sur`-Enforce`. `true`

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

Pour contourner l’arrêt progressif du système d’exploitation lors d’une résiliation forcée, incluez `-SkipOsShutdown $true`.

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

------

## Instance terminée toujours affichée
<a name="terminated-instance-still-displaying"></a>

Après avoir mis fin à une instance, elle reste visible pendant un court instant avant d'être supprimée. L'état indique `terminated`. Si l'entrée n'est pas supprimée après plusieurs heures, contactez le support.

## Erreur : il se peut que l'instance ne soit pas résiliée. Modifier son attribut d'instance disableApiTermination « »
<a name="termination-protection-enabled"></a>

Si vous essayez de résilier une instance et que le message d'erreur `The instance i-1234567890abcdef0 may not be terminated. Modify its 'disableApiTermination' instance attribute` s'affiche, cela signifie que la protection contre la résiliation de l'instance a été activée. La protection contre la résiliation empêche la résiliation accidentelle de l'instance.

Vous devez désactiver la protection contre la résiliation avant de pouvoir résilier l'instance.

Pour de plus amples informations, veuillez consulter [Modification de la protection contre la résiliation d’instance](Using_ChangingDisableAPITermination.md).

## instances lancées ou terminées automatiquement
<a name="automatic-instance-create-or-delete"></a>

De manière générale, ces comportements signifient que vous avez utilisé Amazon EC2 Auto Scaling, la flotte EC2 ou le parc d'instances Spot pour mettre automatiquement à l'échelle vos ressources de calcul en fonction des critères que vous avez définis.
+ Vous mettez fin à une instance et une nouvelle instance se lance automatiquement.
+ Vous lancez une instance et l'une de vos instances se termine automatiquement.
+ Vous arrêtez une instance, elle se termine et une nouvelle instance se lance automatiquement.

Pour arrêter la mise à l'échelle automatique, recherchez le groupe Auto Scaling ou la flotte qui lance les instances et mettez sa capacité à 0 ou supprimez-la.

# Résoudre les problèmes liés à une instance Amazon EC2 inaccessible
<a name="troubleshoot-unreachable-instance"></a>

Les informations suivantes peuvent vous aider à résoudre les problèmes d'instances Amazon EC2 injoignable. Vous pouvez effectuer des captures d'écran ou accéder à la sortie de la console pour vous aider à diagnostiquer les problèmes et déterminer si vous devez redémarrer votre instance. Pour les instances Windows inaccessibles, résolvez les problèmes en consultant les captures d'écran renvoyées par le service. 

**Topics**
+ [Redémarrage d’instance](#instance-console-rebooting)
+ [Sortie de la console de l’instance](#instance-console-console-output)
+ [Création d’une capture d’écran d’une instance inaccessible](#instance-console-screenshot)
+ [Captures d'écran courantes pour les instances Windows](ics-common.md)
+ [Récupération d’instance en cas de plantage de l’ordinateur hôte](#instance-machine-failure)
+ [L’instance est apparue hors ligne et a redémarré de façon inattendue](#troubleshoot-unavailable-instance-unexpected-reboot)

## Redémarrage d’instance
<a name="instance-console-rebooting"></a>

La capacité de redémarrer des instances qui sont généralement inaccessibles est précieuse pour le dépannage et la gestion générale des instances.

Tout comme vous pouvez réinitialiser un ordinateur en appuyant sur le bouton approprié, vous pouvez réinitialiser les instances EC2 en utilisant la console, l'interface ligne de commande ou l'API d'Amazon EC2. Pour de plus amples informations, veuillez consulter [Redémarrez votre EC2 instance Amazon](ec2-instance-reboot.md).

## Sortie de la console de l’instance
<a name="instance-console-console-output"></a>

La sortie de la console est un outil de valeur pour le diagnostic des problèmes. Elle est particulièrement utile pour la résolution des problèmes liés au noyau et à la configuration des services qui pourraient mettre fin à une instance ou la rendre inaccessible avant que son programme fantôme SSH ne puisse être démarré. 
+ **Instances Linux** – La sortie de la console de l'instance affiche exactement la sortie de la console qui serait normalement affichée sur un moniteur physique relié à un ordinateur. La sortie de la console renvoie des informations mises en mémoire tampon qui ont été publiées après un état de transition d’instance (démarrage, arrêt, redémarrage et résiliation). La sortie publiée n’est pas continuellement mise à jour, uniquement lorsqu’elle est probablement très bénéfique.
+ **Instances Windows** – La sortie de la console d'instance inclut les trois dernières erreurs du journal des événements système.

Seul le propriétaire de l’instance peut accéder à la sortie de la console.

Vous pouvez récupérer la dernière sortie de la console série pendant le cycle de vie de l'instance. Cette option est prise en charge uniquement sur les [instances basées sur Nitro](instance-types.md#instance-hypervisor-type).

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

**Pour obtenir la sortie de la console**

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**.

1. Sélectionnez l’instance.

1. Sélectionnez **Actions**, **Surveiller et dépanner**, **Obtenir le journal système**.

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

**Pour obtenir la sortie de la console**  
Utilisez la commande [get-console-output](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-console-output.html).

```
aws ec2 get-console-output --instance-id i-1234567890abcdef0
```

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

**Pour obtenir la sortie de la console**  
Utilisez l’applet de commande [Get-EC2ConsoleOutput](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2ConsoleOutput.html).

```
Get-EC2ConsoleOutput -InstanceId i-1234567890abcdef0
```

------

## Création d’une capture d’écran d’une instance inaccessible
<a name="instance-console-screenshot"></a>

Si vous ne parvenez pas à vous connecter à votre instance, vous pouvez effectuer une capture d'écran de votre instance et l'afficher sous forme d'image. Cette image permet de voir le statut de l’instance et de résoudre le problème plus rapidement.

Vous pouvez générer des captures d’écran pendant que l’instance s’exécute ou après son blocage. L’image est générée au format JPG et ne dépasse pas 100 Ko. Aucun coût de transfert de données n’est facturé pour la capture d’écran.

**Limites**

Cette fonctionnalité n’est pas prise en charge dans les cas suivants :
+ Instances matériel nu (instances de type `*.metal`)
+ L’instance utilise un pilote NVIDIA GRID
+ [Instances alimentées par des processeurs Graviton basés sur Arm](https://aws.amazon.com/ec2/graviton/#EC2_Instances_Powered_by_AWS_Graviton_Processors)
+ Instances Windows activées AWS Outposts
+ Instances Windows sur les Zones AWS Locales

**Prise en charge de la région**

Cette fonctionnalité est disponible dans les régions suivantes :
+ Asie-Pacifique (Thaïlande)
+ Mexique (Centre)
+ GovCloud Régions

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

**Obtention d’une capture d’écran 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, choisissez **Instances**.

1. Sélectionnez l’instance à capturer.

1. Sélectionnez **Actions**, **Surveiller et dépanner** puis **Obtenir la capture d’écran d’instance**.

1. Sélectionnez **Télécharger**ou cliquez avec le bouton droit sur l’image pour la télécharger et l’enregistrer.

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

**Création d’une capture d’écran d’instance**  
Utilisez la commande [get-console-screenshot](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-console-screenshot.html). Le résultat est codé en base64.

```
aws ec2 get-console-screenshot --instance-id i-1234567890abcdef0
```

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

**Création d’une capture d’écran d’instance**  
Utilisez l’applet de commande [Get-EC2ConsoleScreenshot](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2ConsoleScreenshot.html). Le résultat est codé en base64.

```
Get-EC2ConsoleScreenshot -InstanceId i-1234567890abcdef0
```

------

# Captures d'écran courantes pour résoudre les problèmes liés aux instances Windows inaccessibles
<a name="ics-common"></a>

Aidez-vous des informations suivantes pour faciliter le dépannage d’une instance Windows inaccessible grâce aux captures d’écran renvoyées par le service.
+ [Écran de connexion (Ctrl\$1Alt\$1Suppr)](#logon-screen) 
+ [Écran de la console de récupération](#recovery-console-screen) 
+ [Écran du gestionnaire de démarrage Windows](#boot-manager-screen) 
+ [Écran Sysprep](#sysprep-screen) 
+ [Écran de préparation](#getting-ready-screen) 
+ [Écran Windows Update](#windows-update-screen) 
+ [Chkdsk](#Chkdsk) 

## Écran de connexion (Ctrl\$1Alt\$1Suppr)
<a name="logon-screen"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Écran de connexion.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-1.png)


Si une instance devient inaccessible au cours de la connexion, le problème peut venir de votre configuration réseau ou des services Bureau à distance de Windows. Une instance peut également ne pas réagir si un processus utilise une quantité de mémoire important. 

### Configuration réseau
<a name="network-config"></a>

Utilisez les informations suivantes pour vérifier que votre configuration réseau AWS, celle de Microsoft Windows et celle de votre réseau local (ou local) ne bloquent pas l'accès à l'instance.


**AWS configuration réseau**  

| Configuration | Vérifier | 
| --- | --- | 
| Configuration du groupe de sécurité | Vérifiez que le port 3389 est ouvert pour votre groupe de sécurité. Vérifiez que vous vous connectez à l’adresse IP publique appropriée. Si l’instance n’a pas été associée à une EIP, l’adresse IP publique change après l’arrêt ou le démarrage de l’instance. Pour de plus amples informations, veuillez consulter [Le service Bureau à distance ne peut pas se connecter à l’ordinateur distant](troubleshoot-connect-windows-instance.md#rdp-issues). | 
| Configuration VPC (réseau) ACLs | Vérifiez que la liste de contrôle d’accès (ACL) de votre Amazon VPC ne bloque pas l’accès. Pour plus d'informations, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le guide de l'utilisateur Amazon VPC. | 
| Configuration VPN | Si vous vous connectez au VPC à l’aide d’un réseau privé virtuel (VPN), vérifiez la connectivité du tunnel VPN. Pour plus d'informations, consultez [Résolution des problèmes liés AWS au VPN du client : problèmes de connectivité du tunnel avec un VPC](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/VPNTunnelConnectivityTroubleshooting.html). | 


**Configuration du réseau Windows**  

| Configuration | Vérifier | 
| --- | --- | 
| Pare-feu Windows | Vérifiez que le pare-feu Windows ne bloque pas les connexions à votre instance. Désactivez le pare-feu Windows, comme décrit à l’étape 7 de la section de résolution des problèmes liés au service Bureau à distance, [Le service Bureau à distance ne peut pas se connecter à l’ordinateur distant](troubleshoot-connect-windows-instance.md#rdp-issues).  | 
|  TCP/IP Configuration avancée (utilisation d'une adresse IP statique) | L’instance peut ne pas réagir flottee que vous avez configuré une adresse IP statique. Pour un VPC, [créez une interface réseau](create-network-interface.md) et [attachez-la à l’instance](network-interface-attachments.md#attach_eni).  | 

**Configuration réseau locale ou sur site**

Vérifiez qu’une configuration réseau locale ne bloque pas l’accès. Essayez de vous connecter à une autre instance du même VPC comme l’instance inaccessible. Si vous ne parvenez pas à accéder à une autre instance, contactez votre administrateur de réseau local pour déterminer si une politique locale restreint l’accès.

### Problème lié aux services Bureau à distance
<a name="rds-issue"></a>

Si l’instance n’est pas accessible lors de la connexion, le problème peut venir des services RDS sur l’instance.

**Astuce**  
Vous pouvez utiliser le runbook `AWSSupport-TroubleshootRDP` pour vérifier et modifier divers paramètres susceptibles d’affecter les connexions RDP (Remote Desktop Protocol). Pour plus d’informations, consultez [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootrdp.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootrdp.html) dans la référence *AWS Systems Manager Automation runbook*.


**Configuration des services Bureau à distance (RDS)**  

| Configuration | Vérifier | 
| --- | --- | 
| Le service RDS est en cours d’exécution | Vérifiez que le service RDS est exécuté sur l’instance. Connectez-vous à l’instance via le composant logiciel enfichable Services (services.msc) de Microsoft Management Console (MMC). Dans la liste des services, vérifiez que Services Bureau à distance est défini sur En cours d’exécution. Si ce n’est pas le cas, démarrez-le, puis définissez le type de démarrage sur Automatique. Si vous ne parvenez pas à vous connecter à l’instance en utilisant le composant logiciel enfichable Services, détachez le volume racine de l’instance, créez un instantané ou une AMI du volume, attachez le volume d’origine à une autre instance dans la même zone de disponibilité en tant que volume secondaire et modifiez la clé de registre [Start](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959920(v=technet.10)). Lorsque vous avez terminé, rattachez le volume racine à l’instance d’origine. | 
| Le service RDS est activé |  Même si le service a été lancé, il peut être désactivé. Détachez le volume racine de l’instance, prenez un instantané du volume ou créez une AMI, attachez le volume d’origine à une autre instance dans la même zone de disponibilité en tant que volume secondaire, puis activez le service en modifiant la clé de registre **Terminal Server** comme décrit dans [Activation du Bureau à distance sur une instance EC2 avec le Registre à distance](troubleshoot-connect-windows-instance.md#troubleshooting-windows-rdp-remote-registry). Lorsque vous avez terminé, rattachez le volume racine à l’instance d’origine.  | 

### Utilisation élevée du processeur
<a name="high-cpu"></a>

Vérifiez la métrique **CPUUtilization (maximale)** sur votre instance à l'aide d'Amazon CloudWatch. Si **CPUUtilization (Maximum)** est un nombre élevé, attendez que le processeur tombe en panne et essayez de vous reconnecter. Une utilisation élevée de l’UC a plusieurs origines possibles :
+ Windows Update
+ Analyse des logiciels de sécurité
+ Script de démarrage personnalisé
+ Planificateur de tâches

Pour plus d'informations, consultez [Obtenir des statistiques pour une ressource spécifique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SingleMetricPerInstance.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Pour des conseils de dépannage supplémentaires, consultez la page [Utilisation élevée de l'UC peu après le démarrage de Windows (instances Windows uniquement)](troubleshooting-launch.md#high-cpu-issue).

## Écran de la console de récupération
<a name="recovery-console-screen"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Capture d’écran de la console de récupération.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-2.png)


Le système d’exploitation peut démarrer dans la console de récupération et rester bloqué dans cet état si la stratégie `bootstatuspolicy` n’est pas définie sur `ignoreallfailures`. Utilisez la procédure suivante pour remplacer la configuration `bootstatuspolicy` par `ignoreallfailures`.

Par défaut, la configuration de politique pour les fenêtres publiques AMIs fournie par AWS est définie sur`ignoreallfailures`.

1. Arrêtez l’instance inaccessible.

1. Créez un instantané du volume racine. Le volume racine est attaché à l’instance en tant que `/dev/sda1`. 

   Détachez le volume racine de l’instance inaccessible, créez un instantané ou une AMI du volume et attachez-le à une autre instance dans la même zone de disponibilité en tant que volume secondaire.
**Avertissement**  
Si votre instance temporaire et l’instance d’origine sont lancées grâce à la même AMI, vous devez effectuer des étapes supplémentaires ou vous ne pourrez pas démarrer l’instance d’origine après la restauration de son volume racine en raison d’une collision de signature de disque. Si vous devez créer une instance temporaire à l’aide de la même AMI pour éviter une collision de signature de disque, complétez les étape en [Collision de signature de disque](win-ts-common-issues.md#disk-signature-collision).  
Sinon, sélectionnez une autre AMI pour l’instance temporaire. Par exemple, si l’instance d’origine utilise une AMI Windows pour Windows Server 2016, lancez l’instance temporaire à l’aide d’une AMI pour Windows Server 2019.

1. Connectez-vous à l’instance et exécutez la commande suivante à partir d’une invite de commande pour remplacer la configuration `bootstatuspolicy` par `ignoreallfailures`.

   ```
   bcdedit /store Drive Letter:\boot\bcd /set {default} bootstatuspolicy ignoreallfailures
   ```

1. Rattachez le volume à l’instance inaccessible et redémarrez cette dernière.

## Écran du gestionnaire de démarrage Windows
<a name="boot-manager-screen"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Écran du gestionnaire de démarrage Windows.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-3.png)


Le système d'exploitation a subi une corruption fatale dans le fichier système and/or du registre. Lorsque l’instance est bloquée dans cet état, vous devez récupérer l’instance à partir d’une AMI de sauvegarde récente ou lancer une instance de remplacement. Si vous devez accéder aux données de l’instance, détachez les volumes racines de l’instance inaccessible, créez un instantané ou une AMI de ces volumes et attachez-les à une autre instance dans la même zone de disponibilité en tant que volume secondaire.

## Écran Sysprep
<a name="sysprep-screen"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Écran Sysprep.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-4.png)


Cet écran peut s'afficher si vous n'avez pas utilisé le service EC2 Config pour appeler Sysprep ou si le système d'exploitation a échoué lors de l'exécution de Sysprep. Vous pouvez réinitialiser le mot de passe à l'aide de [EC2Rescue](Windows-Server-EC2Rescue.md). Sinon, consultez [Créer une AMI Amazon EC2 à l’aide de Windows Sysprep](ami-create-win-sysprep.md).

## Écran de préparation
<a name="getting-ready-screen"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Écran de préparation.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-5.png)


Actualisez le service de capture d’écran de la console d’instance plusieurs fois pour vérifier que l’anneau de progression tourne. Si l’anneau tourne, attendez que le système d’exploitation démarre. Vous pouvez également vérifier la métrique **CPUUtilization (maximale)** sur votre instance en utilisant Amazon CloudWatch pour vérifier si le système d'exploitation est actif. Si l’anneau de progression ne tourne pas, l’instance est peut-être bloquée au niveau du processus de démarrage. Redémarrez l’instance. Si le redémarrage ne résout pas le problème, récupérez l’instance à partir d’une AMI de sauvegarde récente ou lancez une instance de remplacement. Si vous avez besoin d’accéder aux données de l’instance, détachez le volume racine de l’instance inaccessible et créez un instantané ou une AMI du volume. Attachez-le ensuite à une autre instance de la même zone de disponibilité en tant que volume secondaire.

## Écran Windows Update
<a name="windows-update-screen"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Écran Windows Update.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-6.png)


Le processus Windows Update met à jour le registre. Attendez que la mise à jour soit terminée. Ne redémarrez ou n’arrêtez pas l’instance, car cela peut entraîner une corruption des données au cours de la mise à jour.

**Note**  
Le processus Windows Update peut utiliser des ressources sur le serveur au cours de la mise à jour. Si vous rencontrez souvent ce problème, pensez à utiliser des types d’instance et des volumes EBS plus rapides. 

## Chkdsk
<a name="Chkdsk"></a>

Le service de capture d’écran de la console a renvoyé ce qui suit.

![\[Écran Chkdsk.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/ts-cs-7.png)


Windows exécute l’outil système chkdsk sur le disque pour vérifier l’intégrité du système de fichiers et pour corriger les erreurs système des fichiers logiques. Attendez que le processus se termine.

## Récupération d’instance en cas de plantage de l’ordinateur hôte
<a name="instance-machine-failure"></a>

S’il existe un problème irrécupérable lié au matériel d’un ordinateur hôte sous-jacent, AWS peut planifier un évènement d’arrêt d’instance. Vous êtes averti d’un tel événement en avance par e-mail.

**Pour récupérer une instance basée sur Amazon EBS en cours d’exécution sur un ordinateur hôte qui a planté**

1. Sauvegardez les données importantes qui se trouvent sur les volumes de stockage d’instance sur Amazon EBS ou Amazon S3.

1. Arrêtez l’instance.

1. Démarrez l’instance.

1. Restaurez toutes les données importantes.

Pour de plus amples informations, veuillez consulter [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md).

**Pour récupérer une instance avec un volume racine de stockage d’instance s’exécutant sur un ordinateur hôte défaillant**

1. Créez une AMI à partir de l’instance.

1. Chargez l’image vers Amazon S3.

1. Sauvegardez les données importantes sur Amazon EBS ou Amazon S3.

1. Mettez fin à l’instance.

1. Lancez une nouvelle instance depuis l’AMI.

1. Restaurez toutes les données importantes sur la nouvelle instance.

## L’instance est apparue hors ligne et a redémarré de façon inattendue
<a name="troubleshoot-unavailable-instance-unexpected-reboot"></a>

Si votre instance semble avoir été déconnectée puis redémarrée inopinément, il se peut qu’elle ait fait l’objet d’une récupération automatique des instances. Cela se produit lorsqu'il est AWS détecté que l'instance n'est pas disponible en raison d'un problème matériel ou logiciel sous-jacent et que la restauration automatique simplifiée ou la restauration basée sur l' CloudWatch action est activée sur l'instance.

Au cours du processus de restauration, AWS tente de rétablir la disponibilité de l'instance en la migrant vers un autre matériel. Pour vérifier si la récupération automatique des instances a eu lieu pour votre instance, consultez la section [Vérification de l’occurrence d’une récupération automatique des instances](verify-if-automatic-recovery-occurred.md).

**Note**  
Si votre charge de travail ou votre application ne répond pas, vérifiez si elle s’exécute sur l’instance. Si ce n’est pas le cas, démarrez-la manuellement. Pour éviter que ce problème ne se reproduise à l’avenir, mettez en œuvre un plan de restauration afin de garantir le bon fonctionnement de votre charge de travail ou de votre application après la restauration de l’instance.

# Résoudre les problèmes de connexion à votre instance Amazon EC2 Linux
<a name="TroubleshootingInstancesConnecting"></a>

Les informations suivantes et les erreurs courantes peuvent vous aider à résoudre les problèmes de connexion à votre instance Linux. 

**Topics**
+ [Causes courantes des problèmes de connexion](#TroubleshootingInstancesCommonCauses)
+ [Erreur de connexion à votre instance : connexion expirée](#TroubleshootingInstancesConnectionTimeout)
+ [Erreur : impossible de charger la clé... Attente : N'IMPORTE QUELLE CLÉ PRIVÉE](#troubleshoot-instance-connect-key-file)
+ [Erreur : clé de l'utilisateur non reconnue par le serveur](#TroubleshootingInstancesServerError)
+ [Erreur : autorisation refusée ou connexion fermée par [instance] port 22](#TroubleshootingInstancesConnectingSSH)
+ [Erreur : fichier de clé privée non protégé](#troubleshoot-unprotected-key)
+ [Erreur : La clé privée doit commencer par « -----BEGIN RSA PRIVATE KEY----- » et se terminer par « -----END RSA PRIVATE KEY----- »](#troubleshoot-private-key-file-format)
+ [Erreur : échec de la vérification de la clé d’hôte](#troubleshoot-host-key-verification-failed)
+ [Erreur : le serveur a refusé notre clé *ou* Aucune méthode d'authentification prise en charge disponible](#TroubleshootingInstancesConnectingPuTTY)
+ [Impossible d'envoyer une commande ping à l'instance](#troubleshoot-instance-ping)
+ [Erreur : le serveur a fermé la connexion réseau de manière inopinée](#troubleshoot-ssh)
+ [Erreur : échec de la validation de la clé d'hôte pour EC2 Instance Connect](#troubleshoot-host-key-validation)
+ [Impossible de se connecter à une instance Ubuntu à l'aide de EC2 Instance Connect](#troubleshoot-eic-ubuntu)
+ [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?](#replacing-lost-key-pair)

## Causes courantes des problèmes de connexion
<a name="TroubleshootingInstancesCommonCauses"></a>

Nous vous recommandons de commencer à résoudre les problèmes de connexion aux instances en vérifiant que vous avez correctement effectué les tâches suivantes.

**Vérifiez le nom d'utilisateur de votre instance**  
Vous pouvez vous connecter à votre instance en utilisant le nom d'utilisateur de votre compte utilisateur ou le nom d'utilisateur par défaut de l'AMI que vous avez utilisée pour lancer votre instance.  
+ **Obtenez le nom d’utilisateur de votre compte utilisateur.**

  Pour plus d’informations sur la création d’un compte utilisateur, consultez [Gérez les utilisateurs du système sur votre instance Amazon EC2 Linux](managing-users.md).
+ **Obtenir le nom d’utilisateur par défaut pour l’AMI que vous avez utilisée pour lancer votre instance**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)

**Vérifiez que les règles de votre groupe de sécurité autorisent le trafic**  
Vérifiez que le groupe de sécurité associé à votre instance autorise le trafic SSH entrant à partir de votre adresse IP. Le groupe de sécurité par défaut pour le VPC n'autorise pas le trafic SSH entrant par défaut. Le groupe de sécurité créé par l'assistant de lancement d'instance autorise le trafic SSH entrant par défaut. Pour savoir comment ajouter une règle pour le trafic SSH entrant vers votre instance Linux, consultez [Règles pour la connexion à des instances à partir de votre ordinateur](security-group-rules-reference.md#sg-rules-local-access). Pour connaître les étapes à vérifier, consultez [Erreur de connexion à votre instance : connexion expirée](#TroubleshootingInstancesConnectionTimeout).

**Vérifiez que votre instance est prête**  
Après avoir lancé une instance, il peut s'écouler quelques minutes avant que l'instance ne soit prête à accepter des demandes de connexion. Vérifiez votre instance pour vous assurer qu'elle est en cours d'exécution et qu'elle a réussi ses vérifications d'état.  

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

1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance.

1. Vérifiez les paramètres suivants :

   1. Dans la colonne **État de l'instance**, vérifiez que l'état de votre instance est `running`.

   1. Dans la colonne **Contrôle des statuts**, vérifiez que votre instance a passé avec succès tous les contrôles de statut.

**Vérifiez que vous avez répondu à toutes les conditions préalables pour vous connecter.**  
Assurez-vous de disposer de toutes les informations dont vous avez besoin pour vous connecter. Pour de plus amples informations, veuillez consulter [Se connecter à votre instance Linux à l’aide de SSH](connect-to-linux-instance.md).  
**Connexion à partir de Linux ou macOS X**  
Si le système d'exploitation de votre ordinateur local est Linux ou macOS X, vérifiez les conditions préalables spécifiques à la connexion à une instance Linux suivantes :
+ [Client SSH](connect-linux-inst-ssh.md)
+ [EC2 Instance Connect](connect-linux-inst-eic.md)
+ [AWS Systems Manager Gestionnaire de sessions](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
**Connexion à partir de Windows**  
Si le système d'exploitation de votre ordinateur local est Windows, vérifiez les conditions préalables spécifiques à la connexion à une instance Linux suivantes :
+ [OpenSSH](connect-linux-inst-ssh.md)
+ [PuTTY](connect-linux-inst-from-windows.md)
+ [AWS Systems Manager Gestionnaire de sessions](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [WSL (Windows Subsystem for Linux)](connect-linux-inst-ssh.md)

**Vérifiez si l'instance est une instance gérée**  
Les connexions initiées par l'utilisateur aux instances gérées ne sont pas autorisées. Pour déterminer si l'instance est gérée, recherchez le champ **Géré** correspondant à l'instance. Si la valeur est **vraie**, il s'agit d'une instance gérée. Pour de plus amples informations, veuillez consulter [Instances gérées Amazon EC2](amazon-ec2-managed-instances.md).

## Erreur de connexion à votre instance : connexion expirée
<a name="TroubleshootingInstancesConnectionTimeout"></a>

Si vous essayez de vous connecter à votre instance et vous obtenez le message d'erreur `Network error: Connection timed out` ou `Error connecting to [instance], reason: -> Connection timed out: connect`, essayez ce qui suit :

**Vérifiez les règles du groupe de sécurité.**  
Vous avez besoin d'une règle de groupe de sécurité qui autorise le trafic entrant depuis l' IPv4 adresse publique de votre ordinateur local sur le port approprié.

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

1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance.

1. Sous l'onglet **Sécurité** au bas de la page de la console, sous **Règles entrantes**, vérifiez la liste des règles en vigueur pour l'instance sélectionnée. Vérifiez qu'il existe une règle qui autorise le trafic de votre ordinateur local vers le port 22 (SSH).

   Si votre groupe de sécurité ne possède pas de règle qui permet le trafic entrant à partir de votre ordinateur local, ajoutez une règle à votre règle de sécurité. Pour de plus amples informations, veuillez consulter [Règles pour la connexion à des instances à partir de votre ordinateur](security-group-rules-reference.md#sg-rules-local-access).

1. Pour connaître la règle qui autorise le trafic entrant, consultez la**Source**. Si la valeur est une adresse IP unique et si l'adresse IP n'est pas statique, une nouvelle adresse IP sera attribuée chaque fois que vous redémarrerez votre ordinateur. Cela aura pour conséquence que la règle n'inclut pas le trafic d'adresses IP de votre ordinateur. Il se peut que l'adresse IP ne soit pas statique si votre ordinateur est sur un réseau d'entreprise, si vous vous connectez via un fournisseur de services Internet (ISP), ou si l'adresse IP de votre ordinateur est dynamique et change chaque fois que vous redémarrez votre ordinateur. Pour vous assurer que votre règle de groupe de sécurité autorise le trafic entrant provenant de votre ordinateur local, au lieu de spécifier une adresse IP unique pour**Source**, au lieu de spécifier la plage d'adresses IP utilisées par vos ordinateurs clients.

   Pour plus d'informations sur les règles des groupes de sécurité, consultez la rubrique [Règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l'utilisateur de Amazon VPC*.

**Vérifiez la table de routage pour le sous-réseau.**  
Vous avez besoin d'un itinéraire qui envoie tout le trafic destiné à l'extérieur du VPC vers la passerelle Internet du VPC.

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

1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance.

1. Sous l'onglet **Mise en réseau**, notez les valeurs de l'**ID VPC** et de l'**ID de sous-réseau**.

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

1. Dans le panneau de navigation, choisissez **Passerelles Internet**. Vérifiez qu'il existe une passerelle Internet attachée à votre VPC. Sinon, choisissez **Créer une passerelle Internet**, entrez un nom pour la passerelle Internet et choisissez **Créer une passerelle Internet**. Ensuite, pour la passerelle Internet que vous avez créée, choisissez **Actions**, **Attacher au VPC**, sélectionnez votre VPC, puis choisissez **Attacher la passerelle Internet** pour l'attacher à votre VPC.

1. Dans le panneau de navigation, sélectionnez **Sous-réseaux**, puis sélectionnez votre sous-réseau.

1. Dans l'onglet **Table de routage**, vérifiez qu'il existe une route avec `0.0.0.0/0` comme destination et la passerelle Internet pour votre VPC comme cible. Si vous vous connectez à votre instance à l'aide de son IPv6 adresse, vérifiez qu'il existe un itinéraire pour tout le IPv6 trafic (`::/0`) qui pointe vers la passerelle Internet. Sinon, procédez comme suit :

   1. Choisissez l’ID de la table de routage (rtb-*xxxxxxxx*) pour accéder à cette dernière.

   1. Dans l’onglet **Routes**, choisissez **Edit routes (Modifier les routes)**. Choisissez **Add route (Ajouter une route)** et utilisez `0.0.0.0/0` comme destination et la passerelle Internet comme cible. Pour IPv6, choisissez **Ajouter un itinéraire**, utilisez `::/0` comme destination et la passerelle Internet comme cible.

   1. Choisissez **Save routes (Enregistrer les routes)**.

**Vérifiez la liste de contrôle d'accès (ACL) du réseau pour le sous-réseau.**

Le réseau ACLs doit autoriser le trafic SSH entrant depuis votre adresse IP locale sur le port 22. Elles doivent également autoriser le trafic sortant vers les ports éphémères (1024-65535).

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

1. Dans le volet de navigation, choisissez **Subnets**.

1. Sélectionnez votre sous-réseau.

1. Dans la page **ACL réseau**, pour **Règles entrantes**, vérifiez que les règles autorisent le trafic entrant à partir de votre ordinateur sur le port requis. Sinon, supprimez ou modifiez la règle qui bloque le trafic.

1. Pour **Règles sortantes**, vérifiez que les règles autorisent le trafic vers votre ordinateur sur les ports éphémères. Sinon, supprimez ou modifiez la règle qui bloque le trafic.

**Si votre ordinateur se trouve sur un réseau d'entreprise**  
Demandez à votre administrateur réseau si le pare-feu interne autorise le trafic entrant et sortant de votre ordinateur sur le port 22.

Si votre ordinateur est équipé d'un pare-feu, vérifiez qu'il autorise le trafic entrant et sortant de votre ordinateur sur le port 22.

**Vérifiez que votre instance possède une IPv4 adresse publique.**  
Si non, vous pouvez associer une adresse IP Elastic à votre instance. Pour de plus amples informations, veuillez consulter [Adresses IP élastiques](elastic-ip-addresses-eip.md). 

**Vérifiez la charge de l'UC sur votre instance. Il se peut que le serveur soit surchargé.**  
AWS fournit automatiquement des données telles que CloudWatch les métriques Amazon et le statut de l'instance, que vous pouvez utiliser pour connaître la charge du processeur de votre instance et, si nécessaire, ajuster la manière dont vos charges sont gérées. Pour de plus amples informations, veuillez consulter [Surveillez vos instances à l'aide de CloudWatch](using-cloudwatch.md).
+ Si votre charge est variable, vous pouvez automatiquement effectuer des mises à l'échelle ascendantes et descendantes de vos instances en utilisant l'[Auto Scaling](https://aws.amazon.com/autoscaling/) et l'[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/). 
+ Si votre charge augmente régulièrement, vous pouvez passer à un type d'instance plus important. Pour de plus amples informations, veuillez consulter [Changements de type d'instance Amazon EC2](ec2-instance-resize.md). 

**Pour vous connecter à votre instance à l'aide d'une IPv6 adresse, vérifiez les points suivants :**
+ Votre sous-réseau doit être associé à une table de routage comportant une route pour le IPv6 trafic (`::/0`) vers une passerelle Internet. 
+ Les règles de votre groupe de sécurité doivent autoriser le trafic entrant depuis votre IPv6 adresse locale sur le port 22.
+ Les règles ACL de votre réseau doivent autoriser le trafic entrant et sortant IPv6 .
+ Si vous avez lancé votre instance à partir d'une ancienne AMI, elle n'est peut-être pas configurée pour DHCPv6 (les IPv6 adresses ne sont pas automatiquement reconnues sur l'interface réseau). Pour plus d'informations, consultez la section [Configurer IPv6 sur vos instances](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-dhcpv6) dans le guide de l'*utilisateur Amazon VPC*.
+ Votre ordinateur local doit avoir une IPv6 adresse et doit être configuré pour être utilisé IPv6.

## Erreur : impossible de charger la clé... Attente : N'IMPORTE QUELLE CLÉ PRIVÉE
<a name="troubleshoot-instance-connect-key-file"></a>

Si vous essayez de vous connecter à votre instance et obtenez le message d'erreur `unable to load key ... Expecting: ANY PRIVATE KEY`, le fichier dans lequel la clé privée est stockée est mal configuré. Si le fichier de clé privée se termine par `.pem`, il est peut-être toujours mal configuré. Une cause possible de configuration incorrecte d'un fichier de clé privée est l'absence d'un certificat.

**Si le fichier de clé privée est mal configuré, suivez ces étapes pour corriger l'erreur.**

1. Créez une nouvelle paire de clés. Pour de plus amples informations, veuillez consulter [Créer une paire de clés à l’aide d’Amazon EC2](create-key-pairs.md#having-ec2-create-your-key-pair).
**Note**  
Sinon, vous pouvez créer une nouvelle key pair à l'aide d'un outil tiers. Pour de plus amples informations, veuillez consulter [Créer une paire de clés à l’aide d’un outil tiers et importer la clé publique dans Amazon EC2](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws).

1. Ajoutez la nouvelle paire de clés à votre instance. Pour de plus amples informations, veuillez consulter [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?](#replacing-lost-key-pair).

1. Connectez-vous à votre instance à l'aide de la nouvelle paire de clés.

## Erreur : clé de l'utilisateur non reconnue par le serveur
<a name="TroubleshootingInstancesServerError"></a>

**Si vous utilisez SSH pour vous connecter à votre instance**
+ Utilisez `ssh -vvv` pour obtenir des informations très détaillées sur le débogage en vous connectant :

  ```
  ssh -vvv -i path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com
  ```

  L'exemple de données de sortie suivant montre que vous pouvez voir si vous étiez en train de vous connecter à votre instance avec une clé qui n'était pas reconnue par le serveur.

  ```
  open/ANT/myusername/.ssh/known_hosts).
  debug2: bits set: 504/1024
  debug1: ssh_rsa_verify: signature correct
  debug2: kex_derive_keys
  debug2: set_newkeys: mode 1
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug2: set_newkeys: mode 0
  debug1: SSH2_MSG_NEWKEYS received
  debug1: Roaming not allowed by server
  debug1: SSH2_MSG_SERVICE_REQUEST sent
  debug2: service_accept: ssh-userauth
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug2: key: boguspem.pem ((nil))
  debug1: Authentications that can continue: publickey
  debug3: start over, passed a different list publickey
  debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
  debug3: authmethod_lookup publickey
  debug3: remaining preferred: keyboard-interactive,password
  debug3: authmethod_is_enabled publickey
  debug1: Next authentication method: publickey
  debug1: Trying private key: boguspem.pem
  debug1: read PEM private key done: type RSA
  debug3: sign_and_send_pubkey: RSA 9c:4c:bc:0c:d0:5c:c7:92:6c:8e:9b:16:e4:43:d8:b2
  debug2: we sent a publickey packet, wait for reply
  debug1: Authentications that can continue: publickey
  debug2: we did not send a packet, disable method
  debug1: No more authentication methods to try.
  Permission denied (publickey).
  ```

**Si vous utilisez PuTTY pour vous connecter à votre instance**
+ Vérifiez que votre fichier de clé privée (.pem) a été converti au format reconnu par PuTTY (.ppk). Pour plus d'informations sur la conversion de votre clé privée, consultez [Connectez-vous à votre instance Linux à l’aide de PuTTY](connect-linux-inst-from-windows.md).
**Note**  
Dans PuTTYgen, chargez votre fichier de clé privée et sélectionnez **Enregistrer la clé privée** plutôt que **Générer**. 
+ Vérifiez que vous vous connectez avec le nom d'utilisateur approprié pour votre AMI. Saisissez le nom d'utilisateur dans la case **Nom d'hôte** de la fenêtre **Configuration de PuTTY**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)
+ Vérifiez que vous avez une règle entrante de groupe de sécurité pour permettre le trafic entrant vers le port approprié. Pour de plus amples informations, veuillez consulter [Règles pour la connexion à des instances à partir de votre ordinateur](security-group-rules-reference.md#sg-rules-local-access). 

## Erreur : autorisation refusée ou connexion fermée par [instance] port 22
<a name="TroubleshootingInstancesConnectingSSH"></a>

Si vous vous connectez à votre instance à l'aide de SSH et que vous obtenez l'une des erreurs suivantes : `Host key not found in [directory]`, `Permission denied (publickey)`, `Authentication failed, permission denied` ou `Connection closed by [instance] port 22`, vérifiez que vous vous connectez avec le nom d'utilisateur approprié pour votre AMI *et* que vous avez indiqué le bonne clé privée (fichier `.pem)` pour votre instance).

Les noms d'utilisateur appropriés sont les suivants :


| AMI utilisée pour lancer l’instance | Nom d’utilisateur par défaut | 
| --- | --- | 
|  Amazon Linux  | ec2-user  | 
| CentOS | centos ou ec2-user | 
| Debian | admin | 
| Fedora  | fedora ou ec2-user | 
| FreeBSD | ec2-user | 
| RHEL | ec2-user ou root | 
| SUSE  | ec2-user ou root | 
| Ubuntu  | ubuntu | 
| Oracle  | ec2-user | 
| Bitnami  | bitnami | 
| Rocky Linux  | rocky | 
| Autre | Vérifiez auprès du fournisseur de l'AMI | 

Pa exemple, pour utiliser un client SSH et vous connecter à une instance Amazon Linux, utilisez la commande suivante :

```
ssh -i /path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com
```

Confirmez que vous utilisez le fichier de clé privée qui correspond à la paire de clés que vous avez sélectionnée lorsque vous avez lancé 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**, puis sélectionnez votre instance.

1. Sous l'onglet **Détails**, sous **Détails de l'instance**, vérifiez la valeur **Nom de la paire de clés**.

1. Si vous n'avez pas spécifié une paire de clés lorsque vous avez lancé l'instance, vous pouvez mettre fin à l'instance et lancer une nouvelle instance en vous assurant de spécifier une paire de clés. S'il s'agit d'une instance que vous avez utilisée, mais que vous n'avez plus le fichier `.pem` pour votre paire de clés, vous pouvez remplacer la paire de clés par une nouvelle. Pour de plus amples informations, veuillez consulter [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?](#replacing-lost-key-pair).

Si vous avez généré votre propre paire de clés, assurez-vous que votre générateur de clés est configuré pour créer des clés RSA. Les clés DSA ne sont pas acceptées.

Si vous obtenez une erreur `Permission denied (publickey)` et qu'aucune des réponses ci-dessus ne s'applique (par exemple, vous avez pu vous connecter précédemment), les autorisations sur le répertoire de base de votre instance a peut-être été modifiées. Les autorisations pour `/home/instance-user-name/.ssh/authorized_keys` doivent être limitées au propriétaire uniquement.

**Pour vérifier les autorisations sur votre instance**

1. Arrêtez votre instance et détachez le volume racine. Pour de plus amples informations, veuillez consulter [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md).

1. Lancez une instance temporaire dans la même zone de disponibilité que votre instance actuelle (utilisez une AMI similaire ou la même AMI que vous avez utilisée pour votre instance actuelle) et attachez le volume racine à l'instance temporaire.

1. Connectez-vous à l'instance temporaire, créez un point de montage et montez le volume que vous avez joint.

1. A partir de l'instance temporaire, vérifiez les autorisations du répertoire `/home/instance-user-name/` du volume attaché. Si nécessaire, modifiez les autorisations comme suit :

   ```
   [ec2-user ~]$ chmod 600 mount_point/home/instance-user-name/.ssh/authorized_keys
   ```

   ```
   [ec2-user ~]$ chmod 700 mount_point/home/instance-user-name/.ssh
   ```

   ```
   [ec2-user ~]$ chmod 700 mount_point/home/instance-user-name
   ```

1. Démontez le volume, détachez-le de l'instance temporaire et attachez-le de nouveau à l'instance originale. Assurez-vous que vous avez spécifié le bon nom de périphérique pour le volume racine, par exemple, `/dev/xvda`.

1. Démarrez votre instance. Si vous n'avez plus besoin de l'instance temporaire, vous pouvez la mettre en service.

## Erreur : fichier de clé privée non protégé
<a name="troubleshoot-unprotected-key"></a>

Votre fichier de clé privée doit être protégé des opérations de lecture et d'écriture des autres utilisateurs. Si n'importe qui sauf vous peut lire ou écrire sur votre clé privée, alors SSH ignore votre clé et vous voyez le message d'avertissement suivant.

```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '.ssh/my_private_key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/my_private_key.pem
Permission denied (publickey).
```

Si vous voyez un message similaire lorsque vous essayez de vous connecter à votre instance, examinez la première ligne du message d'erreur pour vérifier que vous utilisez la bonne clé publique pour votre instance. L'exemple ci-dessus utilise la clé privée `.ssh/my_private_key.pem` avec les autorisations sur les fichiers de `0777` ce qui permet à n'importe qui de lire ou écrire sur ce fichier. Ce niveau d'autorisation n'est pas sûr du tout, donc SSH ignore cette clé. 

Si vous vous connectez à partir de macOs ou Linux, exécutez la commande suivante pour corriger cette erreur en remplaçant le chemin par celui de votre fichier de clé privée.

```
[ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem
```

Si vous vous connectez à une instance Linux à partir de Windows, effectuez les étapes suivantes sur votre ordinateur local.

1. Accédez au fichier .pem.

1. Cliquez avec le bouton droit de la souris sur le fichier .pem et sélectionnez**Propriétés**.

1. Choisissez l'onglet **Security (Sécurité)**.

1. Sélectionnez **Avancé**.

1. Vérifiez que vous êtes le propriétaire du fichier. Si ce n'est pas le cas, changez le propriétaire avec votre nom d'utilisateur.

1. Sélectionnez **Désactiver l'héritage** et **Supprimer toutes les autorisations héritées de cet objet**.

1. Sélectionnez **Ajouter**, **Sélectionnez un principal**, saisissez votre nom d'utilisateur et sélectionnez **OK**.

1. À partir de la fenêtre **Entrée d'autorisation**, attribuez les autorisations **Lire** et sélectionnez **OK**.

1. Cliquez sur **Apply** (Appliquer) afin de garantir l'enregistrement de tous les paramètres.

1. Sélectionnez **OK** pour fermer la fenêtre **Paramètres de sécurité avancés**.

1. Sélectionnez **OK** pour fermer la fenêtre **Propriétés**.

1. Vous devriez être en mesure de vous connecter à votre instance Linux à partir de Windows via SSH.

À partir d'une invite de commande Windows, exécutez la commande suivante.

1. À partir de l'invite de commande, accédez à l'emplacement du chemin de fichier de votre fichier .pem.

1. Exécutez la commande suivante pour réinitialiser et supprimer les autorisations explicites :

   ```
   icacls.exe $path /reset
   ```

1. Exécutez la commande suivante pour accorder à l'utilisateur actuel les autorisations de lecture :

   ```
   icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
   ```

1. Exécutez la commande suivante pour désactiver l'héritage et supprimer les autorisations héritées.

   ```
   icacls.exe $path /inheritance:r
   ```

1. Vous devriez être en mesure de vous connecter à votre instance Linux à partir de Windows via SSH.

## Erreur : La clé privée doit commencer par « -----BEGIN RSA PRIVATE KEY----- » et se terminer par « -----END RSA PRIVATE KEY----- »
<a name="troubleshoot-private-key-file-format"></a>

Si vous utilisez un outil tiers, tel que **ssh-keygen**, pour créer une paire de clés RSA, il génère la clé privée au format de clé OpenSSH. Lorsque vous vous connectez à votre instance, si vous utilisez la clé privée au format OpenSSH pour déchiffrer le mot de passe, vous obtenez l'erreur `Private key must begin with "-----BEGIN RSA PRIVATE KEY-----" and end with "-----END RSA PRIVATE KEY-----"`.

Pour résoudre cette erreur, la clé privée doit être au format PEM. Utilisez la commande suivante pour créer la clé privée au format PEM :

```
ssh-keygen -m PEM
```

## Erreur : échec de la vérification de la clé d’hôte
<a name="troubleshoot-host-key-verification-failed"></a>

Cette erreur se produit en cas de discordance entre la clé d’hôte stockée sur l’instance dans le fichier `known_hosts` et sur le client. Par exemple, une incompatibilité peut se produire si vous vous connectez à une instance à l’aide d’une adresse IP publique, puis que vous essayez de vous y reconnecter en utilisant une adresse IP publique différente. Cela peut se produire une fois que vous avez ajouté ou supprimé une adresse IP Elastic, car cela modifie l’adresse IP publique d’une instance.

Pour résoudre cette erreur, commencez par confirmer qu’une modification de la clé d’hôte ou de la configuration réseau de l’instance est attendue. Avant de vous connecter à l’instance, vous pouvez également [vérifier l’empreinte de l’hôte](connection-prereqs-general.md#connection-prereqs-fingerprint). Une fois connecté à l’instance, vous pouvez supprimer l’ancienne clé d’hôte du fichier `known_hosts`. Pour obtenir des instructions, reportez-vous à la documentation de la distribution Linux utilisée sur votre instance.

## Erreur : le serveur a refusé notre clé *ou* Aucune méthode d'authentification prise en charge disponible
<a name="TroubleshootingInstancesConnectingPuTTY"></a>

Si vous utilisez PuTTY pour vous connecter à votre instance et que vous obtenez l'une des erreurs suivantes, Erreur : Le serveur a refusé votre clé ou Erreur : Méthodes d'authentification disponibles non prises en charge, vérifiez que vous vous connectez avec le nom d'utilisateur approprié pour votre AMI. Saisissez le nom d'utilisateur dans **Nom d'utilisateur** de la fenêtre **Configuration de PuTTY**.

Les noms d'utilisateur appropriés sont les suivants :


| AMI utilisée pour lancer l’instance | Nom d’utilisateur par défaut | 
| --- | --- | 
|  Amazon Linux  | ec2-user  | 
| CentOS | centos ou ec2-user | 
| Debian | admin | 
| Fedora  | fedora ou ec2-user | 
| FreeBSD | ec2-user | 
| RHEL | ec2-user ou root | 
| SUSE  | ec2-user ou root | 
| Ubuntu  | ubuntu | 
| Oracle  | ec2-user | 
| Bitnami  | bitnami | 
| Rocky Linux  | rocky | 
| Autre | Vérifiez auprès du fournisseur de l'AMI | 

Vous devez également vérifier que :
+ Utilisez-vous la dernière version de PuTTY. Pour plus d'informations, consultez la [page Web PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/).
+ Votre fichier de clé privée (.pem) a été bien converti au format reconnu par PuTTY (.ppk). Pour plus d'informations sur la conversion de votre clé privée, consultez [Connectez-vous à votre instance Linux à l’aide de PuTTY](connect-linux-inst-from-windows.md).

## Impossible d'envoyer une commande ping à l'instance
<a name="troubleshoot-instance-ping"></a>

La commande `ping` est un type de trafic ICMP. Si vous ne pouvez pas pinger votre instance, assurez-vous que vos règles entrantes de groupe de sécurité autorisent le trafic ICMP pour le message `Echo Request` de toutes les sources, ou de l'ordinateur ou de l'instance à partir desquels vous émettez la commande.

Si vous ne pouvez pas fournir une commande `ping` à partir de votre instance, assurez-vous que vos règles sortantes de groupe de sécurité autorisent le trafic ICMP pour le message `Echo Request` vers toutes les destinations ou vers l'hôte que vous essayez de pinger.

Les commandes `Ping` peuvent également être bloquées par un pare-feu ou un délai d'attente en raison de latence réseau ou de problèmes matériels. Vous devez consulter votre réseau local ou votre administrateur système pour obtenir de l'aide sur la résolution des problèmes supplémentaires.

## Erreur : le serveur a fermé la connexion réseau de manière inopinée
<a name="troubleshoot-ssh"></a>

Si vous vous connectez à votre instance via PuTTY et que vous recevez le message d'erreur « Le serveur a fermé la connexion réseau de manière inopinée », vérifiez que vous avez activé le paramètre keepalive dans la page de Connexion de la Configuration PuTTY, afin d'éviter de vous faire déconnecter. Certains serveurs déconnectent les clients lorsqu'ils n'ont pas reçu de données dans une période de temps spécifiée. Réglez les secondes entre keepalives à 59 secondes. 

Si vous éprouvez encore des difficultés après avoir activé les keepalives, essayez de désactiver l'algorithme de Nagle dans la page de Connexion de la Configuration PuTTY. 

## Erreur : échec de la validation de la clé d'hôte pour EC2 Instance Connect
<a name="troubleshoot-host-key-validation"></a>

Si vous faites pivoter les clés d'hôte de votre instance, les nouvelles clés d'hôte ne sont pas automatiquement téléchargées dans la base de données de clés d'hôte AWS fiables. Cela provoque l'échec de la validation de clé d'hôte lorsque vous essayez de vous connecter à votre instance à l'aide du client EC2 Instance Connect basé sur le navigateur et vous ne parvenez pas à vous connecter à votre instance.

Pour résoudre cette erreur, vous devez exécuter le script `eic_harvest_hostkeys` sur votre instance, qui télécharge votre nouvelle clé d'hôte vers EC2 Instance Connect. Le script se trouve sur `/opt/aws/bin/` sur les instances Amazon Linux 2 et sur `/usr/share/ec2-instance-connect/` sur les instances Ubuntu.

------
#### [ Amazon Linux 2 ]

**Pour résoudre l'erreur de validation de clé d'hôte ayant échoué sur une instance Amazon Linux 2**

1. Connectez-vous à votre instance à l'aide de SSH.

   Vous pouvez vous connecter en utilisant la CLI EC2 Instance Connect ou la paire de clés SSH attribuée à votre instance lors de son lancement, ainsi que le nom d'utilisateur par défaut de l'AMI utilisée pour lancer votre instance. Pour Amazon Linux 2, le nom d’utilisateur par défaut est `ec2-user`.

   Par exemple, si votre instance a été lancée avec Amazon Linux 2, que le nom DNS public de votre instance est `ec2-a-b-c-d.us-west-2.compute.amazonaws.com` et que la paire de clés est `my_ec2_private_key.pem`, utilisez la commande suivante pour établir une connexion SSH à votre instance :

   ```
   $ ssh -i my_ec2_private_key.pem ec2-user@ec2-a-b-c-d.us-west-2.compute.amazonaws.com
   ```

   Pour plus d’informations sur la connexion à votre instance, consultez [Connexion à votre instance Linux à l’aide d’un client SSH](connect-linux-inst-ssh.md).

1. Accédez au dossier suivant.

   ```
   [ec2-user ~]$ cd /opt/aws/bin/
   ```

1. Exécutez la commande suivante sur votre instance. 

   ```
   [ec2-user ~]$ ./eic_harvest_hostkeys
   ```

   Notez qu'un appel réussi n'entraîne pas obligatoirement une sortie.

   Vous pouvez désormais utiliser le client EC2 Instance Connect basé sur le navigateur pour vous connecter à votre instance.

------
#### [ Ubuntu ]

**Pour résoudre l'erreur de validation de clé d'hôte ayant échoué sur une instance Ubuntu**

1. Connectez-vous à votre instance à l’aide de SSH.

   Vous pouvez vous connecter en utilisant la CLI EC2 Instance Connect ou la paire de clés SSH attribuée à votre instance lors de son lancement, ainsi que le nom d'utilisateur par défaut de l'AMI utilisée pour lancer votre instance. Pour Ubuntu, le nom d'utilisateur par défaut est `ubuntu`.

   Par exemple, si votre instance a été lancée avec Ubuntu, que le nom DNS public de votre instance est `ec2-a-b-c-d.us-west-2.compute.amazonaws.com` et que la paire de clés est `my_ec2_private_key.pem`, utilisez la commande suivante pour établir une connexion SSH à votre instance :

   ```
   $ ssh -i my_ec2_private_key.pem ubuntu@ec2-a-b-c-d.us-west-2.compute.amazonaws.com
   ```

   Pour plus d’informations sur la connexion à votre instance, consultez [Connexion à votre instance Linux à l’aide d’un client SSH](connect-linux-inst-ssh.md).

1. Accédez au dossier suivant.

   ```
   [ec2-user ~]$ cd /usr/share/ec2-instance-connect/
   ```

1. Exécutez la commande suivante sur votre instance. 

   ```
   [ec2-user ~]$ ./eic_harvest_hostkeys
   ```

   Notez qu'un appel réussi n'entraîne pas obligatoirement une sortie.

   Vous pouvez désormais utiliser le client EC2 Instance Connect basé sur le navigateur pour vous connecter à votre instance.

------

## Impossible de se connecter à une instance Ubuntu à l'aide de EC2 Instance Connect
<a name="troubleshoot-eic-ubuntu"></a>

Si vous utilisez EC2 Instance Connect pour vous connecter à votre instance Ubuntu et que vous obtenez une erreur lorsque vous tentez de vous connecter, vous pouvez utiliser les informations suivantes pour tenter de résoudre le problème.

**Cause possible**

Le package `ec2-instance-connect` sur l'instance n'est pas la dernière version.

**Solution**

Mettre à jour le package `ec2-instance-connect` sur l'instance vers la dernière version, comme suit :

1. [Se connecter](connect-to-linux-instance.md) à votre instance en utilisant une méthode autre que EC2 Instance Connect.

1. Exécuter la commande suivante sur votre instance pour mettre à jour le package `ec2-instance-connect` vers la dernière version.

   ```
   apt update && apt upgrade
   ```

## J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?
<a name="replacing-lost-key-pair"></a>

Si vous perdez la clé privée pour une instance basée sur des volumes EBS, vous pouvez à nouveau accéder à votre instance. Vous devez arrêter l'instance, détacher son volume racine et l'attacher à une autre instance en tant que volume de données, modifier le fichier `authorized_keys` avec une nouvelle clé publique, replacer le volume dans l'instance d'origine et redémarrer l'instance. Pour plus d'informations sur le lancement et l'arrêt des instances, ainsi que sur la connexion aux instances, consultez [Modifications de l'état de l' EC2 instance Amazon](ec2-instance-lifecycle.md).

Cette procédure est prise en charge uniquement pour des instances avec des volumes racine EBS. Si l’instance dispose d’un volume racine de stockage d’instances, vous ne pouvez pas utiliser cette procédure pour retrouver l’accès à votre instance ; vous devez disposer de la clé privée pour vous connecter à l’instance. Pour déterminer le type de volume racine de votre instance, ouvrez la console Amazon EC2, sélectionnez **Instances**, sélectionnez l’instance, choisissez l’onglet **Stockage**, puis dans la section **Détails du périphérique racine**, vérifiez la valeur de **Type de périphérique racine**. 

La valeur est `EBS` ou `INSTANCE-STORE`.

En plus des étapes suivantes, il existe d'autres façons de vous connecter à votre instance Linux en cas de perte de votre clé privée. Pour de plus amples informations, veuillez consulter [Comment puis-je me connecter à mon instance Amazon EC2 si j'ai perdu ma paire de clés SSH après son lancement initial ?](https://repost.aws/knowledge-center/user-data-replace-key-pair-ec2)

**Topics**
+ [Étape 1 : Créer une nouvelle paire de clés](#step-1-create-new-key-pair)
+ [Étape 2 : Obtenir des informations sur l'instance d'origine et son volume racine](#step-2-get-info-about-original-instance)
+ [Étape 3 : Arrêter l'instance d'origine](#step-3-stop-original-instance)
+ [Étape 4 : Lancer une instance temporaire](#step-4-launch-temp-instance)
+ [Étape 5 : Détacher le volume racine de l'instance d'origine et l'attacher à l'instance temporaire](#step-5-detach-root-volume-and-attach-to-temp-instance)
+ [Étape 6 : Ajouter la nouvelle clé publique `authorized_keys` sur le volume d'origine monté sur l'instance temporaire](#step-6-add-new-public-key-to-authorized_keys)
+ [Étape 7 : Démonter et détacher le volume d'origine de l'instance temporaire, puis le reconnecter à l'instance d'origine](#step-7-unmount-detach-volume-and-reattach-to-original-instance)
+ [Étape 8 : Se connecter à l'instance d'origine à l'aide de la nouvelle paire de clés](#step-8-connect-to-original-instance)
+ [Étape 9 : nettoyer](#step-9-clean-up)

### Étape 1 : Créer une nouvelle paire de clés
<a name="step-1-create-new-key-pair"></a>

Créer une nouvelle paire de clés à l'aide de la console Amazon EC2 ou d'un outil tiers. Si vous souhaitez nommer votre nouvelle paire de clés exactement comme la clé privée perdue, vous devez commencer par supprimer la paire de clés existante. Pour de plus amples informations sur la création d'une paire de clés, veuillez consulter [Créer une paire de clés à l’aide d’Amazon EC2](create-key-pairs.md#having-ec2-create-your-key-pair) ou [Créer une paire de clés à l’aide d’un outil tiers et importer la clé publique dans Amazon EC2](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws).

### Étape 2 : Obtenir des informations sur l'instance d'origine et son volume racine
<a name="step-2-get-info-about-original-instance"></a>

Notez les informations suivantes, car vous en aurez besoin pour effectuer cette procédure.

**Pour obtenir des informations sur votre instance d'origine**

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

1. Choisissez **Instances** dans le panneau de navigation, puis sélectionnez l'instance à laquelle vous souhaitez vous connecter. (Cette instance est qualifiée d'instance *d'origine*.)

1. Sous l'onglet **Details (Détails)**, notez l'ID d'instance et l'ID d'AMI.

1. Sous l'onglet **Networking (Réseaux)**, notez la zone de disponibilité.

1. Sous l'onglet **Storage (Stockage)**, sous **Root device name (Nom du périphérique racine)**, notez le nom du périphérique pour le volume racine (par exemple, `/dev/xvda`). Ensuite, sous **Block devices** (Bloquer les périphériques), recherchez le nom du périphérique et notez l'ID de volume (par exemple, vol-0a1234b5678c910de).

### Étape 3 : Arrêter l'instance d'origine
<a name="step-3-stop-original-instance"></a>

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.

**Avertissement**  
Lorsque vous arrêtez une instance, les données relatives aux volumes de stockage de l'instance sont perdues. Pour conserver ces données, sauvegardez-les dans un espace de stockage permanent.

### Étape 4 : Lancer une instance temporaire
<a name="step-4-launch-temp-instance"></a>

**Pour lancer une instance temporaire**

1. Dans le volet de navigation, choisissez **Instances**, puis **Launch instances** (Lancer des instances).

1. Dans la section **Name and tags** (Noms et identifications), pour **Name** (Nom), saisissez **Temporary** (Temporaire).

1. Dans **Application and OS Images** (Images d'applications et de systèmes d'exploitation), sélectionnez la même AMI que celle utilisée pour lancer l'instance d'origine. Si l'AMI n'est pas disponible, vous pouvez créer une AMI à utiliser depuis l'instance arrêtée. Pour de plus amples informations, veuillez consulter [Créer une AMI basée sur Amazon EBS](creating-an-ami-ebs.md).

1. Dans la section **Instance type** (Type d'instance), sélectionnez le type d'instance par défaut.

1. Dans la section **Key pair** (Paire de clés), pour **Key pair name** (Nom de la paire de clés), sélectionnez une paire de clés existante ou créez-en une.

1. Dans la section **Network settings** (Paramètres réseau), choisissez **Edit** (Modifier), puis pour **Subnet** (Sous-réseau), sélectionnez un sous-réseau dans la même zone de disponibilité que celle de l'instance d'origine.

1. Dans le panneau **Summary** (Récapitulatif), choisissez **Launch** (Lancer).

### Étape 5 : Détacher le volume racine de l'instance d'origine et l'attacher à l'instance temporaire
<a name="step-5-detach-root-volume-and-attach-to-temp-instance"></a>

1. Dans le panneau de navigation, sélectionnez **Volumes**, puis le volume racine pour l’instance d’origine (vous avez noté l’ID de volume au cours d’une étape précédente). Choisissez **Actions**, **Detach Volume** (Détacher un volume), puis choisissez **Detach** (Détacher). Attendez que l'état du volume devienne `available`. (Vous devrez peut-être sélectionner l'icône **Actualiser**.)

1. Tandis que le volume est toujours sélectionné, choisissez **Actions**, puis choisissez **Attach volume** (Attacher un volume). Sélectionnez l'ID d'instance de l'instance temporaire, notez le nom du périphérique spécifié dans **Device name** (Nom du périphérique) (par exemple, `/dev/sdf`), puis sélectionnez **Attach volume** (Attacher un volume).
**Note**  
Si vous avez lancé votre instance d'origine depuis une AWS Marketplace AMI et que votre volume contient des AWS Marketplace codes, vous devez d'abord arrêter l'instance temporaire avant de pouvoir attacher le volume.

### Étape 6 : Ajouter la nouvelle clé publique `authorized_keys` sur le volume d'origine monté sur l'instance temporaire
<a name="step-6-add-new-public-key-to-authorized_keys"></a>

1. Connectez-vous à l'instance temporaire.

1. À partir de l'instance temporaire, montez le volume que vous avez attaché à l'instance afin de pouvoir accéder au système de fichiers. Par exemple, si le nom du périphérique est `/dev/sdf`, utilisez les commandes suivantes pour monter le volume en tant que `/mnt/tempvol`.<a name="device-name"></a>
**Note**  
Le nom du périphérique peut apparaître différemment sur votre instance. Par exemple, les périphériques montés en tant que `/dev/sdf` peuvent également s'afficher en tant que `/dev/xvdf` sur l'instance. Certaines versions de Red Hat (ou ses variantes, comme CentOS) peuvent même incrémenter la lettre finale de quatre caractères, et `/dev/sdf` devient `/dev/xvdk`.

   1. Utilisez la commande **lsblk** pour déterminer si le volume est divisé.

      ```
      [ec2-user ~]$ lsblk
      NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
      xvda    202:0    0    8G  0 disk
      └─xvda1 202:1    0    8G  0 part /
      xvdf    202:80   0  101G  0 disk
      └─xvdf1 202:81   0  101G  0 part
      xvdg    202:96   0   30G  0 disk
      ```

      Dans l'exemple précédent, `/dev/xvda` et `/dev/xvdf` sont des volumes partitionnés, mais `/dev/xvdg` ne l'est pas. Si votre volume est partitionné, vous montez la partition (`/dev/xvdf1)`) au lieu du périphérique brut (`/dev/xvdf`) au cours des étapes suivantes.

   1. Créez un répertoire temporaire pour monter le volume.

      ```
      [ec2-user ~]$ sudo mkdir /mnt/tempvol
      ```

   1. Montez le volume (ou la partition) sur le point de montage temporaire, en utilisant le nom du volume ou du périphérique que vous avez identifié plus tôt. La commande requise dépend du système de fichiers de votre système d'exploitation. Notez que le nom du périphérique peut apparaître différemment sur votre instance. Reportez-vous à l'étape 6 de [note](#device-name) pour plus d'informations.
      + Amazon Linux, Ubuntu et Debian

        ```
        [ec2-user ~]$ sudo mount /dev/xvdf1 /mnt/tempvol
        ```
      + Amazon Linux 2, CentOS, SUSE Linux 12 et RHEL 7.x

        ```
        [ec2-user ~]$ sudo mount -o nouuid /dev/xvdf1 /mnt/tempvol
        ```
**Note**  
Si vous obtenez une erreur indiquant que le système de fichiers est endommagé, exécutez la commande suivante pour utiliser l'utilitaire **fsck** afin de rechercher les erreurs dans votre système de fichiers et de les résoudre.  

   ```
   [ec2-user ~]$ sudo fsck /dev/xvdf1
   ```

1. À partir de l'instance temporaire, utilisez la commande suivante pour mettre à jour `authorized_keys` sur le volume monté avec la nouvelle clé publique de `authorized_keys` pour l'instance temporaire.
**Important**  
Les exemples suivants utilisent le nom d'utilisateur Amazon Linux `ec2-user`. Vous devrez peut-être modifier le nom d'utilisateur, par exemple, `ubuntu` pour les instances Ubuntu.

   ```
   [ec2-user ~]$ cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys
   ```

   Une fois que cette étape est correctement effectuée, vous pouvez passer à l'étape suivante.

   (Facultatif) Sinon, si vous n'êtes pas autorisé à modifier des fichiers dans `/mnt/tempvol`, vous devez mettre à jour le fichier à l'aide de la commande **sudo**, puis vérifier les autorisations sur le fichier afin de vous assurer que vous êtes en mesure de vous connecter à l'instance d'origine. Pour vérifier les autorisations sur le fichier, utilisez la commande suivante.

   ```
   [ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh
   total 4
   -rw------- 1 222 500 398 Sep 13 22:54 authorized_keys
   ```

   Dans cet exemple de sortie, *222* il s'agit de l'ID utilisateur et *500* de l'ID du groupe. Utilisez ensuite la commande **sudo** pour ré-exécuter la commande copy ayant échoué.

   ```
   [ec2-user ~]$ sudo cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys
   ```

   Exécutez à nouveau la commande suivante pour déterminer si les autorisations ont été modifiées.

   ```
   [ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh
   ```

   Si l'ID d'utilisateur et l'ID de groupe ont été modifiés, utilisez la commande suivante pour les restaurer.

   ```
   [ec2-user ~]$ sudo chown 222:500 /mnt/tempvol/home/ec2-user/.ssh/authorized_keys
   ```

### Étape 7 : Démonter et détacher le volume d'origine de l'instance temporaire, puis le reconnecter à l'instance d'origine
<a name="step-7-unmount-detach-volume-and-reattach-to-original-instance"></a>

1. À partir de l'instance temporaire, démontez le volume que vous avez attaché afin de pouvoir l'attacher à nouveau à l'instance d'origine. Par exemple, utilisez la commande suivante pour démonter le volume situé dans `/mnt/tempvol`.

   ```
   [ec2-user ~]$ sudo umount /mnt/tempvol
   ```

1. Détachez le volume de l’instance temporaire (vous l’avez démonté à l’étape précédente) : dans la console Amazon EC2, choisissez **Volumes** dans le panneau de navigation, sélectionnez le volume racine de l’instance d’origine (vous avez noté l’ID de volume à l’étape précédente), choisissez **Actions**, **Détacher un volume**, puis **Détacher**. Attendez que l'état du volume devienne `available`. (Vous devrez peut-être sélectionner l'icône **Actualiser**.)

1. Rattachez le volume à l'instance d'origine : le volume étant toujours sélectionné, choisissez **Actions**, **Attach volume** (Attacher un volume). Sélectionnez l’ID d’instance de l’instance d’origine, précisez le nom du périphérique que vous avez noté précédemment au cours de l’[étape 2](#step-2-get-info-about-original-instance) pour l’attachement du volume racine d’origine (`/dev/sda1` ou `/dev/xvda`), puis choisissez **Attacher un volume**.
**Important**  
Si vous ne spécifiez pas le même nom de périphérique que pour l'attachement original, vous ne pourrez pas démarrer l'instance d'origine. Amazon EC2 s’attend à ce que le volume racine soit sur `sda1` ou `/dev/xvda`.

### Étape 8 : Se connecter à l'instance d'origine à l'aide de la nouvelle paire de clés
<a name="step-8-connect-to-original-instance"></a>

Sélectionnez l'instance d'origine, choisissez **État de l'instance**, **Démarrer l'instance**. Lorsque l'état de l'instance est `running`, vous pouvez vous y connecter à l'aide du fichier de clé privée de votre nouvelle paire de clés.

**Note**  
Si le nom de votre paire de clés et du fichier de clé privée correspondant est différent du nom de la paire de clés initiale, veillez à spécifier le nom du nouveau fichier de clé privée lorsque vous vous connectez à votre instance.

### Étape 9 : nettoyer
<a name="step-9-clean-up"></a>

(Facultatif) Vous pouvez mettre fin à l'instance temporaire si vous n'en avez plus besoin. Sélectionnez l'instance temporaire, puis **Instance State** (État de l'instance) et **Terminate instance** (Résilier l'instance).

# Résolution des problèmes liés aux instances Linux d'Amazon EC2 dont les vérifications du statut ont échoué
<a name="TroubleshootingInstances"></a>

Les informations suivantes peuvent vous aider à résoudre les problèmes si votre instance Linux échoue à un contrôle de statut. Commencez par déterminer si vos applications présentent des problèmes. Si vous constatez que l’instance n’exécute pas vos applications comme prévu, passez en revue les informations de contrôle de statut et les journaux système.

Pour des exemples de problèmes pouvant entraîner l’échec des vérifications d’état, consultez [Contrôles du statut des instances Amazon EC2](monitoring-system-instance-status-check.md).

**Topics**
+ [Examen des informations de contrôle de statut](#InitialSteps)
+ [Récupération des journaux système](#troubleshooting-retrieve-system-logs)
+ [Résolution des problèmes du journal du système pour les instances Linux](#system-log-errors-linux)
+ [Mémoire insuffisante : processus d’arrêt](#MemoryOOM)
+ [ERROR: mmu\$1update failed (la mise à jour de la gestion de la mémoire a échoué)](#MemoryMMU)
+ [Erreur d’E/S (échec du périphérique de stockage en mode bloc)](#DeviceBlock)
+ [I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)](#DeviceDistributed)
+ [request\$1module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)](#KernelLoop)
+ [« FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)](#KernelOld)
+ [« FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)](#KernelMissing)
+ [ERROR Invalid kernel (noyau incompatible EC2)](#KernelInvalid)
+ [fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)](#FilesystemFschk)
+ [General error mounting filesystems (Montage en échec)](#FilesystemGeneral)
+ [VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)](#FilesystemKernel)
+ [Erreur : Impossible de déterminer major/minor le nombre de périphériques racines... (Le fichier racine ne system/device correspond pas)](#FilesystemError)
+ [XENBUS : Device with no driver...](#FilesystemXenbus)
+ [... days without being checked, check forced (Contrôle du système de fichiers nécessaire)](#FilesystemCheck)
+ [fsck a échoué à l’état de sortie... (périphérique manquant)](#FilesystemFschkDied)
+ [Invite GRUB (grubdom>)](#OpSystemGrub)
+ [Mise en service de l’interface eth0 : l’adresse MAC du périphérique eth0 est différente de celle attendue, ignorer. (Adresse MAC codée de manière irréversible)](#OpSystemBringing)
+ [Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Je m'arrête maintenant. (SELinux mauvaise configuration)](#OpSystemUnable)
+ [XENBUS: Timeout connecting to devices (délai d’attente Xenbus)](#OpSystemXenbus)

## Examen des informations de contrôle de statut
<a name="InitialSteps"></a>

**Pour enquêter sur les instances dégradées en utilisant la console Amazon EC2**

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

1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance.

1. Sélectionnez l'onglet **État et alarmes** pour voir les résultats individuels de tous les contrôles d'**état du système, des contrôles**, **statut des instances et des contrôles**, et **statut EBS attachés**.

Si un contrôle de statut a échoué, vous pouvez essayer l’une des options suivantes :
+ Créez une alarme pour récupérer l'instance en réponse à l'échec de la vérification de statut. Pour de plus amples informations, veuillez consulter [Créer des alarmes qui arrêtent, finissent, redémarrent ou récupèrent une instance](UsingAlarmActions.md).
+ (Vérifications de l'état de l'instance) Si vous avez changé le type d'instance pour une [instance basée sur Nitro](instance-types.md#instance-hypervisor-type), les vérifications de statut échouent si vous avez migré depuis une instance qui ne possède pas l'ENA et NVMe les pilotes requis. Pour de plus amples informations, veuillez consulter [Compatibilité pour modifier le type d’instance](resize-limitations.md).
+ Pour une instance avec un volume racine EBS, arrêtez et redémarrez l’instance. Pour de plus amples informations, veuillez consulter [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md).
+ Pour une instance avec un volume racine de stockage d’instances, résiliez l’instance et lancez une instance de remplacement. Pour de plus amples informations, veuillez consulter [Terminez l'instance Amazon EC2](terminating-instances.md).
+ Attendez qu’Amazon EC2 résolve le problème.
+ Contactez Support ou publiez votre problème sur [AWS Re:post](https://repost.aws/).
+ Si votre instance est dans un groupe Auto Scaling :
  + (Contrôles de statut de système et de statut d'instance) Par défaut, Amazon EC2 Auto Scaling lance automatiquement une instance de remplacement. 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*.
  + (Vérifications de statut EBS jointes) Vous devez configurer Amazon EC2 Auto Scaling pour lancer automatiquement une instance de remplacement. Pour de plus amples informations, consulter [ Surveiller et remplacer des instances Auto Scaling par des volumes Amazon EBS altérés](https://docs.aws.amazon.com/autoscaling/ec2/userguide/monitor-and-replace-instances-with-impaired-ebs-volumes.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
+ Récupérez le journal du système et recherchez les erreurs. Pour de plus amples informations, veuillez consulter [Récupération des journaux système](#troubleshooting-retrieve-system-logs).

## Récupération des journaux système
<a name="troubleshooting-retrieve-system-logs"></a>

Si un contrôle de statut d’instance échoue, vous pouvez relancer l’instance et récupérer les journaux du système. Les journaux peuvent révéler une erreur que peut vous aider à résoudre le problème. Le redémarrage efface les informations inutiles des journaux.

**Pour redémarrer une instance et récupérer le journal du système**

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 votre instance.

1. Sélectionnez **État de l’instance**, puis **Redémarrer l’instance**. Le redémarrage de votre instance peut prendre quelques minutes.

1. Vérifiez si le problème existe encore. Dans certains cas, le redémarrage peut résoudre le problème.

1. Lorsque l’état de l’instance est `running`, sélectionnez **Actions**, **Surveiller et dépanner**, **Obtenir le journal système**.

1. Consultez le journal qui apparaît à l’écran et utilisez la liste ci-dessous des déclarations d’erreurs connues du journal du système afin de résoudre votre problème.

1. Si votre problème n’est pas résolu, vous pouvez le publier sur [AWS re:Post](https://repost.aws/).

## Résolution des problèmes du journal du système pour les instances Linux
<a name="system-log-errors-linux"></a>

Pour les instances Linux qui ont échoué à un contrôle de statut d’instance, comme le contrôle d’accessibilité de l’instance, vérifiez que vous avez suivi les étapes ci-dessous pour récupérer le journal du système. La liste suivante contient certaines erreurs communes du journal du système et les actions suggérées que vous pouvez prendre pour résoudre le problème correspondant à chaque erreur.

**Memory Errors**
+ [Mémoire insuffisante : processus d’arrêt](#MemoryOOM)
+ [ERROR: mmu\$1update failed (la mise à jour de la gestion de la mémoire a échoué)](#MemoryMMU)

**Device Errors**
+ [Erreur d’E/S (échec du périphérique de stockage en mode bloc)](#DeviceBlock)
+ [I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)](#DeviceDistributed)

**Kernel Errors**
+ [request\$1module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)](#KernelLoop)
+ [« FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)](#KernelOld)
+ [« FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)](#KernelMissing)
+ [ERROR Invalid kernel (noyau incompatible EC2)](#KernelInvalid)

**File System Errors**
+ [fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)](#FilesystemFschk)
+ [General error mounting filesystems (Montage en échec)](#FilesystemGeneral)
+ [VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)](#FilesystemKernel)
+ [Erreur : Impossible de déterminer major/minor le nombre de périphériques racines... (Le fichier racine ne system/device correspond pas)](#FilesystemError)
+ [XENBUS : Device with no driver...](#FilesystemXenbus)
+ [... days without being checked, check forced (Contrôle du système de fichiers nécessaire)](#FilesystemCheck)
+ [fsck a échoué à l’état de sortie... (périphérique manquant)](#FilesystemFschkDied)

**Operating System Errors**
+ [Invite GRUB (grubdom>)](#OpSystemGrub)
+ [Mise en service de l’interface eth0 : l’adresse MAC du périphérique eth0 est différente de celle attendue, ignorer. (Adresse MAC codée de manière irréversible)](#OpSystemBringing)
+ [Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Je m'arrête maintenant. (SELinux mauvaise configuration)](#OpSystemUnable)
+ [XENBUS: Timeout connecting to devices (délai d’attente Xenbus)](#OpSystemXenbus)

## Mémoire insuffisante : processus d’arrêt
<a name="MemoryOOM"></a>

Une out-of-memory erreur est indiquée par une entrée du journal système similaire à celle illustrée ci-dessous.

```
[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879
or a child 
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-
rss:101196kB, file-rss:204kB
```

### Cause potentielle
<a name="MemoryOOM-potential-cause"></a>

Mémoire épuisée

### Actions suggérées
<a name="MemoryOOM-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## ERROR: mmu\$1update failed (la mise à jour de la gestion de la mémoire a échoué)
<a name="MemoryMMU"></a>

Les échecs de la mise à jour de la gestion de la mémoire sont indiqués par une entrée du journal du système qui est similaire à ce qui suit :

```
...
Press `ESC' to enter the menu... 0   [H[J  Booting 'Amazon Linux 2011.09 (2.6.35.14-95.38.amzn1.i686)'


root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /boot/vmlinuz-2.6.35.14-95.38.amzn1.i686 root=LABEL=/ console=hvc0 LANG=

en_US.UTF-8 KEYTABLE=us

initrd /boot/initramfs-2.6.35.14-95.38.amzn1.i686.img

ERROR: mmu_update failed with rc=-22
```

### Cause potentielle
<a name="MemoryMMU-potential-cause"></a>

Problème avec Amazon Linux

### Action suggérée
<a name="MemoryMMU-suggested-actions"></a>

Publiez votre problème sur [AWS re :Post](https://repost.aws/) ou contactez [Support](https://aws.amazon.com/premiumsupport/).

## Erreur d’E/S (échec du périphérique de stockage en mode bloc)
<a name="DeviceBlock"></a>

Une input/output erreur est indiquée par une entrée du journal système similaire à l'exemple suivant :

```
[9943662.053217] end_request: I/O error, dev sde, sector 52428288
[9943664.191262] end_request: I/O error, dev sde, sector 52428168
[9943664.191285] Buffer I/O error on device md0, logical block 209713024
[9943664.191297] Buffer I/O error on device md0, logical block 209713025
[9943664.191304] Buffer I/O error on device md0, logical block 209713026
[9943664.191310] Buffer I/O error on device md0, logical block 209713027
[9943664.191317] Buffer I/O error on device md0, logical block 209713028
[9943664.191324] Buffer I/O error on device md0, logical block 209713029
[9943664.191332] Buffer I/O error on device md0, logical block 209713030
[9943664.191339] Buffer I/O error on device md0, logical block 209713031
[9943664.191581] end_request: I/O error, dev sde, sector 52428280
[9943664.191590] Buffer I/O error on device md0, logical block 209713136
[9943664.191597] Buffer I/O error on device md0, logical block 209713137
[9943664.191767] end_request: I/O error, dev sde, sector 52428288
[9943664.191970] end_request: I/O error, dev sde, sector 52428288
[9943664.192143] end_request: I/O error, dev sde, sector 52428288
[9943664.192949] end_request: I/O error, dev sde, sector 52428288
[9943664.193112] end_request: I/O error, dev sde, sector 52428288
[9943664.193266] end_request: I/O error, dev sde, sector 52428288
...
```

### Causes potentielles
<a name="DeviceBlock-potential-cause"></a>


| Type d’instance  | Cause potentielle | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Un volume Amazon EBS en échec   | 
|  Basée sur le stockage d’instance  |  Un lecteur physique en échec   | 

### Actions suggérées
<a name="DeviceBlock-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |   Mettez fin à l’instance et lancez une nouvelle instance.  Les données ne peuvent pas être récupérées. Récupérez-les grâce aux sauvegardes.   Il est recommandé d’utiliser soit Amazon S3, soit Amazon EBS pour les sauvegardes. Les volumes de stockage d’instance sont directement reliés aux échecs d’un hôte et d’un disque uniques.   | 

## I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)
<a name="DeviceDistributed"></a>

Une input/output erreur sur le périphérique est indiquée par une entrée du journal système similaire à l'exemple suivant :

```
...
block drbd1: Local IO failed in request_timer_fn. Detaching...

Aborting journal on device drbd1-8.

block drbd1: IO ERROR: neither local nor remote disk

Buffer I/O error on device drbd1, logical block 557056

lost page write due to I/O error on drbd1

JBD2: I/O error detected when updating journal superblock for drbd1-8.
```

### Causes potentielles
<a name="DeviceDistributed-potential-cause"></a>


| Type d’instance  | Cause potentielle | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Un volume Amazon EBS en échec   | 
|  Basée sur le stockage d’instance  |  Un lecteur physique en échec   | 

### Action suggérée
<a name="DeviceDistributed-suggested-actions"></a>

Mettez fin à l’instance et lancez une nouvelle instance. 

Pour une instance basée sur Amazon EBS, vous pouvez récupérer des données à partir d’un instantané récent en créant une image à partir de celle-ci. Toutes les données ajoutées après l’instantané ne peuvent pas être récupérées.

## request\$1module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)
<a name="KernelLoop"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous. L’utilisation d’un noyau Linux instable ou ancien (par exemple, 2.6.16-xenU) peut entraîner une condition de boucle interminable au démarrage.

```
Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 
20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007

BIOS-provided physical RAM map:

 Xen: 0000000000000000 - 0000000026700000 (usable)

0MB HIGHMEM available.
...

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c
```

### Actions suggérées
<a name="KernelLoop-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez un noyau plus récent, soit basé sur GRUB ou statique, avec l’une des options suivantes: Option 1 : Arrêtez l’instance et lancez une nouvelle instance en spécifiant les paramètres `-kernel` et `-ramdisk`. Option 2 : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Arrêtez l’instance et lancez une nouvelle instance en spécifiant les paramètres `-kernel` et `-ramdisk`.   | 

## « FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)
<a name="KernelOld"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
Linux version 2.6.16.33-xenU (root@dom0-0-50-45-1-a4-ee.z-2.aes0.internal) 
(gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #2 SMP Wed Aug 15 17:27:36 SAST 2007
...
FATAL: kernel too old
Kernel panic - not syncing: Attempted to kill init!
```

### Causes potentielles
<a name="KernelOld-potential-cause"></a>

Noyau et identifiant incompatibles

### Actions suggérées
<a name="KernelOld-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## « FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)
<a name="KernelMissing"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
[    0.370415] Freeing unused kernel memory: 1716k freed 
Loading, please wait...
WARNING: Couldn't open directory /lib/modules/2.6.34-4-virtual: No such file or directory
FATAL: Could not open /lib/modules/2.6.34-4-virtual/modules.dep.temp for writing: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
Couldn't get a file descriptor referring to the console
Begin: Loading essential drivers... ...
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Done.
Begin: Waiting for root file system... ...
Done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
ALERT! /dev/sda1 does not exist. Dropping to a shell!


BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu5) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)
```

### Causes potentielles
<a name="KernelMissing-potential-cause"></a>

Une ou plusieurs conditions suivantes peuvent entraîner ce problème :
+ Ramdisk manquant 
+ Modules corrects manquants pour le ramdisk
+ Le volume racine Amazon EBS n’est pas attaché correctement en tant que `/dev/sda1`

### Actions suggérées
<a name="KernelMissing-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## ERROR Invalid kernel (noyau incompatible EC2)
<a name="KernelInvalid"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
...
root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /vmlinuz root=/dev/sda1 ro

initrd /initrd.img

ERROR Invalid kernel: elf_xen_note_check: ERROR: Will only load images 
built for the generic loader or Linux images
xc_dom_parse_image returned -1

Error 9: Unknown boot failure

  Booting 'Fallback'
  
root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /vmlinuz.old root=/dev/sda1 ro

Error 15: File not found
```

### Causes potentielles
<a name="KernelInvalid-potential-cause"></a>

Une ou deux des conditions suivantes peuvent entraîner ce problème :
+ Le noyau fourni n’est pas pris en charge par GRUB 
+ Le noyau de rechange n’existe pas 

### Actions suggérées
<a name="KernelInvalid-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)
<a name="FilesystemFschk"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
		Welcome to Fedora 
		Press 'I' to enter interactive startup.
Setting clock : Wed Oct 26 05:52:05 EDT 2011 [  OK  ]

Starting udev: [  OK  ]

Setting hostname localhost:  [  OK  ]

No devices found
Setting up Logical Volume Management: File descriptor 7 left open
  No volume groups found
[  OK  ]

Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 
/dev/sda1: clean, 82081/1310720 files, 2141116/2621440 blocks
[/sbin/fsck.ext3 (1) -- /mnt/dbbackups] fsck.ext3 -a /dev/sdh 
fsck.ext3: No such file or directory while trying to open /dev/sdh

/dev/sdh: 
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[FAILED]


*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to continue):
```

### Causes potentielles
<a name="FilesystemFschk-potential-cause"></a>
+ Un bogue existe dans les définitions du système de fichiers ramdisk /etc/fstab
+ Définitions du système de fichiers mal configurées dans /etc/fstab
+ Lecteur manquant/en échec

### Actions suggérées
<a name="FilesystemFschk-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) Le sixième champ de fstab définit les exigences de disponibilité du montage. Une valeur non nulle implique qu’un fsck sera effectué sur ce volume et *doit* réussir. L’utilisation de ce champ peut être problématique dans Amazon EC2, car un échec entraîne généralement une invite de la console interactive qui n’est actuellement pas disponible dans Amazon EC2. Faites attention avec cette fonction et lisez la page sur la commande man Linux en ce qui concerne fstab.  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## General error mounting filesystems (Montage en échec)
<a name="FilesystemGeneral"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
Loading xenblk.ko module 
xen-vbd: registered block device major 8

Loading ehci-hcd.ko module
Loading ohci-hcd.ko module
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0

Loading mbcache.ko module
Loading jbd.ko module
Loading ext3.ko module
Creating root device.
Mounting root filesystem.
kjournald starting.  Commit interval 5 seconds

EXT3-fs: mounted filesystem with ordered data mode.

Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
mountall:/proc: unable to mount: Device or resource busy
mountall:/proc/self/mountinfo: No such file or directory
mountall: root filesystem isn't mounted
init: mountall main process (221) terminated with status 1

General error mounting filesystems.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and re-try.
Press enter for maintenance
(or type Control-D to continue):
```

### Causes potentielles
<a name="FilesystemGeneral-potential-cause"></a>


| Type d’instance  | Cause potentielle | 
| --- | --- | 
|  Basée sur Amazon EBS  |   [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |   [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

### Actions suggérées
<a name="FilesystemGeneral-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Essayez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)
<a name="FilesystemKernel"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 
 20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
...
Kernel command line:  root=/dev/sda1 ro 4
...
Registering block device major 8
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
```

### Causes potentielles
<a name="FilesystemKernel-potential-cause"></a>


| Type d’instance  | Cause potentielle | 
| --- | --- | 
|  Basée sur Amazon EBS  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Échec du périphérique matériel.  | 

### Actions suggérées
<a name="FilesystemKernel-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Arrêtez l’instance et lancez une nouvelle instance en utilisant un noyau moderne.   | 

## Erreur : Impossible de déterminer major/minor le nombre de périphériques racines... (Le fichier racine ne system/device correspond pas)
<a name="FilesystemError"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
...
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/vbd/2048
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Initializing network drop monitor service
Freeing unused kernel memory: 508k freed
:: Starting udevd...
done.
:: Running Hook [udev]
:: Triggering uevents...<30>udevd[65]: starting version 173
done.
Waiting 10 seconds for device /dev/xvda1 ...
Root device '/dev/xvda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/xvda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[ramfs /]#
```

### Causes potentielles
<a name="FilesystemError-potential-cause"></a>
+ Pilote du périphérique de stockage en mode bloc virtuel manquant ou configuré de façon incorrecte
+ Conflit de l’énumération du périphérique (sda versus xvda ou sda au lieu de sda1)
+ Choix incorrect du noyau de l’instance

### Actions suggérées
<a name="FilesystemError-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## XENBUS : Device with no driver...
<a name="FilesystemXenbus"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
XENBUS: Device with no driver: device/vbd/2048
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Initializing network drop monitor service
Freeing unused kernel memory: 508k freed
:: Starting udevd...
done.
:: Running Hook [udev]
:: Triggering uevents...<30>udevd[65]: starting version 173
done.
Waiting 10 seconds for device /dev/xvda1 ...
Root device '/dev/xvda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/xvda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[ramfs /]#
```

### Causes potentielles
<a name="FilesystemXenbus-potential-cause"></a>
+ Pilote du périphérique de stockage en mode bloc virtuel manquant ou configuré de façon incorrecte
+ Conflit de l’énumération du périphérique (sda versus xvda)
+ Choix incorrect du noyau de l’instance

### Actions suggérées
<a name="FilesystemXenbus-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## ... days without being checked, check forced (Contrôle du système de fichiers nécessaire)
<a name="FilesystemCheck"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
...
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 
/dev/sda1 has gone 361 days without being checked, check forced
```

### Causes potentielles
<a name="FilesystemCheck-potential-cause"></a>

La durée de contrôle du système de fichiers est dépassée ; un contrôle du système de fichiers est en train d’être forcé.

### Actions suggérées
<a name="FilesystemCheck-suggested-actions"></a>
+ Patientez jusqu’à ce que le contrôle du système de fichiers se termine. Un contrôle de système de fichiers peut prendre longtemps en fonction de la taille du système de fichiers racine. 
+  Modifiez vos systèmes de fichiers pour supprimer l’application du contrôle du système de fichiers (fsck) en utilisant tune2fs ou des outils appropriés pour votre système de fichiers. 

## fsck a échoué à l’état de sortie... (périphérique manquant)
<a name="FilesystemFschkDied"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
Cleaning up ifupdown....
Loading kernel modules...done.
...
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.16.2
/sbin/fsck.xfs: /dev/sdh does not exist
fsck died with exit status 8
[31mfailed (code 8).[39;49m
```

### Causes potentielles
<a name="FilesystemFschkDied-potential-cause"></a>
+ Ramdisk à la recherche d’un lecteur manquant
+ Contrôle de cohérence forcé du système de fichiers
+ Lecteur en échec ou détaché

### Actions suggérées
<a name="FilesystemFschkDied-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Essayez une ou plusieurs des solutions suivants pour résoudre le problème : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Essayez une ou plusieurs des solutions suivants pour résoudre le problème : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## Invite GRUB (grubdom>)
<a name="OpSystemGrub"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous. 

```
    GNU GRUB  version 0.97  (629760K lower / 0K upper memory)

       [ Minimal BASH-like line editing is supported.   For

         the   first   word,  TAB  lists  possible  command

         completions.  Anywhere else TAB lists the possible

         completions of a device/filename. ]

grubdom>
```

### Causes potentielles
<a name="OpSystem-potential-cause"></a>


| Type d’instance  | Causes potentielles | 
| --- | --- | 
|  Basée sur Amazon EBS  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

### Actions suggérées
<a name="OpSystem-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Option 1 : Modifiez l’AMI et relancez l’instance : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) Option 2 : Corrigez l’instance existante: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Option 1 : Modifiez l’AMI et relancez l’instance : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) Option 2 : Arrêtez l’instance et lancez une nouvelle instance en spécifiant le noyau correct.  Pour récupérer les données de l’instance existante, contactez [Support](https://aws.amazon.com/premiumsupport/).   | 

## Mise en service de l’interface eth0 : l’adresse MAC du périphérique eth0 est différente de celle attendue, ignorer. (Adresse MAC codée de manière irréversible)
<a name="OpSystemBringing"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
... 
Bringing up loopback interface:  [  OK  ]

Bringing up interface eth0:  Device eth0 has different MAC address than expected, ignoring.
[FAILED]

Starting auditd: [  OK  ]
```

### Causes potentielles
<a name="OpSystemBringing-potential-cause"></a>

Il s’agit d’une interface MAC codée en dur dans la configuration d’AMI

### Actions suggérées
<a name="OpSystemBringing-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) OU Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Je m'arrête maintenant. (SELinux mauvaise configuration)
<a name="OpSystemUnable"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
audit(1313445102.626:2): enforcing=1 old_enforcing=0 auid=4294967295
Unable to load SELinux Policy. Machine is in enforcing mode. Halting now.
Kernel panic - not syncing: Attempted to kill init!
```

### Causes potentielles
<a name="OpSystemUnable-potential-cause"></a>

SELinux a été activé par erreur :
+ Le noyau fourni n’est pas pris en charge par GRUB
+ Le noyau de rechange n’existe pas

### Actions suggérées
<a name="OpSystemUnable-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## XENBUS: Timeout connecting to devices (délai d’attente Xenbus)
<a name="OpSystemXenbus"></a>

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

```
Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 
20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
...
XENBUS: Timeout connecting to devices!
...
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
```

### Causes potentielles
<a name="OpSystemXenbus-potential-cause"></a>
+ Le périphérique de stockage en mode bloc n’est pas connecté à l’instance
+ Cette instance utilise un ancien noyau de l’instance

### Actions suggérées
<a name="OpSystemXenbus-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

# Résolution des problèmes liés au démarrage d'une instance Linux Amazon EC2 à partir d'un volume incorrect
<a name="instance-booting-from-wrong-volume"></a>

Dans certaines situations, un volume autre que le volume attaché à `/dev/xvda` ou `/dev/sda` devient le volume racine d'une instance Linux. Cela peut arriver lorsque vous avez attaché le volume racine d’une autre instance, ou un volume créé à partir de l’instantané d’un volume racine, à une instance avec un volume racine existant.

Ceci est dû à la façon de fonctionner du ramdisk initial dans Linux. Il choisit le volume définit comme `/` dans le fichier `/etc/fstab`, et dans certaines distributions. Ceci est déterminé par l’étiquette attachée à la partition du volume. Plus spécifiquement, vous trouvez que le fichier `/etc/fstab` ressemble à ce qui suit : 

```
LABEL=/ / ext4 defaults,noatime 1 1 
tmpfs /dev/shm tmpfs defaults 0 0 
devpts /dev/pts devpts gid=5,mode=620 0 0 
sysfs /sys sysfs defaults 0 0 
proc /proc proc defaults 0 0
```

Si vous vérifiez l’étiquette des deux volumes, vous verrez qu’ils contiennent tous les deux l’étiquette `/` : 

```
[ec2-user ~]$ sudo e2label /dev/xvda1 
/ 
[ec2-user ~]$ sudo e2label /dev/xvdf1 
/
```

Dans cet exemple, `/dev/xvdf1` pourrait devenir le volume racine sur lequel votre instance démarre après l’exécution du ramdisk initial, au lieu du volume `/dev/xvda1` à partir duquel vous aviez l’intention de démarrer. Pour résoudre ce problème, utilisez la même commande **e2label** pour changer l’étiquette du volume attaché à partir duquel vous ne souhaitez pas démarrer.

Dans certains cas, spécifier un UUID dans `/etc/fstab` peut résoudre ce problème. Cependant, si les deux volumes proviennent du même instantané ou si le deuxième est créé à partir d’un instantané du volume principal, ils partagent un UUID.

```
[ec2-user ~]$ sudo blkid 
/dev/xvda1: LABEL="/" UUID=73947a77-ddbe-4dc7-bd8f-3fe0bc840778 TYPE="ext4" PARTLABEL="Linux" PARTUUID=d55925ee-72c8-41e7-b514-7084e28f7334 
/dev/xvdf1: LABEL="old/" UUID=73947a77-ddbe-4dc7-bd8f-3fe0bc840778 TYPE="ext4" PARTLABEL="Linux" PARTUUID=d55925ee-72c8-41e7-b514-7084e28f7334
```

**Pour changer l’étiquette d’un volume ext4 attaché**

1. Utilisez la commande **e2label** pour remplacer l’étiquette du volume par autre chose que `/`.

   ```
   [ec2-user ~]$ sudo e2label /dev/xvdf1 old/ 
   ```

1. Vérifiez que le volume possède la nouvelle étiquette.

   ```
   [ec2-user ~]$ sudo e2label /dev/xvdf1 
   old/
   ```

**Pour changer l’étiquette d’un volume xfs attaché**
+ Utilisez la commande **xfs\$1admin** pour remplacer l’étiquette du volume par autre chose que `/`.

  ```
  [ec2-user ~]$ sudo xfs_admin -L old/ /dev/xvdf1
  writing all SBs
  new label = "old/"
  ```

Après avoir modifié l’étiquette du volume comme indiqué, vous devriez pouvoir redémarrer l’instance et avoir le bon volume sélectionné par le ramdisk initial lorsque l’instance démarre.

**Important**  
Si vous prévoyez de détacher le volume avec la nouvelle étiquette et de le renvoyer vers une autre instance pour l’utiliser comme volume racine, vous devez ré-exécuter la procédure ci-dessus et réattribuer à l’étiquette du volume sa valeur d’origine. Sinon, l’autre instance ne démarre pas, car le ramdisk ne peut pas trouver le volume avec l’étiquette `/`.

# Résoudre les problèmes de connexion à votre instance Amazon EC2 Windows
<a name="troubleshoot-connect-windows-instance"></a>

Les informations suivantes et les erreurs courantes peuvent vous aider à résoudre les problèmes de connexion à votre instance Windows.

**Topics**
+ [Le service Bureau à distance ne peut pas se connecter à l’ordinateur distant](#rdp-issues)
+ [Erreur lors de l’utilisation du client RDP macOS](#troubleshoot-instance-connect-mac-rdp)
+ [RDP affiche un écran noir au lieu du bureau](#rdp-black-screen)
+ [Impossible de se connecter à distance à une instance avec un utilisateur autre qu’un administrateur](#remote-failure)
+ [Résolution des problèmes de bureau à distance à l'aide de AWS Systems Manager](#Troubleshooting-Remote-Desktop-Connection-issues-using-AWS-Systems-Manager)
+ [Activation du Bureau à distance sur une instance EC2 avec le Registre à distance](#troubleshooting-windows-rdp-remote-registry)
+ [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance Windows ?](#replacing-lost-key-pair-windows)

## Le service Bureau à distance ne peut pas se connecter à l’ordinateur distant
<a name="rdp-issues"></a>

Essayez d’exécuter l’opération suivante pour résoudre les problèmes liés à votre connexion à votre instance :
+ Vérifiez que vous utilisez le nom d’hôte DNS public adéquat. (Dans la console Amazon EC2, sélectionnez l'instance et cochez **Public DNS (IPv4)** dans le volet de détails.) Si votre instance est un VPC et que le nom DNS public ne s’affiche pas, vous devez activer les noms d’hôtes DNS. Pour plus d’informations, consultez [DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) (Attributs DNS pour votre VPC) dans le *Guide de l’utilisateur d’Amazon VPC*.
+ Vérifiez que votre instance possède une IPv4 adresse publique. Si non, vous pouvez associer une adresse IP Elastic à votre instance. Pour de plus amples informations, veuillez consulter [Adresses IP élastiques](elastic-ip-addresses-eip.md). 
+ Pour vous connecter à votre instance à l'aide d'une IPv6 adresse, vérifiez que votre ordinateur local possède une IPv6 adresse et qu'il est configuré pour l'utiliser IPv6. Pour plus d'informations, consultez la section [Configurer IPv6 sur vos instances](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-dhcpv6) dans le guide de l'*utilisateur Amazon VPC*.
+ Vérifiez que votre groupe de sécurité dispose d'une règle qui autorise l'accès RDP sur le port 3389.
+ Si vous avez copié le mot de passe, mais que vous obtenez l’erreur `Your credentials did not work`, essayez de le saisir manuellement lorsque vous y êtes invité. Il est possible que vous ayez oublié un caractère ou ajouté une espace supplémentaire lorsque vous avez copié le mot de passe.
+ Vérifiez que l’instance a réussi les contrôles d’état. Pour plus d’informations, consultez [Contrôles du statut des instances Amazon EC2](monitoring-system-instance-status-check.md) et [Résolution des problèmes liés aux instances Linux d'Amazon EC2 dont les vérifications du statut ont échoué](TroubleshootingInstances.md).
+ Vérifiez que la table de routage du sous-réseau contient une route qui envoie tout le trafic destiné à l’extérieur du VPC vers la passerelle Internet du VPC. Pour plus d’informations, consultez [Créer une table de routage personnalisée](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing) (Passerelles Internet) dans le *Amazon VPC Guide de l’utilisateur*.
+ Vérifiez que le pare-feu Windows, ou tout autre logiciel de pare-feu, ne bloque pas le trafic RDP vers l’instance. Nous vous recommandons de désactiver le pare-feu Windows et le contrôle d’accès à votre instance à l’aide des règles des groupes de sécurité. Essayez l’une des options suivantes :
  + Utilisez [AWSSupport-TroubleshootRDP](#AWSSupport-TroubleshootRDP) pour [disable the Windows Firewall profiles using SSM Agent](#disable-firewall). Cette option nécessite que l'instance soit configurée pour AWS Systems Manager.
  + Utilisez [AWSSupport-ExecuteEC2Rescue](#AWSSupport-ExecuteEC2Rescue).
  + Arrêtez l’instance, détachez le volume racine et attachez le volume à une instance temporaire en tant que volume de données. Connectez-vous à l’instance temporaire et mettez le volume en ligne. Chargez la ruche du registre à partir du volume de données. Sous `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicyStandardProfile`, définissez `EnableFirewall` sur 0. Déchargez la ruche du registre, puis mettez le volume hors ligne. Détachez le volume de l’instance temporaire et attachez-le à l’instance d’origine en tant que volume racine. Démarrez l’instance d’origine.
+  Vérifiez que l’authentification au niveau du réseau est désactivée sur les instances qui ne font pas partie d’un domaine Active Directory (utilisez [AWSSupport-TroubleshootRDP](#AWSSupport-TroubleshootRDP) pour [disable NLA](#disable-nla)). 
+ Vérifiez que le type de démarrage du service Remote Desktop (TermService) est automatique et que le service est démarré (utilisé [AWSSupport-TroubleshootRDP](#AWSSupport-TroubleshootRDP)pour[enable and start the RDP service](#rdp-auto)). 
+ Vérifiez que vous vous connectez au port RDP (Remote Desktop Protocol) approprié, qui est par défaut le port 3389 (utilisez [AWSSupport-TroubleshootRDP](#AWSSupport-TroubleshootRDP) pour [read the current RDP port](#check-rdp) et [change it back to 3389](#restore-3389)).
+  Vérifiez que les connexions via le service Bureau à distance sont autorisées sur votre instance (utilisez [AWSSupport-TroubleshootRDP](#AWSSupport-TroubleshootRDP) pour [enable Remote Desktop connections](#allow-rdp)).
+ Vérifiez que le mot de passe n’a pas expiré. Si c’est le cas, vous pouvez le réinitialiser. Pour de plus amples informations, veuillez consulter [Réinitialiser le mot de passe de l’administrateur Windows pour une instance Amazon EC2 Windows](ResettingAdminPassword.md).
+ Si vous tentez de vous connecter à l’aide d’un utilisateur que vous avez créé sur l’instance et que vous recevez le message d’erreur `The user cannot connect to the server due to insufficient access privileges`, vérifiez que vous avez autorisé l’utilisateur à se connecter localement. Pour plus d’informations, consultez [Accorder à un membre le droit de se connecter localement](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/ee957044(v%3dws.10)).
+ Si vous tentez d’ouvrir un nombre de sessions RDP simultanées supérieur à la limite autorisée, votre session est mise hors service et le message suivant est renvoyé : `Your Remote Desktop Services session has ended. Another user connected to the remote computer, so your connection was lost.` Par défaut, deux sessions RDP simultanées sont autorisées sur votre instance.

## Erreur lors de l’utilisation du client RDP macOS
<a name="troubleshoot-instance-connect-mac-rdp"></a>

Si vous vous connectez à une instance de Windows Server à l'aide du client RDP (Remote Desktop Connection) du site web de Microsoft, il se peut que vous obteniez l'erreur suivante :

```
Remote Desktop Connection cannot verify the identity of the computer that you want to connect to.
```

Téléchargez l’application Microsoft Remote Desktop à partir du Mac App Store et utilisez cette application pour vous connecter à votre instance.

## RDP affiche un écran noir au lieu du bureau
<a name="rdp-black-screen"></a>

Essayez ce qui suit pour résoudre ce problème :
+ Consultez la sortie de la console pour plus d’informations. Pour obtenir la sortie de la console de votre instance à l’aide de la console Amazon EC2, sélectionnez l’instance, puis **Actions**, **Surveiller et dépanner** et **Obtenir le journal système**.
+ Vérifiez que vous exécutez la version la plus récente de votre client RDP.
+ Essayez les paramètres par défaut pour le client RDP.
+ Si vous utilisez la connexion au Bureau à distance, essayez de la démarrer avec l’option `/admin` comme suit.

  ```
  mstsc /v:instance /admin
  ```
+ Si le serveur exécute une application plein écran, il se peut qu’elle ait cessé de répondre. Utilisez Ctrl\$1Shift\$1Esc pour démarrer le Gestionnaire des tâches de Windows, puis fermez l’application.
+ Si le serveur est sur-utilisé, il peut avoir cessé de répondre. Pour surveiller l’instance à l’aide de la console Amazon EC2, sélectionnez l’instance, puis sélectionnez l’onglet **Surveillance**. Si vous avez besoin d’attribuer une taille supérieure au type d’instance, consultez [Changements de type d'instance Amazon EC2](ec2-instance-resize.md).

## Impossible de se connecter à distance à une instance avec un utilisateur autre qu’un administrateur
<a name="remote-failure"></a>

Si vous ne pouvez pas vous connecter à distance à une instance Windows avec un utilisateur qui n’est pas un compte administrateur, vérifiez que l’utilisateur est autorisé à se connecter localement. Consultez [Accorder à un utilisateur ou à un groupe le droit de se connecter localement aux contrôleurs de domaine du domaine](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee957044(v=ws.10)#grant-a-user-or-group-the-right-to-log-on-locally-to-the-domain-controllers-in-the-domain). 

## Résolution des problèmes de bureau à distance à l'aide de AWS Systems Manager
<a name="Troubleshooting-Remote-Desktop-Connection-issues-using-AWS-Systems-Manager"></a>

Vous pouvez l'utiliser AWS Systems Manager pour résoudre les problèmes de connexion à votre instance Windows à l'aide du protocole RDP.

### AWSSupport-TroubleshootRDP
<a name="AWSSupport-TroubleshootRDP"></a>

Le document AWSSupport-TroubleshootRDP d'automatisation permet à l'utilisateur de vérifier ou de modifier les paramètres courants de l'instance cible susceptibles d'avoir un impact sur les connexions RDP (Remote Desktop Protocol), tels que le **port RDP**, l'**authentification de la couche réseau (NLA)** et les profils de pare-feu **Windows**. Par défaut, le document lit et produit les valeurs de ces paramètres.

Le document AWSSupport-TroubleshootRDP d'automatisation peut être utilisé avec des instances EC2, des instances sur site et des machines virtuelles (VMs) activées pour être utilisées avec AWS Systems Manager (instances gérées). En outre, il peut également être utilisé avec des instances EC2 pour Windows Server qui *ne sont pas* activées pour une utilisation avec Systems Manager. Pour plus d'informations sur l'activation des instances à utiliser avec AWS Systems Manager, consultez la section [Nœuds gérés](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-managed-nodes.html) dans le *guide de AWS Systems Manager l'utilisateur*.

**Pour résoudre les problèmes liés à l'utilisation du document AWSSupport-TroubleshootRDP**

1. Connectez-vous à la [console Systems Manager](https://console.aws.amazon.com/systems-manager/).

1.  Vérifiez que vous êtes dans la même région que l’instance dégradée.

1. Dans le volet de navigation de gauche, choisissez **Documents**. 

1. Sur l’onglet **Owned by Amazon** (Propriété d’Amazon), saisissez `AWSSupport-TroubleshootRDP` dans le champ de recherche. Lorsque le document `AWSSupport-TroubleshootRDP` apparaît, sélectionnez-le.

1. Sélectionnez **Execute automation (Exécuter l’automatisation)**.

1. Pour **Mode d’exécution**, choisissez **Exécution simple**.

1. Pour les **paramètres d'entrée **InstanceId****, activez **Afficher le sélecteur d'instance interactif**.

1. Sélectionnez votre instance Amazon EC2.

1. Consultez les [exemples](#AWSSupport-TroubleshootRDP-Examples), puis choisissez **Exécuter**.

1. Pour surveiller la progression de l’exécution, dans **Statut de l’exécution**, attendez que le statut passe de **En attente** à **Réussite**. Développez **Sorties** pour afficher les résultats. Pour afficher la sortie de chaque étape, dans **Étapes exécutées**, choisissez l’**ID d’étape**.

#### AWSSupport-TroubleshootRDP exemples
<a name="AWSSupport-TroubleshootRDP-Examples"></a>

Les exemples suivants vous montrent comment effectuer des tâches de dépannage courantes à l'aide deAWSSupport-TroubleshootRDP. Vous pouvez utiliser l'exemple de AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-automation-execution.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-automation-execution.html)commande ou le lien fourni vers le AWS Management Console.

**Example Exemple : Vérifier le statut RDP actuel**  <a name="check-rdp"></a>
AWS CLI:  

```
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-1234567890abcdef0, Action=Custom" --region region_code
```
AWS Systems Manager console :  

```
https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootRDP?region=region#documentVersion=$LATEST
```

**Example Exemple : Désactiver le pare-feu Windows**  <a name="disable-firewall"></a>
AWS CLI:  

```
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-1234567890abcdef0, Action=Custom, Firewall=Disable" --region region_code
```
AWS Systems Manager console :  

```
https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootRDP?region=region_code#documentVersion=$LATEST&Firewall=Disable
```

**Example Exemple : Désactiver l’authentification au niveau du réseau**  <a name="disable-nla"></a>
AWS CLI:  

```
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-1234567890abcdef0, Action=Custom, NLASettingAction=Disable" --region region_code
```
AWS Systems Manager console :  

```
https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootRDP?region=region_code#documentVersion
```

**Example Exemple : Définir le type de démarrage du service RDP sur Automatique et démarrer le service RDP**  <a name="rdp-auto"></a>
AWS CLI:  

```
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-1234567890abcdef0, Action=Custom, RDPServiceStartupType=Auto, RDPServiceAction=Start" --region region_code
```
AWS Systems Manager console :  

```
https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootRDP?region=region_code#documentVersion=$LATEST&RDPServiceStartupType=Auto&RDPServiceAction=Start
```

**Example Exemple : Restaurer le port RDP par défaut (3389)**  <a name="restore-3389"></a>
AWS CLI:  

```
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-1234567890abcdef0, Action=Custom, RDPPortAction=Modify" --region region_code
```
AWS Systems Manager console :  

```
https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootRDP?region=region_code#documentVersion=$LATEST&RDPPortAction=Modify
```

**Example Exemple : Autoriser les connexions à distance**  <a name="allow-rdp"></a>
AWS CLI:  

```
aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-1234567890abcdef0, Action=Custom, RemoteConnections=Enable" --region region_code
```
AWS Systems Manager console :  

```
https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootRDP?region=region_code#documentVersion=$LATEST&RemoteConnections=Enable
```

### AWSSupport-ExecuteEC2 Secours
<a name="AWSSupport-ExecuteEC2Rescue"></a>

Le document d'automatisation de AWSSupport-ExecuteEC 2Rescue utilise EC2Rescue pour Windows Server pour résoudre et restaurer automatiquement la connectivité des instances EC2 et les problèmes RDP. Pour plus d'informations, voir [Exécuter l'outil EC2 Rescue sur des instances inaccessibles](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2rescue.html).

Le document d'automatisation de AWSSupport-ExecuteEC 2Rescue exige l'arrêt et le redémarrage de l'instance. Systems Manager Automation arrête l’instance et crée une Amazon Machine Image (AMI). Les données stockées sur les volumes de stockage d’instance sont perdues. L’adresse IP publique est modifiée si vous n’utilisez pas une adresse IP Elastic. Pour plus d'informations, voir [Exécuter l'outil EC2 Rescue sur des instances inaccessibles](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2rescue.html) dans le *Guide de l'AWS Systems Manager utilisateur*.

**Pour résoudre les problèmes à l'aide du document AWSSupport-ExecuteEC 2Rescue**

1. Ouvrez la [console Systems Manager](https://console.aws.amazon.com/systems-manager/).

1. Vérifiez que vous êtes dans la même région que l’instance Amazon EC2 dégradée.

1. Dans le panneau de navigation, choisissez **Documents**.

1. Recherchez et sélectionnez le document `AWSSupport-ExecuteEC2Rescue`, puis choisissez **Exécuter l’automatisation**.

1. Dans **Execution mode (Mode d’exécution)**, choisissez **Simple Execution (Exécution simple)**.

1.  Dans la section **Paramètres d'entrée**, pour **UnreachableInstanceId**, entrez l'ID d'instance Amazon EC2 de l'instance inaccessible.

1.  (Facultatif) Pour **LogDestination**, entrez le nom du bucket Amazon Simple Storage Service (Amazon S3) si vous souhaitez collecter les journaux du système d'exploitation pour le dépannage de votre instance Amazon EC2. Les journaux sont chargés automatiquement dans le compartiment spécifié.

1. Sélectionnez **Execute (Exécuter)**.

1.  Pour surveiller la progression de l’exécution, dans **Execution statut (Statut de l’exécution)**, attendez que le statut passe de **Pending (En attente)** à **Success (Succès)**. Développez **Sorties** pour afficher les résultats. Pour afficher la sortie de chaque étape, dans **Executed Steps (Étapes exécutées)**, choisissez l’**ID d’étape**.

## Activation du Bureau à distance sur une instance EC2 avec le Registre à distance
<a name="troubleshooting-windows-rdp-remote-registry"></a>

Si votre instance inaccessible n'est pas gérée par le gestionnaire de session de AWS Systems Manager, vous pouvez utiliser le registre distant pour activer Remote Desktop. 

1. À partir de la console EC2, arrêtez l’instance inaccessible.

1. Détachez le volume racine de l’instance inaccessible et attachez-le à une instance accessible dans la même zone de disponibilité que le volume de stockage. Si vous n’avez pas d’instance accessible dans la même zone de disponibilité, lancez-en une. Notez le nom du périphérique du volume racine de l’instance inaccessible.

1. Sur l’instance accessible, ouvrez la Gestion des disques. Vous pouvez le faire en exécutant la commande suivante dans une fenêtre d’invite de commande.

   ```
   diskmgmt.msc
   ```

1. Cliquez avec le bouton droit sur le volume récemment attaché provenant de l’instance inaccessible, puis sélectionnez **En ligne**.

1. Ouvrez l’Éditeur du Registre Windows. Vous pouvez le faire en exécutant la commande suivante dans une fenêtre d’invite de commande.

   ```
   regedit
   ```

1. Dans l’Éditeur du Registre, choisissez **HKEY\$1LOCAL\$1MACHINE**, puis sélectionnez **Fichier**, **Charger Hive**.

1. Sélectionnez le lecteur du volume attaché, accédez à `\Windows\System32\config\`, sélectionnez `SYSTEM`, puis choisissez **Ouvrir**.

1. Dans **Nom de clé**, entrez un nom unique pour le répertoire de stockage et choisissez **OK**.

1. Sauvegardez la ruche du registre avant d’apporter des modifications au registre. 

   1. Dans l'arborescence de la console de l'éditeur de registre, sélectionnez la ruche que vous avez chargée : **HKEY\$1LOCAL\$1MACHINE** \$1. *your-key-name*

   1. Choisissez **Fichier**, **Exporter**.

   1. Dans la boîte de dialogue Exporter un fichier du Registre, choisissez l’emplacement vers lequel vous souhaitez enregistrer la copie de sauvegarde, puis tapez un nom pour le fichier de sauvegarde dans le champ **Nom du fichier**.

   1. Choisissez **Enregistrer**.

1. Dans l'éditeur du registre, accédez à`HKEY_LOCAL_MACHINE\your key name\ControlSet001\Control\Terminal Server`, puis dans le volet de détails, double-cliquez sur **FDeny TSConnections**.

1. Dans la zone **Modifier la valeur DWORD**, entrez `0` dans le champ **Données de valeur**. 

1. Choisissez **OK**.
**Note**  
Si la valeur du champ **Données de valeur** est `1`, l’instance refusera les connexions au bureau à distance. La valeur `0` autorise les connexions au bureau à distance.

1. ****Dans l'éditeur du registre, choisissez **HKEY\$1LOCAL\$1MACHINE** \$1*your-key-name*, puis sélectionnez Fichier, Décharger la ruche.****

1. Fermez l’Éditeur du Registre et la Gestion des disques.

1. À partir de la console EC2, détachez le volume de l’instance accessible et attachez-le à nouveau à l’instance inaccessible. Lorsque vous attachez le volume à l’instance inaccessible, saisissez le nom du périphérique que vous avez enregistré précédemment dans le champ **Périphérique**.

1. Redémarrez l’instance inaccessible. 

## J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance Windows ?
<a name="replacing-lost-key-pair-windows"></a>

Lorsque vous vous connectez à une instance Windows lancée récemment, vous déchiffrez le mot de passe du compte administrateur à l’aide de la clé privée de la paire de clés que vous avez spécifiée lors du lancement de l’instance.

Si vous perdez le mot de passe administrateur et que vous n’avez plus de clé privée, vous devez réinitialiser le mot de passe ou créer une nouvelle instance. Pour de plus amples informations, veuillez consulter [Réinitialiser le mot de passe de l’administrateur Windows pour une instance Amazon EC2 Windows](ResettingAdminPassword.md). Pour connaître les étapes de réinitialisation du mot de passe à l’aide d’un document Systems Manager, consultez [Réinitialiser des mots de passe et des clés SSH sur des instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2reset.html) dans le *Guide de l’utilisateur AWS Systems Manager *.

# Résoudre les problèmes de démarrage des instances Amazon EC2 Windows
<a name="common-messages"></a>

Vous trouverez ci-dessous des conseils de dépannage pour vous aider à résoudre les problèmes de mot de passe et d'activation avec les instances Amazon EC2 Windows.

**Topics**
+ [« Le mot de passe n'est pas disponible »](#password-not-available)
+ [« Mot de passe pas encore disponible »](#password-not-ready)
+ [« Récupération du mot de passe Windows impossible »](#cannot-retrieve-password)
+ [« En attente du service de métadonnées »](#metadata-unavailable)
+ [« L'activation de Windows est impossible »](#activate-windows)
+ [« Windows n'est pas authentique (0x80070005) »](#windows-not-genuine)
+ [« Aucun serveur de licences Terminal Server n'est disponible pour fournir une licence »](#no-license-servers)
+ [« Certains paramètres sont gérés par votre organisation »](#some-settings-managed-by-org)

## « Le mot de passe n'est pas disponible »
<a name="password-not-available"></a>

Pour vous connecter à une instance Windows à l'aide des services Bureau à distance, vous devez spécifier un compte et un mot de passe. Les comptes et mots de passe fournis sont basés sur l'AMI que vous avez utilisée pour lancer l'instance. Vous pouvez récupérer le mot de passe généré automatiquement pour le compte d'administrateur ou utiliser le compte et le mot de passe utilisés dans l'instance originale à partir de laquelle l'AMI a été créée.

Vous pouvez générer un mot de passe pour le compte administrateur des instances lancées à l'aide d'une AMI Windows personnalisée. Pour générer le mot de passe, vous devrez configurer certains paramètres du système d'exploitation avant la création de l'AMI. Pour de plus amples informations, veuillez consulter [Créer une AMI basée sur Amazon EBS](creating-an-ami-ebs.md).

Si votre instance Windows n'est pas configurée pour générer un mot de passe aléatoire, vous recevez le message suivant lorsque vous extrayez le mot de passe généré automatiquement à l'aide de la console :

```
Password is not available.
The instance was launched from a custom AMI, or the default password has changed. A
password cannot be retrieved for this instance. If you have forgotten your password, you can
reset it using the Amazon EC2 configuration service. For more information, see Passwords for a
Windows Server instance.
```

Recherchez l'instance dans la sortie de la console pour voir si l'AMI que vous avez utilisée pour lancer l'instance a été créée avec la génération de mot de passe désactivée. Si la génération de mot de passe est désactivée, la sortie de la console contient ce qui suit :

```
Ec2SetPassword: Disabled
```

Si la génération de mot de passe est désactivée et que vous avez oublié le mot de passe de l'instance originale, vous pouvez réinitialiser le mot de passe de cette instance. Pour de plus amples informations, veuillez consulter [Réinitialiser le mot de passe de l’administrateur Windows pour une instance Amazon EC2 Windows](ResettingAdminPassword.md).

## « Mot de passe pas encore disponible »
<a name="password-not-ready"></a>

Pour vous connecter à une instance Windows à l'aide des services Bureau à distance, vous devez spécifier un compte et un mot de passe. Les comptes et mots de passe fournis sont basés sur l'AMI que vous avez utilisée pour lancer l'instance. Vous pouvez récupérer le mot de passe généré automatiquement pour le compte d'administrateur ou utiliser le compte et le mot de passe utilisés dans l'instance originale à partir de laquelle l'AMI a été créée.

Votre mot de passe devrait être disponible d'ici quelques minutes. Si le mot de passe n'est pas disponible, vous recevrez le message suivant lorsque vous extrayez le mot de passe généré automatiquement à l'aide de la console :

```
Password not available yet.
Please wait at least 4 minutes after launching an instance before trying to retrieve the 
auto-generated password.
```

Si cela fait plus de quatre minutes et que vous ne pouvez toujours pas obtenir le mot de passe, il est possible que l'agent de lancement de votre instance ne soit pas configuré pour générer un mot de passe. Pour cela, vérifiez si sortie de la console est vide. Pour de plus amples informations, veuillez consulter [Impossible d’obtenir la sortie de la console](win-ts-common-issues.md#no-console-output).

Vérifiez également que l'`ec2:GetPasswordData`action est autorisée sur le compte Gestion des identités et des accès AWS (IAM) utilisé pour accéder au portail de gestion. Pour plus d'informations sur les autorisations IAM, consultez [Qu'est-ce qu'IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)

## « Récupération du mot de passe Windows impossible »
<a name="cannot-retrieve-password"></a>

Pour récupérer le mot de passe généré automatiquement pour le compte d'administrateur, vous devez utiliser la clé privée de la paire de clés que vous avez spécifiée lors du lancement de l'instance. Si vous n'avez pas spécifié de paire de clés existante au lancement de l'instance, vous recevez le message suivant.

```
Cannot retrieve Windows password
```

Vous pouvez mettre cette instance hors service et lancer une nouvelle instance à l'aide de la même AMI, en veillant à spécifier une paire de clés.

## « En attente du service de métadonnées »
<a name="metadata-unavailable"></a>

Une instance Windows doit obtenir des informations auprès des métadonnées de son instance avant qu'elle puisse s'activer. Par défaut, le `WaitForMetaDataAvailable` paramètre garantit que le service EC2 Config attend que les métadonnées de l'instance soient accessibles avant de poursuivre le processus de démarrage. Pour de plus amples informations, veuillez consulter [Utiliser les métadonnées des instances pour gérer votre instance EC2](ec2-instance-metadata.md).

Si l'instance échoue au test d'accessibilité de l'instance, essayez la solution suivante pour résoudre le problème.
+ Vérifiez le bloc d'adresse CIDR de votre VPC. Une instance Windows ne peut pas démarrer correctement si elle est lancée dans un VPC ayant une plage d'adresses IP comprise entre `224.0.0.0` et `255.255.255.255` (plages d'adresses IP de classe D et de classe E). Ces plages d'adresses IP sont réservées et ne doivent pas être attribuées aux périphériques hôtes. Nous vous conseillons de créer un VPC avec un bloc d'adresse CIDR des plages d'adresses IP privées (non publiquement routables), comme spécifié dans la norme [RFC 1918](http://www.faqs.org/rfcs/rfc1918.html).
+ Il est possible que le système ait été configuré avec une adresse IP statique. Essayez de [créer une interface réseau](create-network-interface.md) et de l'[attacher à l'instance](network-interface-attachments.md#attach_eni).
+ 

**Pour activer DHCP sur une instance Windows à laquelle vous ne parvenez pas à vous connecter**

  1. Arrêtez l'instance affectée et détachez son volume racine.

  1. Lancez une instance temporaire dans la même zone de disponibilité que l’instance affectée.
**Avertissement**  
Si votre instance temporaire est basée sur la même AMI que l’instance d’origine, vous devez effectuer des étapes supplémentaires. Dans le cas contraire, vous ne serez pas en mesure de démarrer l’instance d’origine après la restauration de son volume racine en raison d’une collision de signature de disque. Sinon, sélectionnez une autre AMI pour l’instance temporaire. Par exemple, si l'instance d'origine utilise l'AMI AWS Windows pour Windows Server 2016, lancez l'instance temporaire à l'aide de l'AMI AWS Windows pour Windows Server 2019.

  1. Attachez le volume racine de l’instance affectée à cette instance temporaire. Connectez-vous à l'instance temporaire, ouvrez l'utilitaire **Gestion des disques** et mettez le lecteur en ligne.

  1. Dans l'instance temporaire, ouvrez **Regedit** et sélectionnez **HKEY\$1LOCAL\$1MACHINE**. Dans le menu **File (Fichier)**, choisissez **Load Hive (Charger Hive)**. Sélectionnez le lecteur, ouvrez le fichier `Windows\System32\config\SYSTEM` et spécifiez un nom de clé lorsque vous y êtes invité (vous pouvez utiliser n'importe quel nom).

  1. Sélectionnez la clé que vous venez de charger et naviguez jusqu'à `ControlSet001\Services\Tcpip\Parameters\Interfaces`. Chaque interface réseau est répertoriée par un GUID. Sélectionnez l'interface réseau correcte. Si DHCP est désactivé et qu'une adresse IP statique est attribuée, `EnableDHCP` est défini sur 0. Pour activer DHCP, définissez `EnableDHCP` sur 1 et supprimez les clés suivantes si elles existent : `NameServer`, `SubnetMask`, `IPAddress` et `DefaultGateway`. Sélectionnez à nouveau la clé, puis dans le menu **File (Fichier)**, sélectionnez **Unload Hive (Décharger Hive)**.
**Note**  
Si vous avez plusieurs interfaces réseau, vous devrez identifier l'interface appropriée pour activer DHCP. Pour identifier l'interface réseau appropriée, consultez les valeurs de clé `NameServer`, `SubnetMask`, `IPAddress` et `DefaultGateway`. Ces valeurs affichent la configuration statique de l'instance précédente. 

  1. (Facultatif) Si DHCP est déjà activé, il est possible que vous ne disposiez pas d'une route vers le service de métadonnées. La mise à jour de EC2 Config peut résoudre ce problème.

     1. [Téléchargez](https://s3.amazonaws.com/ec2-downloads-windows/EC2Config/EC2Install.zip) et installez la dernière version du service EC2 Config. Pour en savoir plus sur l’installation de ce service, consultez [Installez la dernière version de EC2 Config](UsingConfig_Install.md).

     1. Extrayez les fichiers du fichier `.zip` dans le répertoire `Temp` du lecteur que vous avez attaché.

     1. Ouvrez **Regedit** et sélectionnez **HKEY\$1LOCAL\$1MACHINE**. Dans le menu **File (Fichier)**, choisissez **Load Hive (Charger Hive)**. Sélectionnez le lecteur, ouvrez le fichier `Windows\System32\config\SOFTWARE` et spécifiez un nom de clé lorsque vous y êtes invité (vous pouvez utiliser n'importe quel nom).

     1. Sélectionnez la clé que vous venez de charger et naviguez jusqu'à `Microsoft\Windows\CurrentVersion`. Sélectionnez la clé `RunOnce`. (Si elle n'existe pas, cliquez avec le bouton droit sur `CurrentVersion`, pointez la souris vers **Nouveau**, sélectionnez **Clé** et nommez la clé `RunOnce`.) Cliquez avec le bouton droit, pointez la souris vers **Nouveau** et sélectionnez **Valeur de chaîne**. Entrez le nom `Ec2Install` et les données `C:\Temp\Ec2Install.exe -q`.

     1. Sélectionnez à nouveau la clé, puis dans le menu **File (Fichier)**, sélectionnez **Unload Hive (Décharger Hive)**.

  1. (Facultatif) Si votre instance temporaire est basée sur la même AMI que l’instance d’origine, vous devez effectuer les étapes suivantes. Dans le cas contraire, vous ne serez pas en mesure de démarrer l’instance d’origine après la restauration de son volume racine en raison d’une collision de signature de disque.
**Avertissement**  
La procédure suivante décrit comment modifier le Registre Windows à l’aide de l’Éditeur de Registre. Si vous n’êtes pas familier avec le Registre Windows ou comment apporter des modifications en toute sécurité à l’aide de l’Éditeur de Registre, consultez [Configurer le registre](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725612(v=ws.11)).

     1. Ouvrez une invite de commande, saisissez **regedit.exe**, puis appuyez sur Entrée.

     1. Dans **Editeur de registre**, choisissez **HKEY\$1LOCAL\$1MACHINE** dans le menu contextuel (clic droit), puis choisissez **Rechercher**.

     1. Cliquez sur **Windows Boot Manager**, puis.choisissez **Rechercher suivant**.

     1. Choisissez la clé nommée `11000001`. Cette clé est apparentée à la clé que vous avez trouvée à l’étape précédente.

     1. Dans le volet droit, choisissez `Element`, puis.**Modifier** à partir du menu contextuel (clic droit).

     1. Localisez la signature du disque de quatre octets au décalage 0x38 dans les données. Inversez les octets pour créer la signature du disque et l’écrire. Par exemple, la signature de disque représentée par les données suivantes est `E9EB3AA5` :

        ```
        ...
        0030  00 00 00 00 01 00 00 00
        0038  A5 3A EB E9 00 00 00 00
        0040  00 00 00 00 00 00 00 00
        ...
        ```

     1. Dans une fenêtre d'invite de commandes, exécutez la commande suivante pour démarrer Microsoft DiskPart.

        ```
        diskpart
        ```

     1. Exécutez la DiskPart commande suivante pour sélectionner le volume. (Vous pouvez vérifier que le numéro de disque est 1 à l’aide de l’utilitaire **Gestion des disques**.

        ```
        DISKPART> select disk 1
        
        Disk 1 is now the selected disk.
        ```

     1. Exécutez la DiskPart commande suivante pour obtenir la signature du disque.

        ```
        DISKPART>  uniqueid disk
        
        Disk ID: 0C764FA8
        ```

     1. Si la signature de disque affichée à l'étape précédente ne correspond pas à la signature de disque de BCD que vous avez notée plus tôt, utilisez la DiskPart commande suivante pour modifier la signature de disque afin qu'elle corresponde :

        ```
        DISKPART> uniqueid disk id=E9EB3AA5
        ```

  1. À l’aide de l’utilitaire **Gestion des disques**, déconnectez le lecteur.
**Note**  
Le lecteur est automatiquement hors ligne si l’instance temporaire exécute le même système d’exploitation que l’instance concernée. Vous n’aurez donc pas besoin de le mettre hors ligne manuellement.

  1. Détachez le volume de l’instance temporaire. Vous pouvez mettre l'instance temporaire hors service si vous n'en avez plus besoin.

  1. Restaurez le volume racine de l'instance affectée en attachant le volume en tant que `/dev/sda1`.

  1. Démarrez l'instance concernée.

Si vous êtes connecté à l'instance, ouvrez un navigateur Internet dans l'instance et entrez l'URL suivante pour le serveur de métadonnées :

```
http://169.254.169.254/latest/meta-data/
```

Si vous ne pouvez pas contacter le serveur de métadonnées, essayez la solution suivante pour résoudre le problème :
+ [Téléchargez](https://s3.amazonaws.com/ec2-downloads-windows/EC2Config/EC2Install.zip) et installez la dernière version du service EC2 Config. Pour en savoir plus sur l’installation de ce service, consultez [Installez la dernière version de EC2 Config](UsingConfig_Install.md).
+ Vérifiez si l’instance Windows exécute des pilotes PV Red Hat. Si c'est le cas, mettez à jour les pilotes PV Citrix. Pour de plus amples informations, veuillez consulter [Mettre à niveau des pilotes PV sur les instances EC2 Windows](Upgrading_PV_drivers.md).
+ Vérifiez que les paramètres du pare-feu et du proxy ne bloquent pas le trafic sortant vers le service de métadonnées (`169.254.169.254`) ou les AWS KMS serveurs (les adresses sont spécifiées dans les `TargetKMSServer` éléments dans`C:\Program Files\Amazon\Ec2ConfigService\Settings\ActivationSettings.xml`). IPSec
+ Vérifiez que vous disposez d'une route vers le service de métadonnées (`169.254.169.254`) à l'aide de la commande suivante.

  ```
  route print
  ```
+ Vérifiez les problèmes de réseau susceptibles d'affecter la zone de disponibilité de votre instance. Accédez à [http://status.aws.amazon.com/](https://status.aws.amazon.com/).

## « L'activation de Windows est impossible »
<a name="activate-windows"></a>

Les instances Windows utilisent l' AWS KMS activation Windows. Vous pouvez recevoir ce message :`A problem occurred when Windows tried to activate. Error Code 0xC004F074`, si votre instance ne parvient pas à atteindre le AWS KMS serveur. Windows doit être activé tous les 180 jours. EC2Config tente de contacter le AWS KMS serveur avant l'expiration de la période d'activation pour s'assurer que Windows reste activé.

Si vous rencontrez un problème d'activation Windows, utilisez la procédure suivante pour le résoudre.

**Pour EC2 Config (Windows Server 2012 R2 AMIs et versions antérieures)**

1. [Téléchargez](https://s3.amazonaws.com/ec2-downloads-windows/EC2Config/EC2Install.zip) et installez la dernière version du service EC2 Config. Pour en savoir plus sur l’installation de ce service, consultez [Installez la dernière version de EC2 Config](UsingConfig_Install.md).

1. Connectez-vous à l'instance et ouvrez le fichier suivant : `C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml`.

1. Localisez le WindowsActivate plugin **Ec2** dans le `config.xml` fichier. Remplacez l'état par **Activé**, puis enregistrez vos modifications.

1. Dans le composant logiciel enfichable Windows Services, redémarrez le service EC2 Config ou redémarrez l'instance.

Si cette procédure ne résout pas le problème d'activation, suivez ces étapes supplémentaires.

1. Définissez l' AWS KMS objectif : **C:\$1> slmgr.vbs /skms 169.254.169.250:1688**

1. Activez Windows : **C:\$1> slmgr.vbs /ato**

**Pour EC2 le lancement (Windows Server 2016 AMIs et versions ultérieures)**

1. À partir d'une PowerShell invite indiquant les droits d'administration, importez le module EC2 Launch :

   ```
   PS C:\> Import-Module "C:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psd1"
   ```

1. Appelez la fonction Add-Routes pour voir la liste des nouvelles routes :

   ```
   PS C:\> Add-Routes
   ```

1. Appelez la ActivationSettings fonction Set- :

   ```
   PS C:\> Set-Activationsettings
   ```

1. Ensuite, exécutez le script suivant pour activer Windows :

   ```
   PS C:\> cscript "${env:SYSTEMROOT}\system32\slmgr.vbs" /ato
   ```

 Pour EC2 Config et EC2 Launch, si vous recevez toujours une erreur d'activation, vérifiez les informations suivantes.
+ Vérifiez que vous disposez de routes vers les AWS KMS serveurs. Ouvrez `C:\Program Files\Amazon\Ec2ConfigService\Settings\ActivationSettings.xml` et recherchez les éléments `TargetKMSServer`. Exécutez la commande suivante et vérifiez si les adresses de ces AWS KMS serveurs sont répertoriées.

  ```
  route print
  ```
+ Vérifiez que la clé AWS KMS client est définie. Exécutez la commande suivante et consultez la sortie.

  ```
  C:\Windows\System32\slmgr.vbs /dlv
  ```

  Si le résultat contient le message d'erreur : clé de produit introuvable, la clé AWS KMS client n'est pas définie. Si la clé AWS KMS client n'est pas définie, recherchez-la comme décrit dans cet article de Microsoft : [activation du AWS KMS client et clés de produit](https://learn.microsoft.com/en-us/windows-server/get-started/kms-client-activation-keys), puis exécutez la commande suivante pour définir la clé AWS KMS client.

  ```
  C:\Windows\System32\slmgr.vbs /ipk client_key
  ```
+ Vérifiez que le système dispose de l'heure et du fuseau horaires adéquats. Si vous utilisez un fuseau horaire différent de celui de l'heure universelle coordonnée (UTC), ajoutez la clé de registre suivante et attribuez-lui la valeur `1` pour vous assurer que l'heure est correcte : `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal`.
+ Si le pare-feu Windows est activé, désactivez-le temporairement à l'aide de la commande suivante.

  ```
  netsh advfirewall set allprofiles state off
  ```

## « Windows n'est pas authentique (0x80070005) »
<a name="windows-not-genuine"></a>

Les instances Windows utilisent l' AWS KMS activation Windows. Si une instance ne parvient pas à terminer le processus d'activation, elle signale que la copie de Windows n'est pas authentique.

Essayez les suggestions de la section [« L'activation de Windows est impossible »](#activate-windows).

## « Aucun serveur de licences Terminal Server n'est disponible pour fournir une licence »
<a name="no-license-servers"></a>

Par défaut, la licence Windows Server autorise deux utilisateurs simultanés via les services Bureau à distance. Si vous devez fournir à plus de deux utilisateurs un accès simultané à votre instance Windows via Bureau à distance, vous pouvez acheter une licence d'accès client (CAL) des services Bureau à distance et installer l'hôte de la session des services Bureau à distance et les rôles du Serveur du Gestionnaire de licences des services Bureau à distance.

Vérifiez les problèmes suivants :
+ Vous avez dépassé le nombre maximal de sessions RDP simultanées.
+ Vous avez installé le rôle des services Bureau à distance Windows.
+ Le Gestionnaire de licences a expiré. Le cas échéant, vous ne pouvez pas vous connecter à votre instance Windows en tant qu'utilisateur. Vous pouvez essayer l'une des actions suivantes : 
  + Connectez-vous à l'instance à partir de la ligne de commande à l'aide du paramètre `/admin`, par exemple : 

    ```
    mstsc /v:instance /admin
    ```

    Pour plus d'informations, consultez l'article Microsoft suivant : [Access Remote Desktop Via Command Line](https://learn.microsoft.com/en-us/archive/technet-wiki/4487.access-remote-desktop-via-commandline).
  + Arrêtez l'instance, détachez ses volumes Amazon EBS et attachez-les à une autre instance dans la même zone de disponibilité pour récupérer vos données.

## « Certains paramètres sont gérés par votre organisation »
<a name="some-settings-managed-by-org"></a>

Les instances lancées à partir de la dernière version de Windows Server AMIs peuvent afficher un message de dialogue Windows Update indiquant « Certains paramètres sont gérés par votre organisation ». Ce message apparaît en réponse à des changements dans Windows Server et n'affecte pas le comportement de Windows Update, ni votre capacité à gérer les paramètres de mise à jour.

**Pour supprimer l'avertissement**

1. Ouvrez `gpedit.msc` et accédez à **Configuration ordinateur**, **Modèles d'administration**, **Composants Windows**, **Mises à jour Windows**. Modifiez **Configurer la mise à jour automatique** et définissez la valeur **activé**.

1. Dans une invite de commandes, mettez à jour la politique de groupe avec **gpupdate /force**.

1. Fermez et rouvrez les Paramètres de Windows Update. Vous verrez le message ci-dessus indiquant que vos paramètres sont gérés par votre organisation, suivi par « Nous téléchargerons automatiquement les mises à jour, sauf si vous disposez d'une connexion limitée (où des frais s'appliquent). Dans ce cas, nous ne téléchargerons automatiquement que les mises à jour nécessaires au bon fonctionnement de Windows. »

1. Revenez à `gpedit.msc` et redéfinissez la stratégie de groupe sur la valeur **non configuré**. Exécutez à nouveau **gpupdate /force**.

1. Fermez l'invite de commande et patientez quelques minutes.

1. Rouvrez les Paramètres de Windows Update. Le message « Certains paramètres sont gérés par votre organisation. » ne doit pas s'afficher.

# Résoudre les problèmes liés aux instances Amazon EC2 Windows
<a name="win-ts-common-issues"></a>

Vous trouverez ci-dessous des conseils pour vous aider à résoudre les problèmes liés aux instances Amazon EC2 Windows.

**Topics**
+ [Impossible de connecter le Gestionnaire de AWS Systems Manager sessions à une instance Windows Server 2025](#connect-sysmgr-win2025)
+ [Les volumes EBS ne s’initialisent pas sur Windows Server 2016 et 2019](#init-disks-win2k16)
+ [Démarrer une instance Windows EC2 en mode de restauration des services d’annuaire (DSRM)](#boot-dsrm)
+ [L’instance perd la connectivité réseau ou les tâches programmées ne s’exécutent pas au moment prévu](#instance-loses-network-connectivity)
+ [Impossible d’obtenir la sortie de la console](#no-console-output)
+ [Windows Server 2012 R2 non disponible sur le réseau](#server-2012-network-loss)
+ [Collision de signature de disque](#disk-signature-collision)

## Impossible de connecter le Gestionnaire de AWS Systems Manager sessions à une instance Windows Server 2025
<a name="connect-sysmgr-win2025"></a>

Il se peut que vous rencontriez un problème lors de la connexion du Gestionnaire de AWS Systems Manager sessions à une instance Windows Server 2025. Pour résoudre ce problème, connectez-vous à l’instance, puis accédez à l’`Settings > Apps > Optional Features`instance et ajoutez-la`WMIC`. Redémarrez le service SSM Agent ou redémarrez l’instance, et vous Sessions Manager devriez vous connecter.

Vous pouvez également utiliser la PowerShell commande suivante pour effectuer la même action :

```
Start-Process -FilePath "$env:SystemRoot\system32\Dism.exe" -ArgumentList @('/Online', '/Add-Capability', '/CapabilityName:WMIC~~~~') -Wait; Restart-Service -Name AmazonSSMAgent
```

## Les volumes EBS ne s’initialisent pas sur Windows Server 2016 et 2019
<a name="init-disks-win2k16"></a>

Les instances créées à partir d'Amazon Machine Images (AMIs) pour Windows Server 2016 et 2019 utilisent l'agent EC2 Launch v1 pour diverses tâches de démarrage, notamment l'initialisation de volumes EBS. Par défaut, EC2 Launch v1 n'initialise pas les volumes secondaires. Cependant, vous pouvez configurer EC2 Launch v1 pour initialiser automatiquement ces disques, comme suit.

**Mapper les lettres de lecteur avec les volumes**

1. Connectez-vous à l’instance que vous voulez configurer et ouvrez le fichier `C:\ProgramData\Amazon\EC2-Windows\Launch\Config\DriveLetterMappingConfig.json` dans un éditeur de texte.

1. Spécifiez les paramètres du volume, comme suit :

   ```
   {
   "driveLetterMapping": [
   	{
   	  "volumeName": "sample volume",
   	  "driveLetter": "H"
   	}]
   }
   ```

1. Enregistrez les modifications, puis fermez le fichier.

1. Ouvrez Windows PowerShell et utilisez la commande suivante pour exécuter le script EC2 Launch v1 qui initialise les disques :

   ```
   PS C:\>  C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeDisks.ps1
   ```

   Pour initialiser les disques chaque fois que l’instance démarre, ajoutez l’indicateur `-Schedule` comme suit :

   ```
   PS C:\>  C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeDisks.ps1 -Schedule
   ```

   L'agent EC2 Launch v1 peut exécuter des scripts d'initialisation d'instance, par exemple `initializeDisks.ps1` en parallèle avec le `InitializeInstance.ps1` script. Si le script `InitializeInstance.ps1` redémarre l’instance, il peut interrompre d’autres tâches planifiées qui s’exécutent au démarrage de l’instance. Pour éviter tout conflit potentiel, nous vous recommandons d’ajouter de la logique à votre script `initializeDisks.ps1`pour vous assurer que l’initialisation de l’instance est terminée en premier.
**Note**  
Si le script de EC2 lancement n'initialise pas les volumes, assurez-vous qu'ils sont en ligne. Si les volumes sont hors ligne, exécutez la commande suivante pour mettre tous les disques en ligne.  

   ```
   PS C:\> Get-Disk | Where-Object IsOffline -Eq $True | Set-Disk -IsOffline $False
   ```

## Démarrer une instance Windows EC2 en mode de restauration des services d’annuaire (DSRM)
<a name="boot-dsrm"></a>

Si une instance s’exécutant sur Microsoft Active Directory fait l’objet d’une défaillance système ou rencontre d’autres problèmes majeurs, vous pouvez la dépanner en la démarrant dans une version spéciale du mode sans échec Safe Mode appelé *Mode de restauration des services d’annuaire* (DSRM). Le mode DSRM vous permet de réparer ou de récupérer Active Directory.

### Prise en charge du pilote de DSRM
<a name="boot-dsrm-driver"></a>

La méthode avec laquelle vous activez le mode DSRM et démarrez dans l’instance dépend des pilotes que l’instance exécute. Dans la console EC2, vous pouvez afficher les détails de la version du pilote d’une instance dans le journal système. Le tableau suivant montre quels sont les pilotes pris en charge pour DSRM.


| Versions des pilotes | Mode DSRM pris en charge ? | Étapes suivantes | 
| --- | --- | --- | 
| PV Citrix 5.9 | Non | Restaurez l’instance à partir d’une sauvegarde. Vous ne pouvez pas activer le mode DSRM. | 
| AWS PV 7.2.0 | Non | Si DSRM n’est pas pris en charge pour ce pilote, vous pouvez toujours détacher le volume racine de l’instance, créer un instantané ou une AMI du volume et l’attacher à une autre instance dans la même zone de disponibilité en tant que volume secondaire. Vous pouvez ensuite activer DSRM (comme décrit dans cette section). | 
| AWS PV 7.2.2 et versions ultérieures | Oui | Détachez le volume racine, attachez-le à une autre instance, puis activez le mode DSRM (comme décrit dans cette section). | 
| Mise en réseau améliorée | Oui | Détachez le volume racine, attachez-le à une autre instance, puis activez le mode DSRM (comme décrit dans cette section). | 

Pour plus d’informations sur la façon d’activer la mise en réseau améliorée, consultez[Activez la mise en réseau améliorée grâce à l’ENA sur vos instances EC2](enhanced-networking-ena.md). Pour plus d'informations sur la mise à niveau des pilotes AWS PV, voir [Mettre à niveau les pilotes PV sur les instances Windows](Upgrading_PV_drivers.md).

### Configurer une instance à démarrer dans le mode DSRM
<a name="configure-boot-dsrm"></a>

Les instances Windows EC2 n’ont pas de connectivité réseau tant que le système d’exploitation ne s’exécute pas. C’est pourquoi vous ne pouvez pas appuyer sur la touche F8 de votre clavier pour sélectionner une option de démarrage. Vous devez utiliser l’une des procédures suivantes pour démarrer une instance Windows Server EC2 dans le mode DSRM.

Si vous craignez qu’Active Directory ait été corrompu et que l’instance soit toujours en cours d’exécution, vous pouvez configurer l’instance pour démarrer dans le mode DSRM à l’aide de la boîte de dialogue Configuration du système ou l’invite de commande.

**Pour démarrer une instance en ligne dans le mode DSRM à l’aide de la boîte de dialogue Configuration du système**

1. Dans la boîte de dialogue **Exécuter**, tapez `msconfig` et appuyez sur Entrée.

1. Choisissez l’onglet **Démarrage**.

1. Sous **Options de démarrage**, choisissez **Démarrage sécurisé**.

1. Choisissez **Réparer Active Directory**, puis **OK**. Le système vous invite à redémarrer le serveur.

**Pour démarrer une instance en ligne dans le mode DSRM à l’aide de la ligne de commande**  
A partir d’une fenêtre d’invite de commande, exécutez la commande suivante :

```
bcdedit /set safeboot dsrepair
```

Si une instance est hors ligne et inaccessible, vous devez détacher le volume racine et l’attacher à une autre instance pour activer le mode DSRM.

**Pour démarrer une instance hors ligne dans le mode DSRM**

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. Recherchez et sélectionnez l’instance affectée. Choisissez **État de l’instance**, **Arrêter l’instance**.

1. Choisissez **Lancer les instances** et créez une instance temporaire dans la même zone de disponibilité que l’instance affectée. Choisissez un type d’instance qui utilise une autre version de Windows. Par exemple, si votre instance est Windows Server 2016, choisissez une instance Windows Server 2019.
**Important**  
Si vous ne créez pas l’instance dans la même zone de disponibilité que l’instance affectée, vous ne pourrez pas attacher le volume racine de celle-ci à la nouvelle instance.

1. Dans le panneau de navigation, choisissez **Volumes**.

1. Recherchez le volume racine de l’instance affectée. [Détachez](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-detaching-volume.html) le volume et [attachez](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-attaching-volume.html)-le à l’instance temporaire que vous avez créée précédemment. Attachez-le avec le nom du périphérique par défaut (xvdf).

1. Utilisez les services Bureau à distance pour vous connecter à l’instance temporaire, puis utilisez l’utilitaire Gestion des disques pour [rendre le volume disponible](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html).

1. Ouvrez une invite de commande et exécutez la commande suivante. Remplacez *D* par la lettre de lecteur réelle du volume secondaire que vous venez d’attacher :

   ```
   bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair
   ```

1. Dans l’utilitaire Gestion des disques, choisissez le lecteur que vous avez attaché précédemment, ouvrez le menu contextuel (clic droit) et choisissez **Hors connexion**.

1. Dans la console Amazon EC2, détachez le volume affecté de l’instance temporaire et rattachez-le à votre instance originale avec le nom de périphérique `/dev/sda1`. Vous devez spécifier ce nom de périphérique pour désigner le volume en tant que volume racine.

1. [Démarrez](Stop_Start.md) l’instance.

1. Une fois que l’instance réussit les vérifications de l’état dans la console EC2, connectez-vous à l’instance à l’aide des services Bureau à distance et vérifiez qu’elle démarre dans le mode DSRM.

1. (Facultatif) Supprimez ou arrêtez l’instance temporaire que vous avez créée au cours de cette procédure.

## L’instance perd la connectivité réseau ou les tâches programmées ne s’exécutent pas au moment prévu
<a name="instance-loses-network-connectivity"></a>

Si vous redémarrez votre instance et qu’elle perd sa connectivité réseau, il est possible que l’instance ne soit pas à l’heure.

Par défaut, les instances Windows utilisent l’heure universelle coordonnée (UTC). Si vous définissez l’heure de votre instance sur un autre fuseau horaire et que vous la redémarrez, l’heure se décale et l’instance perd temporairement son adresse IP. L’instance finit par rétablir sa connectivité réseau, mais cela peut prendre plusieurs heures. Le délai nécessaire pour que l’instance rétablisse sa connectivité réseau dépend de la différence entre l’heure universelle coordonnée (UTC) et l’autre fuseau horaire.

Ce problème peut également entraîner l’absence d’exécution de tâches planifiées au moment prévu. Dans ce cas, les tâches planifiées ne s’exécutent pas au moment prévu, car l’heure de l’instance est incorrecte.

Pour utiliser un fuseau horaire autre que UTC de manière persistante, vous devez définir la clé de **RealTimeIsUniversal**registre. Sans cette clé, une instance utilise l’heure universelle coordonnée (UTC) après avoir redémarré.

**Pour résoudre les problèmes d’heure qui entraînent une perte de la connectivité réseau**

1. Vérifiez que vous exécutez les pilotes PV recommandés. Pour de plus amples informations, veuillez consulter [Mettre à niveau des pilotes PV sur les instances EC2 Windows](Upgrading_PV_drivers.md).

1. Vérifiez que la clé de registre suivante existe et qu'elle est définie sur `1` : **HKEY\$1LOCAL\$1MACHINE \$1 SYSTEM \$1 \$1 Control \$1 \$1 CurrentControlSet TimeZoneInformation RealTimeIsUniversal**

## Impossible d’obtenir la sortie de la console
<a name="no-console-output"></a>

Pour les instances Windows, la sortie de la console de l’instance affiche la sortie des tâches exécutées à l’aide du processus d’amorçage Windows. Si Windows démarre correctement, le dernier message enregistré est `Windows is Ready to use`. Vous pouvez également afficher des messages de journaux d’événements sur la console, mais cette fonction peut ne pas être activée par défaut selon votre version de Windows. Pour de plus amples informations, veuillez consulter [Agents de lancement Windows sur les instances Amazon EC2 Windows](configure-launch-agents.md).

Pour obtenir la sortie de la console de votre instance à l’aide de la console Amazon EC2, sélectionnez l’instance, puis **Actions**, **Surveiller et dépanner** et **Obtenir le journal système**. Pour obtenir le résultat de la console à l'aide de la ligne de commande, utilisez l'une des commandes suivantes : [get-console-output](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-console-output.html)(AWS CLI) ou [Get-EC2ConsoleOutput](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2ConsoleOutput.html)(AWS Tools for Windows PowerShell).

Pour les instances exécutant Windows Server 2012 R2 et versions antérieures, si la sortie de la console est vide, cela peut indiquer un problème avec le service EC2 Config, tel qu'un fichier de configuration mal configuré ou un échec du démarrage de Windows. Pour résoudre le problème, téléchargez et installez la dernière version de EC2 Config. Pour de plus amples informations, veuillez consulter [Installez la dernière version de EC2 Config](UsingConfig_Install.md).

## Windows Server 2012 R2 non disponible sur le réseau
<a name="server-2012-network-loss"></a>

Pour plus d’informations sur le dépannage d’une instance Windows Server 2012 R2 qui n’est pas disponible sur le réseau, consultez [Windows Server 2012 R2 perd la connectivité réseau et de stockage après le redémarrage d’une instance](pvdrivers-troubleshooting.md#server2012R2-instance-unavailable).

## Collision de signature de disque
<a name="disk-signature-collision"></a>

Vous pouvez vérifier et résoudre les collisions de signatures de disque à l'aide de [EC2Rescue for Windows Server](Windows-Server-EC2Rescue.md). Vous pouvez également résoudre manuellement les problèmes de signature de disque en effectuant les opérations suivantes :
**Avertissement**  
La procédure suivante décrit comment modifier le Registre Windows à l’aide de l’Éditeur de Registre. Si vous n’êtes pas familier avec le Registre Windows ou comment apporter des modifications en toute sécurité à l’aide de l’Éditeur de Registre, consultez [Configurer le registre](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725612(v=ws.11)).

1. Ouvrez une invite de commande, saisissez **regedit.exe**, puis appuyez sur Entrée.

1. Dans **Editeur de registre**, choisissez **HKEY\$1LOCAL\$1MACHINE** dans le menu contextuel (clic droit), puis choisissez **Rechercher**.

1. Cliquez sur **Windows Boot Manager**, puis.choisissez **Rechercher suivant**.

1. Choisissez la clé nommée `11000001`. Cette clé est apparentée à la clé que vous avez trouvée à l’étape précédente.

1. Dans le volet droit, choisissez `Element`, puis.**Modifier** à partir du menu contextuel (clic droit).

1. Localisez la signature du disque de quatre octets au décalage 0x38 dans les données. Il s’agit de la signature BCD (Boot Configuration Database). Inversez les octets pour créer la signature du disque et l’écrire. Par exemple, la signature de disque représentée par les données suivantes est `E9EB3AA5` :

   ```
   ...
   0030  00 00 00 00 01 00 00 00
   0038  A5 3A EB E9 00 00 00 00
   0040  00 00 00 00 00 00 00 00
   ...
   ```

1. Dans une fenêtre d'invite de commandes, exécutez la commande suivante pour démarrer Microsoft DiskPart.

   ```
   diskpart
   ```

1. Exécutez la `select disk` DiskPart commande et spécifiez le numéro de disque du volume concerné par la collision de signature de disque.
**Astuce**  
Pour vérifier le numéro de disque du volume présentant la collision de signature de disque, utilisez l’utilitaire **Gestion des disques**. Ouvrez une invite de commande, saisissez `compmgmt.msc`, puis appuyez sur **Entrée**. Dans le volet de navigation de gauche, double-cliquez sur **Gestion des disques**. Dans l’utilitaire **Gestion des disques**, vérifiez le numéro de disque du volume présentant la collision de signature de disque.

   ```
   DISKPART> select disk 1
   Disk 1 is now the selected disk.
   ```

1. Exécutez la DiskPart commande suivante pour obtenir la signature du disque.

   ```
   DISKPART>  uniqueid disk
   Disk ID: 0C764FA8
   ```

1. Si la signature de disque affichée à l'étape précédente ne correspond pas à la signature de disque que vous avez notée précédemment, utilisez la DiskPart commande suivante pour modifier la signature de disque afin qu'elle corresponde :

   ```
   DISKPART> uniqueid disk id=E9EB3AA5
   ```

# Débogage du noyau pour les instances Windows sur le réseau
<a name="troubleshoot-windows-with-kdnet"></a>

Le module d'extensibilité KDNET pour Elastic Network Adapter (ENA) est une couche de support des pilotes matériels qui permet le débogage du noyau Windows sur le réseau via ENA sur les instances Amazon Elastic Compute Cloud. Vous pouvez utiliser le module d'extensibilité avec le Windows Debugger (WinDbg) pour effectuer un débogage au niveau du noyau sur des instances EC2 exécutant Windows.

Le débogage du noyau vous aide à diagnostiquer et à résoudre les problèmes de bas niveau du système d'exploitation tels que les erreurs d'écran bleu (BSOD), les défaillances de pilotes et les problèmes de démarrage sur vos instances Windows EC2.

**Topics**
+ [Conditions préalables](#kdnet-prerequisites)
+ [Étape 1 : Installation des outils de débogage Windows sur l'hôte de débogage](#kdnet-step1-install-debugging-tools)
+ [Étape 2 : Configuration de la cible de débogage](#kdnet-step2-setup-debug-target)
+ [Étape 3 : démarrer la session de débogage sur l'hôte de débogage](#kdnet-step3-start-debugging-session)
+ [Étape 4 : redémarrez la cible de débogage](#kdnet-step4-reboot-debug-target)
+ [Nettoyer les paramètres de débogage après le débogage](#kdnet-clean-up)
+ [Limitations](#kdnet-limitations)
+ [Informations complémentaires](#kdnet-additional-notes)

## Conditions préalables
<a name="kdnet-prerequisites"></a>

Avant de commencer, assurez-vous de disposer des éléments suivants :

Deux instances Windows EC2, dans le même sous-réseau :
+ Une instance **hôte de débogage** : exécute le débogueur Windows (). WinDbg
+ Une instance **cible de débogage** : l'instance que vous souhaitez déboguer.

Pour plus d'informations sur le lancement d'instances, consultez[Commencez avec Amazon EC2](EC2_GetStarted.md).

Les groupes de sécurité pour les instances hôte et cible doivent autoriser le trafic UDP entrant et sortant sur le port utilisé pour le débogage de KDNET (plage recommandée : 50000—50039). Le moyen le plus simple de configurer cela consiste à créer un groupe de sécurité avec une règle entrante qui autorise le trafic UDP à partir de lui-même comme source, puis à associer ce groupe de sécurité aux deux instances. Pour plus d’informations, consultez [Règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC*.

L'instance cible de débogage doit exécuter l'une des versions Windows suivantes (ou une version ultérieure) :
+ Windows Server 2025 avec le numéro de version 26100.7462 (correctif de décembre 2025)
+ Windows 11 24H2 avec le numéro de version 26100.7309
+ Windows 11 25H2 avec le numéro de version 26200.7309

**Note**  
Le module d'extensibilité KDNET pour ENA est distribué dans le cadre de Windows et ne peut être mis à jour que par le biais de mises à jour cumulatives mensuelles de Windows. Nous vous recommandons de conserver la dernière version de Windows KB installée sur la cible de débogage afin de vous assurer que vous disposez de la version la plus récente de celle-ci.  
Pour vérifier que le module est présent sur la cible de débogage, exécutez la commande suivante dans une PowerShell session élevée :  

```
Test-Path C:\Windows\system32\kd_02_1d0f.dll
```
Si la commande revient`True`, le module est disponible.

## Étape 1 : Installation des outils de débogage Windows sur l'hôte de débogage
<a name="kdnet-step1-install-debugging-tools"></a>

Installez les outils de débogage Windows sur l'instance hôte de débogage en exécutant la commande suivante dans une PowerShell session :

```
winget install microsoft.windbg
```

Pour obtenir des instructions d'installation détaillées, voir [Installer le débogueur Windows](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/) dans la documentation Microsoft.

Après l'installation, vérifiez que le débogueur fonctionne en exécutant la commande suivante dans une PowerShell session :

```
windbgx
```

La WinDbg fenêtre devrait s'ouvrir. Si c'est le cas, l'installation est réussie et vous pouvez fermer la fenêtre.

## Étape 2 : Configuration de la cible de débogage
<a name="kdnet-step2-setup-debug-target"></a>

**Note**  
Lorsque le débogage du noyau est actif, le périphérique ENA utilisé pour la session de débogage est dédié au trafic du débogueur uniquement. Si vous devez conserver l'accès à Internet sur l'instance cible de débogage pendant le débogage, attachez un deuxième ENA à l'instance avant de commencer.

Sur la cible de débogage, ouvrez une PowerShell session élevée et configurez le débogage du noyau en suivant les étapes ci-dessous.

Exécutez la commande suivante pour répertorier le bus, le périphérique et le numéro de fonction de l'adaptateur ENA connecté à l'instance :

```
Get-NetAdapter -Physical |
    Where-Object -Property PnPDeviceID -Match -Value '^PCI\\VEN_1D0F&DEV_EC2[01]&' |
    Get-NetAdapterHardwareInfo |
    Select-Object InterfaceDescription, BusNumber, DeviceNumber, FunctionNumber |
    Format-List
```

### Si plusieurs adaptateurs ENA sont attachés à l'instance
<a name="kdnet-multiple-ena-adapters"></a>

Si plusieurs adaptateurs ENA sont attachés à l'instance, utilisez la commande suivante pour mapper chaque adaptateur physique à son adresse IP privée. Vous pouvez croiser ces informations dans la AWS Management Console section **EC2 → Instances → [ID d'instance] → Mise en réseau → Interfaces réseau**. Cela vous permet de corréler des groupes d'interface réseau IDs IPs, privés et de sécurité spécifiques avec l'adaptateur au niveau du système d'exploitation pour un débogage ciblé.

```
Get-NetAdapter -Physical |
    Where-Object PnPDeviceID -Match '^PCI\\VEN_1D0F&DEV_EC2[01]&' |
    ForEach-Object {
        $adapter = $_
        $hwInfo = $adapter | Get-NetAdapterHardwareInfo
        $ipInfo = Get-NetIPAddress -InterfaceIndex $adapter.InterfaceIndex -AddressFamily IPv4
        [PSCustomObject]@{
            InterfaceDescription = $adapter.InterfaceDescription
            IPAddress            = $ipInfo.IPAddress
            BusNumber            = $hwInfo.BusNumber
            DeviceNumber         = $hwInfo.DeviceNumber
            FunctionNumber       = $hwInfo.FunctionNumber
        }
    } | Format-List
```

Notez les `FunctionNumber` valeurs `BusNumber``DeviceNumber`, et de l'adaptateur ENA à utiliser pour le débogage à partir de la sortie.

Exécutez les commandes suivantes pour configurer le débogage du noyau. Remplacez les valeurs d'espace réservé par votre configuration spécifique :

```
bcdedit /debug on
bcdedit /set loadoptions FORCEHVTONOTSHAREDEBUGDEVICE
bcdedit /dbgsettings net hostip:host-private-ip port:port-number key:encryption-key busparams:b.d.f
```

**Note**  
Vérifiez l'existence `loadoptions` en exécutant la commande suivante. Si une valeur est renvoyée, copiez cette chaîne et `;FORCEHVTONOTSHAREDEBUGDEVICE` ajoutez-la.  

```
(bcdedit /enum) -match "loadoptions"
```

Où :
+ *host-private-ip*— IPv4 Adresse privée de l'instance hôte de débogage. Si vos instances sont lancées dans un sous-réseau IPv6 réservé, consultez [Configuration de KDNET dans la documentation Microsoft pour en](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection#ipv6) savoir plus sur IPv6 l'utilisation IPv6 de KDNET.
+ *port-number*— Port à utiliser pour la session de débogage. La plage recommandée est comprise entre 50000 et 50039 (par exemple,). `50000`
+ *encryption-key*— Une clé de 256 bits utilisée pour chiffrer la connexion de débogage, spécifiée sous la forme de quatre valeurs de 64 bits séparées par des points. Chaque valeur 64 bits peut comporter jusqu'à 13 caractères en utilisant uniquement des lettres minuscules de a à z et des chiffres de 0 à 9. Les caractères spéciaux ne sont pas autorisés. Exemple de clé de chiffrement :`1kdnet2keys3.4kdnet5keys6.7kdnet8keys9.10kdnet11ke`.
+ *b.d.f*— Les numéros de bus, de périphérique et de fonction du périphérique ENA, formatés comme `bus.device.function` (par exemple`0.3.0`), utilisés pour le débogage.

**Astuce**  
Pour déboguer le processus de démarrage de Windows, exécutez également la commande suivante :  

```
bcdedit /bootdebug on
```

## Étape 3 : démarrer la session de débogage sur l'hôte de débogage
<a name="kdnet-step3-start-debugging-session"></a>

Pour autoriser le débogage du trafic sur l'hôte, vous pouvez créer une règle de pare-feu pour l' WinDbg application ou pour un port UDP spécifique.

**Option 1 : Autoriser l' WinDbg application**  
Exécutez les commandes suivantes pour autoriser l' WinDbg exécutable :

```
$WinDbgxPath = "$env:LocalAppData\Microsoft\WindowsApps\WinDbgX.exe"
New-NetFirewallRule -DisplayName "Allow Inbound KDNET Connection" -Action Allow -Program $WinDbgxPath
```

**Option 2 : autoriser un port UDP spécifique**  
Vous pouvez également autoriser le trafic UDP entrant vers le port configuré pour le débogage du noyau. *port-number*Remplacez-le par le port KDNET de votre choix :

```
$DebugPort = port-number
New-NetFirewallRule -DisplayName "Allow Inbound KDNET Connection" -Direction Inbound -LocalPort $DebugPort -Protocol UDP -Action Allow
```

**Note**  
Les configurations de pare-feu peuvent être limitées par la politique de groupe de domaines (GPO) ou nécessiter des autorisations d'administrateur élevées. Si la commande échoue, contactez votre administrateur réseau.

 WinDbg Commencez par le port et la clé correspondant à la configuration de la cible de débogage. Vous pouvez spécifier des options supplémentaires de débogage du noyau documentées dans la [référence de ligne de WinDbg commande Microsoft](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/windbg-command-line-preview#kernel-options) en fonction de votre cas d'utilisation.

```
windbgx -k net:port=port-number,key=encryption-key
```

WinDbg s'ouvre et attend que la cible de débogage se connecte.

## Étape 4 : redémarrez la cible de débogage
<a name="kdnet-step4-reboot-debug-target"></a>

Sur la cible de débogage, redémarrez l'instance pour initier la connexion de débogage :

```
shutdown -r -t 0
```

Après le redémarrage de la cible de débogage, l'hôte WinDbg de débogage se connecte automatiquement à la cible. Vous pouvez désormais l'utiliser WinDbg pour inspecter l'état du noyau, définir des points d'arrêt et diagnostiquer les problèmes.

## Nettoyer les paramètres de débogage après le débogage
<a name="kdnet-clean-up"></a>

**Sur la cible de débogage**  
Une fois le débogage terminé, supprimez la configuration de débogage du noyau de la cible de débogage pour rétablir le comportement de démarrage normal. Sur la cible de débogage, ouvrez une PowerShell session élevée et exécutez les commandes suivantes :

```
bcdedit /debug off
bcdedit /dbgsettings LOCAL
bcdedit /deletevalue loadoptions
```

Si vous en avez un `loadoptions` autre`FORCEHVTONOTSHAREDEBUGDEVICE`, vous devez restaurer le paramètre `bcdedit /set loadoptions` en utilisant l'original`loadoptions`.

Si vous avez activé le débogage au démarrage, exécutez également :

```
bcdedit /bootdebug off
```

Redémarrez l'instance pour que les modifications prennent effet.

**Sur l'hôte de débogage**  
Supprimez la règle de pare-feu en exécutant :

```
Remove-NetFirewallRule -DisplayName "Allow Inbound KDNET Connection"
```

## Limitations
<a name="kdnet-limitations"></a>

Le module d'extensibilité KDNET pour ENA ne prend actuellement pas en charge :
+ types d'instances x86\$164 non métalliques de 8e génération (par exemple,) `m8a.xlarge`
+ types d'instances x86\$164 non métalliques 48xlarge de 7e génération (par exemple,) `m7a.48xlarge`
+ types d'instances u7i

Le module ne prend actuellement pas en charge les instances pour lesquelles le démarrage sécurisé est activé. Vous pouvez vérifier le statut `Confirm-SecureBootUEFI` en exécutant une PowerShell session élevée. Si le résultat est le cas`True`, Secure Boot est actif. Notez que le démarrage sécurisé est activé par défaut sur toutes les images fournies par Amazon avec le préfixe « TPM ».

## Informations complémentaires
<a name="kdnet-additional-notes"></a>

Si vous rencontrez des problèmes pour connecter le débogueur à l'instance cible, vérifiez les points suivants :
+ Toutes les conditions requises répertoriées dans ce guide sont remplies, y compris la version de build Windows Server requise et la présence du module d'extensibilité.
+ Les groupes de sécurité attachés aux deux instances sont correctement configurés pour autoriser le trafic entre eux sur le port de débogage configuré.
+ Les règles du pare-feu Windows sur les instances hôtes ne bloquent pas le trafic réseau entre les deux instances sur le port configuré.

Pour obtenir des instructions supplémentaires, voir [Configurer le débogage manuel du noyau du réseau KDNET](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection) dans la documentation Microsoft.

# Réinitialiser le mot de passe de l’administrateur Windows pour une instance Amazon EC2 Windows
<a name="ResettingAdminPassword"></a>

Si vous ne pouvez plus vous connecter à votre instance Amazon EC2 Windows parce que le mot de passe de l’administrateur Windows a été perdu ou a expiré, vous pouvez réinitialiser le mot de passe.

**Note**  
Il existe un document AWS Systems Manager d'automatisation qui applique automatiquement les étapes manuelles nécessaires pour réinitialiser le mot de passe de l'administrateur local. Pour plus d’informations, consultez la section [Réinitialiser les mots de passe et les clés SSH sur les instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2reset.html) dans le *Guide de l’utilisateur AWS Systems Manager *.

Les méthodes manuelles pour réinitialiser le mot de passe administrateur utilisent EC2 Launch v2, EC2 Config ou EC2 Launch.
+ Pour tous les systèmes Windows pris en charge AMIs qui incluent l'agent EC2 Launch v2, utilisez EC2 Launch v2.
+ Pour Windows AMIs antérieur à Windows Server 2016, utilisez le service EC2 Config.
+ Pour Windows Server 2016 et versions ultérieures AMIs, utilisez le service EC2 Launch.

Ces procédures expliquent aussi comment vous connecter à une instance, si vous avez perdu la paire de clés qui a été utilisée pour créer l’instance. Amazon EC2 utilise une clé publique pour chiffrer une portion de données, telle qu’un mot de passe, et une clé privée pour déchiffrer les données. La clé publique et la clé privée constituent une *paire de clés*. Avec les instances Windows, vous utilisez une paire de clés pour obtenir le mot de passe administrateur, puis vous vous connectez à l’aide du protocole RDP.

**Note**  
Si vous avez désactivé le compte d'administrateur local sur l'instance et que celle-ci est configurée pour Systems Manager, vous pouvez également réactiver et réinitialiser votre mot de passe d'administrateur local à l'aide de la commande EC2 Rescue and Run. Pour plus d'informations, consultez la section [Utiliser EC2 Rescue for Windows Server avec la commande d'exécution de Systems Manager](ec2rw-ssm.md).

**Topics**
+ [Réinitialiser le mot de passe administrateur Windows pour l'instance EC2 à l'aide de EC2 Launch v2](ResettingAdminPassword_EC2Launchv2.md)
+ [Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Launch](ResettingAdminPassword_EC2Launch.md)
+ [Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Config](ResettingAdminPassword_EC2Config.md)

# Réinitialiser le mot de passe administrateur Windows pour l'instance EC2 à l'aide de EC2 Launch v2
<a name="ResettingAdminPassword_EC2Launchv2"></a>

Si vous avez perdu votre mot de passe administrateur Windows et que vous utilisez une AMI Windows compatible incluant l'agent EC2 Launch v2, vous pouvez utiliser EC2 Launch v2 pour générer un nouveau mot de passe.

Si vous utilisez une AMI Windows Server 2016 ou version ultérieure qui n'inclut pas l'agent EC2 Launch v2, consultez[Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Launch](ResettingAdminPassword_EC2Launch.md).

Si vous utilisez une AMI Windows Server antérieure à Windows Server 2016 qui n'inclut pas l'agent EC2 Launch v2, consultez[Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Config](ResettingAdminPassword_EC2Config.md).

**Note**  
Si vous avez désactivé le compte d'administrateur local sur l'instance et que celle-ci est configurée pour Systems Manager, vous pouvez également réactiver et réinitialiser votre mot de passe d'administrateur local à l'aide de la commande EC2 Rescue and Run. Pour plus d'informations, consultez la section [Utiliser EC2 Rescue for Windows Server avec la commande d'exécution de Systems Manager](ec2rw-ssm.md).

**Note**  
Il existe un document AWS Systems Manager d'automatisation qui applique automatiquement les étapes manuelles nécessaires pour réinitialiser le mot de passe de l'administrateur local. Pour plus d’informations, consultez la section [Réinitialiser les mots de passe et les clés SSH sur les instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2reset.html) dans le *Guide de l’utilisateur AWS Systems Manager *.

Pour réinitialiser votre mot de passe administrateur Windows à l'aide de EC2 Launch v2, vous devez effectuer les opérations suivantes :
+ [Étape 1 : vérifier que l'agent EC2 Launch v2 est en cours d'exécution](#resetting-password-ec2launchv2-step1)
+ [Étape 2 : Détacher le volume racine de l’instance](#resetting-password-ec2launchv2-step2)
+ [Étape 3 : Attacher le volume à une instance temporaire](#resetting-password-ec2launchv2-step3)
+ [Étape 4 : Supprimer le fichier .run-once.](#resetting-password-ec2launchv2-step4)
+ [Étape 5 : Redémarrer l’instance originale](#resetting-password-ec2launchv2-step5)

## Étape 1 : vérifier que l'agent EC2 Launch v2 est en cours d'exécution
<a name="resetting-password-ec2launchv2-step1"></a>

Avant de tenter de réinitialiser le mot de passe administrateur, vérifiez que l'agent EC2 Launch v2 est installé et en cours d'exécution. Vous utiliserez l'agent EC2 Launch v2 pour réinitialiser le mot de passe administrateur plus loin dans cette section.

**Pour vérifier que l'agent EC2 Launch v2 est en cours d'exécution**

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 sélectionnez l’instance dont le mot de passe doit être réinitialisé. Cette instance s’appelle l’instance *originale* dans cette procédure.

1. Sélectionnez **Actions**, **Surveiller et dépanner**, **Obtenir le journal système**.

1. Localisez l'entrée EC2 Launch, par exemple **Launch : EC2 Launch v2 service v2.0.124**. Si vous voyez cette entrée, le service EC2 Launch v2 est en cours d'exécution.

   Si le résultat du journal système est vide ou si l'agent EC2 Launch v2 n'est pas en cours d'exécution, dépannez l'instance à l'aide du service Instance Console Screenshot. Pour de plus amples informations, veuillez consulter [Création d’une capture d’écran d’une instance inaccessible](troubleshoot-unreachable-instance.md#instance-console-screenshot).

## Étape 2 : Détacher le volume racine de l’instance
<a name="resetting-password-ec2launchv2-step2"></a>

Vous ne pouvez pas utiliser EC2 Launch v2 pour réinitialiser un mot de passe administrateur si le volume sur lequel le mot de passe est stocké est attaché à une instance en tant que volume racine. Vous devez détacher le volume de l’instance originale avant de pouvoir l’attacher à une instance temporaire en tant que volume secondaire.

**Détacher le volume racine 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 qui nécessite une réinitialisation du mot de passe et choisissez **État de l’instance**, **Arrêter l’instance**. Une fois que le statut de l’instance est passé à **Arrêtée**, passez à l’étape suivante.

1. (Facultatif) Si vous disposez de la clé privée que vous avez spécifiée lors du lancement de cette instance, passez à l’étape suivante. Sinon, procédez comme suit pour remplacer l’instance par une nouvelle instance que vous lancez par une nouvelle paire de clés.

   1. Créez une nouvelle paire de clés à l’aide de la console Amazon EC2. Si vous souhaitez nommer votre nouvelle paire de clés exactement comme la clé privée perdue, vous devez commencer par supprimer la paire de clés existante.

   1. Sélectionnez l’instance à remplacer. Notez le type d’instance, le VPC, le sous-réseau, le groupe de sécurité et le rôle IAM de l’instance.

   1. Une fois l’instance sélectionnée, choisissez **Actions**, **Image et modèles**, **Créer l’image**. Saisissez le nom et la description de l’image, puis choisissez **Créer l’image**.

   1. Dans le panneau de navigation, sélectionnez **AMIs**. Attendez que l’état de l’image devienne **disponible**. Ensuite, sélectionnez l’image et choisissez **Lancer l’instance à partir de l’AMI**.

   1. Remplissez les champs pour lancer une instance, en vous assurant de sélectionner le même type d’instance, le même VPC, le même sous-réseau, le même groupe de sécurité et le même rôle IAM que l’instance à remplacer, puis choisissez **Lancer l’instance**.

   1. Lorsque vous y êtes invité, choisissez la paire de clés que vous avez créée pour la nouvelle instance, puis cliquez sur **Lancer l’instance**.

   1. (Facultatif) Si l’instance d’origine a une adresse IP Elastic associée, associez-la à la nouvelle instance. Si l’instance d’origine comporte des volumes EBS en plus du volume racine, transférez-les vers la nouvelle instance.

1. Détachez le volume racine de l’instance d’origine comme suit :

   1. Sélectionnez l’instance d’origine et cliquez sur l’onglet **Stockage**. Notez le nom du périphérique racine sous **Nom du périphérique racine**. Recherchez le volume portant ce nom de périphérique dans la section **Périphérique de stockage en mode bloc** et notez l’ID du volume.

   1. Dans le panneau de navigation, choisissez **Volumes**.

   1. Dans la liste des volumes, sélectionnez le volume que vous avez noté comme périphérique racine, puis choisissez **Actions**, **Détacher un volume**. Une fois le statut du volume passé à **disponible**, passez à l’étape suivante.

1. Si vous avez créé une nouvelle instance pour remplacer votre instance d’origine, vous pouvez mettre fin à l’instance d’origine maintenant. Elle n’est plus nécessaire. Dans la suite de cette procédure, toutes les références à l’instance d’origine s’appliquent à la nouvelle instance que vous avez créée.

## Étape 3 : Attacher le volume à une instance temporaire
<a name="resetting-password-ec2launchv2-step3"></a>

Ensuite, lancez une instance temporaire et attachez-lui le volume en tant que volume secondaire. Il s’agit de l’instance que vous utilisez pour modifier le fichier de configuration.

**Pour lancer une instance temporaire et attacher le volume**

1. Lancez l’instance temporaire comme suit :

   1. Dans le panneau de navigation, choisissez **Instances**, puis choisissez **Lancer une instance**, puis sélectionnez une AMI.
**Important**  
Pour éviter les collisions de signature de disque, vous devez sélectionner une AMI pour une autre version de Windows. Par exemple, si l’instance d’origine exécute Windows Server 2019, lancez l’instance temporaire à l’aide de l’AMI d’origine pour Windows Server 2016.

   1. Quittez le type d’instance par défaut, puis choisissez **Suivant : configurer les détails de l’instance**.

   1. Dans la page **Configurer les détails d’instance**, pour **Sous-réseau**, sélectionnez la même zone de disponibilité que l’instance d’origine et choisissez **Revoir et lancer**.
**Important**  
Lancez une instance temporaire dans la même zone de disponibilité que l’instance d’origine. Si votre instance temporaire se trouve dans une zone de disponibilité différente, vous ne pouvez pas y attacher le volume racine de l’instance d’origine.

   1. Sur la page **Review Instance Launch**, sélectionnez **Launch**.

   1. Lorsque vous y êtes invité, créez une nouvelle paire de clés, téléchargez-la dans un emplacement sûr de votre ordinateur, puis choisissez **Lancer des instances**.

1. Attachez le volume à l’instance temporaire en tant que volume secondaire, comme suit :

   1. Dans le panneau de navigation, sélectionnez **Volumes**, choisissez le volume que vous avez détaché de l’instance d’origine, et sélectionnez **Actions**, **Attacher un volume**.

   1. Dans la boîte de dialogue **Attacher un volume**, pour **Instances**, commencez par saisir le nom ou l’ID de votre instance temporaire, puis sélectionnez-la dans la liste.

   1. Pour **Appareil**, saisissez **xvdf** (s’il n’est pas déjà présent), puis choisissez**Attacher**.

## Étape 4 : Supprimer le fichier .run-once.
<a name="resetting-password-ec2launchv2-step4"></a>

Vous devez à présent supprimer le fichier `.run-once` du volume hors ligne attaché à l’instance. Cela indique à EC2 Launch v2 d'exécuter toutes les tâches avec une fréquence de`once`, y compris la définition du mot de passe administrateur. Le chemin du fichier dans le volume secondaire que vous avez joint est similaire à `D:\ProgramData\Amazon\EC2Launch\state\.run-once`.

**Pour supprimer le fichier .run-once**

1. Ouvrez l’utilitaire **Gestion des disques** et mettez le lecteur en ligne à l’aide des instructions suivantes : [Rendre un volume Amazon EBS disponible à l’utilisation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html).

1. Localisez le fichier `.run-once` sur le disque que vous avez mis en ligne.

1. Supprimez le fichier .run-once.

**Important**  
Tous les scripts définis comme devant être exécutés une fois seront déclenchés par cette action.

## Étape 5 : Redémarrer l’instance originale
<a name="resetting-password-ec2launchv2-step5"></a>

Après avoir supprimé le fichier `.run-once`, rattachez le volume à l’instance originale en tant que volume racine et connectez-vous à l’instance en utilisant sa paire de clés pour récupérer le mot de passe administrateur.

1. Rattachez le volume à l’instance originale comme suit :

   1. Dans le panneau de navigation, choisissez **Volumes**, sélectionnez le volume que vous avez détaché de l’instance temporaire, et sélectionnez **Actions**, **Attacher un volume**.

   1. Dans la boîte de dialogue **Attacher un volume**, pour **Instances**, saisissez le nom ou l’ID de votre instance d’origine, puis sélectionnez l’instance.

   1. Pour **Appareil**, saisissez **/dev/sda1**.

   1. Choisissez **Attacher**. Une fois le statut du volume passé à `in-use`, passez à l’étape suivante.

1. Dans le panneau de navigation, choisissez **Instances**. Sélectionnez l’instance d’origine et choisissez **État de l’instance**, **Démarrer l’instance**. Après que l’état de l’instance est passé à `Running`, passez à l’étape suivante.

1. Récupérez votre nouveau mot de passe administrateur Windows à l’aide de la clé privée de la nouvelle paire de clés et connectez-vous à l’instance. Pour de plus amples informations, veuillez consulter [Se connecter à votre instance Windows à l’aide de RDP](connecting_to_windows_instance.md).
**Important**  
L’instance reçoit une nouvelle adresse IP publique après que vous l’arrêtiez et la redémarriez. Veillez à vous connecter à l’instance à l’aide de son nom DNS public. Pour de plus amples informations, veuillez consulter [Modifications de l'état de l' EC2 instance Amazon](ec2-instance-lifecycle.md).

1. (Facultatif) Vous pouvez résilier l’instance temporaire si vous n’en avez plus besoin. Sélectionnez l’instance temporaire, puis choisissez **État de l’instance** et **Résilier l’instance**.

# Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Launch
<a name="ResettingAdminPassword_EC2Launch"></a>

Si vous avez perdu votre mot de passe administrateur Windows et que vous utilisez une AMI Windows Server 2016 ou version ultérieure, vous pouvez utiliser l'[outil EC2 Rescue](Windows-Server-EC2Rescue.md), qui utilise le service EC2 Launch pour générer un nouveau mot de passe.

Si vous utilisez une AMI Windows Server 2016 ou version ultérieure qui n'inclut pas l'agent EC2 Launch v2, vous pouvez utiliser EC2 Launch v2 pour générer un nouveau mot de passe.

Si vous utilisez une AMI Windows Server antérieure à Windows Server 2016, consultez [Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Config](ResettingAdminPassword_EC2Config.md).

**Avertissement**  
Lorsque vous arrêtez une instance, les données relatives aux volumes de stockage de l'instance sont perdues. Pour conserver ces données, sauvegardez-les dans un espace de stockage permanent.

**Note**  
Si vous avez désactivé le compte d'administrateur local sur l'instance et que celle-ci est configurée pour Systems Manager, vous pouvez également réactiver et réinitialiser votre mot de passe d'administrateur local à l'aide de la commande EC2 Rescue and Run. Pour plus d'informations, consultez la section [Utiliser EC2 Rescue for Windows Server avec la commande d'exécution de Systems Manager](ec2rw-ssm.md).

**Note**  
Il existe un document AWS Systems Manager d'automatisation qui applique automatiquement les étapes manuelles nécessaires pour réinitialiser le mot de passe de l'administrateur local. Pour plus d’informations, consultez la section [Réinitialiser les mots de passe et les clés SSH sur les instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2reset.html) dans le *Guide de l’utilisateur AWS Systems Manager *.

Pour réinitialiser votre mot de passe administrateur Windows à l'aide de EC2 Launch, vous devez effectuer les opérations suivantes :
+ [Étape 1 : Détacher le volume racine de l’instance](#resetting-password-ec2launch-step1)
+ [Étape 2 : Attacher le volume à une instance temporaire](#resetting-password-ec2launch-step2)
+ [Étape 3 : Réinitialiser le mot de passe administrateur](#resetting-password-ec2launch-step3)
+ [Étape 4 : Redémarrer l’instance originale](#resetting-password-ec2launch-step4)

## Étape 1 : Détacher le volume racine de l’instance
<a name="resetting-password-ec2launch-step1"></a>

Vous ne pouvez pas utiliser EC2 Launch pour réinitialiser un mot de passe administrateur si le volume sur lequel le mot de passe est stocké est attaché à une instance en tant que volume racine. Vous devez détacher le volume de l’instance originale avant de pouvoir l’attacher à une instance temporaire en tant que volume secondaire.

**Détacher le volume racine 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 qui nécessite une réinitialisation du mot de passe et choisissez **État de l’instance**, **Arrêter l’instance**. Une fois que le statut de l’instance est passé à **Arrêtée**, passez à l’étape suivante.

1. (Facultatif) Si vous disposez de la clé privée que vous avez spécifiée lors du lancement de cette instance, passez à l’étape suivante. Sinon, procédez comme suit pour remplacer l’instance par une nouvelle instance que vous lancez par une nouvelle paire de clés.

   1. Créez une nouvelle paire de clés à l’aide de la console Amazon EC2. Si vous souhaitez nommer votre nouvelle paire de clés exactement comme la clé privée perdue, vous devez commencer par supprimer la paire de clés existante.

   1. Sélectionnez l’instance à remplacer. Notez le type d’instance, le VPC, le sous-réseau, le groupe de sécurité et le rôle IAM de l’instance.

   1. Une fois l’instance sélectionnée, choisissez **Actions**, **Image et modèles**, **Créer l’image**. Saisissez le nom et la description de l’image, puis choisissez **Créer l’image**.

   1. Dans le panneau de navigation, sélectionnez **AMIs**. Attendez que l’état de l’image devienne **disponible**. Ensuite, sélectionnez l’image et choisissez **Lancer l’instance à partir de l’AMI**.

   1. Remplissez les champs pour lancer une instance, en vous assurant de sélectionner le même type d’instance, le même VPC, le même sous-réseau, le même groupe de sécurité et le même rôle IAM que l’instance à remplacer, puis choisissez **Lancer l’instance**.

   1. Lorsque vous y êtes invité, choisissez la paire de clés que vous avez créée pour la nouvelle instance, puis cliquez sur **Lancer l’instance**.

   1. (Facultatif) Si l’instance d’origine a une adresse IP Elastic associée, associez-la à la nouvelle instance. Si l’instance d’origine comporte des volumes EBS en plus du volume racine, transférez-les vers la nouvelle instance.

1. Détachez le volume racine de l’instance d’origine comme suit :

   1. Sélectionnez l’instance d’origine et cliquez sur l’onglet **Stockage**. Notez le nom du périphérique racine sous **Nom du périphérique racine**. Recherchez le volume portant ce nom de périphérique dans la section **Périphérique de stockage en mode bloc** et notez l’ID du volume.

   1. Dans le panneau de navigation, choisissez **Volumes**.

   1. Dans la liste des volumes, sélectionnez le volume que vous avez noté comme périphérique racine, puis choisissez **Actions**, **Détacher un volume**. Une fois le statut du volume passé à **disponible**, passez à l’étape suivante.

1. Si vous avez créé une nouvelle instance pour remplacer votre instance d’origine, vous pouvez mettre fin à l’instance d’origine maintenant. Elle n’est plus nécessaire. Dans la suite de cette procédure, toutes les références à l’instance d’origine s’appliquent à la nouvelle instance que vous avez créée.

## Étape 2 : Attacher le volume à une instance temporaire
<a name="resetting-password-ec2launch-step2"></a>

Ensuite, lancez une instance temporaire et attachez-lui le volume en tant que volume secondaire. Il s'agit de l'instance que vous utilisez pour exécuter EC2 Launch.

**Pour lancer une instance temporaire et attacher le volume**

1. Lancez l’instance temporaire comme suit :

   1. Dans le panneau de navigation, choisissez **Instances**, puis choisissez **Lancer une instance**, puis sélectionnez une AMI.
**Important**  
Pour éviter les collisions de signature de disque, vous devez sélectionner une AMI pour une autre version de Windows. Par exemple, si l’instance d’origine exécute Windows Server 2019, lancez l’instance temporaire à l’aide de l’AMI d’origine pour Windows Server 2016.

   1. Quittez le type d’instance par défaut, puis choisissez **Suivant : configurer les détails de l’instance**.

   1. Dans la page **Configurer les détails d’instance**, pour **Sous-réseau**, sélectionnez la même zone de disponibilité que l’instance d’origine et choisissez **Revoir et lancer**.
**Important**  
Lancez une instance temporaire dans la même zone de disponibilité que l’instance d’origine. Si votre instance temporaire se trouve dans une zone de disponibilité différente, vous ne pouvez pas y attacher le volume racine de l’instance d’origine.

   1. Sur la page **Review Instance Launch**, sélectionnez **Launch**.

   1. Lorsque vous y êtes invité, créez une nouvelle paire de clés, téléchargez-la dans un emplacement sûr de votre ordinateur, puis choisissez **Lancer des instances**.

1. Attachez le volume à l’instance temporaire en tant que volume secondaire, comme suit :

   1. Dans le panneau de navigation, sélectionnez **Volumes**, choisissez le volume que vous avez détaché de l’instance d’origine, et sélectionnez **Actions**, **Attacher un volume**.

   1. Dans la boîte de dialogue **Attacher un volume**, pour **Instances**, commencez par saisir le nom ou l’ID de votre instance temporaire, puis sélectionnez-la dans la liste.

   1. Pour **Appareil**, saisissez **xvdf** (s’il n’est pas déjà présent), puis choisissez**Attacher**.

## Étape 3 : Réinitialiser le mot de passe administrateur
<a name="resetting-password-ec2launch-step3"></a>

Connectez-vous ensuite à l'instance temporaire et utilisez EC2 Launch pour réinitialiser le mot de passe administrateur.

**Pour réinitialiser le mot de passe administrateur**

1. Connectez-vous à l'instance temporaire et utilisez l'outil EC2 Rescue for Windows Server sur l'instance pour réinitialiser le mot de passe administrateur comme suit :

   1. Téléchargez le fichier zip [EC2Rescue for Windows Server](https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip), extrayez le contenu et exécutez **EC2Rescue.exe**.

   1. Sur l’écran **License Agreement (Contrat de licence)**, lisez le contrat de licence et, si vous acceptez les conditions, choisissez **I agree (J’accepte)**.

   1. Sur l'écran **Welcome to EC2 Rescue for Windows Server**, choisissez **Next**.

   1. Sur l’écran **Select mode**, choisissez **Offline instance**.

   1. Sur l’écran **Select a disk**, sélectionnez le périphérique **xvdf** et choisissez **Next**.

   1. Confirmez la sélection de disque et choisissez **Yes (Oui)**.

   1. Une fois le volume chargé, choisissez **OK**.

   1. Sur l’écran **Select Offline Instance Option**, choisissez **Diagnose and Rescue**.

   1. Sur l’écran **Summary**, vérifiez les informations, puis choisissez **Next**.

   1. Sur l’écran **Detected possible issues**, sélectionnez **Reset Administrator Password** et choisissez **Next**.

   1. Sur l’écran **Confirm**, choisissez **Rescue**, **OK**.

   1. Sur l’écran **Done**, choisissez **Finish**.

   1. Fermez l’outil EC2Rescue for Windows Server, déconnectez-vous de l’instance temporaire, puis revenez à la console Amazon EC2.

1. Détachez le volume (`xvdf`) secondaire de l’instance temporaire comme suit :

   1. Dans le panneau de navigation, sélectionnez **Instances** et choisissez l’instance temporaire.

   1. Notez l’ID du volume EBS répertorié comme **xvdf** disponible sous l’onglet **Stockage** de l’instance temporaire.

   1. Dans le panneau de navigation, choisissez **Volumes**.

   1. Dans la liste des volumes, sélectionnez le volume noté à l’étape précédente, puis choisissez **Actions** et **Détacher un volume**. Une fois le statut du volume passé à **disponible**, passez à l’étape suivante.

## Étape 4 : Redémarrer l’instance originale
<a name="resetting-password-ec2launch-step4"></a>

Après avoir réinitialisé le mot de passe administrateur à l'aide de EC2 Launch, rattachez le volume à l'instance d'origine en tant que volume racine et connectez-vous à l'instance à l'aide de sa paire de clés pour récupérer le mot de passe administrateur.

**Pour redémarrer l’instance originale**

1. Rattachez le volume à l’instance originale comme suit :

   1. Dans le panneau de navigation, choisissez **Volumes**, sélectionnez le volume que vous avez détaché de l’instance temporaire, et sélectionnez **Actions**, **Attacher un volume**.

   1. Dans la boîte de dialogue **Attacher un volume**, pour **Instances**, saisissez le nom ou l’ID de votre instance d’origine, puis sélectionnez l’instance.

   1. Pour **Appareil**, saisissez **/dev/sda1**.

   1. Choisissez **Attacher**. Une fois le statut du volume passé à `in-use`, passez à l’étape suivante.

1. Dans le panneau de navigation, choisissez **Instances**. Sélectionnez l’instance d’origine et choisissez **État de l’instance**, **Démarrer l’instance**. Après que l’état de l’instance est passé à `Running`, passez à l’étape suivante.

1. Récupérez votre nouveau mot de passe administrateur Windows à l’aide de la clé privée de la nouvelle paire de clés et connectez-vous à l’instance. Pour de plus amples informations, veuillez consulter [Se connecter à votre instance Windows à l’aide de RDP](connecting_to_windows_instance.md).

1. (Facultatif) Vous pouvez résilier l’instance temporaire si vous n’en avez plus besoin. Sélectionnez l’instance temporaire, puis choisissez **État de l’instance** et **Résilier l’instance**.

# Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Config
<a name="ResettingAdminPassword_EC2Config"></a>

Si vous avez perdu votre mot de passe administrateur Windows et que vous utilisez une AMI Windows avant Windows Server 2016, vous pouvez utiliser l'agent EC2 Config pour générer un nouveau mot de passe.

Si vous utilisez une AMI Windows Server 2016 ou version ultérieure, consultez [Réinitialisez le mot de passe administrateur Windows pour l'instance EC2 à l'aide EC2 de Launch](ResettingAdminPassword_EC2Launch.md) ou utilisez l'[outil EC2 Rescue](Windows-Server-EC2Rescue.md), qui utilise le service EC2 Launch pour générer un nouveau mot de passe.

**Note**  
Si vous avez désactivé le compte d'administrateur local sur l'instance et que celle-ci est configurée pour Systems Manager, vous pouvez également réactiver et réinitialiser votre mot de passe d'administrateur local à l'aide de la commande EC2 Rescue and Run. Pour plus d'informations, consultez la section [Utiliser EC2 Rescue for Windows Server avec la commande d'exécution de Systems Manager](ec2rw-ssm.md).

**Note**  
Il existe un document AWS Systems Manager d'automatisation qui applique automatiquement les étapes manuelles nécessaires pour réinitialiser le mot de passe de l'administrateur local. Pour plus d’informations, consultez la section [Réinitialiser les mots de passe et les clés SSH sur les instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-ec2reset.html) dans le *Guide de l’utilisateur AWS Systems Manager *.

Pour réinitialiser votre mot de passe administrateur Windows à l'aide de EC2 Config, vous devez effectuer les opérations suivantes :
+ [Étape 1 : vérifier que le service EC2 Config est en cours d'exécution](#resetting-password-ec2config-step1)
+ [Étape 2 : Détacher le volume racine de l’instance](#resetting-password-ec2config-step2)
+ [Étape 3 : Attacher le volume à une instance temporaire](#resetting-password-ec2config-step3)
+ [Étape 4 : Modifier le fichier de configuration](#resetting-password-ec2config-step4)
+ [Étape 5 : Redémarrer l’instance originale](#resetting-password-ec2config-step5)

## Étape 1 : vérifier que le service EC2 Config est en cours d'exécution
<a name="resetting-password-ec2config-step1"></a>

Avant de tenter de réinitialiser le mot de passe administrateur, vérifiez que le service EC2 Config est installé et en cours d'exécution. Vous utiliserez le service EC2 Config pour réinitialiser le mot de passe administrateur plus loin dans cette section.

**Pour vérifier que le service EC2 Config est en cours d'exécution**

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 sélectionnez l’instance dont le mot de passe doit être réinitialisé. Cette instance s’appelle l’instance *originale* dans cette procédure.

1. Sélectionnez **Actions**, **Surveiller et dépanner**, **Obtenir le journal système**.

1. Recherchez l’entrée Agent EC2, par exemple, **EC2 Agent: Ec2Config service v3.18.1118**. Si vous voyez cette entrée, le service EC2 Config est en cours d'exécution.

   Si le résultat du journal système est vide ou si le service EC2 Config n'est pas en cours d'exécution, dépannez l'instance à l'aide du service Instance Console Screenshot. Pour de plus amples informations, veuillez consulter [Création d’une capture d’écran d’une instance inaccessible](troubleshoot-unreachable-instance.md#instance-console-screenshot).

## Étape 2 : Détacher le volume racine de l’instance
<a name="resetting-password-ec2config-step2"></a>

Vous ne pouvez pas utiliser EC2 Config pour réinitialiser un mot de passe administrateur si le volume sur lequel le mot de passe est stocké est attaché à une instance en tant que volume racine. Vous devez détacher le volume de l’instance originale avant de pouvoir l’attacher à une instance temporaire en tant que volume secondaire.

**Détacher le volume racine 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 qui nécessite une réinitialisation du mot de passe et choisissez **État de l’instance**, **Arrêter l’instance**. Une fois que le statut de l’instance est passé à **Arrêtée**, passez à l’étape suivante.

1. (Facultatif) Si vous disposez de la clé privée que vous avez spécifiée lors du lancement de cette instance, passez à l’étape suivante. Sinon, procédez comme suit pour remplacer l’instance par une nouvelle instance que vous lancez par une nouvelle paire de clés.

   1. Créez une nouvelle paire de clés à l’aide de la console Amazon EC2. Si vous souhaitez nommer votre nouvelle paire de clés exactement comme la clé privée perdue, vous devez commencer par supprimer la paire de clés existante.

   1. Sélectionnez l’instance à remplacer. Notez le type d’instance, le VPC, le sous-réseau, le groupe de sécurité et le rôle IAM de l’instance.

   1. Une fois l’instance sélectionnée, choisissez **Actions**, **Image et modèles**, **Créer l’image**. Saisissez le nom et la description de l’image, puis choisissez **Créer l’image**.

   1. Dans le panneau de navigation, sélectionnez **AMIs**. Attendez que l’état de l’image devienne **disponible**. Ensuite, sélectionnez l’image et choisissez **Lancer l’instance à partir de l’AMI**.

   1. Remplissez les champs pour lancer une instance, en vous assurant de sélectionner le même type d’instance, le même VPC, le même sous-réseau, le même groupe de sécurité et le même rôle IAM que l’instance à remplacer, puis choisissez **Lancer l’instance**.

   1. Lorsque vous y êtes invité, choisissez la paire de clés que vous avez créée pour la nouvelle instance, puis cliquez sur **Lancer l’instance**.

   1. (Facultatif) Si l’instance d’origine a une adresse IP Elastic associée, associez-la à la nouvelle instance. Si l’instance d’origine comporte des volumes EBS en plus du volume racine, transférez-les vers la nouvelle instance.

1. Détachez le volume racine de l’instance d’origine comme suit :

   1. Sélectionnez l’instance d’origine et cliquez sur l’onglet **Stockage**. Notez le nom du périphérique racine sous **Nom du périphérique racine**. Recherchez le volume portant ce nom de périphérique dans la section **Périphérique de stockage en mode bloc** et notez l’ID du volume.

   1. Dans le panneau de navigation, choisissez **Volumes**.

   1. Dans la liste des volumes, sélectionnez le volume que vous avez noté comme périphérique racine, puis choisissez **Actions**, **Détacher un volume**. Une fois le statut du volume passé à **disponible**, passez à l’étape suivante.

1. Si vous avez créé une nouvelle instance pour remplacer votre instance d’origine, vous pouvez mettre fin à l’instance d’origine maintenant. Elle n’est plus nécessaire. Dans la suite de cette procédure, toutes les références à l’instance d’origine s’appliquent à la nouvelle instance que vous avez créée.

## Étape 3 : Attacher le volume à une instance temporaire
<a name="resetting-password-ec2config-step3"></a>

Ensuite, lancez une instance temporaire et attachez-lui le volume en tant que volume secondaire. Il s’agit de l’instance que vous utilisez pour modifier le fichier de configuration.

**Pour lancer une instance temporaire et attacher le volume**

1. Lancez l’instance temporaire comme suit :

   1. Dans le panneau de navigation, choisissez **Instances**, puis choisissez **Lancer une instance**, puis sélectionnez une AMI.
**Important**  
Pour éviter les collisions de signature de disque, vous devez sélectionner une AMI pour une autre version de Windows. Par exemple, si l’instance d’origine exécute Windows Server 2019, lancez l’instance temporaire à l’aide de l’AMI d’origine pour Windows Server 2016.

   1. Quittez le type d’instance par défaut, puis choisissez **Suivant : configurer les détails de l’instance**.

   1. Dans la page **Configurer les détails d’instance**, pour **Sous-réseau**, sélectionnez la même zone de disponibilité que l’instance d’origine et choisissez **Revoir et lancer**.
**Important**  
Lancez une instance temporaire dans la même zone de disponibilité que l’instance d’origine. Si votre instance temporaire se trouve dans une zone de disponibilité différente, vous ne pouvez pas y attacher le volume racine de l’instance d’origine.

   1. Sur la page **Review Instance Launch**, sélectionnez **Launch**.

   1. Lorsque vous y êtes invité, créez une nouvelle paire de clés, téléchargez-la dans un emplacement sûr de votre ordinateur, puis choisissez **Lancer des instances**.

1. Attachez le volume à l’instance temporaire en tant que volume secondaire, comme suit :

   1. Dans le panneau de navigation, sélectionnez **Volumes**, choisissez le volume que vous avez détaché de l’instance d’origine, et sélectionnez **Actions**, **Attacher un volume**.

   1. Dans la boîte de dialogue **Attacher un volume**, pour **Instances**, commencez par saisir le nom ou l’ID de votre instance temporaire, puis sélectionnez-la dans la liste.

   1. Pour **Appareil**, saisissez **xvdf** (s’il n’est pas déjà présent), puis choisissez**Attacher**.

## Étape 4 : Modifier le fichier de configuration
<a name="resetting-password-ec2config-step4"></a>

Après avoir attaché le volume à une instance temporaire en tant que volume secondaire, modifiez le plug-in `Ec2SetPassword` dans le fichier de configuration.

**Pour modifier le fichier de configuration**

1. Dans l’instance temporaire, modifiez le fichier de configuration sur le volume secondaire comme suit :

   1. Lancez et connectez-vous à l’instance temporaire.

   1. Suivez les instructions ci-dessous pour mettre le lecteur en ligne : [Mettez un volume Amazon EBS à disposition](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html).

   1. Accédez au volume secondaire et ouvrez `\Program Files\Amazon\Ec2ConfigService\Settings\config.xml` à l’aide d’un éditeur de texte comme le Bloc-notes.

   1. En haut du fichier, recherchez le plug-in portant le nom `Ec2SetPassword`, comme illustré dans la capture d’écran. Remplacez la valeur `Disabled` de l’état par `Enabled` et enregistrez le fichier.  
![\[Zone du fichier Config.xml à modifier\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/pwreset_config.png)

1. Après avoir modifié le fichier de configuration, détachez le volume secondaire de l’instance temporaire comme suit :

   1. À l’aide de l’utilitaire **Gestion des disques**, déconnectez le volume.

   1. Déconnectez-vous de l’instance temporaire et revenez à la console Amazon EC2.

   1. Dans le panneau de navigation, sélectionnez **Volumes**, choisissez le volume, puis sélectionnez **Actions**, **Détacher un volume**. Une fois le statut du volume passé à **disponible**, passez à l’étape suivante.

## Étape 5 : Redémarrer l’instance originale
<a name="resetting-password-ec2config-step5"></a>

Après avoir modifié le fichier de configuration, rattachez le volume à l’instance originale en tant que volume racine et connectez-vous à l’instance en utilisant sa paire de clés pour récupérer le mot de passe administrateur.

1. Rattachez le volume à l’instance originale comme suit :

   1. Dans le panneau de navigation, choisissez **Volumes**, sélectionnez le volume que vous avez détaché de l’instance temporaire, et sélectionnez **Actions**, **Attacher un volume**.

   1. Dans la boîte de dialogue **Attacher un volume**, pour **Instances**, saisissez le nom ou l’ID de votre instance d’origine, puis sélectionnez l’instance.

   1. Pour **Appareil**, saisissez **/dev/sda1**.

   1. Choisissez **Attacher**. Une fois le statut du volume passé à `in-use`, passez à l’étape suivante.

1. Dans le panneau de navigation, choisissez **Instances**. Sélectionnez l’instance d’origine et choisissez **État de l’instance**, **Démarrer l’instance**. Après que l’état de l’instance est passé à `Running`, passez à l’étape suivante.

1. Récupérez votre nouveau mot de passe administrateur Windows à l’aide de la clé privée de la nouvelle paire de clés et connectez-vous à l’instance. Pour de plus amples informations, veuillez consulter [Se connecter à votre instance Windows à l’aide de RDP](connecting_to_windows_instance.md).
**Important**  
L’instance reçoit une nouvelle adresse IP publique après que vous l’arrêtiez et la redémarriez. Veillez à vous connecter à l’instance à l’aide de son nom DNS public. Pour de plus amples informations, veuillez consulter [Modifications de l'état de l' EC2 instance Amazon](ec2-instance-lifecycle.md).

1. (Facultatif) Vous pouvez résilier l’instance temporaire si vous n’en avez plus besoin. Sélectionnez l’instance temporaire, puis choisissez **État de l’instance** et **Résilier l’instance**.

# Résolution des problèmes de Sysprep avec les instances Windows d'Amazon EC2
<a name="sysprep-troubleshoot"></a>

Si vous rencontrez des problèmes ou que vous recevez des messages d’erreur pendant les préparations d’images, consultez les journaux suivants : L'emplacement du journal varie selon que vous exécutez EC2 Config, EC2 Launch v1 ou EC2 Launch v2 avec Sysprep.
+ `%WINDIR%\Panther\Unattendgc`(EC2Config, EC2 Launch v1 et EC2 Launch v2)
+ `%WINDIR%\System32\Sysprep\Panther`(EC2Config, EC2 Launch v1 et EC2 Launch v2)
+ `C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt`(EC2Config uniquement)
+ `C:\ProgramData\Amazon\Ec2Config\Logs`(EC2Config uniquement)
+ `C:\ProgramData\Amazon\EC2-Windows\Launch\Log\EC2Launch.log`(EC2Lancer la version 1 uniquement)
+ `%ProgramData%\Amazon\EC2Launch\log\agent.log`(EC2Lancer la v2 uniquement)

Si vous recevez un message d’erreur pendant la préparation de l’image avec Sysprep, il se peut que le système d’exploitation ne soit pas disponible. Pour consulter les fichiers journaux, vous devez arrêter l’instance, attacher son volume racine à une autre instance sain sur un volume secondaire, puis consulter les journaux mentionnés précédemment sur le volume secondaire. Pour plus d’informations sur l’objectif des fichiers journaux par nom, veuillez consulter [Windows Setup-Related Log Files](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/deployment-troubleshooting-and-log-files#windows-setup-related-log-files) dans la documentation Microsoft.

Si vous trouvez des erreurs dans le fichier journal Unattendgc, utilisez l’[outil Error Lookup de Microsoft](https://www.microsoft.com/en-us/download/details.aspx?id=100432) pour en savoir plus sur les erreurs. Le problème suivant signalé dans le fichier journal Unattendgc est généralement dû à un ou plusieurs profils utilisateur corrompus sur l’instance :

```
Error [Shell Unattend] _FindLatestProfile failed (0x80070003) [gle=0x00000003]
Error [Shell Unattend] CopyProfile failed (0x80070003) [gle=0x00000003]
```

Vous avez deux options à votre disposition pour le résoudre :

**Option 1**

Utilisez Regedit sur l’instance pour rechercher la clé suivante. Vérifiez qu’il n’existe aucune clé de registre de profil d’utilisateur supprimé.

`[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\`

**Option 2**

1. Modifiez le fichier concerné, comme suit :
   + Windows Server 2012 R2 et versions antérieures : modifiez le fichier de réponses EC2 Config (`C:\Program Files\Amazon\Ec2ConfigService\sysprep2008.xml`).
   + Windows Server 2016 et 2019 – Modifiez le fichier de réponses unattend.xml (`C:\ProgramData\Amazon\EC2-Windows\Launch\Sysprep\Unattend.xml`).
   + Windows Server 2022 – Modifiez le fichier de réponse unattend.xml (`C:\ProgramData\Amazon\EC2Launch\sysprep\unattend.xml`). 

1. Remplacez `<CopyProfile>true</CopyProfile>` par `<CopyProfile>false</CopyProfile>`

1. Exécutez à nouveau Sysprep. Notez que cette modification apportée à la configuration entraîne la suppression du profil utilisateur de l’administrateur intégré une fois Sysprep terminé.

# Résoudre les problèmes d'une instance Linux Amazon EC2 défectueuse à l'aide de Rescue EC2
<a name="Linux-Server-EC2Rescue"></a>

*EC2Rescue pour Linux est un easy-to-use outil open source qui peut être exécuté sur une instance Amazon EC2 Linux pour diagnostiquer, dépanner et résoudre les problèmes courants à l'aide de sa bibliothèque de plus de 100 modules.* Les modules sont des fichiers YAML qui contiennent un script BASH ou Python et les métadonnées nécessaires.

Voici quelques cas d'utilisation généralisés des instances EC2 Rescue for Linux :
+ Collecte des journaux syslog et du gestionnaire de packages
+ Collecte de données sur l’utilisation des ressources
+ Diagnostiquer et remédier aux paramètres problématiques connus du noyau et aux problèmes courants d’OpenSSH

**Note**  
Le runbook `AWSSupport-TroubleshootSSH` AWS Systems Manager Automation installe EC2 Rescue pour Linux, puis utilise l'outil pour vérifier ou tenter de résoudre les problèmes courants qui empêchent une connexion SSH à une instance Linux. Pour de plus amples informations, veuillez consulter [AWSSupport-TroubleshootSSH](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootssh.html).

Si vous utilisez une instance Windows, consultez [Résoudre les problèmes d'une instance Windows Amazon EC2 défectueuse à l'aide de Rescue EC2](Windows-Server-EC2Rescue.md).

**Topics**
+ [Installez EC2 Rescue](ec2rl_install.md)
+ [Exécuter les commandes EC2 Rescue](ec2rl_working.md)
+ [Développer des modules EC2 de sauvetage](ec2rl_moduledev.md)

# Installer EC2Rescue sur une instance Amazon EC2 Linux
<a name="ec2rl_install"></a>

L’outil EC2Rescue pour Linux peut être installé sur une instance Amazon EC2 Linux qui satisfait les prérequis suivants.

**Conditions préalables**
+ Systèmes d’exploitation pris en charge :
  + Amazon Linux 2
  + Amazon Linux 2016.09\$1
  + SUSE Linux Enterprise Server 12\$1
  + RHEL 7\$1
  + Ubuntu 16.04\$1
+ Configuration logicielle requise :
  + Python 2.7.9\$1 ou 3.2\$1

## Installez EC2 Rescue
<a name="ec2rl-install"></a>

Le `AWSSupport-TroubleshootSSH` runbook installe EC2 Rescue pour Linux, puis utilise l'outil pour vérifier ou tenter de résoudre les problèmes courants qui empêchent une connexion à distance à une machine Linux via SSH. Pour plus d’informations et pour exécuter cette automatisation, consultez [Support-TroubleshootSSH](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootssh.html).

Si votre système dispose de la version Python requise, vous pouvez installer la build standard. Dans le cas contraire, vous pouvez installer la build de la solution groupée, qui inclut une copie minimale de Python.

**Pour installer la build standard**

1. À partir d'une instance Linux fonctionnelle, téléchargez l'outil [EC2Rescue for Linux](https://s3.amazonaws.com/ec2rescuelinux/ec2rl.tgz) :

   ```
   curl -O https://s3.amazonaws.com/ec2rescuelinux/ec2rl.tgz
   ```

1. (*Facultatif*) Vérifiez la signature du fichier d'installation de EC2 Rescue for Linux. Pour de plus amples informations, veuillez consulter [(Facultatif) Vérifiez la signature de EC2 Rescue for Linux](#ec2rl_verify).

1. Téléchargez le fichier de hachage sha256 :

   ```
   curl -O https://s3.amazonaws.com/ec2rescuelinux/ec2rl.tgz.sha256
   ```

1. Vérifiez l’intégrité du tarball :

   ```
   sha256sum -c ec2rl.tgz.sha256
   ```

1. Déballez le tarball :

   ```
   tar -xzvf ec2rl.tgz
   ```

1. Vérifiez l’installation en énumérant le fichier d’aide :

   ```
   cd ec2rl-<version_number>
   ./ec2rl help
   ```

**Pour installer la build de la solution groupée**  
Pour un lien vers le téléchargement et une liste des limitations, consultez [EC2Rescue for Linux](https://github.com/awslabs/aws-ec2rescue-linux/blob/master/README.md) sur github.

## (Facultatif) Vérifiez la signature de EC2 Rescue for Linux
<a name="ec2rl_verify"></a>

Voici le processus recommandé pour vérifier la validité du package EC2 Rescue for Linux pour les systèmes d'exploitation basés sur Linux.

Lorsque vous téléchargez une application à partir d’Internet, nous vous recommandons d’authentifier l’identité de l’éditeur du logiciel et de vérifier que l’application n’a pas été modifiée ou corrompue depuis sa publication. Cela vous évitera d’installer une version de l’application contenant un virus ou tout autre code malveillant.

Si, après avoir exécuté les étapes décrites dans cette rubrique, vous constatez que le logiciel de EC2 Rescue for Linux est altéré ou endommagé, n'exécutez pas le fichier d'installation. Contactez plutôt Amazon Web Services.

EC2Les fichiers Rescue for Linux pour les systèmes d'exploitation basés sur Linux sont signés à l'aide de GnuPG, une implémentation open source de la norme Pretty Good Privacy (OpenPGP) pour les signatures numériques sécurisées. GnuPG (également connu sous le nom de GPG) fournit une authentification et un contrôle d'intégrité par le biais d'une signature numérique. AWS publie une clé publique et des signatures que vous pouvez utiliser pour vérifier le package EC2 Rescue for Linux téléchargé. [Pour plus d'informations sur PGP et GnuPG (GPG), consultez https://www.gnupg.org/.](https://www.gnupg.org/)

La première étape consiste à établir une approbation avec l’éditeur du logiciel. Téléchargez la clé publique de l’éditeur du logiciel, vérifiez que le propriétaire de cette clé publique est bien celui qu’il prétend être, puis ajoutez la clé publique à votre porte-clés. Votre porte-clés est un ensemble de clés publiques connues. Après avoir établi l’authenticité de la clé publique, vous pouvez l’utiliser pour vérifier la signature de l’application.

**Topics**
+ [Authentification et importation de la clé publique](#ec2rl_authenticate)
+ [Vérification de la signature du package](#ec2rl_verify_signature)

### Authentification et importation de la clé publique
<a name="ec2rl_authenticate"></a>

L'étape suivante du processus consiste à authentifier la clé publique EC2 Rescue for Linux et à l'ajouter en tant que clé fiable dans votre trousseau de clés GPG.

**Pour authentifier et importer la clé publique EC2 Rescue for Linux**

1. À l’invite de commande, utilisez la commande suivante pour obtenir une copie de votre clé publique GPG :

   ```
   curl -O https://s3.amazonaws.com/ec2rescuelinux/ec2rl.key
   ```

1. À l'invite de commande dans le répertoire où vous avez enregistré`ec2rl.key`, utilisez la commande suivante pour importer la clé publique EC2 Rescue for Linux dans votre jeu de clés :

   ```
   gpg2 --import ec2rl.key
   ```

   La commande renvoie un résultat semblable à ce qui suit :

   ```
   gpg: /home/ec2-user/.gnupg/trustdb.gpg: trustdb created
   gpg: key 2FAE2A1C: public key "ec2autodiag@amazon.com <EC2 Rescue for Linux>" imported
   gpg: Total number processed: 1
   gpg:               imported: 1  (RSA: 1)
   ```
**Astuce**  
Si vous voyez une erreur indiquant que la commande est introuvable, installez l’utilitaire GnuPG avec `apt-get install gnupg2` (Linux basé sur Debian) ou `yum install gnupg2` (Linux basé sur Red Hat).

### Vérification de la signature du package
<a name="ec2rl_verify_signature"></a>

Après avoir installé les outils GPG, authentifié et importé la clé publique EC2 Rescue for Linux, et vérifié que la clé publique EC2 Rescue for Linux est fiable, vous êtes prêt à vérifier la signature du script d'installation de EC2 Rescue for Linux.

**Pour vérifier la signature du script d'installation de EC2 Rescue for Linux**

1. À l’invite de commande, exécutez la commande suivante pour télécharger le fichier signature du script d’installation :

   ```
   curl -O https://s3.amazonaws.com/ec2rescuelinux/ec2rl.tgz.sig
   ```

1. Vérifiez la signature en exécutant la commande suivante à l'invite de commande dans le répertoire où vous l'avez enregistrée `ec2rl.tgz.sig` et dans le fichier d'installation de EC2 Rescue for Linux. Ces deux fichiers doivent être présents.

   ```
   gpg2 --verify ./ec2rl.tgz.sig
   ```

   Le résultat doit ressembler à ce qui suit :

   ```
   gpg: Signature made Thu 12 Jul 2018 01:57:51 AM UTC using RSA key ID 6991ED45
   gpg: Good signature from "ec2autodiag@amazon.com <EC2 Rescue for Linux>"
   gpg: WARNING: This key is not certified with a trusted signature!
   gpg:          There is no indication that the signature belongs to the owner.
   Primary key fingerprint: E528 BCC9 0DBF 5AFA 0F6C  C36A F780 4843 2FAE 2A1C
        Subkey fingerprint: 966B 0D27 85E9 AEEC 1146  7A9D 8851 1153 6991 ED45
   ```

   Si la sortie contient cette phrase`Good signature from "ec2autodiag@amazon.com <EC2 Rescue for Linux>"`, cela signifie que la signature a été vérifiée avec succès et que vous pouvez exécuter le script d'installation de EC2 Rescue for Linux.

   Si le résultat inclut l’expression `BAD signature`, vérifiez si vous avez effectué la procédure correctement. Si vous continuez à obtenir cette réponse, contactez Amazon Web Services et n’exécutez pas le fichier d’installation que vous avez précédemment téléchargé.

Voici les informations détaillées sur les avertissements qui peuvent s’afficher :
+ **WARNING: This key is not certified with a trusted signature\$1 There is no indication that the signature belongs to the owner.**Cela fait référence à votre niveau de confiance personnel dans votre conviction que vous possédez une clé publique authentique pour EC2 Rescue for Linux. Dans un monde idéal, vous visiteriez un bureau Amazon Web Services et recevriez la clé en personne. Cependant, vous la téléchargez le plus souvent à partir d’un site Web. Dans le cas présent, le site Web est un site Amazon Web Services.
+ **gpg2: no ultimately trusted keys found.** Cela signifie que la clé spécifique n’est pas « approuvée en dernier lieu » par vous-même (ou par d’autres personnes de confiance).

Pour plus d'informations, consultez [https://www.gnupg.org/](https://www.gnupg.org/).

# Exécuter les commandes EC2Rescue sur une instance Amazon EC2 Linux
<a name="ec2rl_working"></a>

EC2Rescue est un outil en ligne de commande. Après avoir installé EC2 Rescue sur votre instance Linux, vous pouvez obtenir de l'aide générale sur l'utilisation de l'outil en exécutant`./ec2rl help`. Vous pouvez consulter les modules disponibles en exécutant`./ec2rl list`, et vous pouvez obtenir de l’aide sur un module spécifique en exécutant `./ec2rl help module_name`.

Les tâches suivantes sont des tâches courantes que vous pouvez effectuer pour commencer à utiliser cet outil.

**Topics**
+ [Exécuter les modules EC2 Rescue](#ec2rl_running_module)
+ [Téléchargez les résultats du module EC2 Rescue](#ec2rl_uploading_results)
+ [Créer des sauvegardes d’une instance Linux Amazon EC2](#ec2rl_creating_backups)

## Exécuter les modules EC2 Rescue
<a name="ec2rl_running_module"></a>

**Pour exécuter tous les modules EC2 Rescue**  
Utilisez la commande **./ec2rl run** sans indiquer de paramètres supplémentaires. Certains modules nécessitent un accès racine. Si vous n’êtes pas un utilisateur racine, utilisez **sudo** lorsque vous exécutez la commande.

```
./ec2rl run
```

**Pour exécuter un module EC2 Rescue spécifique**  
Utilisez la commande **./ec2rl run** et pour `--only-modules`, indiquez le nom du module à exécuter. Certains modules nécessitent des *arguments* pour être utilisés.

```
./ec2rl run --only-modules=module_name --arguments
```

Par exemple, pour exécuter le module **dig** afin d’interroger le domaine `amazon.com`, utilisez la commande suivante.

```
./ec2rl run --only-modules=dig --domain=amazon.com
```

**Pour consulter les résultats d'un module EC2 Rescue**  
Exécutez le module et consultez le fichier journal dans `cat /var/tmp/ec2rl/logfile_location`. Par exemple, le fichier journal du module **dig** se trouve à l’emplacement suivant :

```
cat /var/tmp/ec2rl/timestamp/mod_out/run/dig.log
```

## Téléchargez les résultats du module EC2 Rescue
<a name="ec2rl_uploading_results"></a>

Si vous avez Support demandé les résultats d'un module EC2 Rescue, vous pouvez télécharger le fichier journal à l'aide de l'outil EC2 Rescue. Vous pouvez télécharger les résultats soit vers un emplacement fourni par, Support soit vers un compartiment Amazon S3 dont vous êtes le propriétaire.

**Pour télécharger les résultats vers un emplacement fourni par Support**  
Utilisez la commande **./ec2rl upload**. Pour`--upload-directory`, indiquez l’emplacement du fichier journal. Pour`--support-url`, indiquez l’URL fournie par Support.

```
./ec2rl upload --upload-directory=/var/tmp/ec2rl/logfile_location --support-url="url_provided_by_aws_support"
```

**Pour télécharger les résultats vers un compartiment Amazon S3**  
Utilisez la commande **./ec2rl upload**. Pour`--upload-directory`, indiquez l’emplacement du fichier journal. Pour`--presigned-url`, indiquez une URL pré-signée pour le compartiment S3. Pour plus d'informations sur la génération de documents pré-signés URLs pour Amazon S3, consultez [Uploading objects using](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html) Pre-Signed. URLs

```
./ec2rl upload --upload-directory=/var/tmp/ec2rl/logfile_location --presigned-url="presigned_s3_url"
```

## Créer des sauvegardes d’une instance Linux Amazon EC2
<a name="ec2rl_creating_backups"></a>

Vous pouvez utiliser EC2 Rescue pour sauvegarder votre instance Linux en créant une AMI ou en créant des instantanés de ses volumes attachés.

**Pour créer une AMI**  
Utilisez la commande `./ec2rl run` et pour : `backup`, indiquez `ami`.

```
./ec2rl run --backup=ami
```

**Pour créer des instantanés multi-volumes de tous les volumes associés**  
Utilisez la commande `./ec2rl run` et pour : `backup`, indiquez `allvolumes`.

```
./ec2rl run --backup=allvolumes
```

**Pour créer un instantané d’un volume associé spécifique**  
Utilisez la commande `./ec2rl run` et pour : `backup`, indiquez l’ID du volume à sauvegarder.

```
./ec2rl run --backup=vol-01234567890abcdef
```

# Développer des modules EC2Rescue pour les instances Linux Amazon EC2
<a name="ec2rl_moduledev"></a>

Les modules sont écrits en YAML, une norme de sérialisation des données. Le fichier YAML d’un module se compose d’un document unique, qui représente le module et ses attributs.

## Ajouter des attributs de module
<a name="ec2rl-adding-modules"></a>

Le tableau suivant répertorie les attributs de module disponibles.


| Attribut | Description | 
| --- | --- | 
| name | Nom du module. La longueur du nom doit être inférieure ou égale à 18 caractères. | 
| Version | Numéro de version du module. | 
| title | Titre court et descriptif du module. La longueur de cette valeur doit être inférieure ou égale à 50 caractères. | 
| helptext |  Description étendue du module. La longueur de chaque ligne doit être inférieure ou égale à 75 caractères. Si le module consomme des arguments, obligatoires ou facultatifs, incluez-les dans la valeur helptext. Exemples : <pre>helptext: !!str |<br />  Collect output from ps for system analysis<br />  Consumes --times= for number of times to repeat<br />  Consumes --period= for time period between repetition</pre> | 
| placement | Étape dans laquelle le module doit être exécuté. Valeurs prises en charge : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html)  | 
| langage | Langage dans lequel le code du module est écrit. Valeurs prises en charge : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html)  Le code Python doit être compatible avec Python 2.7.9\$1 et Python 3.2\$1.   | 
| remediation |  Indique si le module prend en charge la correction. Les valeurs prises en charge sont `True` ou `False`. Le module utilise par défaut `False` si aucune valeur n’est indiquée. Il s’agit donc d’un attribut facultatif pour les modules qui ne prennent pas en charge la correction.  | 
| content | Intégralité du code de script. | 
| contrainte | Nom de l’objet contenant les valeurs de contrainte. | 
| domaine | Descripteur de la façon dont le module est regroupé ou classé. L’ensemble de modules inclus utilise les domaines suivants :  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html) | 
| class | Descripteur du type de tâche effectué par le module. L’ensemble de modules inclus utilise les classes suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html) | 
| distro | Liste des distributions Linux que ce module prend en charge. L’ensemble de modules inclus utilise les distributions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html) | 
| obligatoire | Arguments obligatoires que le module consomme à partir des options de la CLI. | 
| facultatif | Arguments facultatifs que le module peut utiliser. | 
| logiciel | Exécutables logiciels utilisés dans le module. Cet attribut a pour but de spécifier un logiciel qui n’est pas installé par défaut. La logique EC2 Rescue for Linux garantit que ces programmes sont présents et exécutables avant d'exécuter le module. | 
| package | Package logiciel source pour un exécutable. Cet attribut a pour but de fournir des détails étendus sur le package avec le logiciel, y compris une URL pour le téléchargement ou pour obtenir de plus amples informations. | 
| sudo | Indique si l’accès racine est obligatoire pour exécuter le module.  Vous n’avez pas besoin d’implémenter des vérifications sudo dans le script du module. Si la valeur est vraie, la logique EC2 Rescue for Linux n'exécute le module que lorsque l'utilisateur exécutant dispose d'un accès root. | 
| perfimpact | Indique si le module peut avoir un impact important sur les performances qui affecte l’environnement dans lequel il est exécuté. Si la valeur est true et que l’argument `--perfimpact=true` n’est pas présent, le module est ignoré. | 
| parallelexclusive | Spécifie un programme qui requiert une exclusivité mutuelle. Par exemple, tous les modules qui spécifient « bpf » sont exécutés en série. | 

## Ajouter des variables d’environnement
<a name="ec2rl_adding_envvars"></a>

Le tableau suivant répertorie les variables d’environnement disponibles.


| Variable d’environnement | Description | 
| --- | --- | 
|  `EC2RL_CALLPATH`  | Chemin vers ec2rl.py. Ce chemin peut être utilisé pour localiser le répertoire lib et utiliser les modules Python fournis. | 
|  `EC2RL_WORKDIR`  |  Répertoire tmp principal pour l’outil de diagnostic. Valeur par défaut: `/var/tmp/ec2rl`. | 
|  `EC2RL_RUNDIR`  |  Répertoire dans lequel toutes les sorties sont stockées. Valeur par défaut: `/var/tmp/ec2rl/<date&timestamp>`.  | 
|  `EC2RL_GATHEREDDIR`  |  Répertoire racine dans lequel placer les données collectées sur le module. Valeur par défaut:`/var/tmp/ec2rl/<date&timestamp>/mod_out/gathered/`.  | 
|  `EC2RL_NET_DRIVER`  |  Pilote utilisé pour la première interface réseau non virtuelle, triée par ordre alphabétique, de l’instance. Exemples : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html)  | 
|  `EC2RL_SUDO`  |  True si EC2 Rescue for Linux est exécuté en tant que root ; sinon, faux.  | 
|  `EC2RL_VIRT_TYPE`  |  Type de virtualisation, tel que fourni par les métadonnées d’instance. Exemples : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rl_moduledev.html)  | 
|  `EC2RL_INTERFACES`  |  Liste énumérée des interfaces du système. La valeur est une chaîne contenant des noms, tels que `eth0`, `eth1`, etc. Elle est générée via `functions.bash` et est disponible uniquement pour les modules dont elle provient.  | 

## Utiliser la syntaxe YAML
<a name="ec2rl_yamlsyntax"></a>

Tenez compte des points suivants lorsque vous créez vos fichiers YAML de module :
+ Le triple trait d’union (`---`) indique le début explicite d’un document.
+ La balise `!ec2rlcore.module.Module` indique à l’analyseur YAML le constructeur à appeler lors de la création de l’objet à partir du flux de données. Vous trouverez le constructeur dans le fichier `module.py`.
+ La balise `!!str` indique à l’analyseur YAML de ne pas tenter de déterminer le type des données, et d’interpréter plutôt le contenu comme un littéral de chaîne.
+ Le caractère pipe (`|`) indique à l’analyseur YAML que la valeur est une scalaire littérale. Dans ce cas, l’analyseur inclut tous les espaces. C’est important pour les modules car les caractères de mise en retrait et de saut de ligne sont conservés.
+ La mise en retrait standard YAML correspond à deux espaces, comme illustré dans les deux exemples suivants. Veillez à conserver la mise en retrait standard (par exemple, quatre espaces pour Python) pour votre script, puis mettez en retrait l’intégralité du contenu à l’aide de deux espaces dans le fichier du module.

## Exemples de modules
<a name="ec2rl_example"></a>

Example un (`mod.d/ps.yaml`):

```
--- !ec2rlcore.module.Module
# Module document. Translates directly into an almost-complete Module object
name: !!str ps
path: !!str
version: !!str 1.0
title: !!str Collect output from ps for system analysis
helptext: !!str |
  Collect output from ps for system analysis
  Requires --times= for number of times to repeat
  Requires --period= for time period between repetition
placement: !!str run
package: 
  - !!str
language: !!str bash
content: !!str |
  #!/bin/bash
  error_trap()
  {
      printf "%0.s=" {1..80}
      echo -e "\nERROR:	"$BASH_COMMAND" exited with an error on line ${BASH_LINENO[0]}"
      exit 0
  }
  trap error_trap ERR

  # read-in shared function
  source functions.bash
  echo "I will collect ps output from this $EC2RL_DISTRO box for $times times every $period seconds."
  for i in $(seq 1 $times); do
      ps auxww
      sleep $period
  done
constraint:
  requires_ec2: !!str False
  domain: !!str performance
  class: !!str collect
  distro: !!str alami ubuntu rhel suse
  required: !!str period times
  optional: !!str
  software: !!str
  sudo: !!str False
  perfimpact: !!str False
  parallelexclusive: !!str
```

# Résoudre les problèmes d'une instance Windows Amazon EC2 défectueuse à l'aide de Rescue EC2
<a name="Windows-Server-EC2Rescue"></a>

EC2Rescue for Windows Server est un easy-to-use outil que vous exécutez sur une instance Amazon EC2 Windows Server pour diagnostiquer et résoudre d'éventuels problèmes. Il est utile non seulement pour collecter les fichiers journaux et résoudre les problèmes, mais aussi pour rechercher de manière proactive les éventuels sujets de préoccupation. Il permet même d’examiner les volumes racine Amazon EBS pour d’autres instances et de collecter les journaux correspondants à des fins de dépannage des instances Windows Server à l’aide de ce volume. Voici quelques problèmes courants que EC2 Rescue peut résoudre :
+ Problèmes liés à la connectivité de l’instance en raison d’un pare-feu, du protocole de bureau à distance (RDP) ou de la configuration de l’interface réseau
+ Problèmes liés au démarrage du système d’exploitation en raison d’une erreur d’arrêt, d’une boucle de démarrage ou d’un registre corrompu
+ Problèmes pouvant nécessiter une analyse avancée des journaux et une résolution des problèmes

EC2Rescue pour Windows Server comporte deux modules différents :
+ Un **module de collecte de données** qui recueille des données provenant de différentes sources
+ Un **module d’analyse** qui analyse les données collectées en fonction d’une série de règles prédéfinies afin d’identifier les problèmes et de fournir des suggestions

L’outil EC2Rescue pour Windows Server fonctionne uniquement sur les instances Amazon EC2 exécutant Windows Server 2012 et les versions ultérieures. Lorsque l’outil démarre, il vérifie s’il s’exécute sur une instance Amazon EC2.

**Note**  
Le runbook `AWSSupport-ExecuteEC2Rescue` AWS Systems Manager Automation utilise l'outil EC2Rescue pour dépanner et, dans la mesure du possible, résoudre les problèmes de connectivité courants avec l'instance EC2 spécifiée. Pour plus d'informations et pour exécuter cette automatisation, voir [> AWSSupport-ExecuteEC 2Rescue](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-executeec2rescue.html).

Si vous utilisez une instance Linux, consultez [Résoudre les problèmes d'une instance Linux Amazon EC2 défectueuse à l'aide de Rescue EC2](Linux-Server-EC2Rescue.md).

**Topics**
+ [Résoudre les problèmes à l'aide de l' EC2interface utilisateur](ec2rw-gui.md)
+ [Résolution des problèmes à l'aide de la EC2 Rescue CLI](ec2rw-cli.md)
+ [Résolution des problèmes à l'aide EC2 de Rescue and Systems Manager](ec2rw-ssm.md)

# Résoudre les problèmes d'une instance Windows défectueuse à l'aide de l'interface graphique EC2 Rescue
<a name="ec2rw-gui"></a>

EC2Rescue for Windows Server peut effectuer l'analyse suivante sur des **instances hors ligne** :


| Option | Description | 
| --- | --- | 
| Diagnostic et résolution des problèmes | EC2Rescue for Windows Server peut détecter et résoudre les problèmes liés aux paramètres de service suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) | 
| Restaurer | Effectuez l’une des opérations suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-gui.html) | 
| Capture Logs | Permet de capturer des journaux sur l’instance en vue de les analyser. | 

EC2Rescue for Windows Server peut collecter les données suivantes à partir d'**instances actives et hors ligne** :


| Élément | Description | 
| --- | --- | 
| Event Log | Collecte les journaux des événements de l'application, du système et de la EC2 configuration. | 
| Registre | Collecte les ruches SYSTEM et SOFTWARE. | 
| Windows Update Log | Permet de collecter les fichiers journaux générés par Windows Update. Dans Windows Server 2016 et les versions ultérieures, le journal est collecté au format Event Tracing for Windows (ETW). | 
| Sysprep Log | Permet de collecter les fichiers journaux générés par l’outil Windows System Preparation. | 
| Journal de configuration du pilote | Collecte les journaux Windows SetupAPI (setupapi.dev.log et setupapi.setup.log). | 
| Boot Configuration | Collecte la ruche HKEY\$1LOCAL\$1MACHINE\$1BCD00000000. | 
| Memory Dump | Permet de collecter les fichiers de vidage de mémoire existant sur l’instance. | 
| EC2Fichier de configuration | Collecte les fichiers journaux générés par le service EC2 Config. | 
| EC2Fichier de lancement | Collecte les fichiers journaux générés par les scripts de EC2 lancement. | 
| SSM Agent File | Permet de collecter les fichiers journaux générés par SSM Agent et les journaux Patch Manager. | 
| Fichier élastique GPUs EC2 | Collecte les journaux d'événements liés à Elastic GPUs. | 
| ECS | Permet de collecter les journaux liés à Amazon ECS. | 
| CloudEndure | Collecte les fichiers journaux relatifs à CloudEndure l'agent. | 
| AWS Agent de réplication pour les fichiers journaux MGN ou DRS | Collecte les fichiers journaux liés à AWS Application Migration Service ou Reprise après sinistre AWS Elastic. | 

EC2Rescue for Windows Server peut collecter les données supplémentaires suivantes à partir d'**instances actives** :


| Élément | Description | 
| --- | --- | 
| System Information | Recueille MSInfo32. | 
| Résultat de la politique de groupe | Collecte un rapport de politique de groupe. | 

## Analyser une instance hors connexion
<a name="ec2rescue-offline"></a>

L’option **Offline Instance (Instance hors ligne)** est pratique pour déboguer les problèmes de démarrage liés aux instances Windows.

**Pour effectuer une action sur une instance hors ligne**

1. À partir d'une instance Windows Server fonctionnelle, téléchargez l'outil [EC2Rescue for Windows Server](https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip?x-download-source=docs) et extrayez les fichiers.

   Vous pouvez exécuter la PowerShell commande suivante pour télécharger EC2 Rescue sans modifier votre configuration de sécurité renforcée (ESC) d'Internet Explorer :

   ```
   Invoke-WebRequest https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip -OutFile $env:USERPROFILE\Desktop\EC2Rescue_latest.zip
   ```

   Cette commande téléchargera le fichier EC2 Rescue .zip sur le bureau de l'utilisateur actuellement connecté.
**Note**  
Si vous recevez un message d'erreur lors du téléchargement du fichier et que vous utilisez Windows Server 2016 ou une version antérieure, il est possible que le protocole TLS 1.2 doive être activé sur votre PowerShell terminal. Vous pouvez activer le protocole TLS 1.2 pour la PowerShell session en cours à l'aide de la commande suivante, puis réessayer :  

   ```
   [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
   ```

1. Arrêtez l’instance défaillante si ce n’est pas déjà fait.

1. Détachez le volume racine EBS de l'instance défectueuse et attachez-le à une instance Windows fonctionnelle sur laquelle EC2 Rescue for Windows Server est installé.

1. Exécutez l'outil EC2 Rescue for Windows Server sur l'instance de travail et choisissez **Offline Instance**.

1. Sélectionnez le disque du volume nouvellement monté et choisissez **Next (Suivant)**.

1. Confirmez la sélection de disque et choisissez **Yes (Oui)**.

1. Choisissez l’option d’instance en ligne à exécuter puis sélectionnez **Next (Suivant)**.

L'outil EC2 Rescue for Windows Server analyse le volume et collecte des informations de dépannage en fonction des fichiers journaux sélectionnés.

## Collecter des données à partir d’une instance active
<a name="ec2rescue-active"></a>

Vous pouvez collecter des journaux et d’autres données à partir d’une instance active.

**Pour collecter des données à partir d’une instance active**

1. Connectez-vous à votre instance Windows.

1. Téléchargez l'outil [EC2Rescue for Windows Server](https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip?x-download-source=docs) sur votre instance Windows et extrayez les fichiers.

   Vous pouvez exécuter la PowerShell commande suivante pour télécharger EC2 Rescue sans modifier votre configuration de sécurité renforcée (ESC) d'Internet Explorer :

   ```
   Invoke-WebRequest https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip -OutFile $env:USERPROFILE\Desktop\EC2Rescue_latest.zip
   ```

   Cette commande téléchargera le fichier EC2 Rescue .zip sur le bureau de l'utilisateur actuellement connecté.
**Note**  
Si vous recevez un message d'erreur lors du téléchargement du fichier et que vous utilisez Windows Server 2016 ou une version antérieure, il est possible que le protocole TLS 1.2 doive être activé sur votre PowerShell terminal. Vous pouvez activer le protocole TLS 1.2 pour la PowerShell session en cours à l'aide de la commande suivante, puis réessayer :  

   ```
   [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
   ```

1. Ouvrez l'application EC2 Rescue for Windows Server et acceptez le contrat de licence.

1. Choisissez **Next (Suivant)**, **Current instance (Instance actuelle)**, **Capture logs (Capturer les journaux)**.

1. Sélectionnez les éléments de données à collecter et choisissez **Collect... (Collecter...)**. Lisez l’avertissement et choisissez **Yes (Oui)** pour continuer.

1. Choisissez un nom de fichier et un emplacement pour le fichier ZIP et cliquez sur **Save (Enregistrer)**.

1. Une fois EC2 Rescue for Windows Server terminé, choisissez **Ouvrir le dossier contenant** pour afficher le fichier ZIP.

1. Choisissez **Finish** (Terminer).

# Résoudre les problèmes d'une instance Windows défectueuse à l'aide de la EC2 Rescue CLI
<a name="ec2rw-cli"></a>

L'interface de ligne de commande (CLI) EC2 Rescue for Windows Server vous permet d'exécuter un plug-in EC2 Rescue for Windows Server (appelé « action ») par programmation.

L'outil EC2 Rescue for Windows Server possède deux modes d'exécution :
+ **/online** —Cela vous permet d'agir sur l'instance sur laquelle EC2 Rescue for Windows Server est installé, par exemple de collecter des fichiers journaux.
+ **/offline :** <device\$1id>—Cela vous permet d'agir sur le volume racine hors ligne attaché à une instance Windows Amazon EC2 distincte, sur laquelle vous avez EC2 installé Rescue for Windows Server.

Téléchargez l'outil [EC2Rescue for Windows Server EC2](https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip?x-download-source=docs) sur votre instance Windows et extrayez les fichiers. Vous pouvez afficher le fichier d’aide avec la commande suivante :

```
EC2RescueCmd.exe /help
```

EC2Rescue for Windows Server peut effectuer les actions suivantes sur une instance Amazon EC2 Windows :
+ [Action de collecte](#ec2rw-collect)
+ [Action de résolution](#ec2rw-rescue)
+ [Action de restauration](#ec2rw-restore)

## Action de collecte
<a name="ec2rw-collect"></a>

**Note**  
Vous pouvez collecter tous les journaux, un groupe de journaux complet ou un journal individuel au sein d’un groupe.

EC2Rescue for Windows Server peut collecter les données suivantes à partir d'**instances actives et hors ligne**.


| Groupe de journaux | Journaux disponibles | Description | 
| --- | --- | --- | 
| all |  | Collecte tous les journaux disponibles. | 
| eventlog |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les journaux des événements de l'application, du système et de la EC2 configuration. | 
| memory-dump |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Permet de collecter les fichiers de vidage de mémoire existant sur l’instance. | 
| ec2config |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les fichiers journaux générés par le service EC2 Config. | 
| ec2launch |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les fichiers journaux générés par les scripts de EC2 lancement. | 
| ssm-agent |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Permet de collecter les fichiers journaux générés par SSM Agent et les journaux Patch Manager. | 
| sysprep | 'Log Files' | Permet de collecter les fichiers journaux générés par l’outil Windows System Preparation. | 
| driver-setup |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les journaux Windows SetupAPI (setupapi.dev.log et setupapi.setup.log). | 
| registry |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les ruches SYSTEM et SOFTWARE. | 
| egpu |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les journaux d'événements liés à Elastic GPUs. | 
| boot-config | 'BCDEDIT Output' | Collecte la ruche HKEY\$1LOCAL\$1MACHINE\$1BCD00000000. | 
| windows-update | 'Log Files' | Permet de collecter les fichiers journaux générés par Windows Update. Dans Windows Server 2016 et les versions ultérieures, le journal est collecté au format Event Tracing for Windows (ETW). | 
| cloudendure |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | Collecte les fichiers journaux relatifs à CloudEndure l'agent. | 

EC2Rescue for Windows Server peut collecter les données supplémentaires suivantes à partir d'**instances actives**.


| Groupe de journaux | Journaux disponibles | Description | 
| --- | --- | --- | 
| system-info | 'MSInfo32 Output' | Collecte MSInfo32. | 
| gpresult | 'GPResult Output' |  Collecte un rapport de politique de groupe.  | 

Les options suivantes sont disponibles :
+ **/output : < outputFilePath >** ‐ Emplacement du chemin du fichier de destination requis pour enregistrer les fichiers journaux collectés au format zip.
+ **/no-offline** : attribut facultatif utilisé en mode hors ligne. Ne met pas le volume hors connexion après avoir exécuté l’action.
+ **/no-fix-signature**‐ Attribut facultatif utilisé en mode hors ligne. Ne corrige pas une collision de signature de disque possible après avoir exécuté l’action.

### Exemples
<a name="ec2rw-collect-examples"></a>

Voici des exemples d'utilisation de la CLI EC2 Rescue for Windows Server.

#### Exemples en mode en ligne
<a name="ec2rw-collect-examples-online"></a>

Collecter tous les journaux disponibles :

```
EC2RescueCmd /accepteula /online /collect:all /output:<outputFilePath>
```

Collecter uniquement un groupe de journaux spécifique :

```
EC2RescueCmd /accepteula /online /collect:ec2config /output:<outputFilePath>
```

Collecter des journaux individuels au sein d’un groupe de journaux :

```
EC2RescueCmd /accepteula /online /collect:'ec2config.Log Files,driver-setup.SetupAPI Log Files' /output:<outputFilePath>
```

#### Exemples de mode hors connexion
<a name="ec2rw-collect-examples-offline"></a>

Collecter tous les journaux disponibles à partir d’un volume EBS. Le volume est spécifié par la valeur d’ID de périphérique.

```
EC2RescueCmd /accepteula /offline:xvdf /collect:all /output:<outputFilePath>
```

Collecter uniquement un groupe de journaux spécifique :

```
EC2RescueCmd /accepteula /offline:xvdf /collect:ec2config /output:<outputFilePath>
```

## Action de résolution
<a name="ec2rw-rescue"></a>

EC2Rescue for Windows Server peut détecter et résoudre les problèmes liés aux paramètres de service suivants :


|  Groupe de services  | Actions disponibles |  Description  | 
| --- | --- | --- | 
| all |  |  | 
| system-time | 'RealTimeIsUniversal' | Heure du système[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html) | 
| firewall |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  |  Pare-feu Windows [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | 
| rdp |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  |  Bureau à distance [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | 
| ec2config |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  |  EC2Config [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | 
| ec2launch | 'Reset Administrator Password' | Génère un nouveau mot de passe administrateur Windows. | 
| network | 'DHCP Service Startup' |  Interface réseau [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/ec2rw-cli.html)  | 

Les options suivantes sont disponibles :
+ **/level:<level>** : attribut facultatif pour le niveau de contrôle que l’action doit déclencher. Les valeurs autorisées sont les suivantes: `information`, `warning`, `error`, `all`. Par défaut, l’attribut est défini sur `error`.
+ **/check-only** : attribut facultatif qui génère un rapport mais n’effectue aucune modification sur le volume hors ligne.
**Note**  
Si EC2 Rescue for Windows Server détecte une possible collision de signature de disque, il corrige la signature une fois le processus hors ligne terminé par défaut, même lorsque vous utilisez l'`/check-only`option. Vous devez utiliser l’option `/no-fix-signature` pour empêcher la correction.
+ **/no-offline** : attribut facultatif qui empêche la mise hors ligne du volume une fois l’action exécutée.
+ **/no-fix-signature**‐ Attribut facultatif qui ne corrige pas une éventuelle collision de signature de disque une fois l'action terminée.

### Exemples de résolution
<a name="ec2rw-rescue-examples"></a>

Voici des exemples d'utilisation de la CLI EC2 Rescue for Windows Server. Le volume est spécifié à l’aide de la valeur d’ID de périphérique.

Tenter de corriger tous les problèmes identifiés sur un volume :

```
EC2RescueCmd /accepteula /offline:xvdf /rescue:all
```

Tenter de corriger tous les problèmes identifiés au sein d’un groupe de services sur un volume :

```
EC2RescueCmd /accepteula /offline:xvdf /rescue:firewall
```

Tenter de corriger un élément spécifique au sein d’un groupe de services sur un volume :

```
EC2RescueCmd /accepteula /offline:xvdf /rescue:rdp.'Service Start'
```

Spécifier plusieurs problèmes à tenter de corriger sur un volume :

```
EC2RescueCmd /accepteula /offline:xvdf /rescue:'system-time.RealTimeIsUniversal,ec2config.Service Start'
```

## Action de restauration
<a name="ec2rw-restore"></a>

EC2Rescue for Windows Server peut détecter et résoudre les problèmes liés aux paramètres de service suivants :


|  Groupe de services  | Actions disponibles |  Description  | 
| --- | --- | --- | 
|  Restaurer la dernière configuration correcte connue  | lkgc | Dernière configuration correcte connue : tente de démarrer l’instance avec son dernier état de démarrage connu. | 
| Restaurer le registre Windows à partir de la dernière sauvegarde | regback | Restaurer le registre à partir de la sauvegarde : restaure le registre à partir de \$1Windows\$1System32\$1config\$1RegBack. | 

Les options suivantes sont disponibles :
+ **/no-offline** — Attribut facultatif qui empêche la mise hors connexion du volume une fois l’action exécutée.
+ **/no-fix-signature**—Attribut facultatif qui ne corrige pas une éventuelle collision de signatures de disque une fois l'action terminée.

### Exemples de restauration
<a name="ec2rw-restore-examples"></a>

Voici des exemples d'utilisation de la CLI EC2 Rescue for Windows Server. Le volume est spécifié à l’aide de la valeur d’ID de périphérique.

Restaurer la dernière configuration correcte connue sur un volume :

```
EC2RescueCmd /accepteula /offline:xvdf /restore:lkgc
```

Restaurer la dernière sauvegarde du registre Windows sur un volume :

```
EC2RescueCmd /accepteula /offline:xvdf /restore:regback
```

# Résoudre les problèmes d'une instance Windows défectueuse avec EC2 Rescue and Systems Manager
<a name="ec2rw-ssm"></a>

Support vous fournit un document de commande d'exécution de Systems Manager pour vous interfacer avec votre instance compatible avec Systems Manager afin d'exécuter EC2 Rescue for Windows Server. Le document Exécuter la commande s’appelle `AWSSupport-RunEC2RescueForWindowsTool`.

Le document Exécuter la commande Systems Manager effectue les tâches suivantes :
+ Télécharge et vérifie EC2 Rescue pour Windows Server.
+ Importe un PowerShell module pour faciliter votre interaction avec l'outil.
+ S'exécute EC2 RescueCmd avec la commande et les paramètres fournis.

Le document Exécuter la commande Systems Manager accepte trois paramètres :
+ **Commande** : action EC2 Rescue for Windows Server. Les valeurs autorisées actuelles sont :
  + **ResetAccess**—Réinitialise le mot de passe de l'administrateur local. Le mot de passe administrateur local de l’instance actuelle sera réinitialisé et le mot de passe généré de manière aléatoire sera stocké de manière sécurisée dans le Parameter Store en tant que `/EC2Rescue/Password/<INSTANCE_ID>`. Si vous sélectionnez cette action sans fournir de paramètres, les mots de passe sont chiffrés automatiquement avec la clé KMS par défaut. Vous pouvez aussi spécifier l’ID d’une clé KMS dans Paramètres pour chiffrer le mot de passe avec votre propre clé.
  + **CollectLogs**—Exécute EC2 Rescue for Windows Server avec l'`/collect:all`action. Si vous sélectionnez cette action, `Parameters` doit inclure le nom d’un compartiment Amazon S3 dans lequel les journaux seront chargés.
  + **FixAll**—Exécute EC2 Rescue for Windows Server avec l'`/rescue:all`action. Si vous sélectionnez cette action, `Parameters` doit inclure le nom du périphérique de stockage en mode bloc à corriger.
+ **Paramètres** : PowerShell paramètres à transmettre pour la commande spécifiée.

## Exigences
<a name="ec2rw-requirements"></a>

Pour exécuter l'**ResetAccess**action, votre instance Amazon EC2 doit être associée à une politique autorisant l'écriture du mot de passe chiffré dans Parameter Store. Après avoir attaché la politique, attendez quelques minutes avant de tenter de réinitialiser le mot de passe d’une instance après avoir attaché cette politique au rôle IAM correspondant.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:PutParameter"
      ],
      "Resource": [
        "arn:aws:ssm:us-east-1:111122223333:parameter/EC2Rescue/Passwords/<instanceid>"
      ]
    }
  ]
}
```

------

Si vous utilisez une clé KMS personnalisée, et non la clé KMS par défaut, utilisez plutôt cette politique.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:PutParameter"
      ],
      "Resource": [
        "arn:aws:ssm:us-east-1:111122223333:parameter/EC2Rescue/Passwords/<instanceid>"
      ] 
    }, 
    { 
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt"
      ],
      "Resource": [
        "arn:aws:kms:us-east-1:111122223333:key/<kmskeyid>"
      ]
    }
  ]
}
```

------

## Affichage du JSON pour le document
<a name="ec2rw-view-json"></a>

La procédure suivante décrit comment afficher le JSON pour ce document.

**Pur afficher le JSON pour le document Exécuter la commande Systems Manager**

1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Dans le volet de navigation, développez **Outils de gestion des modifications** et choisissez **Documents**.

1. Dans la barre de recherche, saisissez `AWSSupport-RunEC2RescueForWindowsTool`, puis sélectionnez le document `AWSSupport-RunEC2RescueForWindowsTool`.

1. Sélectionnez l'onglet **Contenu**.

## Exemples
<a name="ec2rw-ssm-examples"></a>

Voici quelques exemples d'utilisation du document Run Command de Systems Manager pour exécuter EC2 Rescue for Windows Server, à l'aide du AWS CLI. Pour plus d'informations sur l'envoi de commandes à l'aide du AWS CLI, voir [send-command](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html).

**Topics**
+ [Tentative de correction de tous les problèmes identifiés sur un volume racine hors connexion](#ec2rw-ssm-exam1)
+ [Collectez les journaux à partir de l’instance Amazon EC2 Windows actuelle](#ec2rw-ssm-exam2)
+ [Réinitialisez le mot de passe administrateur local](#ec2rw-ssm-exam4)

### Tentative de correction de tous les problèmes identifiés sur un volume racine hors connexion
<a name="ec2rw-ssm-exam1"></a>

Essayez de corriger tous les problèmes identifiés sur un volume racine hors connexion attaché à une instance Amazon EC2 Windows :

```
aws ssm send-command --instance-ids "i-0cb2b964d3e14fd9f" --document-name "AWSSupport-RunEC2RescueForWindowsTool" --parameters "Command=FixAll, Parameters='xvdf'" --output text
```

### Collectez les journaux à partir de l’instance Amazon EC2 Windows actuelle
<a name="ec2rw-ssm-exam2"></a>

Collectez tous les journaux à partir de l’instance Amazon EC2 Windows en ligne actuelle et chargez-les dans un compartiment Amazon S3 :

```
aws ssm send-command --instance-ids "i-0cb2b964d3e14fd9f" --document-name "AWSSupport-RunEC2RescueForWindowsTool" --parameters "Command=CollectLogs, Parameters='amzn-s3-demo-bucket'" --output text
```

### Réinitialisez le mot de passe administrateur local
<a name="ec2rw-ssm-exam4"></a>

Les exemples suivants illustrent les méthodes vous permettant de réinitialiser le mot de passe administrateur local. La sortie fournit un lien vers Parameter Store, dans lequel vous pouvez trouver le mot de passe sécurisé généré de manière aléatoire que vous pouvez utiliser ensuite pour RDP dans votre instance Windows Amazon EC2 en tant qu’administrateur local.

Réinitialisez le mot de passe administrateur local d'une instance en ligne en utilisant le mot de passe par défaut AWS KMS key alias/aws/ssm :

```
aws ssm send-command --instance-ids "i-0cb2b964d3e14fd9f" --document-name "AWSSupport-RunEC2RescueForWindowsTool" --parameters "Command=ResetAccess" --output text
```

Réinitialiser le mot de passe administrateur local d’une instance en ligne à l’aide d’une clé KMS :

```
aws ssm send-command --instance-ids "i-0cb2b964d3e14fd9f" --document-name "AWSSupport-RunEC2RescueForWindowsTool" --parameters "Command=ResetAccess, Parameters=a133dc3c-a2g4-4fc6-a873-6c0720104bf0" --output text
```

**Note**  
Dans cet exemple, l’clé KMS est `a133dc3c-a2g4-4fc6-a873-6c0720104bf0`.

# EC2 Serial Console pour les instances
<a name="ec2-serial-console"></a>

Avec l’EC2 Serial Console , vous avez accès au port série de votre instance Amazon EC2, que vous pouvez utiliser pour résoudre les problèmes de démarrage, de configuration réseau et autres. La console série ne requiert pas que votre instance possède des capacités de mise en réseau. La console série vous permet de commander une instance comme si votre clavier et votre moniteur étaient directement connectés au port série de cette dernière. La session de la console série dure du redémarrage à l’arrêt de l’instance. Pendant le redémarrage, vous pouvez afficher tous les messages de démarrage depuis le début.

L’accès à la console série n’est pas disponible par défaut. Votre organisation doit autoriser le compte à accéder à la console série et configurer des politiques IAM pour accorder à vos utilisateurs l’accès à la console série. L'accès à la console série peut être contrôlé à un niveau granulaire à l'aide d'instances IDs, de balises de ressources et d'autres leviers IAM. Pour de plus amples informations, veuillez consulter [Configurer l’accès à l’EC2 Serial Console](configure-access-to-serial-console.md).

Vous pouvez accéder à la console série à l’aide de la console EC2 ou de l’ AWS CLI.

La console série est disponible sans frais supplémentaires.

**Topics**
+ [Conditions préalables pour l’EC2 Serial Console](ec2-serial-console-prerequisites.md)
+ [Configurer l’accès à l’EC2 Serial Console](configure-access-to-serial-console.md)
+ [Connexion à l’EC2 Serial Console](connect-to-serial-console.md)
+ [Déconnexion de l’EC2 Serial Console](disconnect-serial-console-session.md)
+ [Résolvez les problèmes de votre instance Amazon EC2 à l’aide de EC2 Serial Console](troubleshoot-using-serial-console.md)

# Conditions préalables pour l’EC2 Serial Console
<a name="ec2-serial-console-prerequisites"></a>

**Topics**
+ [Régions AWS](#sc-prereqs-regions)
+ [Zones de longueur d'onde et AWS Outposts](#sc-prereqs-wavelength-zones-outposts)
+ [Local Zones](#sc-prereqs-local-zones)
+ [Types d’instances](#sc-prereqs-instance-types)
+ [Octroi de l’accès](#sc-prereqs-configure-ec2-serial-console)
+ [Prise en charge d’un client basé sur un navigateur](#sc-prereqs-for-browser-based-connection)
+ [État de l’instance](#sc-prereqs-instance-state)
+ [Amazon EC2 Systems Manager](#sc-prereqs-ssm)
+ [Configuration de l’outil de dépannage de votre choix](#sc-prereqs-configure-troubleshooting-tool)

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

Pris en charge dans tous les Régions AWS domaines.

## Zones de longueur d'onde et AWS Outposts
<a name="sc-prereqs-wavelength-zones-outposts"></a>

Non pris en charge.

## Local Zones
<a name="sc-prereqs-local-zones"></a>

Prise en charge dans toutes les zones locales.

## Types d’instances
<a name="sc-prereqs-instance-types"></a>

Types d’instances pris en charge :
+ **Linux**
  + Toutes les instances virtualisées créées sur la base de Nitro System.
  + Toutes les instances de matériel nu à l’exception de :
    + Usage général : `a1.metal`, `mac1.metal`, `mac2.metal`
    + Calcul accéléré : `g5g.metal`
    + Mémoire optimisée : `u-6tb1.metal`, `u-9tb1.metal`, `u-12tb1.metal`, `u-18tb1.metal`, `u-24tb1.metal`
+ **Windows**

  Toutes les instances virtualisées créées sur la base de Nitro System. Non pris en charge par les instances à matériel nu.

## Octroi de l’accès
<a name="sc-prereqs-configure-ec2-serial-console"></a>

Vous devez effectuer les tâches de configuration pour octroyer l’accès à l’EC2 Serial Console. Pour de plus amples informations, veuillez consulter [Configurer l’accès à l’EC2 Serial Console](configure-access-to-serial-console.md).

## Prise en charge d’un client basé sur un navigateur
<a name="sc-prereqs-for-browser-based-connection"></a>

Pour vous connecter à la console série à [l'aide du client basé sur un navigateur](connect-to-serial-console.md#sc-connect-browser-based-client), votre navigateur doit être compatible. WebSocket Si votre navigateur ne le prend pas en charge WebSocket, connectez-vous à la console série à [l'aide de votre propre clé et d'un client SSH](connect-to-serial-console.md#sc-connect-SSH).

## État de l’instance
<a name="sc-prereqs-instance-state"></a>

Doit indiquer `running`.

Vous ne pouvez pas vous connecter à la console série si l’instance est à l’état `pending`, `stopping`, `stopped`, `shutting-down` ou `terminated`.

Pour plus d’informations sur les états de l’instance, consultez [Modifications de l'état de l' EC2 instance Amazon](ec2-instance-lifecycle.md).

## Amazon EC2 Systems Manager
<a name="sc-prereqs-ssm"></a>

Si l’instance utilise Amazon EC2 Systems Manager, SSM Agent version 3.0.854.0 ou ultérieure doit être installé sur l’instance. Pour plus d’informations sur SSM Agent, veuillez consulter [Utilisation de SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) dans le *Guide de l’utilisateur AWS Systems Manager *.

## Configuration de l’outil de dépannage de votre choix
<a name="sc-prereqs-configure-troubleshooting-tool"></a>

Pour dépanner votre instance à l'aide de la console série, vous pouvez utiliser GRUB ou SysRq sur les instances Linux, et la console d'administration spéciale (SAC) sur les instances Windows. Avant de pouvoir utiliser ces outils, vous devez d’abord effectuer des étapes de configuration sur chaque instance sur laquelle vous allez les utiliser.

Utilisez les instructions fournies pour le système d’exploitation de votre instance pour configurer l’outil de résolution des problèmes de votre choix.

### (Instances Linux) Configurer GRUB
<a name="configure-grub"></a>

Pour configurer GRUB, choisissez l’une des procédures suivantes en fonction de l’AMI utilisée pour lancer l’instance.

------
#### [ Amazon Linux 2 ]

**Pour configurer GRUB sur une instance Amazon Linux 2**

1. [Se connecter à votre instance Linux à l’aide de SSH](connect-to-linux-instance.md)

1. Ajoutez ou modifiez les options suivantes dans `/etc/default/grub`:
   + Configurez `GRUB_TIMEOUT=1`.
   + Addition `GRUB_TERMINAL="console serial"`.
   + Addition `GRUB_SERIAL_COMMAND="serial --speed=115200"`.

   Voici un exemple de `/etc/default/grub`. Vous devrez peut-être modifier la configuration en fonction de la configuration de votre système.

   ```
   GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
   GRUB_TIMEOUT=1
   GRUB_DISABLE_RECOVERY="true"
   GRUB_TERMINAL="console serial"
   GRUB_SERIAL_COMMAND="serial --speed=115200"
   ```

1. Appliquez la configuration mise à jour en exécutant la commande suivante.

   ```
   [ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   ```

------
#### [ Ubuntu ]

**Pour configurer GRUB sur une instance Ubuntu**

1. [Connectez-vous à votre instance](connect-to-linux-instance.md).

1. Ajoutez ou modifiez les options suivantes dans `/etc/default/grub.d/50-cloudimg-settings.cfg`:
   + Configurez `GRUB_TIMEOUT=1`.
   + Addition `GRUB_TIMEOUT_STYLE=menu`.
   + Addition `GRUB_TERMINAL="console serial"`.
   + Supprimez `GRUB_HIDDEN_TIMEOUT`.
   + Addition `GRUB_SERIAL_COMMAND="serial --speed=115200"`.

   Voici un exemple de `/etc/default/grub.d/50-cloudimg-settings.cfg`. Vous devrez peut-être modifier la configuration en fonction de la configuration de votre système.

   ```
   # Cloud Image specific Grub settings for Generic Cloud Images
   # CLOUD_IMG: This file was created/modified by the Cloud Image build process
   
   # Set the recordfail timeout
   GRUB_RECORDFAIL_TIMEOUT=0
   
   # Do not wait on grub prompt
   GRUB_TIMEOUT=1
   GRUB_TIMEOUT_STYLE=menu
   
   # Set the default commandline
   GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295"
   
   # Set the grub console type
   GRUB_TERMINAL="console serial"
   GRUB_SERIAL_COMMAND="serial --speed 115200"
   ```

1. Appliquez la configuration mise à jour en exécutant la commande suivante.

   ```
   [ec2-user ~]$ sudo update-grub
   ```

------
#### [ RHEL ]

**Pour configurer GRUB sur une instance RHEL**

1. [Connectez-vous à votre instance](connect-to-linux-instance.md).

1. Ajoutez ou modifiez les options suivantes dans `/etc/default/grub`:
   + Supprimez `GRUB_TERMINAL_OUTPUT`.
   + Addition `GRUB_TERMINAL="console serial"`.
   + Addition `GRUB_SERIAL_COMMAND="serial --speed=115200"`.

   Voici un exemple de `/etc/default/grub`. Vous devrez peut-être modifier la configuration en fonction de la configuration de votre système.

   ```
   GRUB_TIMEOUT=1
   GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
   GRUB_DEFAULT=saved
   GRUB_DISABLE_SUBMENU=true
   GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto"
   GRUB_DISABLE_RECOVERY="true"
   GRUB_ENABLE_BLSCFG=true
   GRUB_TERMINAL="console serial"
   GRUB_SERIAL_COMMAND="serial --speed=115200"
   ```

1. Appliquez la configuration mise à jour en exécutant la commande suivante.

   ```
   [ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
   ```

   Pour RHEL 9.2 et les versions antérieures, utilisez la commande suivante.

   ```
   [ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   ```

------
#### [ CentOS ]

Pour les instances lancées à l’aide d’une AMI CentOS, GRUB est configuré pour la console série par défaut.

Voici un exemple de `/etc/default/grub`. En fonction de la configuration de votre système, il se peut que votre configuration soit différente. 

```
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial --speed=115200"
GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto console=ttyS0,115200"
GRUB_DISABLE_RECOVERY="true"
```

------

### (instances Linux) Configurer SysRq
<a name="configure-sysrq"></a>

Pour configurer SysRq, vous devez activer les SysRq commandes pour le cycle de démarrage en cours. Pour que la configuration soit persistante, vous pouvez également activer les SysRq commandes pour les démarrages suivants.

**Pour activer toutes les SysRq commandes pour le cycle de démarrage en cours**

1. [Connectez-vous à votre instance](connect-to-linux-instance.md).

1. Exécutez la commande suivante.

   ```
   [ec2-user ~]$ sudo sysctl -w kernel.sysrq=1
   ```

   Ce paramètre est effacé au prochain redémarrage.

**Pour activer toutes les SysRq commandes pour les démarrages suivants**

1. Créez le fichier `/etc/sysctl.d/99-sysrq.conf` et ouvrez-le dans votre éditeur préféré.

   ```
   [ec2-user ~]$ sudo vi /etc/sysctl.d/99-sysrq.conf
   ```

1. Ajoutez la ligne suivante.

   ```
   kernel.sysrq=1
   ```

1. Redémarrez l’instance pour appliquer les modifications.

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

1. À l’invite `login`, entrez le nom d’utilisateur de l’utilisateur avec un mot de passe que vous avez [configuré précédemment](configure-access-to-serial-console.md#set-user-password), puis appuyez sur **Entrée**.

1. À l’invite `Password`, entrez le mot de passe, puis appuyez sur **Entrée**.

### (Instances Windows) Activer SAC et le menu de démarrage
<a name="configure-sac-bootmenu"></a>

**Note**  
Si vous activez SAC sur une instance, les services EC2 qui reposent sur la récupération de mot de passe ne fonctionnent pas à partir de la console Amazon EC2. Les agents de lancement Windows on Amazon EC2 (EC2Config, EC2Launch v1 et EC2Launch v2) s’appuient sur la console série pour exécuter diverses tâches. Ces tâches ne s’exécutent pas correctement lorsque vous activez SAC sur une instance. Pour plus d’informations sur les agents de lancement Windows sur Amazon EC2, consultez [Configurez votre instance Amazon EC2 Windows](ec2-windows-instances.md). Si vous activez SAC, vous pouvez le désactiver ultérieurement. Pour de plus amples informations, veuillez consulter [Désactiver SAC et le menu de démarrage](troubleshoot-using-serial-console.md#disable-sac-bootmenu).

Utilisez l’une des méthodes suivantes pour activer SAC et le menu de démarrage sur une instance.

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

**Pour activer SAC et le menu de démarrage sur une instance Windows**

1. [Connectez-vous](connecting_to_windows_instance.md) à votre instance et effectuez les étapes suivantes à partir d'une ligne de PowerShell commande élevée.

1. Activez SAC.

   ```
   bcdedit /ems '{current}' on
   bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
   ```

1. Activez le menu de démarrage.

   ```
   bcdedit /set '{bootmgr}' displaybootmenu yes
   bcdedit /set '{bootmgr}' timeout 15
   bcdedit /set '{bootmgr}' bootems yes
   ```

1. Appliquez la configuration mise à jour en redémarrant l’instance.

   ```
   shutdown -r -t 0
   ```

------
#### [ Command prompt ]

**Pour activer SAC et le menu de démarrage sur une instance Windows**

1. [Connectez-vous](connecting_to_windows_instance.md) à votre instance et exécutez les étapes suivantes à partir de l’invite de commandes.

1. Activez SAC.

   ```
   bcdedit /ems {current} on
   bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
   ```

1. Activez le menu de démarrage.

   ```
   bcdedit /set {bootmgr} displaybootmenu yes
   bcdedit /set {bootmgr} timeout 15
   bcdedit /set {bootmgr} bootems yes
   ```

1. Appliquez la configuration mise à jour en redémarrant l’instance.

   ```
   shutdown -r -t 0
   ```

------

# Configurer l’accès à l’EC2 Serial Console
<a name="configure-access-to-serial-console"></a>

Pour configurer l’accès à la console série, vous devez accorder l’accès à la console série au niveau du compte, puis configurer des politiques IAM pour accorder l’accès à vos utilisateurs. Pour les instances Linux, vous devez également configurer un utilisateur avec mot de passe sur chaque instance afin que vos utilisateurs puissent utiliser la console série pour la résolution des problèmes.

EC2 Serial Console utilise une connexion par port série virtuel pour interagir avec une instance. Cette connexion est indépendante du VPC de l’instance, ce qui vous permet de travailler avec le système d’exploitation de l’instance et d’exécuter des outils de résolution des problèmes même en cas d’échec du démarrage ou de problèmes de configuration réseau. Comme cette connexion se trouve en dehors du réseau VPC, l’EC2 Serial Console n’utilise pas le groupe de sécurité de l’instance ou l’ACL du réseau de sous-réseaux pour autoriser le trafic vers l’instance.

**Avant de commencer**  
Vérifiez que les [conditions préalables](ec2-serial-console-prerequisites.md) sont remplies.

**Topics**
+ [Niveaux d’accès à l’EC2 Serial Console](#serial-console-access-levels)
+ [Gérer l’accès du compte à l’EC2 Serial Console](#serial-console-account-access)
+ [Configurer les politiques IAM pour l’accès à l’EC2 Serial Console](#serial-console-iam)
+ [Définir un mot de passe utilisateur de système d’exploitation sur une instance Linux](#set-user-password)

## Niveaux d’accès à l’EC2 Serial Console
<a name="serial-console-access-levels"></a>

Par défaut, il n’est pas possible d’accéder à la console série au niveau du compte. Vous devez accorder explicitement l’accès à la console série au niveau du compte. Pour plus d’informations, veuillez consulter [Gérer l’accès du compte à l’EC2 Serial Console](#serial-console-account-access).

Vous pouvez utiliser une politique de contrôle de service (SCP) pour autoriser l’accès à la console série au sein de votre organisation. Vous pouvez ensuite disposer d’un contrôle d’accès granulaire au niveau de l’utilisateur à l’aide d’une politique IAM pour contrôler l’accès. En combinant des politiques SCP et IAM, vous disposez de différents niveaux de contrôle d’accès à la console série.

**Niveau de l’organisation**  
Vous pouvez utiliser une politique de contrôle de service (SCP) pour autoriser l’accès à la console série aux comptes membre au sein de votre organisation. Pour plus d'informations SCPs, consultez la section [Politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de AWS Organizations l'utilisateur*.

**Niveau de l’instance**  
Vous pouvez configurer les politiques d'accès à la console série en utilisant IAM PrincipalTag et les ResourceTag constructions et en spécifiant les instances par leur ID. Pour de plus amples informations, veuillez consulter [Configurer les politiques IAM pour l’accès à l’EC2 Serial Console](#serial-console-iam).

**Niveau utilisateur**  
Vous pouvez configurer l’accès au niveau de l’utilisateur en configurant une politique IAM pour autoriser ou interdire à un utilisateur spécifié d’envoyer la clé publique SSH en mode push au service de console série d’une instance particulière. Pour de plus amples informations, veuillez consulter [Configurer les politiques IAM pour l’accès à l’EC2 Serial Console](#serial-console-iam).

**Niveau du système** d’exploitation (instances Linux uniquement)  
Vous pouvez définir un mot de passe utilisateur au niveau du système d’exploitation invité. Cela permet d’accéder à la console série pour certains cas d’utilisation. Toutefois, pour surveiller les journaux, vous n’avez pas besoin d’un utilisateur avec un mot de passe. Pour plus d’informations, veuillez consulter [Définir un mot de passe utilisateur de système d’exploitation sur une instance Linux](#set-user-password).

## Gérer l’accès du compte à l’EC2 Serial Console
<a name="serial-console-account-access"></a>

Par défaut, il n’est pas possible d’accéder à la console série au niveau du compte. Vous devez accorder explicitement l’accès à la console série au niveau du compte.

Ce paramètre est configuré au niveau du compte, soit directement dans le compte, soit à l’aide d’une politique déclarative. Il doit être configuré dans chaque Région AWS endroit où vous souhaitez autoriser l'accès à la console série. L’utilisation d’une politique déclarative vous permet d’appliquer le paramètre à plusieurs régions simultanément, ainsi qu’à plusieurs comptes simultanément. Lorsqu’une politique déclarative est utilisée, vous ne pouvez pas modifier le paramètre directement dans un compte. Cette rubrique décrit comment configurer le paramètre directement dans un compte. Pour plus d’informations sur l’utilisation des politiques déclaratives, consultez la section [Politiques déclaratives](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) dans le *Guide de l’utilisateur AWS Organizations *.

**Contents**
+ [Autoriser les utilisateurs à gérer l’accès du compte](#sc-account-access-permissions)
+ [Afficher l’état de l’accès du compte à la console série](#sc-view-account-access)
+ [Autoriser le compte à accéder à la console série](#sc-grant-account-access)
+ [Interdire au compte l’accès à la console série](#sc-deny-account-access)

### Autoriser les utilisateurs à gérer l’accès du compte
<a name="sc-account-access-permissions"></a>

Pour permettre à vos utilisateurs de gérer l’accès du compte à l’EC2 Serial Console, vous devez leur octroyer les autorisations IAM requises.

La politique suivante accorde des autorisations pour afficher l’état du compte, et autoriser et interdire le compte à accéder à l’EC2 Serial Console .

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:GetSerialConsoleAccessStatus",
                "ec2:EnableSerialConsoleAccess",
                "ec2:DisableSerialConsoleAccess"
            ],
            "Resource": "*"
        }
    ]
}
```

------

Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.

### Afficher l’état de l’accès du compte à la console série
<a name="sc-view-account-access"></a>

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

**Pour afficher l’accès du compte à la console série**

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 **Dashboard** (Tableau de bord).

1. Sur la carte **Attributs du compte**, sous **Paramètres**, choisissez **EC2 Serial Console.**

1. Dans l’onglet **EC2 Serial Console**, la valeur de **Accès à EC2 Serial Console** est soit **Autorisé**, soit **Interdit**.

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

**Pour afficher l’accès du compte à la console série**  
Utilisez la commande [get-serial-console-access-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-serial-console-access-status.html).

```
aws ec2 get-serial-console-access-status
```

Voici un exemple de sortie. Une valeur de `true` indique que le compte est autorisé à accéder à la console série.

```
{
    "SerialConsoleAccessEnabled": true,
    "ManagedBy": "account"
}
```

Le champ `ManagedBy` indique l’entité qui a configuré le paramètre. Les valeurs possibles sont `account` (configurées directement) ou `declarative-policy`. Pour plus d’informations, consultez la rubrique [Politiques déclaratives](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) dans le *Guide de l’utilisateur AWS Organizations *.

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

**Pour afficher l’accès du compte à la console série**  
Utilisez l’applet de commande [Get-EC2SerialConsoleAccessStatus](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2SerialConsoleAccessStatus.html).

```
Get-EC2SerialConsoleAccessStatus -Select *
```

Voici un exemple de sortie. Une valeur de `True` indique que le compte est autorisé à accéder à la console série.

```
ManagedBy SerialConsoleAccessEnabled
--------- --------------------------
account   True
```

Le champ `ManagedBy` indique l’entité qui a configuré le paramètre. Les valeurs possibles sont `account` (configurées directement) ou `declarative-policy`. Pour plus d’informations, consultez la rubrique [Politiques déclaratives](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) dans le *Guide de l’utilisateur AWS Organizations *.

------

### Autoriser le compte à accéder à la console série
<a name="sc-grant-account-access"></a>

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

**Pour autoriser le compte à accéder à la console série**

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 **Dashboard** (Tableau de bord).

1. Sur la carte **Attributs du compte**, sous **Paramètres**, choisissez **EC2 Serial Console.**

1. Choisissez **Gérer**.

1. Pour autoriser toutes les instances du compte à accéder à l’EC2 Serial Console, cochez la case **Autoriser**.

1. Choisissez **Mettre à jour**.

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

**Pour autoriser le compte à accéder à la console série**  
Utilisez la commande [enable-serial-console-access](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-serial-console-access.html).

```
aws ec2 enable-serial-console-access
```

Voici un exemple de sortie.

```
{
    "SerialConsoleAccessEnabled": true
}
```

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

**Pour autoriser le compte à accéder à la console série**  
Utilisez l’applet de commande [Enable-EC2SerialConsoleAccess](https://docs.aws.amazon.com/powershell/latest/reference/items/Enable-EC2SerialConsoleAccess.html).

```
Enable-EC2SerialConsoleAccess
```

Voici un exemple de sortie.

```
True
```

------

### Interdire au compte l’accès à la console série
<a name="sc-deny-account-access"></a>

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

**Pour interdire au compte l’accès à la console série**

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 **Dashboard** (Tableau de bord).

1. Sur la carte **Attributs du compte**, sous **Paramètres**, choisissez **EC2 Serial Console.**

1. Choisissez **Gérer**.

1. Pour interdire l’accès à l’EC2 Serial Console de toutes les instances du compte, décochez la case **Autoriser**.

1. Choisissez **Mettre à jour**.

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

**Pour interdire au compte l’accès à la console série**  
Utilisez la commande [disable-serial-console-access](https://docs.aws.amazon.com/cli/latest/reference/ec2/disable-serial-console-access.html).

```
aws ec2 disable-serial-console-access
```

Voici un exemple de sortie.

```
{
    "SerialConsoleAccessEnabled": false
}
```

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

**Pour interdire au compte l’accès à la console série**  
Utilisez l’applet de commande [Disable-EC2SerialConsoleAccess](https://docs.aws.amazon.com/powershell/latest/reference/items/Disable-EC2SerialConsoleAccess.html).

```
Disable-EC2SerialConsoleAccess
```

Voici un exemple de sortie.

```
False
```

------

## Configurer les politiques IAM pour l’accès à l’EC2 Serial Console
<a name="serial-console-iam"></a>

Par défaut, vos utilisateurs n’ont pas accès à la console série. Votre organisation doit configurer des politiques IAM pour accorder à vos utilisateurs l’accès requis. Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *IAM Guide de l’utilisateur*.

Pour accéder à la console série, créez un document de politique JSON qui inclut l’action `ec2-instance-connect:SendSerialConsoleSSHPublicKey`. Cette action accorde à un utilisateur l’autorisation d’envoyer la clé publique en mode push au service de console série, qui démarre une session de console série. Nous vous recommandons de limiter l’accès à des instances EC2 spécifiques. Sinon, tous les utilisateurs disposant de cette autorisation peuvent se connecter à la console série de toutes les instances EC2.

**Topics**
+ [Autoriser explicitement l’accès à la console série](#iam-explicitly-allow-access)
+ [Refuser explicitement l’accès à la console série](#serial-console-IAM-policy)
+ [Utiliser des balises de ressources pour contrôler l’accès à la console série](#iam-resource-tags)

### Autoriser explicitement l’accès à la console série
<a name="iam-explicitly-allow-access"></a>

Par défaut, personne n’a accès à la console série. Pour accorder l’accès à la console série, vous devez configurer une politique pour autoriser explicitement cet accès. Nous vous recommandons de configurer une politique qui restreint l’accès à des instances spécifiques.

La politique suivante permet d’accéder à la console série d’une instance spécifique, identifiée par son ID d’instance.

Notez que les actions `DescribeInstances`, `DescribeInstanceTypes` et `GetSerialConsoleAccessStatus` ne prennent pas en charge les autorisations au niveau des ressources. Par conséquent, toutes les ressources, indiquées par un astérisque `*`, doivent être spécifiées pour ces actions.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowDescribeInstances",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceTypes",
                "ec2:GetSerialConsoleAccessStatus"
            ],
             "Resource": "*"
        },
        {
            "Sid": "AllowinstanceBasedSerialConsoleAccess",
            "Effect": "Allow",
            "Action": [
                "ec2-instance-connect:SendSerialConsoleSSHPublicKey"
            ],
            "Resource": "arn:aws:ec2:us-east-1:111122223333:instance/i-0598c7d356eba48d7"
        }
    ]
}
```

------

### Refuser explicitement l’accès à la console série
<a name="serial-console-IAM-policy"></a>

La politique IAM suivante autorise l’accès à la console série de toutes les instances, désignées par `*` (astérisque), et refuse explicitement l’accès à la console série d’une instance spécifique, identifiée par son ID.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowSerialConsoleAccess",
            "Effect": "Allow",
            "Action": [
                "ec2-instance-connect:SendSerialConsoleSSHPublicKey",
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceTypes",
                "ec2:GetSerialConsoleAccessStatus"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenySerialConsoleAccess",
            "Effect": "Deny",
            "Action": [
                "ec2-instance-connect:SendSerialConsoleSSHPublicKey"
            ],
            "Resource": "arn:aws:ec2:us-east-1:111122223333:instance/i-0598c7d356eba48d7"
        }
    ]
}
```

------

### Utiliser des balises de ressources pour contrôler l’accès à la console série
<a name="iam-resource-tags"></a>

Vous pouvez utiliser des balises de ressource pour contrôler l’accès à la console série d’une instance.

Le contrôle d'accès basé sur les attributs est une stratégie d'autorisation qui définit les autorisations en fonction de balises pouvant être associées aux utilisateurs et AWS aux ressources. Par exemple, la politique suivante permet à un utilisateur d’initier une connexion à la console série pour une seule instance si la balise de ressource de cette instance et la balise du principal possèdent la même valeur `SerialConsole` en clé de balise.

Pour plus d'informations sur l'utilisation de balises pour contrôler l'accès à vos AWS ressources, consultez la section [Contrôle de l'accès aux AWS ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html#access_tags_control-resources) dans le *guide de l'utilisateur IAM*.

Notez que les actions `DescribeInstances`, `DescribeInstanceTypes` et `GetSerialConsoleAccessStatus` ne prennent pas en charge les autorisations au niveau des ressources. Par conséquent, toutes les ressources, indiquées par un astérisque `*`, doivent être spécifiées pour ces actions.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowDescribeInstances",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceTypes",
                "ec2:GetSerialConsoleAccessStatus"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowTagBasedSerialConsoleAccess",
            "Effect": "Allow",
            "Action": [
                "ec2-instance-connect:SendSerialConsoleSSHPublicKey"
            ],
            "Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/SerialConsole": "${aws:PrincipalTag/SerialConsole}"
                }
            }
        }
    ]
}
```

------

## Définir un mot de passe utilisateur de système d’exploitation sur une instance Linux
<a name="set-user-password"></a>

Vous pouvez vous connecter à la console série sans mot de passe. Toutefois, pour *utiliser* la console série pour résoudre les problèmes d’une instance, cette dernière doit avoir un utilisateur de système d’exploitation avec mot de passe.

Vous pouvez définir le mot de passe pour n’importe quel utilisateur du système d’exploitation, y compris l’utilisateur racine. Notez que l’utilisateur racine peut modifier tous les fichiers, tandis que chaque utilisateur du système d’exploitation peut avoir des autorisations limitées.

Vous devez définir un mot de passe utilisateur pour chaque instance pour laquelle vous utilisez la console série. Vous n’aurez besoin d’effectuer cette opération qu’une seule fois pour chaque instance.

**Note**  
Par défaut, les AMIs données fournies par ne AWS sont pas configurées avec un utilisateur basé sur un mot de passe. Si vous avez lancé votre instance à l’aide d’une AMI sur laquelle le mot de passe utilisateur racine est déjà configuré, vous pouvez ignorer ces instructions.

**Pour définir un mot de passe utilisateur de système d’exploitation sur une instance Linux**

1. [Connectez-vous](connect-to-linux-instance.md) à votre instance. Vous pouvez utiliser n’importe quelle méthode de connexion à votre instance, à l’exception de la méthode de connexion à l’EC2 Serial Console .

1. Pour définir le mot de passe d’un utilisateur, utilisez la commande **passwd**. Dans l’exemple suivant, l’utilisateur est `root`.

   ```
   [ec2-user ~]$ sudo passwd root
   ```

   Voici un exemple de sortie.

   ```
   Changing password for user root.
   New password:
   ```

1. À l’invite `New password`, entrez le nouveau mot de passe.

1. À l’invite, saisissez à nouveau le mot de passe.

# Connexion à l’EC2 Serial Console
<a name="connect-to-serial-console"></a>

Vous pouvez vous connecter à la console série de votre instance EC2 à l’aide de la console Amazon EC2 ou via SSH. Une fois connecté à la console série, vous pouvez l’utiliser pour résoudre les problèmes de démarrage, de configuration réseau et autres. Pour plus d’informations sur la résolution des problèmes, consultez [Résolvez les problèmes de votre instance Amazon EC2 à l’aide de EC2 Serial Console](troubleshoot-using-serial-console.md).

**Considérations**
+ Une seule connexion de console série active est prise en charge par instance.
+ La connexion à la console série dure généralement une heure, à moins que [vous ne vous déconnectiez](disconnect-serial-console-session.md). Toutefois, pendant la maintenance du système, Amazon EC2 déconnecte la session de console série.

  La durée de la connexion n’est pas déterminée par la durée de validité de vos informations d’identification IAM. Si vos informations d’identification IAM expirent, la connexion persiste jusqu’à ce que la durée maximale de la connexion à la console série soit atteinte. Lorsque vous utilisez l’expérience de console EC2 Serial Console, si vos informations d’identification IAM expirent, résiliez la connexion en fermant la page du navigateur.
+ 30 secondes sont nécessaires pour déconnecter une session après la déconnexion de la console série afin d’autoriser une nouvelle session.
+ Ports de console série pris en charge : `ttyS0` (instances Linux) et `COM1` (instances Windows)
+ Lorsque vous vous connectez à la console série, vous pouvez observer une légère baisse de débit de votre instance.

**Topics**
+ [Connexion à l’aide du client basé sur un navigateur](#sc-connect-browser-based-client)
+ [Connexion à l’aide de votre propre clé et d’un client SSH](#sc-connect-SSH)
+ [Points de terminaison et empreintes digitales de l’EC2 Serial Console](#sc-endpoints-and-fingerprints)

## Connexion à l’aide du client basé sur un navigateur
<a name="sc-connect-browser-based-client"></a>

Vous pouvez vous connecter à la console série de votre instance EC2 à l’aide du client basé sur le navigateur. Pour ce faire, sélectionnez l’instance sur la console Amazon EC2 et choisissez de vous connecter à la console série. Le client basé sur le navigateur gère les autorisations et fournit une connexion réussie.

l’EC2 Serial Console fonctionne à partir de la plupart des navigateurs et prend en charge les entrées au clavier et à la souris.

Avant d’établir la connexion, assurez-vous d’avoir réuni les [conditions préalables](ec2-serial-console-prerequisites.md).

**Pour vous connecter au port série de votre instance à l’aide du client basé sur le navigateur (console Amazon EC2)**

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 **Actions**, **Monitor and troubleshoot** (Surveiller et dépanner), **EC2 Serial Console**, **Connect** (Se connecter).

   Sinon, sélectionnez l’instance et choisissez **Connect** (Se connecter), **EC2 Serial Console**, **Connect** (Se connecter).

   Une fenêtre de terminal dans le navigateur s’ouvre.

1. Appuyez sur **Entrée**. Si une invite de connexion est retournée, vous êtes connecté à la console série.

   Si l’écran reste noir, vous pouvez utiliser les informations suivantes pour résoudre les problèmes de connexion à la console série :
   + **Vérifiez que vous avez configuré l’accès à la console série. ** Pour de plus amples informations, veuillez consulter [Configurer l’accès à l’EC2 Serial Console](configure-access-to-serial-console.md).
   + (Instances Linux uniquement) ** SysRq À utiliser pour se connecter à la console série.** SysRq ne nécessite pas que vous vous connectiez à l'aide du client basé sur un navigateur. Pour de plus amples informations, veuillez consulter [(Instances Linux) SysRq À utiliser pour dépanner votre instanceSysRq (Linux)](troubleshoot-using-serial-console.md#SysRq).
   + (Instances Linux uniquement) **Redémarrez getty.** Si vous disposez d’un accès SSH à votre instance, connectez-vous à cette dernière à l’aide de SSH et redémarrez getty à l’aide de la commande suivante.

     ```
     [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0
     ```
   + **Redémarrez votre instance.** Vous pouvez redémarrer votre instance en utilisant SysRq (instances Linux), la console EC2 ou le AWS CLI. Pour plus d’informations, consultez [(Instances Linux) SysRq À utiliser pour dépanner votre instanceSysRq (Linux)](troubleshoot-using-serial-console.md#SysRq) (instances Linux) ou [Redémarrez votre EC2 instance Amazon](ec2-instance-reboot.md).

1. À l’invite `login`, entrez le nom d’utilisateur de l’utilisateur avec un mot de passe que vous avez [configuré précédemment](configure-access-to-serial-console.md#set-user-password), puis appuyez sur **Entrée**.

1. À l’invite `Password`, entrez le mot de passe, puis appuyez sur **Entrée**.

## Connexion à l’aide de votre propre clé et d’un client SSH
<a name="sc-connect-SSH"></a>

Vous pouvez utiliser votre propre clé SSH et vous connecter à votre instance à partir du client SSH de votre choix en utilisant l’API de la console série. Vous bénéficiez ainsi de la capacité de la console série d’envoyer une clé publique en mode push à l’instance.

Après avoir appuyé sur la clé SSH sur l’instance, la connexion SSH n’est pas soumise aux politiques IAM que vous avez configurées pour accorder aux utilisateurs l’accès à l’EC2 Serial Console.

**Avant de commencer**  
Vérifiez que les [conditions préalables](ec2-serial-console-prerequisites.md) sont remplies.

**Pour vous connecter à la console série d’une instance à l’aide de SSH**

1. **Envoyez votre clé publique SSH en mode push à l’instance pour démarrer une session de console série**

   Utilisez la commande [send-serial-console-ssh-public-key](https://docs.aws.amazon.com/cli/latest/reference/ec2-instance-connect/send-serial-console-ssh-public-key.html) pour transmettre votre clé publique SSH à l'instance. Une session de console série démarre.

   Si une session de console série a déjà été démarrée pour cette instance, la commande échoue car vous ne pouvez avoir qu’une seule session ouverte à la fois. 30 secondes sont nécessaires pour déconnecter une session après la déconnexion de la console série afin d’autoriser une nouvelle session. 

   ```
   aws ec2-instance-connect send-serial-console-ssh-public-key \
       --instance-id i-001234a4bf70dec41EXAMPLE \
       --serial-port 0 \
       --ssh-public-key file://my_key.pub \
       --region us-east-1
   ```

1. 

**Connexion à la console série à l’aide de votre clé privée**

   Utilisez la commande **ssh** pour vous connecter à la console série avant que la clé publique ne soit supprimée du service de console série. Vous avez 60 secondes avant sa suppression.

   Utilisez la clé privée qui correspond à la clé publique.

   Le format du nom d’utilisateur est `instance-id.port0`. Il comprend l’ID d’instance et le port 0. Dans l’exemple suivant, le nom d’utilisateur est `i-001234a4bf70dec41EXAMPLE.port0`.

   Le point de terminaison du service Serial Console est différent pour chaque région. Consultez le tableau [Points de terminaison et empreintes digitales de l’EC2 Serial Console](#sc-endpoints-and-fingerprints) pour le point de terminaison de chaque région. Dans l’exemple suivant, le service de console série se trouve dans la région us-east-1.

   ```
   ssh -i my_key i-001234a4bf70dec41EXAMPLE.port0@serial-console.ec2-instance-connect.us-east-1.aws
   ```

   L’exemple suivant utilise `timeout 3600` pour configurer votre session SSH afin qu’elle se termine après une heure. Les processus démarrés pendant la session peuvent continuer à s’exécuter sur votre instance après la fin de la session.

   ```
   timeout 3600 ssh -i my_key i-001234a4bf70dec41EXAMPLE.port0@serial-console.ec2-instance-connect.us-east-1.aws
   ```

1. 

**(Facultatif) Vérification de l’empreinte digitale**

   Lorsque vous vous connectez pour la première fois à la console série, vous êtes invité à vérifier l’empreinte digitale. Vous pouvez comparer l’empreinte digitale de la console série avec l’empreinte digitale affichée pour vérification. Si ces empreintes ne correspondent pas, il se peut que quelqu'un tente une « man-in-the-middle » attaque. Si elles correspondent, vous pouvez vous connecter en toute confiance à la console série.

   L’empreinte digitale suivante concerne le service de console série dans la région us-east-1. Pour obtenir les empreintes digitales de chaque région, consultez [Points de terminaison et empreintes digitales de l’EC2 Serial Console](#sc-endpoints-and-fingerprints).

   ```
   SHA256:dXwn5ma/xadVMeBZGEru5l2gx+yI5LDiJaLUcz0FMmw
   ```

   L’empreinte digitale n’apparaît que la première fois que vous vous connectez à la console série.

1. Appuyez sur **Entrée**. Si une invite est retournée, vous êtes connecté à la console série.

   Si l’écran reste noir, vous pouvez utiliser les informations suivantes pour résoudre les problèmes de connexion à la console série :
   + **Vérifiez que vous avez configuré l’accès à la console série. ** Pour de plus amples informations, veuillez consulter [Configurer l’accès à l’EC2 Serial Console](configure-access-to-serial-console.md).
   + (Instances Linux uniquement) ** SysRq À utiliser pour se connecter à la console série.** SysRq ne nécessite pas de connexion via SSH. Pour de plus amples informations, veuillez consulter [(Instances Linux) SysRq À utiliser pour dépanner votre instanceSysRq (Linux)](troubleshoot-using-serial-console.md#SysRq).
   + (Instances Linux uniquement) **Redémarrez getty.** Si vous disposez d’un accès SSH à votre instance, connectez-vous à cette dernière à l’aide de SSH et redémarrez getty à l’aide de la commande suivante.

     ```
     [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0
     ```
   + **Redémarrez votre instance.** Vous pouvez redémarrer votre instance en utilisant SysRq (instances Linux uniquement), la console EC2 ou le AWS CLI. Pour plus d’informations, consultez [(Instances Linux) SysRq À utiliser pour dépanner votre instanceSysRq (Linux)](troubleshoot-using-serial-console.md#SysRq) (instances Linux uniquement) ou [Redémarrez votre EC2 instance Amazon](ec2-instance-reboot.md).

1. À l’invite `login`, entrez le nom d’utilisateur de l’utilisateur avec un mot de passe que vous avez [configuré précédemment](configure-access-to-serial-console.md#set-user-password), puis appuyez sur **Entrée**.

1. À l’invite `Password`, entrez le mot de passe, puis appuyez sur **Entrée**.

## Points de terminaison et empreintes digitales de l’EC2 Serial Console
<a name="sc-endpoints-and-fingerprints"></a>

Vous trouverez ci-dessous les points de terminaison de service et les empreintes digitales de l’EC2 Serial Console. Pour vous connecter par programmation à la Serial Console d’une instance, vous utilisez un point de terminaison EC2 Serial Console. Les points de terminaison EC2 Serial Console sont uniques pour chaque Région AWS .


| Nom de la région | Région | Endpoint | Empreinte | 
| --- | --- | --- | --- | 
| USA Est (Ohio) | us-east-2 | serial-console.ec2-instance-connect.us-east-2.aws | SHA256: EhwPkTzRt TY7 TRSzz26 RM7m CZN0xw xBB0/HVV9j/d/0 | 
| USA Est (Virginie du Nord) | us-east-1 | serial-console.ec2-instance-connect.us-east-1.aws | SHA256: VMe BZGEru5l2gx DXWN5mA/XAD\$1Yi5 Oui LDi LUcz0 FMmw | 
| USA Ouest (Californie du Nord) | us-west-1 | serial-console.ec2-instance-connect.us-west-1.aws | SHA256: OHldlc MET8u7 QLSX3jm RTRAPFHVtqbyo LZBMUCqi H3Y | 
| USA Ouest (Oregon) | us-west-2 | serial-console.ec2-instance-connect.us-west-2.aws | SHA256: EMCIe23 TqKa BI6y GHainq ZcMwqNkDhh AVHa1 O2Jx VUc | 
| Afrique (Le Cap) | af-south-1 | ec2-serial-console.af-south-1.api.aws | SHA256: RMWWZ2f VePe JUqzj KIg XsczoHlz O5JL2 21ED00biiWi | 
| Asie-Pacifique (Hong Kong) | ap-east-1 | ec2-serial-console.ap-east-1.api.aws | SHA256:T0Q1 AKJBP7Tkm2x C9b Ynick lpiXxCho ZHpln XVi JFsj | 
| Asie-Pacifique (Taipei) | ap-east-2 | ec2-serial-console.ap-east-2.api.aws | SHA256: DE8a QqsHwBr Z1RSF5/D40TR2 FWDQ GnyMqnSc CUa1z1e | 
| Asie-Pacifique (Hyderabad) | ap-south-2 | ec2-serial-console.ap-south-2.api.aws | SHA256: WJg PBSw V4/SHN\$1 15 OPITValoew AuYj DVW845 JEh DKRs | 
| Asie-Pacifique (Jakarta) | ap-southeast-3 | ec2-serial-console.ap-southeast-3.api.aws | SHA256:5 ZwgrCh XITq \$1lfns32 L/4O0ZiFBx4BZgS Encre YFqy3o8m | 
| Asie-Pacifique (Malaisie) | ap-southeast-5 | ec2-serial-console.ap-southeast-5.api.aws | SHA256c : QXTHQMRcq RdIjm AGo AMBSExeo RobYyRw T67 A yTjnEi | 
| Asie-Pacifique (Nouvelle Zélande) | ap-southeast-6 | ec2-serial-console.ap-southeast-6.api.aws | SHA256HJKjrw:wnltdh0gvfm5u \$1 CS\$1LLKv4 ElFuKoJgalc SKqj | 
| Asie-Pacifique (Melbourne) | ap-southeast-4 | ec2-serial-console.ap-southeast-4.api.aws | SHA256:Avaq 27 hFgLvjn g TSSh Z0oV7H90P0 OEt6 M GG46wf ZJv | 
| Asie-Pacifique (Mumbai) | ap-south-1 | serial-console.ec2-instance-connect.ap-south-1.aws | SHA256o : BLXc Ymkla EGH8ISO51rez BSu40 HHEbli ARx TPi SM35 | 
| Asie-Pacifique (Osaka) | ap-northeast-3 | ec2-serial-console.ap-northeast-3.api.aws | SHA256BKBnBuFnHr:AM0/JI 9AxSG G8TU/VVHFXE/3UCyJSQ EV3 | 
| Asie-Pacifique (Séoul) | ap-northeast-2 | serial-console.ec2-instance-connect.ap-northeast-2.aws | SHA256:FOQWXNX\$1DZ\$1\$1GU BX\$1FRC SRQRI NTztg9 PK49 WYMq ZM2d | 
| Asie-Pacifique (Singapour) | ap-southeast-1 | serial-console.ec2-instance-connect.ap-southeast-1.aws | SHA256: Wn PLFNn7 CQDHx3qmw Lu1Gy/O8 ZuAC6L45COY TUX7 LQg | 
| Asie-Pacifique (Sydney) | ap-southeast-2 | serial-console.ec2-instance-connect.ap-southeast-2.aws | SHA256: yFvMw UK9l EUQj QTRo XXzu VSe9 N\$1CW9/W984Cf5Tgzo4 | 
| Asie-Pacifique (Thaïlande) | ap-southeast-7 | ec2-serial-console.ap-southeast-7.api.aws | SHA256: KCAZi RYr vTwixWmvc R1q2LQSG7 2 wmj DY VT31 XRg SdEf | 
| Asie-Pacifique (Tokyo) | ap-northeast-1 | serial-console.ec2-instance-connect.ap-northeast-1.aws | SHA256: RQfs DCZTOf Qawew Em/ \$1 TRDV1t9 HMr FQe CRl IOT5um4k | 
| Canada (Centre) | ca-central-1 | serial-console.ec2-instance-connect.ca-central-1.aws | SHA256:P2O2J MWKPo6 eV2GCZ OZwmp YW738 FIOTHd UTy YMMO7s4 | 
| Canada-Ouest (Calgary) | ca-west-1 | ec2-serial-console.ca-west-1.api.aws | SHA256: S3RC8Li2XHBHR3IEDJ 6Q JNx GAFLPGOLjx7 IxxXrGckk | 
| Chine (Beijing) | cn-north-1 | ec2-serial-console---cn-north-1---api.amazonwebservices.com.rproxy.govskope.ca.cn | SHA2562 g : HVFy4 H7UU3\$1A D28V/LGGT\$1Y FUx ggMeqjvSlgngpg | 
| Chine (Ningxia) | cn-northwest-1 | ec2-serial-console---cn-northwest-1---api.amazonwebservices.com.rproxy.govskope.ca.cn | SHA256:Tdgr NZki QOd YEBUh Vf O4Sz M UA09 VWI5r YOZGTogpwmi | 
| Europe (Francfort) | eu-central-1 | serial-console.ec2-instance-connect.eu-central-1.aws | SHA256: yIcOd OlkXvOl ACMFS/ 8AMZ1toE\$1BBNr Fy0K0DE2C JJ3 | 
| Europe (Irlande) | eu-west-1 | serial-console.ec2-instance-connect.eu-west-1.aws | SHA256:H2AA HathHTM6EZS3BJ7UDGUXI2 E GAWO4 qTrHj ZAw CW6 | 
| Europe (Londres) | eu-west-2 | serial-console.ec2-instance-connect.eu-west-2.aws | SHA256:a69rd5 3t 8 CE/AEG4Amm53I6lkD1ZPvS/BCV TPW2 RnJg | 
| Europe (Milan) | eu-south-1 | ec2-serial-console.eu-south-1.api.aws | SHA256:LC0K OVJnpg Fy A7N99eCLB S7X7 BVrxn0 XSX95cuu QK30 | 
| Europe (Paris) | eu-west-3 | serial-console.ec2-instance-connect.eu-west-3.aws | SHA256:q8ldnaf9pymene8bn Y3/kxsw FVng RPAr JUzfrlxe EWs | 
| Europe (Espagne) | eu-south-2 | ec2-serial-console.eu-south-2.api.aws | SHA256:Go CW2 DFRlu669 QNxq FxEcs ZUz R6f/4F4N7T45 ZcwoEc | 
| Europe (Stockholm) | eu-north-1 | serial-console.ec2-instance-connect.eu-north-1.aws | SHA256:tk GFFUVUDvoc Di GSS3 EPNp KFKLw Cu8GDL6W2UI32 X84 | 
| Europe (Zurich) | eu-central-2 | ec2-serial-console.eu-central-2.api.aws | SHA256: 8 PPx BMf6 WdCw 2 m 0 kFW/m4/4 Oa NUlz IfRz XFut QXWp6mk | 
| Israël (Tel Aviv) | il-central-1 | ec2-serial-console.il-central-1.api.aws | SHA256JR6q8v6kNNPi8\$1 QSFQ4dj5dim M ZPTgwgs M1 SNvt Yu | 
| Mexique (Centre) | mx-central-1 | ec2-serial-console.mx-central-1.api.aws | SHA256: BCu QNk VL13i\$1 CcVnt 18EF4P2 FetB32 ZHUr BBAOxl GS0 | 
| Moyen-Orient (Bahreïn) | me-south-1 | ec2-serial-console.me-south-1.api.aws | SHA256: NPJ LLKHu2 QnLdUq VArso 2k K5V C3K8 PJOMRJKCBz CDq | 
| Moyen-Orient (EAU) | me-central-1 | ec2-serial-console.me-central-1.api.aws | SHA256:ZPB5DUKIbZ\$1L0 B4 dFwPeyyk I/XZ LE MPBYh XNe FSDKBv | 
| Amérique du Sud (São Paulo) | sa-east-1 | serial-console.ec2-instance-connect.sa-east-1.aws | SHA256:RD2\$1/32OGNJeW1Y QZC\$1botBiH62OQ I VIem ENa APDq1d | 
| AWS GovCloud (USA Est) | us-gov-east-1 | serial-console.ec2-instance-connect. us-gov-east-1. amazonaws.com | SHA256: TiWe19 \$1 F28 GWsoy LClrtvu38 YEEh DHIkqn DcZnmtebv | 
| AWS GovCloud (US-Ouest) | us-gov-west-1 | serial-console.ec2-instance-connect. us-gov-west-1. amazonaws.com | SHA256:kf OFRWLa OZf OlPf B\$1UTBd3BRF8 8n iW5dQ GO2 YZLq XZi | 

# Déconnexion de l’EC2 Serial Console
<a name="disconnect-serial-console-session"></a>

Si vous n’avez plus besoin d’être connecté à l’EC2 Serial Console de votre instance, vous pouvez vous en déconnecter. Lorsque vous vous déconnectez de la console série, toutes les sessions shell en cours d’exécution sur l’instance continuent de s’exécuter. Si vous souhaitez mettre fin à la session du shell, vous devez y mettre fin avant de vous déconnecter de la console série.

**Considérations**
+ La connexion à la console série dure généralement une heure, à moins que vous ne vous déconnectiez. Toutefois, pendant la maintenance du système, Amazon EC2 déconnecte la session de console série.
+ 30 secondes sont nécessaires pour déconnecter une session après la déconnexion de la console série afin d’autoriser une nouvelle session.

La méthode de déconnexion de la console série dépend du client.

**Client basé sur le navigateur**  
Pour vous déconnecter de la console série, fermez la fenêtre du terminal du navigateur de la console.

**Client OpenSSH standard**  
Pour vous déconnecter de la console série, utilisez la commande suivante pour fermer la connexion SSH. Cette commande doit être exécutée immédiatement après une nouvelle ligne.

```
~.
```

La commande permettant d’interrompre une connexion SSH peut être différente selon le client SSH que vous utilisez.

# Résolvez les problèmes de votre instance Amazon EC2 à l’aide de EC2 Serial Console
<a name="troubleshoot-using-serial-console"></a>

À l’aide de l’EC2 Serial Console , vous pouvez résoudre les problèmes de démarrage, de configuration réseau et autres en vous connectant au port série de votre instance.

Utilisez les instructions fournies pour le système d’exploitation de votre instance et pour l’outil que vous avez configuré sur votre instance.

**Topics**
+ [GRUB (Linux)](#grub)
+ [SysRq (Linux)](#SysRq)
+ [SAC (Windows)](#troubleshooting-sac)

**Conditions préalables**  
Avant de commencer, assurez-vous que vous avez réuni les [conditions préalables](ec2-serial-console-prerequisites.md), y compris la configuration de l’outil de résolution des problèmes de votre choix.

## (Instances Linux) Utilisez GRUB pour dépanner votre instance
<a name="grub"></a>

GNU GRUB (abréviation de GNU GRand Unified Bootloader, communément appelé GRUB) est le chargeur de démarrage par défaut pour la plupart des systèmes d'exploitation Linux. Dans le menu GRUB, vous pouvez sélectionner le noyau dans lequel démarrer ou modifier les entrées du menu pour modifier le mode de démarrage du noyau. Cela peut être utile lors de la résolution des problèmes d’une instance défaillante.

Le menu GRUB s’affiche pendant le processus de démarrage. Le menu n’est pas accessible via le SSH normal, mais vous pouvez y accéder via l’EC2 Serial Console.

Vous pouvez démarrer en mode utilisateur unique ou en mode utilisateur unique. Le mode utilisateur unique démarre le noyau à un niveau d’exécution inférieur. Par exemple, il peut monter le système de fichiers mais pas activer le réseau, ce qui vous permet d’effectuer la maintenance nécessaire pour réparer l’instance. Le mode d’urgence est similaire au mode utilisateur unique, sauf que le noyau fonctionne au niveau d’exécution le plus bas possible.

**Pour démarrer en mode utilisateur unique**

1. [Connectez-vous](connect-to-serial-console.md) à la console série de l’instance.

1. Redémarrez l’instance à l’aide de la commande suivante.

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

1. Pendant le redémarrage, lorsque le menu GRUB apparaît, appuyez sur n’importe quelle touche pour arrêter le processus de démarrage.

1. Dans le menu GRUB, utilisez les touches fléchées pour sélectionner le noyau de démarrage et appuyez sur `e` sur votre clavier. 

1. Utilisez les touches fléchées pour localiser votre curseur sur la ligne contenant le noyau. La ligne commence par `linux` ou `linux16` en fonction de l’AMI utilisée pour lancer l’instance. Pour Ubuntu, deux lignes commençant par `linux` doivent toutes deux être modifiées à l’étape suivante.

1. À la fin de la ligne, ajoutez le mot `single`.

   Voici un exemple pour Amazon Linux 2.

   ```
   linux /boot/vmlinuz-4.14.193-149.317.amzn2.aarch64 root=UUID=d33f9c9a-\
   dadd-4499-938d-ebbf42c3e499 ro  console=tty0 console=ttyS0,115200n8 net.ifname\
   s=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.she\
   ll=0 single
   ```

1. Appuyez sur **Ctrl\$1X** pour démarrer en mode utilisateur unique.

1. À l’invite `login`, entrez le nom d’utilisateur de l’utilisateur avec un mot de passe que vous avez [configuré précédemment](configure-access-to-serial-console.md#set-user-password), puis appuyez sur **Entrée**.

1. À l’invite `Password`, entrez le mot de passe, puis appuyez sur **Entrée**.

 

**Pour démarrer en mode d’urgence**  
Suivez les mêmes étapes que le mode utilisateur unique, mais à l’étape 6, ajoutez le mot `emergency` au lieu de `single`.

## (Instances Linux) SysRq À utiliser pour dépanner votre instance
<a name="SysRq"></a>

La touche System Request (SysRq), parfois qualifiée de SysRq « magique », peut être utilisée pour envoyer directement une commande au noyau, en dehors d'un shell, et le noyau répondra, indépendamment de ce que fait le noyau. Par exemple, si l'instance ne répond plus, vous pouvez utiliser la SysRq clé pour indiquer au noyau de se bloquer ou de redémarrer. Pour plus d'informations, voir [Magic SysRq key](https://en.wikipedia.org/wiki/Magic_SysRq_key) sur Wikipedia.

Vous pouvez utiliser des SysRq commandes dans le client basé sur le navigateur de la console série EC2 ou dans un client SSH. La commande d’envoi d’une requête d’interruption est différente pour chaque client.

Pour l'utiliser SysRq, choisissez l'une des procédures suivantes en fonction du client que vous utilisez.

------
#### [ Browser-based client ]

**À utiliser SysRq dans le client basé sur un navigateur de console série**

1. [Connectez-vous](connect-to-serial-console.md) à la console série de l’instance.

1. Pour envoyer une demande d’interruption, appuyez sur `CTRL+0` (zéro). Si votre clavier prend cette fonctionnalité en charge, vous pouvez également envoyer une demande d’interruption à l’aide de la touche Pause ou Attn.

   ```
   [ec2-user ~]$ CTRL+0
   ```

1. Pour émettre une SysRq commande, appuyez sur la touche de votre clavier correspondant à la commande requise. Par exemple, pour afficher une liste de SysRq commandes, appuyez sur`h`.

   ```
   [ec2-user ~]$ h
   ```

   Le résultat de la commande `h` est similaire à ce qui suit.

   ```
   [ 1169.389495] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems
   (j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r
   ) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z)
   ```

------
#### [ SSH client ]

**À utiliser SysRq dans un client SSH**

1. [Connectez-vous](connect-to-serial-console.md) à la console série de l’instance.

1. Pour envoyer une demande d’interruption, appuyez sur `~B` (tilde, suivi de `B` majuscule).

   ```
   [ec2-user ~]$ ~B
   ```

1. Pour émettre une SysRq commande, appuyez sur la touche de votre clavier correspondant à la commande requise. Par exemple, pour afficher une liste de SysRq commandes, appuyez sur`h`.

   ```
   [ec2-user ~]$ h
   ```

   Le résultat de la commande `h` est similaire à ce qui suit.

   ```
   [ 1169.389495] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems
   (j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r
   ) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z)
   ```
**Note**  
La commande permettant d’envoyer une requête d’interruption peut être différente selon le client SSH que vous utilisez.

------

## (Instances Windows) Utilisez SAC pour dépanner votre instance
<a name="troubleshooting-sac"></a>

La console d’administration spéciale (SAC) de Windows permet de résoudre les problèmes d’une instance Windows. En vous connectant à la console série de l’instance et en utilisant SAC, vous pouvez interrompre le processus de démarrage et démarrer Windows en mode sans échec.

**Note**  
Si vous activez SAC sur une instance, les services EC2 qui reposent sur la récupération de mot de passe ne fonctionnent pas à partir de la console Amazon EC2. Les agents de lancement Windows on Amazon EC2 (EC2Config, EC2Launch v1 et EC2Launch v2) s’appuient sur la console série pour exécuter diverses tâches. Ces tâches ne s’exécutent pas correctement lorsque vous activez SAC sur une instance. Pour plus d’informations sur les agents de lancement Windows sur Amazon EC2, consultez [Configurez votre instance Amazon EC2 Windows](ec2-windows-instances.md). Si vous activez SAC, vous pouvez le désactiver ultérieurement. Pour de plus amples informations, veuillez consulter [Désactiver SAC et le menu de démarrage](#disable-sac-bootmenu).

**Topics**
+ [Utiliser SAC](#use-sac)
+ [Utiliser le menu de démarrage](#use-boot-menu)
+ [Désactiver SAC et le menu de démarrage](#disable-sac-bootmenu)

### Utiliser SAC
<a name="use-sac"></a>

**Pour utiliser SAC**

1. [Connectez-vous à la console série](connect-to-serial-console.md)

   Si SAC est activée sur l’instance, la console série affiche l’invite `SAC>`.  
![\[L’invite SAC s’affiche sur la console série.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-3.png)

1. Pour afficher les commandes SAC, saisissez « ? », puis appuyez **Entrée**.

   Sortie attendue  
![\[Entrez un point d’interrogation pour afficher les commandes SAC.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-4.png)

1. Pour créer un canal d’invite de commande (tel que `cmd0001` ou `cmd0002`), saisissez « cmd », puis appuyez sur **Entrée**.

1. Pour afficher le canal d’invite de commande, appuyez sur **ÉCHAP**, puis appuyez sur **TAB**.

   Sortie attendue  
![\[Le canal d’invite de commande.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-5.png)

1. Pour changer de canal, appuyez simultanément sur **ÉCHAP \$1 TAB \$1 numéro de canal**. Par exemple, pour basculer vers le canal `cmd0002` (s’il a été créé), appuyez sur **ÉCHAP\$1Tab\$12**.

1. Entrez les informations d’identification requises par le canal d’invite de commandes.  
![\[L’invite de commandes nécessite des informations d’identification.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-6.png)

   L’invite de commande correspond au shell de commande complet que vous obtenez sur un bureau, mais ne permet toutefois pas la lecture des caractères déjà envoyés.  
![\[Un shell de commande complet.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-7.png)

**PowerShell peut également être utilisé à partir de l'invite de commande.**

Notez que vous devrez peut-être définir la préférence de progression en mode silencieux.

![\[PowerShell dans l'invite de commande.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-8.png)


### Utiliser le menu de démarrage
<a name="use-boot-menu"></a>

Si le menu de démarrage de l’instance est activé et qu’il est redémarré après la connexion via SSH, vous devriez voir le menu de démarrage, comme suit.

![\[Menu de démarrage dans l’invite de commande.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-1.png)


**Commandes du menu de démarrage**

ENTRÉE  
Démarre l’entrée sélectionnée du système d’exploitation.

TAB  
Bascule vers le menu Outils.

ESC  
Annule et redémarre l’instance.

ESC suivi de 8  
Revient à appuyer sur **F8**. Affiche les options avancées de l’élément sélectionné.

Touche Esc \$1 flèche gauche  
Retourne au menu de démarrage initial.  
La touche Esc seule ne vous ramène pas au menu principal car Windows attend de voir si une séquence d’échappement est en cours.

![\[Options de démarrage avancées.\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/images/win-boot-2.png)


### Désactiver SAC et le menu de démarrage
<a name="disable-sac-bootmenu"></a>

Si vous activez SAC et le menu de démarrage, vous pouvez désactiver ces fonctions ultérieurement.

Utilisez l’une des méthodes suivantes pour désactiver SAC et le menu de démarrage sur une instance.

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

**Pour désactiver SAC et le menu de démarrage sur une instance Windows**

1. [Connectez-vous](connecting_to_windows_instance.md) à votre instance et effectuez les étapes suivantes à partir d'une ligne de PowerShell commande élevée.

1. Désactivez d’abord le menu de démarrage en changeant la valeur en `no`.

   ```
   bcdedit /set '{bootmgr}' displaybootmenu no
   ```

1. Ensuite, désactivez SAC en changeant la valeur en `off`.

   ```
   bcdedit /ems '{current}' off
   ```

1. Appliquez la configuration mise à jour en redémarrant l’instance.

   ```
   shutdown -r -t 0
   ```

------
#### [ Command prompt ]

**Pour désactiver SAC et le menu de démarrage sur une instance Windows**

1. [Connectez-vous](connecting_to_windows_instance.md) à votre instance et exécutez les étapes suivantes à partir de l’invite de commandes.

1. Désactivez d’abord le menu de démarrage en changeant la valeur en `no`.

   ```
   bcdedit /set {bootmgr} displaybootmenu no
   ```

1. Ensuite, désactivez SAC en changeant la valeur en `off`.

   ```
   bcdedit /ems {current} off
   ```

1. Appliquez la configuration mise à jour en redémarrant l’instance.

   ```
   shutdown -r -t 0
   ```

------

# Envoyez une interruption de diagnostic pour débuguer une instance Amazon EC2 inaccessible
<a name="diagnostic-interrupt"></a>

**Avertissement**  
Les interruptions de diagnostic sont destinées à être utilisées par les utilisateurs avancés. Une utilisation incorrecte pourrait avoir un impact négatif sur votre instance. L’envoi d’une interruption de diagnostic à une instance peut déclencher un plantage et un redémarrage d’une instance, ce qui peut entraîner la perte de données.

Vous pouvez envoyer une interruption de diagnostic à une instance inaccessible ou qui ne répond pas pour déclencher manuellement une *panique du noyau* pour une instance Linux, ou une *erreur d'arrêt* (communément appelée *erreur d'écran bleu*) pour une instance Windows.

**Instances Linux**  
Les systèmes d’exploitation Linux tombent généralement en panne et redémarrent en cas de panique de noyau. Le comportement spécifique du système d’exploitation dépend de sa configuration. Vous pouvez aussi utiliser une panique de noyau pour que le noyau système du système d’exploitation de l’instance effectue des tâches telles que la génération d’un fichier de vidage sur incident. Vous pouvez alors utiliser les informations du fichier de vidage sur incident pour effectuer l’analyse de la cause de la panne et le débogage de l’instance. Les données de vidage sur incident sont générées localement par le système d’exploitation sur l’instance elle-même.

**instances Windows**  
En général, les systèmes d’exploitation Windows tombent en panne et redémarrent en cas d’erreur d’arrêt, mais le comportement du système dépend de sa configuration. Une erreur d’arrêt peut également provoquer l’écriture d’informations de débogage dans un fichier par le système d’exploitation (par exemple, vidage mémoire du noyau). Vous pouvez ensuite utiliser ces informations pour effectuer une analyse de la cause racine et déboguer l’instance. Les données de vidage mémoire sont générées localement par le système d’exploitation sur l’instance elle-même.

Avant d’envoyer une interruption de diagnostic à votre instance, nous vous recommandons de consulter la documentation de votre système d’exploitation, puis d’apporter les modifications nécessaires à la configuration.

**Topics**
+ [Types d’instance pris en charge](#diagnostic-interrupt-instances)
+ [Conditions préalables](#diagnostic-interrupt-prereqs)
+ [Envoi d’une interruption de diagnostic](#diagnostic-interrupt-use)

## Types d’instance pris en charge
<a name="diagnostic-interrupt-instances"></a>

L'interruption diagnostique est prise en charge sur tous les types d'instances basées sur Nitro, à l'exception de celles alimentées par des processeurs AWS Graviton. Pour plus d'informations, consultez [les instances basées sur le système AWS Nitro](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) et [AWS Graviton](https://aws.amazon.com/ec2/graviton/).

## Conditions préalables
<a name="diagnostic-interrupt-prereqs"></a>

Avant d’utiliser une interruption de diagnostic, vous devez configurer le système d’exploitation de votre instance. Cela garantit qu'elle effectue les actions dont vous avez besoin lorsqu'une panique du noyau (instances Linux) ou une erreur d'arrêt (instances Windows) se produit.

### Instances Linux
<a name="diagnostic-interrupt-prereqs-linux"></a>

**Pour configurer Amazon Linux 2 ou Amazon Linux 2023 afin qu'il génère un fichier de vidage en cas de panique du noyau**

1. Connectez-vous à votre instance.

1. Installez **kexec** et **kdump**.

   ```
   [ec2-user ~]$ sudo yum install kexec-tools -y
   ```

1. Configurez le noyau afin qu’il réserve une quantité appropriée de mémoire pour le noyau secondaire. La quantité de mémoire à réserver dépend de la quantité de mémoire totale disponible de votre instance. Ouvrez le fichier `/etc/default/grub` à l’aide de votre éditeur de texte préféré, localisez la ligne commençant par `GRUB_CMDLINE_LINUX_DEFAULT`, puis ajoutez le paramètre `crashkernel` au format suivant : `crashkernel=memory_to_reserve`. Par exemple, pour réserver `256MB`, modifiez le fichier `grub` comme suit :

   ```
   GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=256M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
   GRUB_TIMEOUT=0
   GRUB_DISABLE_RECOVERY="true"
   ```

1. Enregistrez les modifications, puis fermez le fichier `grub`.

1. Reconstruisez le fichier GRUB2 de configuration.

   ```
   [ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   ```

1. Sur les instances basées sur les processeurs Intel et AMD, la commande `send-diagnostic-interrupt` envoie une *interruption non masquable (NMI) inconnue* à l’instance. Vous devez configurer le noyau pour tomber en panne lorsqu’il reçoit l’interruption NMI inconnue. Ouvrez le fichier `/etc/sysctl.conf` à l’aide de l’éditeur de texte de votre choix et ajoutez ce qui suit.

   ```
   kernel.unknown_nmi_panic=1
   ```

1. Redémarrez votre instance et reconnectez-la.

1. Vérifiez que le noyau a été démarré avec le paramètre `crashkernel` correct.

   ```
   $ grep crashkernel /proc/cmdline
   ```

   L’exemple de sortie suivant illustre une configuration réussie.

   ```
   BOOT_IMAGE=/boot/vmlinuz-4.14.128-112.105.amzn2.x86_64 root=UUID=a1e1011e-e38f-408e-878b-fed395b47ad6 ro crashkernel=256M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0
   ```

1. Vérifiez que le service **kdump** est en cours d’exécution.

   ```
   [ec2-user ~]$ systemctl status kdump.service
   ```

   L’exemple de sortie suivant présente le résultat lorsque le service **kdump** est en cours d’exécution.

   ```
   kdump.service - Crash recovery kernel arming
      Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
      Active: active (exited) since Fri 2019-05-24 23:29:13 UTC; 22s ago
     Process: 2503 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
    Main PID: 2503 (code=exited, status=0/SUCCESS)
   ```

**Note**  
Par défaut, le fichier de vidage sur incident est enregistré dans `/var/crash/`. Pour modifier cet emplacement, modifiez le fichier `/etc/kdump.conf` à l’aide de l’éditeur de texte de votre choix.

**Pour configurer SUSE Linux Enterprise, Ubuntu ou Red Hat Enterprise Linux**  
Sur les instances basées sur les processeurs Intel et AMD, la commande `send-diagnostic-interrupt` envoie une *interruption non masquable (NMI) inconnue* à l’instance. Vous devez configurer le noyau de manière à ce qu'il se ferme lorsqu'il reçoit une NMI inconnue en ajustant le fichier de configuration de votre système d'exploitation. Pour savoir comment configurer le noyau pour qu'il se ferme, consultez la documentation de votre système d'exploitation :
+ [SUSE Linux Enterprise](https://www.suse.com/support/kb/doc/?id=3374462)
+ [Ubuntu](https://ubuntu.com/server/docs/kernel-crash-dump)
+ [Red Hat Enterprise Linux (RHEL) ](https://access.redhat.com/solutions/6038)

### instances Windows
<a name="diagnostic-interrupt-prereqs-windows"></a>

**Pour configurer Windows afin qu’il génère un vidage mémoire en d’erreur d’arrêt**

1. Connectez-vous à votre instance.

1. Ouvrez le **Panneau de configuration**, choisissez **Système**, **Paramètres système avancés**.

1. Dans la boîte de dialogue **Propriétés**, choisissez l’onglet **Paramètres système avancés**.

1. Dans la section **Démarrage et récupération**, choisissez **Paramètres...**.

1. Dans la section **System failure (Échec système)**, configurez les paramètres comme vous le souhaitez, puis choisissez **OK**.

Pour plus d’informations sur la configuration des erreurs d’arrêt de Windows, veuillez consulter [Overview of memory dump file options for Windows](https://support.microsoft.com/en-us/help/254649/overview-of-memory-dump-file-options-for-windows).

## Envoi d’une interruption de diagnostic
<a name="diagnostic-interrupt-use"></a>

Une fois que vous avez effectué les modifications de configuration nécessaires, vous pouvez envoyer une interruption de diagnostic à votre instance à l'aide de l'API Amazon EC2 AWS CLI ou Amazon EC2.

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

**Pour envoyer une interruption de diagnostic à votre instance**  
Utilisez la commande [send-diagnostic-interrupt](https://docs.aws.amazon.com/cli/latest/reference/ec2/send-diagnostic-interrupt.html).

```
aws ec2 send-diagnostic-interrupt --instance-id i-1234567890abcdef0
```

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

**Pour envoyer une interruption de diagnostic à votre instance**  
Utilisez l’applet de commande [Send-EC2DiagnosticInterrupt](https://docs.aws.amazon.com/powershell/latest/reference/items/Send-EC2DiagnosticInterrupt.html).

```
Send-EC2DiagnosticInterrupt -InstanceId i-1234567890abcdef0
```

------