Pourquoi ne puis-je pas démarrer l'agent SSM sur mon instance Windows Amazon EC2 ?

Résolution

Remarque : Pour déterminer si une instance répond aux exigences requises pour un nœud géré, il est recommandé d'utiliser la version ssm-cli 3.1.501.0. Pour plus d'informations, consultez la sectionRésolution des problèmes liés à la disponibilité des nœuds gérés à l'aide de ssm-cli.

Les raisons suivantes expliquent pourquoi l'agent SSM peut ne pas démarrer votre instance Windows.

Le rôle IAM ne dispose pas des autorisations nécessaires

Vous devez disposer des autorisations appropriées pour effectuer des appels d'API vers un point de terminaison Systems Manager. Associez la politique d'autorisations AmazonSSMManagedInstanceCore au rôle AWS Identity and Access Management (IAM) associé à votre instance. Si vous utilisez une politique IAM personnalisée, vérifiez que celle-ci utilise les autorisations disponibles dans AmazonSSMManagedInstanceCore. Assurez-vous également que la stratégie d’approbation de votre rôle IAM autorise ec2.amazonaws.com à endosser ce rôle. Pour plus d’informations, consultez la section Étape 1 : Configurer les autorisations d'instance pour Systems Manager.

**L'agent SSM ne peut pas accéder aux métadonnées de l'instance **

L'agent SSM doit communiquer avec le service de métadonnées de l'instance pour obtenir les informations nécessaires sur l'instance. Pour accéder aux métadonnées de votre instance, utilisez le navigateur de l'instance en cours d'exécution.

Si vous ne pouvez pas accéder aux métadonnées, exécutez la commande route print depuis Windows PowerShell ou CMD. Examinez la sortie pour vérifier s'il existe un itinéraire similaire aux itinéraires suivants :

Persistent Routes:   

Network Address     Netmask             Gateway Address     Metric  
169.254.169.254     255.255.255.255     172.31.16.1         15  
169.254.169.250     255.255.255.255     172.31.16.1         15  
169.254.169.251     255.255.255.255     172.31.16.1         15  
169.254.169.249     255.255.255.255     172.31.16.1         15  
169.254.169.123     255.255.255.255     172.31.16.1         15  
169.254.169.253     255.255.255.255     172.31.16.1         15

Si l’itinéraire est absent ou si l'adresse de la passerelle ne correspond pas au sous-réseau actuel, effectuez l'une des étapes suivantes :

• Ajoutez manuellement l'itinéraire :

  route add -p 169.254.169.254 mask 255.255.255.255 x.x.x.x

  Remarque : Remplacez x.x.x.x par l’adresse de passerelle de votre instance.

• Si l'instance dispose de la version 1 d'EC2Launch, exécutez la commande suivante à partir d'une session Windows PowerShell avec un niveau élevé :

  import-Module c:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1 ; Add-Routes

• Si l'instance possède EC2Launch version 2 ou EC2Config, redémarrez les services. Cela définit les itinéraires statiques non persistants pour atteindre le service de métadonnées et les serveurs AWS KMS.

  Si l’itinéraire existe mais que l'instance ne peut pas récupérer les métadonnées, vérifiez la configuration du pare-feu Windows Defender, du pare-feu tiers ou de l'antivirus de votre instance. Vérifiez que le trafic vers 169.254.169.254 n’est pas explicitement refusé. Pour plus d’informations, reportez-vous à la section Pourquoi mon instance Amazon EC2 Windows génère-t-elle une erreur « En attente du service de métadonnées » ?

L'instance n'est pas connectée au point de terminaison SSM

Vérifiez que l'instance est connectée aux points de terminaison de Systems Manager sur le port 443. Exécutez les commandes Windows PowerShell suivantes pour vérifier la connectivité. Remplacez RegionID par la région AWS dans laquelle se trouve l'instance :

• Test-NetConnection ssm.RegionID.amazonaws.com -port 443
• Test-NetConnection ec2messages.RegionID.amazonaws.com -port 443
• Test-NetConnection ssmmessages.RegionID.amazonaws.com -port 443

Sous-réseaux publics

Les points de terminaison Systems Manager sont des points de terminaison publics. Cela signifie que votre instance doit utiliser une passerelle Internet pour accéder à Internet. Si vous rencontrez des problèmes lorsque vous vous connectez aux terminaux à partir d'instances d'un sous-réseau public, confirmez les configurations suivantes :

• La table de routage utilisée par votre instance doit contenir un itinéraire vers Internet.
• Vos groupes de sécurité Amazon Virtual Private Cloud (Amazon VPC) et vos listes de contrôle d’accès réseau (ACL réseau) autorisent les connexions sortantes sur le port 443.

Sous-réseaux privés

Pour les sous-réseaux privés, votre instance doit utiliser une passerelle NAT pour accéder à Internet. Vous pouvez également configurer les points de terminaison Amazon VPC pour atteindre les points de terminaison Systems Manager. Cela vous permet d'utiliser des adresses IP privées pour accéder aux API Amazon EC2 et Systems Manager. Pour en savoir plus, consultez la section Pourquoi mon instance EC2 ne s'affiche-t-elle pas en tant que nœud géré ou affiche-t-elle l'état « Connexion perdue » dans Systems Manager ?

Les paramètres de proxy ne sont pas appliqués

Si vous utilisez des proxys, les paramètres du proxy sont évalués et appliqués à la configuration de l'agent lorsque vous démarrez l'agent SSM. Pour plus d'informations, consultez la section Configurer l'agent SSM pour utiliser un proxy pour les instances Windows Server.

L'agent SSM n'est pas la dernière version

Il est recommandé de télécharger et d'installer manuellement la dernière version de l'agent SSM. Pour consulter les informations relatives aux dernières versions de l'agent SSM, consultez les versions de l'agent Amazon SSM sur le site Web de GitHub.

Si l'instance ne démarre pas l'agent SSM après avoir effectué les étapes précédentes, consultez les journaux de l'agent SSM pour poursuivre le dépannage.