Aller au contenu

AWS Mis à jour le 2026-10-06

EC2 Instance Connect vs Session Manager vs SSH classique : choisir un modèle d'accès

Comparez Session Manager d'AWS Systems Manager, EC2 Instance Connect et les clés SSH classiques pour accéder à vos serveurs EC2. Voyez ce que chacun exige, ce qu'il journalise et lequel adopter par défaut en production.

Pour la plupart des parcs EC2 de production, choisissez Session Manager, la fonction d’AWS Systems Manager qui ouvre un terminal depuis le navigateur ou la CLI sans port 22. L’accès passe par IAM, le service de permissions d’AWS, donc aucune clé SSH à gérer et chaque session peut être journalisée. EC2 Instance Connect convient au cas plus étroit où il vous faut vraiment SSH, car il pousse une clé temporaire qui expire après 60 secondes. Le SSH classique reste valable là où un outil patrimonial l’exige, ou si votre équipe utilise déjà des certificats SSH de courte durée sur site et dans d’autres nuages. Le choix compte surtout plus tard, quand il faut prouver qui s’est connecté, à quel serveur, et ce qu’il a fait.

Ce que vous décidez

Trois modèles d’accès, trois mécanismes de confiance :

  • SSH classique : une paire de clés créée au lancement (ou distribuée à la main), le port 22 ouvert vers quelque chose, authorized_keys comme source de vérité. Le contrôle d’accès vit sur chaque boîte; la révocation implique de toucher chaque boîte; l’audit est ce que l’hôte journalise et que personne n’expédie. Ça marche partout, y compris hors AWS, ce qui est à la fois sa vertu et la raison pour laquelle ça traîne.
  • EC2 Instance Connect (EIC) : toujours du SSH sur le fil, mais les clés deviennent éphémères — aws ec2-instance-connect send-ssh-public-key pousse une clé publique valide 60 secondes, autorisée par IAM. L’instance a besoin de l’agent EIC (préinstallé sur les AMI Amazon Linux et Ubuntu) et d’un port 22 joignable. La variante EC2 Instance Connect Endpoint enlève l’exigence d’IP publique : elle donne un tunnel TCP vers les sous-réseaux privés sans bastion, toujours contrôlé par IAM.
  • SSM Session Manager : pas du SSH du tout. L’agent SSM sur l’instance ouvre une connexion sortante vers le service Systems Manager; les sessions passent par ce canal. Aucun port entrant, aucune clé, aucun bastion, ça fonctionne dans les sous-réseaux privés (via NAT ou points d’accès VPC), les politiques IAM décident qui atteint quelles instances (même par balise), et les sessions peuvent être journalisées frappe par frappe vers CloudWatch Logs ou S3. La redirection de ports et un mode SSH-par-SSM couvrent la plupart des objections « mais j’ai besoin de scp ». Les détails vivent dans la documentation Systems Manager.

La différence opérationnelle apparaît au départ d’un employé et à l’heure de l’audit. Avec des clés SSH, l’accès d’un ingénieur qui part meurt quand quelqu’un modifie chaque authorized_keys (donc, des semaines plus tard, peut-être). Avec SSM ou EIC, il meurt avec son identité IAM dans l’heure. Et quand un questionnaire de sécurité demande « qui a accédé à la production le 3 juin », Session Manager a une réponse; des fichiers auth.log éparpillés, généralement pas.

Quoi vérifier en premier

  • L’agent SSM roule-t-il déjà sur tout le parc? Il est livré avec Amazon Linux, Ubuntu et la plupart des AMI modernes — la moitié de la migration est peut-être déjà faite.
  • Les instances ont-elles un profil d’instance avec AmazonSSMManagedInstanceCore? Ça, plus du 443 sortant, c’est toute l’exigence côté serveur.
  • Qu’est-ce qui a le port 22 ouvert, et vers où? 0.0.0.0/0 sur le 22 est le constat qui fixe l’urgence.
  • Où vivent les clés privées SSH aujourd’hui? Portables, coffres partagés, systèmes CI — l’étalement que vous vous apprêtez à retirer.
  • Des flux de travail qui exigent vraiment la sémantique SSH — jobs rsync, scripts de déploiement patrimoniaux, développeurs avec de fortes opinions tmux — qui ont besoin d’un plan de transition plutôt que d’un décret.

Comment vérifier

Quelles instances sont gérées par SSM et joignables en ce moment :

aws ssm describe-instance-information \
  --query 'InstanceInformationList[].[InstanceId,PingStatus,PlatformName,AgentVersion]' \
  --output table

