Ton instance RDS n'a pas d'endpoint public.
Atteins-la via AWS SSM, sans bastion.
AgentsRoom ouvre vers ta base une session de redirection de port AWS Session Manager et y branche son client SQL. La session lance aws ssm start-session avec le document AWS-StartPortForwardingSessionToRemoteHost, autorisée par le profil AWS déjà configuré sur ta 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 tu peux 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 tu as 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 ta 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 pour toi et met un client SQL à l'autre bout. Tu choisis l'instance, la région et le profil une fois, tu y rattaches une connexion base de données, et à partir de là ouvrir cette base tient en un clic. La session est autorisée par ton propre profil AWS ou ta connexion SSO : 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 te 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 ta 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 ta 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.
Enregistre une connexion AWS SSM
Dans le gestionnaire de connexions, ajoute une connexion et choisis AWS SSM comme transport. Tu lui donnes l'ID d'instance d'une machine EC2 gérée capable d'atteindre la base (i-0123456789abcdef0), ton 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 ta machine.
Ajoute la base et fais-la passer par cette connexion
Ajoute une connexion MySQL ou MariaDB avec l'endpoint RDS comme hôte, le port, l'utilisateur et la base. Dans le champ Passer par, choisis la connexion AWS SSM que tu viens 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 tu ouvres 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ête-la, ou laisse un agent la requêter
La console SQL se connecte à 127.0.0.1 sur le port redirigé et se comporte comme n'importe quelle autre connexion : explorateur de schéma, une instruction à la fois, résultats plafonnés. Un agent IA de code peut requêter la même connexion via MCP, en lecture seule, sans jamais recevoir le mot de passe. Fermer la connexion tue le processus 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 tu as déjà ouvert une session de redirection de port à la main, c'est la ligne que tu connais 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 tu as 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 tu es connecté.
Ce qui doit être vrai avant que ça marche
AgentsRoom pilote ta 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 ta machine
AgentsRoom appelle directement le binaire aws. Si aws ssm start-session marche dans ton 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 te 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 tes 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 ta 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 ton 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 tu fais 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 ton profil AWS ou ta 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 ta machine l'y rejoint.
L'autorisation reste là où ton organisation la gère déjà. La session est accordée par ton 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, quoi que la connexion autorise à un humain.
MySQL et MariaDB uniquement, et PostgreSQL n'en fait pas partie
Le client de base de données parle le protocole réseau de MySQL, donc les moteurs qui marchent sont MySQL et MariaDB. Sur RDS, ça veut dire RDS for MySQL, RDS for MariaDB et les éditions Aurora compatibles MySQL. RDS for PostgreSQL et Aurora PostgreSQL ne sont pas supportés, pas plus que SQL Server, Oracle, MongoDB ou SQLite. Tu mérites de le savoir avant le téléchargement plutôt qu'après.
Le transport SSM, lui, est indifférent au moteur puisqu'il redirige un port TCP. Ce qui manque pour PostgreSQL, c'est le client au-dessus, pas le tunnel en dessous. Le prochain moteur est décidé par ce que les gens demandent : si le tien manque, dis lequel sur le backlog public et il sera compté.
Demander ton 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 tu relis et enregistres.
AgentsRoom ouvre lui-même la session SSM quand l'agent demande, donc l'agent ne manipule jamais un identifiant AWS, un mot de passe de base ni un numéro de port. Ce qui revient, c'est un jeu de résultats. db_query est en lecture seule quoi que la connexion autorise, et cette règle vit dans l'application desktop plutôt que dans le processus MCP : elle tient même si on convainc l'agent de demander autre chose.
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, aucun identifiant à laisser fuir dans son contexte, et aucun moyen d'atteindre cette base une fois l'application fermée.
FAQ
Comment me connecter à une instance RDS qui n'a pas d'endpoint public ?
Via une session de redirection de port AWS SSM. Enregistre une connexion AWS SSM qui pointe vers une instance EC2 gérée capable d'atteindre la base, puis crée la connexion MySQL ou MariaDB avec l'endpoint RDS comme hôte et choisis cette connexion SSM dans le champ Passer par. AgentsRoom ouvre la session avec aws ssm start-session et branche le client SQL sur le port loopback redirigé. La base ne gagne aucun endpoint public et son security group ne change pas.
Quel document SSM AgentsRoom utilise-t-il ?
AWS-StartPortForwardingSessionToRemoteHost, avec host réglé sur l'endpoint de la base, portNumber sur le port de la base et localPortNumber sur le port loopback réservé sur ta machine. Ce document redirige à travers l'instance gérée vers un troisième hôte, ce qui est exactement le cas d'une instance RDS dans un sous-réseau privé. Rediriger vers l'instance elle-même, c'est le même document avec host=localhost.
Ai-je encore besoin d'un bastion ?
Non. Session Manager remplace la machine rebond pour cet usage : l'instance gérée n'a besoin d'aucun port SSH entrant ni d'IP publique, le trafic sort de l'instance vers le service Systems Manager, et ta machine rejoint la session depuis l'extérieur. Il n'y a plus de liste de clés à maintenir ni de sous-réseau public à surveiller.
Que dois-je installer sur ma machine ?
L'AWS CLI et le session-manager-plugin, plus un profil AWS ou une connexion SSO qui marche. AgentsRoom appelle directement le binaire aws : si aws ssm start-session marche dans ton terminal, ça marche ici. Si le plugin manque, la session sort immédiatement et AgentsRoom te montre l'erreur affichée par la CLI au lieu de rester bloqué sur une invite invisible.
AgentsRoom stocke-t-il une clé AWS pour ça ?
Non. La session est autorisée par les identifiants AWS déjà configurés sur ta machine, passés à la CLI en --profile et --region. AgentsRoom stocke l'ID d'instance, le nom du profil et la région, qui ne sont pas des identifiants. Le mot de passe de la base est autre chose : il vit dans le coffre chiffré par le trousseau de ton système, et il n'est jamais renvoyé à un agent IA.
Quel port local le tunnel utilise-t-il, et qui peut l'atteindre ?
Le système d'exploitation choisit un port libre à l'ouverture, et le tunnel le lie à 127.0.0.1 uniquement. Rien sur le réseau local ne peut l'atteindre, et il n'y a pas de port fixe à deviner. Le tunnel n'est considéré comme prêt qu'une fois que ce port accepte vraiment une connexion TCP, et il est fermé avec la connexion.
Est-ce que ça marche avec RDS for PostgreSQL ?
Non. Le client de base de données supporte MySQL et MariaDB uniquement, donc sur RDS ça veut dire RDS for MySQL, RDS for MariaDB et les éditions Aurora compatibles MySQL. RDS for PostgreSQL et Aurora PostgreSQL ne sont pas supportés aujourd'hui, pas plus que SQL Server, Oracle, MongoDB ou SQLite. Le tunnel SSM, lui, redirige un port TCP et se moque du moteur : ce qui manque, c'est le client au-dessus. Demande un moteur sur le backlog public et il sera compté.
Puis-je rediriger vers l'instance EC2 elle-même plutôt que vers une base ?
Oui. C'est le même document avec host=localhost, donc un service qui écoute sur l'instance gérée est joignable de la même façon. La même connexion AWS SSM ouvre aussi une session terminal classique sur cette instance, ce qui permet de lancer une CLI d'agent sur une machine qui n'a aucun port SSH entrant.
Un agent IA peut-il requêter la base à travers le tunnel ?
Oui, en lecture seule. Un agent nomme une connexion enregistrée via AgentsRoom MCP, l'application ouvre la session SSM et exécute elle-même l'instruction, et seul le jeu de résultats revient. L'agent ne reçoit jamais le profil AWS, les identifiants de l'endpoint ni le mot de passe de la base, et db_query refuse tout ce qui n'est pas une lecture, quoi que cette connexion autorise à un humain.
Tu pourrais aussi aimer
Connexions bases de données
Enregistre tes connexions MySQL et MariaDB, atteins une base dans un sous-réseau privé via un tunnel SSH ou une session AWS SSM, et laisse tes agents IA la requêter via MCP. Lecture seule par défaut, une seule instruction par appel, résultats plafonnés, et le mot de passe n'arrive jamais jusqu'à l'agent.
Connexions SSH
Enregistre tes connexions SSH, ouvre un terminal SSH intégré et lance Claude Code, Codex ou Antigravity CLI directement sur ton serveur distant ou ton VPS. Authentification par clé ou mot de passe, profils de connexion par projet, sans client SSH séparé.
Gestionnaire de secrets
Range tes clés d'API, tes tokens et tes mots de passe dans le trousseau de ton système, référence-les avec {{secret:NAME}} dans tes commandes de dev et les environnements de tes agents, et laisse 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 Mac 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 construction, projets d'équipe partagés : le tout dans une vue unifiée et entièrement chiffrée de bout en bout.
Requête la base que personne ne peut atteindre
Télécharge AgentsRoom, enregistre une connexion AWS SSM, fais-y passer une base MySQL ou MariaDB, et requête ton 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.
Aperçu d'AgentsRoom en action.