Votre instance RDS n'a pas d'endpoint public.
Atteignez-la via AWS SSM, sans bastion.
AgentsRoom ouvre une session de redirection de port AWS Session Manager vers votre base et y branche son client de base de données. La session lance aws ssm start-session avec le document AWS-StartPortForwardingSessionToRemoteHost, autorisée par le profil AWS déjà configuré sur votre machine.
La base reste dans son sous-réseau privé, le security group reste fermé, et rien de nouveau n'est exposé sur internet. Ce qui change, c'est que vous pouvez enfin la requêter, et un agent IA de code aussi, en lecture seule.
Comment AgentsRoom atteint une instance RDS dans un sous-réseau privé via AWS Systems Manager, sans rien ouvrir sur internet.
La situation est assez banale pour être ennuyeuse, et assez pénible pour coûter un après-midi. Une instance Amazon RDS vit dans un sous-réseau privé. Elle n'a pas d'endpoint public. Son security group accepte le trafic de l'application, et de rien d'autre. Il n'y a aucun port SSH entrant dans ce VPC, parce que quelqu'un a bien fait son travail et l'a fermé. Et maintenant vous avez besoin de regarder trois lignes pour comprendre un bug.
AWS Systems Manager Session Manager règle déjà le transport. Une instance EC2 gérée située dans le VPC peut rediriger un port local de votre machine vers un troisième hôte qu'elle sait joindre, ce qu'est exactement une instance RDS dans un sous-réseau privé. Le document qui fait ça s'appelle AWS-StartPortForwardingSessionToRemoteHost, et la commande est aws ssm start-session. Rien d'exotique, rien à installer sur la base.
AgentsRoom lance cette commande à votre place et pose un client de base de données à l'autre bout. Vous choisissez l'instance, la région et le profil une fois, vous y rattachez une connexion de base de données, et à partir de là ouvrir cette base tient en un clic. La session est autorisée par votre propre profil AWS ou votre connexion SSO, donc aucune clé ni mot de passe n'est stocké pour le saut lui-même.
Les contournements habituels coûtent tous quelque chose
Trois réponses au même problème, et ce que chacune vous facture.
Un bastion à maintenir
Une machine rebond dans un sous-réseau public, c'est un serveur qu'on patche, qu'on surveille, qu'on paie et qu'on finit par oublier. Elle porte un port SSH entrant, une liste de clés autorisées qui dérive au fil des arrivées et des départs, et un security group à une modification distraite d'être ouvert au monde. Elle n'existe que pour qu'une personne atteigne une base de temps en temps.
Un VPN pour une question de trois lignes
Un VPN client met votre machine entière dans le réseau pour répondre à une question sur trois lignes. Il faut le provisionner, le distribuer, le renouveler et le révoquer, il se bagarre avec le reste de votre connectivité, et sur un portable qui change de réseau c'est la pièce qui casse en premier. La plupart des équipes qui en ont un gardent quand même un bastion à côté.
Des identifiants qui circulent
La solution de repli que tout le monde finit par prendre est pire : l'endpoint et le mot de passe atterrissent dans un message de chat, une note partagée, un script commité par accident, ou un prompt envoyé à un agent IA. L'accès se répand dans des endroits que personne ne suit, et le révoquer plus tard veut dire faire tourner un identifiant en espérant que toutes les copies ont disparu.
D'une base RDS privée à un jeu de résultats
Quatre étapes, faites une fois, puis c'est un clic.
Enregistrez une connexion AWS SSM
Dans le gestionnaire de connexions, ajoutez une connexion et choisissez AWS SSM comme transport. Vous lui donnez l'ID d'instance d'une machine EC2 gérée capable d'atteindre la base (i-0123456789abcdef0), votre profil AWS et la région. Il n'y a ni champ mot de passe ni champ clé, parce que la session est autorisée par les identifiants AWS déjà présents sur votre machine.
Ajoutez la base et faites-la passer par cette connexion
Ajoutez une connexion de base de données avec l'endpoint RDS comme hôte, le port, l'utilisateur et la base, et choisissez son moteur. Dans le champ « Joindre via », choisissez la connexion AWS SSM que vous venez d'enregistrer au lieu de « Connexion directe ». C'est toute la configuration : l'endpoint reste privé, le security group reste fermé.
AgentsRoom ouvre la session
Quand vous ouvrez la connexion, AgentsRoom demande au système d'exploitation un port loopback libre, puis lance aws ssm start-session avec le document AWS-StartPortForwardingSessionToRemoteHost, en passant l'endpoint RDS en host, le port de la base en portNumber et le port réservé en localPortNumber. Il attend que ce port accepte vraiment une connexion TCP avant de déclarer le tunnel prêt, pour que le client ne se connecte jamais trop tôt.
Requêtez-la, ou laissez un agent la requêter
La console se connecte à 127.0.0.1 sur le port redirigé et se comporte comme n'importe quelle autre connexion : navigateur de schémas, une instruction à la fois, résultats plafonnés. Un agent IA de code peut interroger la même connexion en MCP, en lecture seule, sans jamais recevoir le mot de passe. Fermer la connexion tue le process de session avec elle.
La commande qu'AgentsRoom lance
Il n'y a aucun protocole propriétaire ici et rien n'est réimplémenté en JavaScript. AgentsRoom lance l'AWS CLI comme processus enfant, avec des arguments passés directement plutôt qu'à travers un shell, et lit sa sortie. Si vous avez déjà ouvert une session de redirection de port à la main, c'est la ligne que vous connaissez déjà.
aws ssm start-session \
--target i-0a1b2c3d4e5f \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters host=acme-prod.abc123.eu-west-1.rds.amazonaws.com,\
portNumber=3306,localPortNumber=54321 \
--profile acme-prod --region eu-west-1L'ID d'instance, l'endpoint, la région et le profil viennent de la connexion que vous avez enregistrée. Le port local est choisi par le système d'exploitation au moment de l'ouverture.
Rediriger vers l'instance gérée elle-même, plutôt que vers une base derrière elle, c'est le même document avec host=localhost. C'est pour ça que le même type de connexion couvre à la fois une base dans un sous-réseau privé et un service qui tourne sur l'instance à laquelle vous êtes connecté.
Ce qui doit être vrai avant que ça marche
AgentsRoom pilote votre configuration AWS, il ne la remplace pas. Cinq choses doivent être en place, et ce sont les cinq mêmes dont Session Manager a besoin tout seul.
L'AWS CLI sur votre machine
AgentsRoom appelle directement le binaire aws. Si aws ssm start-session marche dans votre terminal, ça marche ici.
Le session-manager-plugin
Session Manager a besoin de son plugin installé à côté de la CLI. Sans lui, la session sort immédiatement et AgentsRoom vous montre l'erreur affichée par la CLI au lieu de rester bloqué.
Un profil AWS ou une connexion SSO qui marche
L'autorisation vient de vos propres identifiants, passés en --profile et --region. AgentsRoom stocke le nom du profil et la région, jamais une clé, jamais un secret.
Une instance gérée dans le VPC
Une machine EC2 enregistrée auprès de Systems Manager, avec l'agent SSM en marche et un rôle d'instance qui autorise la session. C'est le nœud par lequel passe le trafic, et il n'a besoin d'aucun port entrant à lui.
Un chemin de l'instance vers la base
Le security group de la base doit accepter le trafic de l'instance sur le port de la base, et votre politique IAM doit autoriser ssm:StartSession avec ce document. Rien d'autre dans le VPC n'a besoin de changer.
Ce que le tunnel fait, et ce qu'il refuse de faire
Les propriétés qui décident si on peut laisser ça configuré sur un portable.
Loopback uniquement
Le port redirigé est lié à 127.0.0.1 et à rien d'autre. Une base atteinte comme ça n'est jamais republiée sur le réseau local : le Wi-Fi d'un café ne transforme pas votre portable en proxy ouvert vers la production.
Un port choisi par l'OS
AgentsRoom demande un port libre au système d'exploitation et le donne à la session. Il n'y a pas de port fixe à deviner, rien à réserver à l'avance, et aucune collision avec ce que vous faites tourner par ailleurs.
Prêt veut dire prêt
Le tunnel n'est résolu qu'une fois que le port local accepte vraiment une connexion TCP, et il abandonne avec l'erreur affichée par la CLI si ça n'arrive jamais. Pas d'attente arbitraire, pas de client qui se connecte à un port qui n'écoute pas encore.
Ni clé ni mot de passe pour le saut
La session SSM est autorisée par votre profil AWS ou votre session SSO. AgentsRoom stocke l'ID d'instance, le nom du profil et la région, et rien qui puisse être rejoué par quelqu'un qui aurait lu cette configuration.
La base reste en lecture seule
Une connexion base de données est en lecture seule à sa création. Une écriture demande que cette connexion précise soit rendue accessible en écriture et une confirmation explicite, et une connexion marquée production le dit haut et fort dans cette confirmation.
Une instruction par appel
Chaque appel porte exactement une instruction, donc rien ne se cache derrière un point-virgule, et les résultats sont plafonnés pour qu'une requête large ne noie ni une fenêtre ni le contexte d'un agent.
Pourquoi c'est moins d'accès, pas plus
Un tunnel, ça sonne comme un trou, et le réflexe est bon : la plupart des façons d'atteindre une base privée élargissent bel et bien la surface d'attaque. Celle-ci la réduit. Rien n'est ouvert côté base, aucun port entrant n'est créé dans le VPC, et l'instance gérée n'a besoin d'aucun service SSH à elle. Le trafic sort de l'instance vers le service Systems Manager, et votre machine l'y rejoint.
L'autorisation reste là où votre organisation la gère déjà. La session est accordée par votre identité AWS, via le profil ou la connexion SSO déjà configurée sur la machine, ce qui veut dire qu'elle est journalisée comme n'importe quelle autre session Session Manager, révoquée le jour où cette identité l'est, et cadrée par une politique IAM plutôt que par qui détient une clé. AgentsRoom stocke l'ID d'instance, le nom du profil et la région : rien de tout ça n'est un identifiant.
Côté base, les garde-fous sont les mêmes que pour toute connexion AgentsRoom. Lecture seule par défaut, une instruction par appel, résultats plafonnés, et un marqueur production qui durcit la confirmation d'écriture. Un agent IA qui requête via MCP reçoit un jeu de résultats et jamais le mot de passe, et l'outil qu'il utilise refuse tout ce qui n'est pas une lecture, sauf si vous avez rendu cette connexion inscriptible et activé « Autoriser les agents à écrire » pour elle.
Quatre moteurs à travers le tunnel, et ceux qui manquent encore
Le tunnel redirige un port TCP et se moque du moteur ; ce qui compte, c'est le client posé dessus. AgentsRoom en livre quatre : MySQL et MariaDB, PostgreSQL, SQL Server, et MongoDB. Sur RDS, ça couvre RDS for MySQL, RDS for MariaDB, RDS for PostgreSQL, RDS for SQL Server, les éditions Aurora compatibles avec MySQL ou PostgreSQL, et Amazon DocumentDB côté MongoDB. Oracle n'est pas supporté. Vous méritez de le savoir avant le téléchargement plutôt qu'après.
Le transport SSM lui-même est agnostique : il redirige un port TCP. Ce qui décide, c'est le client posé dessus, et c'est là qu'Oracle manque encore. Le prochain moteur est décidé par ce que les gens demandent : si le vôtre manque, dites lequel sur le backlog public et il sera compté.
Demander votre moteur de base de donnéesUn agent peut la requêter aussi, en lecture seule
Une fois la connexion créée, un agent IA de code peut l'utiliser via AgentsRoom MCP en la nommant. db_list renvoie les connexions enregistrées et leurs métadonnées, db_schema parcourt les schémas, les tables et les colonnes sans une ligne de SQL, db_query exécute une instruction et renvoie des lignes plafonnées, et db_connection_new propose une base pas encore enregistrée en pré-remplissant le formulaire que vous relisez et enregistrez.
AgentsRoom ouvre lui-même la session SSM quand l’agent le demande, donc l’agent ne manipule jamais d’identifiant AWS, de mot de passe de base ni de numéro de port. Ce qui revient, c’est un jeu de résultats. Les écritures demandent une connexion inscriptible et l’activation explicite de « Autoriser les agents à écrire ». L’option est désactivée par défaut et les écritures sont immédiates une fois autorisées.
C'est tout l'intérêt de le faire proprement. Un agent qui débogue contre un réplica de production dans un sous-réseau privé lit les lignes qui expliquent le bug, et n'a aucun chemin pour les modifier tant que vous n'avez pas ouvert cette connexion aux écritures des agents, aucun identifiant à laisser fuir dans son contexte, et aucun moyen d'atteindre cette base une fois l'application fermée.
Comment me connecter à une instance RDS qui n'a pas d'endpoint public ?
Quel document SSM AgentsRoom utilise-t-il ?
Ai-je encore besoin d'un bastion ?
Que dois-je installer sur ma machine ?
AgentsRoom stocke-t-il une clé AWS pour ça ?
Quel port local le tunnel utilise-t-il, et qui peut l'atteindre ?
Est-ce que ça marche avec RDS for PostgreSQL ?
Puis-je rediriger vers l'instance EC2 elle-même plutôt que vers une base ?
Un agent IA peut-il requêter la base à travers le tunnel ?
Vous pourriez aussi aimer
Connexions bases de données
Enregistrez vos connexions MySQL, PostgreSQL, SQL Server, MongoDB, SQLite et Google BigQuery, atteignez une base dans un sous-réseau privé via un tunnel SSH ou une session AWS SSM, et laissez vos agents IA l'interroger en MCP. Lecture seule par défaut, une instruction par appel, résultats plafonnés, et le mot de passe n'atteint jamais l'agent. Export, import et copie de base à base pour MySQL, PostgreSQL et MongoDB.
Connexions SSH
Enregistrez vos connexions SSH, ouvrez un terminal SSH intégré et lancez Claude Code, Codex ou Antigravity CLI directement sur votre serveur distant ou votre VPS. Authentification par clé ou mot de passe, profils de connexion par projet, sans client SSH séparé.
Gestionnaire de secrets
Rangez vos clés d'API, vos tokens et vos mots de passe dans le trousseau de votre système, référencez-les avec {{secret:NAME}} dans vos commandes de dev et les environnements de vos agents, et laissez AgentsRoom les résoudre au lancement. Les agents voient les noms, jamais les valeurs, et rien n'est jamais synchronisé vers un serveur.
Flotte à distance
Exécutez des agents de codage Claude, Codex et Antigravity sur chaque ordinateur que vous possédez, et invitez vos coéquipiers à collaborer sur les mêmes agents en temps réel. Machine de bureau, machine à domicile, serveur de build, projets d'équipe partagés : le tout dans une vue unifiée et entièrement chiffrée de bout en bout.
Requêtez la base que personne ne peut atteindre
Téléchargez AgentsRoom, enregistrez une connexion AWS SSM, pointez une base MySQL, PostgreSQL, SQL Server ou MongoDB dessus, et interrogez votre instance RDS privée sans bastion, sans VPN et sans mot de passe partagé.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Des agents qu'on lit comme une conversation
Chaque agent a un rôle, un visage et un fil que vous lisez comme une messagerie.