Les instances absentes de cette liste manquent soit d’agent, soit de profil d’instance, soit d’un chemin réseau vers les points d’accès SSM. Testez une session :

aws ssm start-session --target i-0123456789abcdef0

Trouvez les groupes de sécurité qui exposent encore le 22 au monde :

aws ec2 describe-security-group-rules \
  --filters Name=cidr-ipv4,Values=0.0.0.0/0 \
  --query 'SecurityGroupRules[?FromPort==`22` && IsEgress==`false`].[GroupId]' --output text

Dans la console, Systems Manager > Fleet Manager montre les nœuds gérés; Systems Manager > Session Manager > Session history montre qui s’est connecté où — les événements CloudTrail StartSession corroborent. Pour EIC, les tentatives de connexion apparaissent dans CloudTrail comme SendSSHPublicKey.

L’approche

  1. Câblez les prérequis sur tout le parc : un profil d’instance portant AmazonSSMManagedInstanceCore (bâti comme décrit dans les profils d’instance IAM bien faits), l’agent présent, et du 443 sortant — via NAT ou, plus propre pour les sous-réseaux privés, des points d’accès VPC SSM.
  2. Activez la journalisation des sessions avant le déploiement, pas après : préférences Session Manager → CloudWatch Logs ou S3, avec chiffrement. La valeur d’audit commence au jour un.
  3. Accordez l’accès par IAM, délimité par balises. ssm:StartSession conditionné sur ssm:resourceTag/Environment donne le staging aux développeurs et la production aux opérateurs sans lister d’ID d’instances.
  4. Roulez les deux modèles pendant deux ou trois semaines. Laissez les gens travailler via Session Manager (y compris aws ssm start-session --document-name AWS-StartPortForwardingSession pour les tunnels de base de données) pendant que le port 22 existe encore comme filet.
  5. Fermez le port 22. Supprimez les règles entrantes, gardez les clés sous scellés un trimestre, et guettez qui crie — ce cri, c’est un flux de travail non documenté que vous pourrez enfin corriger correctement.
  6. Gardez EIC Endpoint pour les exceptions. Les vrais besoins SCP/SFTP et les outils tiers qui ne parlent que SSH peuvent passer par un Instance Connect Endpoint avec clés éphémères — contrôlé par IAM, sans exposition permanente, sans bastion à maintenir.

Quand c’est le mauvais choix

Si votre parc s’étend sur du sur-site et d’autres nuages et que votre équipe roule une configuration SSH mature à base de certificats (certificats courts émis par une CA, audit centralisé), SSM y est un déplacement latéral — quoique l’agent SSM supporte l’activation hybride si vous voulez un seul tableau. Les conceptions réseau isolées ou sans points d’accès SSM exigent d’abord le travail de points d’accès VPC; ne livrez pas un modèle que les gens ne peuvent pas atteindre. Et gardez un chemin bris de vitre documenté (un EIC Endpoint, ou une paire de clés dans un coffre scellé) pour le jour où IAM, SSM ou votre fournisseur d’identité lui-même sera la panne.

Erreurs fréquentes

  • Fermer le port 22 avant de vérifier que chaque instance affiche Online dans SSM — les retardataires non gérés deviennent injoignables exactement quand vous en avez besoin.
  • Sauter la journalisation des sessions et récolter le bénéfice de sécurité mais aucun bénéfice d’audit.
  • Laisser les paires de clés du lancement valides pour toujours après la migration, de sorte que la vieille porte reste déverrouillée derrière la neuve.
  • Traiter EIC et Session Manager comme la même chose — EIC exige toujours un SSH joignable et une distribution compatible EIC; SSM n’exige ni l’un ni l’autre mais n’est pas du SSH.

Garder le contrôle

  • Une règle AWS Config ou un script hebdomadaire signalant tout groupe de sécurité avec le 22 ouvert au-delà des sources approuvées.
  • Une alerte sur StartSession vers les instances de production hors des heures ouvrables, et une revue mensuelle de l’historique des sessions.
  • Cuisez l’agent, le profil d’instance et les préférences de journalisation dans les modèles de lancement et les AMI dorées pour que les nouvelles instances arrivent conformes.
  • Retestez le chemin bris de vitre chaque trimestre; une porte d’urgence non testée est un mur.

Prenez Session Manager comme défaut, Instance Connect Endpoint pour les exceptions en forme de SSH, et laissez les clés SSH permanentes prendre leur retraite avec honneurs. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.