Accéder à une instance EC2 depuis le navigateur peut faire gagner beaucoup de temps, mais seulement si la méthode reste simple à opérer et claire à auditer. Avec EC2 Instance Connect, AWS propose une voie d’accès plus propre que le duo classique “clé SSH partagée + bastion”, surtout quand une équipe IT veut limiter l’exposition réseau sans perdre en réactivité. Dans cet article, j’explique ce que fait réellement ce mécanisme, quand je le recommande, comment l’utiliser depuis la console et quelles limites je vérifie avant de le mettre en production.
Les points essentiels à garder en tête avant d’ouvrir une session navigateur
- L’accès depuis la console ouvre une session SSH dans le navigateur et évite de manipuler une clé longue durée à la main.
- La clé envoyée à l’instance est éphémère: elle reste dans les métadonnées environ 60 secondes.
- Pour une instance avec IP publique, la console suffit; pour une instance privée, il faut un point d’accès privé adapté.
- Les demandes passent par IAM, c’est-à-dire la couche de droits d’AWS, et les tentatives sont consignées dans CloudTrail.
- Le bon choix dépend surtout du niveau d’exposition réseau accepté par l’équipe, pas seulement du confort d’usage.
Ce que fait vraiment ce service et ce qu’il ne fait pas
Je vois ce service comme un pont entre gouvernance IAM et simplicité d’accès. Quand tu l’utilises depuis la console AWS, le principe est simple: AWS pousse une clé publique temporaire vers l’instance, puis l’ouverture de session se fait dans le navigateur. La clé ne reste pas en place indéfiniment, ce qui réduit nettement le risque lié aux clés oubliées ou partagées trop largement.
Le point important, c’est que la session SSH ne s’arrête pas parce que les droits IAM expirent. Une fois la connexion établie, elle continue jusqu’à la fermeture de la session elle-même. Autrement dit, la sécurité se joue au moment de l’autorisation initiale, mais aussi dans la manière dont l’équipe gère la fin de session et les accès opérateurs.
Je précise aussi ce que ce mécanisme ne remplace pas: ce n’est ni un outil de transfert massif, ni un tunnel applicatif générique, ni une réponse magique à une architecture réseau mal découpée. Il simplifie l’administration, pas la conception globale de la sécurité. C’est justement pour cela qu’il faut le situer face aux autres options d’accès, et non le traiter comme une solution unique.
Une fois ce cadre posé, on peut comparer plus proprement les méthodes selon le contexte d’exploitation.
Dans quels cas je le choisis plutôt qu’une autre méthode
Quand je conseille une équipe, je pars rarement de la technologie. Je pars du besoin réel: accès ponctuel, administration régulière, réseau privé, audit strict, ou suppression des clés partagées. Selon ce critère, le bon choix n’est pas toujours le même.
| Méthode | Quand je la privilégie | Point fort | Limite à connaître |
|---|---|---|---|
| Connexion SSH depuis la console | Accès rapide à une instance exposée avec IP publique | Très simple pour l’administrateur, ouverture dans le navigateur | Nécessite une configuration réseau et une instance compatibles |
| Point d’accès privé | Instance en sous-réseau privé, sans IP publique | Réduit l’exposition externe et évite un bastion dédié | Le réseau et les groupes de sécurité demandent plus de rigueur |
| Session Manager | Shell navigateur avec forte exigence d’audit et peu d’entrées SSH | Bonne option pour limiter encore davantage les ports ouverts | Ce n’est pas la même logique d’exploitation qu’une session SSH classique |
| Bastion host | Environnement ancien ou architecture déjà bâtie autour d’un point d’entrée unique | Compatible avec beaucoup de schémas existants | Ajoute une brique à maintenir et à durcir |
Ma règle pratique est assez nette: si l’équipe veut surtout simplifier l’administration sans exposer davantage le réseau, je regarde d’abord la connexion navigateur et le chemin privé. Si l’objectif est de réduire au maximum la surface SSH, je compare sérieusement avec Session Manager. Le bastion, lui, reste souvent un choix de transition plus qu’un choix final.
Cette logique de choix est utile, mais elle ne remplace pas le parcours concret de connexion dans la console, qui est le point où beaucoup d’équipes perdent du temps au premier test.
Se connecter depuis la console AWS sans se tromper
Le parcours est court, mais il faut respecter l’ordre des vérifications. Si tu veux éviter les essais inutiles, je recommande de poser d’abord les prérequis réseau, puis seulement de cliquer dans la console.
- Ouvre la console EC2, sélectionne l’instance, puis choisis l’action de connexion.
- Vérifie d’abord le type d’adresse disponible: une IP publique ou IPv6 permet la connexion navigateur directe; si l’instance n’a qu’une IPv4 privée, il faut passer par un point d’accès privé.
- Dans l’onglet de connexion, choisis la méthode adaptée à la situation de l’instance.
- Contrôle le nom d’utilisateur Linux affiché ou attendu par l’image système, car une erreur à ce stade bloque la suite même si le réseau est bon.
- Lance la connexion: le terminal s’ouvre alors dans le navigateur.
Le détail que beaucoup sous-estiment, c’est la cohérence entre l’instance, son adresse et le mode de connexion choisi. Sur le terrain, j’ai vu des blocages venir non pas du navigateur, mais d’un mauvais présupposé sur l’IP disponible ou sur le profil de l’image Linux. Quand on corrige cela, la connexion devient très directe.
Une fois la méthode navigateur maîtrisée, le vrai sujet d’architecture devient le cas des instances privées, là où le point d’accès dédié change vraiment la donne.
Ce que change le point d’accès privé
Le point d’accès privé est la partie la plus intéressante pour un environnement sérieux, parce qu’il permet de rejoindre une instance sans IP publique et sans bastion. AWS le présente comme un proxy TCP conscient des identités: la connexion est authentifiée et autorisée avant d’atteindre le VPC, ce qui donne une approche plus propre qu’un simple trou réseau ouvert à la main.
Je trouve cette option particulièrement pertinente dans trois cas: une production isolée, une équipe qui veut conserver une vraie séparation entre réseau interne et accès d’exploitation, ou un contexte où l’on veut garder un accès humain ponctuel sans exposer les instances sur Internet. Le support des charges SSH et RDP est aussi utile, surtout quand on doit traiter à la fois Linux et Windows dans le même standard d’exploitation.
Deux limites méritent d’être citées sans détour. D’abord, ce mécanisme est pensé pour le trafic d’administration, pas pour des transferts lourds: les volumes importants sont bridés. Ensuite, il n’y a pas de coût additionnel pour créer le point d’accès lui-même, mais un transfert inter-AZ peut générer des frais de données si l’instance et le point d’accès ne sont pas dans la même zone de disponibilité. C’est une nuance qui compte quand on industrialise plusieurs environnements.
En pratique, je considère cette brique comme la meilleure réponse quand l’objectif est de garder l’accès humain, tout en restant cohérent avec une stratégie réseau fermée. Et c’est là que les sujets de sécurité prennent tout leur sens.
Les réglages de sécurité qui font la différence
Sur ce type d’accès, la sécurité ne dépend pas seulement du mécanisme lui-même. Elle dépend de ce que l’on autorise, de ce que l’on journalise et de ce que l’on laisse persister après la connexion. Je vérifie systématiquement quelques points.
- Les droits IAM doivent être limités au strict nécessaire, car c’est eux qui autorisent l’action initiale.
- CloudTrail doit être activé et surveillé, puisque les connexions réussies comme échouées y sont tracées.
- Les groupes de sécurité du point d’accès et de l’instance doivent être cohérents: le premier doit pouvoir joindre la destination, et la logique d’entrée doit correspondre au mode choisi.
- La clé est temporaire, mais la session ne l’est pas forcément: fermer l’onglet ou le terminal reste un geste de fin de session important.
- La préservation de l’IP client demande de la prudence, car elle ne s’applique pas partout et peut changer les règles de sécurité à écrire.
Le point sur l’IP client mérite un mot de méthode. Si tu actives cette préservation, certaines contraintes apparaissent: le point d’accès doit être en IPv4, l’instance doit rester dans le même VPC, et certains cas anciens ne sont pas compatibles. Je préfère le dire clairement, parce que c’est typiquement le genre de détail qui fait croire à tort que “ça ne marche pas”, alors que c’est juste une incompatibilité de configuration.
Quand ces garde-fous sont en place, les difficultés restantes relèvent surtout des erreurs de mise en œuvre. C’est le dernier bloc que je passe toujours en revue avant de valider une configuration.
Les erreurs qui bloquent souvent la première connexion
La plupart des échecs que je rencontre tiennent à des hypothèses implicites, pas à une faiblesse du service. Voici les plus fréquents:
- Essayer d’ouvrir la session navigateur sur une instance qui n’a ni IP publique ni point d’accès privé.
- Oublier que le composant nécessaire doit être présent sur l’instance Linux lorsque la méthode choisie l’exige.
- Confondre les règles de sécurité du point d’accès avec celles de l’instance elle-même.
- Attendre du mécanisme qu’il serve à des transferts lourds, alors qu’il est conçu pour de l’administration.
- Ne pas vérifier la compatibilité entre le type d’adresse du point d’accès et celui de l’instance.
- Penser que l’expiration des droits IAM coupe automatiquement une session déjà ouverte.
J’ajoute un conseil simple: teste toujours avec un compte d’exploitation limité avant de généraliser à toute l’équipe. C’est la manière la plus rapide de voir si le problème vient des droits, du réseau ou du type d’instance. Et elle évite de déboguer en prod ce qui aurait dû être validé sur un environnement contrôlé.
Une fois ces vérifications faites, on ne parle plus d’un gadget de console, mais d’un vrai choix d’architecture pour l’accès opérateur.
La configuration que je retiens pour une équipe IT mature
Si je devais retenir une ligne directrice simple, je dirais ceci: le navigateur est une bonne porte d’entrée, à condition de rester discipliné sur l’IAM, le réseau et l’audit. Pour une instance temporaire ou un environnement de test, l’accès console direct suffit souvent. Pour une production privée, je préfère un point d’accès privé, des groupes de sécurité très serrés et des journaux CloudTrail suivis régulièrement.
- Pour l’exploitation ponctuelle, je privilégie la simplicité sans multiplier les briques.
- Pour une prod isolée, je choisis la voie privée et j’évite de rendre l’instance joignable inutilement.
- Pour une équipe qui veut aller plus loin dans la réduction de SSH, je compare toujours avec Session Manager avant de figer l’architecture.
Au fond, le bon design n’est pas celui qui impressionne en réunion; c’est celui qui réduit le risque, reste lisible pour l’équipe et ne complique pas la vie au premier incident. C’est précisément là que ce mode d’accès prend de la valeur, parce qu’il rapproche l’opérationnel de la sécurité au lieu de les opposer.
