Je RDS-instance heeft geen publiek eindpunt.
Bereik hem via AWS SSM, zonder bastion.
AgentsRoom opent een port-forwardingsessie van AWS Session Manager naar je database en verbindt zijn SQL-client daardoorheen. De sessie voert aws ssm start-session uit met het document AWS-StartPortForwardingSessionToRemoteHost, geautoriseerd door het AWS-profiel dat al op je machine is geconfigureerd.
De database blijft in zijn private subnet, de beveiligingsgroep blijft dicht, en er wordt niets nieuws aan het internet blootgesteld. Wat verandert, is dat je hem eindelijk kunt bevragen, en een AI-coderingsagent ook, alleen-lezen.
Hoe AgentsRoom een RDS-instance in een privaat subnet bereikt via AWS Systems Manager, zonder iets open te zetten naar het internet.
De opzet komt vaak genoeg voor om saai te zijn, en is vervelend genoeg om een middag te kosten. Een Amazon RDS-instance staat in een privaat subnet. Hij heeft geen publiek eindpunt. Zijn beveiligingsgroep accepteert verkeer van de applicatie, en van niets anders. Nergens in die VPC staat een inkomende SSH-poort open, want iemand heeft het goede gedaan en die dichtgezet. En nu moet je drie rijen bekijken om een bug te begrijpen.
AWS Systems Manager Session Manager lost het transport al op. Een beheerde EC2-node binnen de VPC kan een lokale poort op jouw machine doorsturen naar een derde host die hij kan bereiken, en dat is precies wat een RDS-instance in een privaat subnet is. Het document dat dat doet heet AWS-StartPortForwardingSessionToRemoteHost, en de opdracht is aws ssm start-session. Niets exotisch, en niets om op de database te installeren.
AgentsRoom voert die opdracht voor je uit en zet er een SQL-client aan de andere kant op. Je kiest één keer de instance, de regio en het profiel, je koppelt er een databaseverbinding aan, en vanaf dan is die database openen één klik. De sessie wordt geautoriseerd door je eigen AWS-profiel of SSO-login, dus voor de hop zelf wordt geen sleutel en geen wachtwoord bewaard.
De gebruikelijke omwegen kosten allemaal iets
Drie antwoorden op hetzelfde probleem, en wat elk daarvan je kost.
Een bastionhost om te onderhouden
Een jump box in een publiek subnet is een server die je patcht, monitort, betaalt en uiteindelijk vergeet. Hij draagt een inkomende SSH-poort met zich mee, een lijst geautoriseerde sleutels die verschuift naarmate mensen komen en gaan, en een beveiligingsgroep die één onoplettende wijziging verwijderd is van open staan voor de hele wereld. Hij bestaat alleen zodat iemand af en toe een database kan bereiken.
Een VPN voor een vraag over drie rijen
Een client-VPN zet je hele machine binnen het netwerk om een vraag over drie rijen te beantwoorden. Hij moet worden ingericht, uitgerold, verlengd en ingetrokken, hij vecht met de rest van je connectiviteit, en op een laptop die tussen netwerken beweegt is het het onderdeel dat als eerste stukgaat. De meeste teams die er een hebben, houden er nog steeds een bastion naast.
Inloggegevens die rondgaan
Het alternatief waar iedereen op terugvalt is erger: het eindpunt en het wachtwoord belanden in een chatbericht, een gedeelde notitie, een script dat per ongeluk is gecommit, of een prompt die naar een AI-agent gaat. De toegang verspreidt zich naar plekken die niemand bijhoudt, en hem later intrekken betekent een inloggegeven roteren en hopen dat elke kopie weg is.
Van een private RDS-instance naar een resultaatset
Vier stappen, één keer gedaan, daarna is het één klik.
Bewaar een AWS SSM-verbinding
Voeg in de verbindingbeheerder een verbinding toe en zet het transport op AWS SSM. Je geeft het instance-ID op van een beheerde EC2-node die de database kan bereiken (i-0123456789abcdef0), je AWS-profiel en de regio. Er is geen wachtwoordveld en geen sleutelveld, want de sessie wordt geautoriseerd door de AWS-inloggegevens die al op je machine staan.
Voeg de database toe en bereik hem via die verbinding
Voeg een MySQL- of MariaDB-verbinding toe met het RDS-eindpunt als host, plus de poort, de gebruiker en de database. Kies in het veld Bereiken via de AWS SSM-verbinding die je net hebt bewaard, in plaats van Directe verbinding. Dat is de hele configuratie: het eindpunt blijft privé, de beveiligingsgroep blijft dicht.
AgentsRoom opent de sessie
Wanneer je de verbinding opent, vraagt AgentsRoom het besturingssysteem om een vrije loopback-poort en start daarna aws ssm start-session met het document AWS-StartPortForwardingSessionToRemoteHost, met het RDS-eindpunt als host, de databasepoort als portNumber en de gereserveerde poort als localPortNumber. De app wacht tot die poort daadwerkelijk een TCP-verbinding accepteert voordat ze de tunnel gereed verklaart, zodat de client nooit te vroeg verbindt.
Bevraag hem, of laat een agent het doen
De SQL-console verbindt met 127.0.0.1 op de doorgestuurde poort en gedraagt zich als elke andere verbinding: schemabrowser, één statement tegelijk, begrensde resultaatsets. Een AI-coderingsagent kan dezelfde verbinding via MCP bevragen, alleen-lezen, zonder ooit het wachtwoord te krijgen. De verbinding sluiten beëindigt het sessieproces mee.
De opdracht die AgentsRoom start
Er zit hier geen eigen protocol achter en er wordt niets nagebouwd in JavaScript. AgentsRoom start de AWS CLI als kindproces, met argumenten die rechtstreeks worden meegegeven in plaats van via een shell, en leest de uitvoer. Heb je ooit met de hand een port-forwardingsessie geopend, dan is dit de regel die je al kent.
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-1Het instance-ID, het eindpunt, de regio en het profiel komen uit de verbinding die je hebt bewaard. De lokale poort wordt bij het openen door het besturingssysteem gekozen.
Doorsturen naar de beheerde node zelf, in plaats van naar een database erachter, is hetzelfde document met host=localhost. Daarom dekt hetzelfde verbindingstype zowel een database in een privaat subnet als een dienst die draait op de instance waarmee je verbonden bent.
Wat er moet kloppen voordat het werkt
AgentsRoom bestuurt je AWS-opzet, het vervangt hem niet. Vijf dingen moeten op hun plek staan, en het zijn dezelfde vijf die Session Manager op zichzelf nodig heeft.
De AWS CLI op je machine
AgentsRoom roept het aws-binary rechtstreeks aan. Werkt aws ssm start-session in je terminal, dan werkt het hier.
De session-manager-plugin
Session Manager heeft zijn plugin nodig, geïnstalleerd naast de CLI. Zonder die plugin stopt de sessie meteen en toont AgentsRoom je de fout die de CLI heeft geprint, in plaats van te blijven hangen.
Een werkend AWS-profiel of SSO-login
De autorisatie komt van je eigen inloggegevens, meegegeven als --profile en --region. AgentsRoom bewaart de profielnaam en de regio, nooit een sleutel, nooit een geheim.
Een beheerde node in de VPC
Een EC2-instance die is geregistreerd bij Systems Manager, met de SSM Agent actief en een instance-profiel dat de sessie toestaat. Het is de node waar het verkeer doorheen gaat, en hij heeft zelf geen enkele inkomende poort nodig.
Een pad van de node naar de database
De beveiligingsgroep van de database moet verkeer van de node op de databasepoort accepteren, en je IAM-policy moet ssm:StartSession met dat document toestaan. Verder hoeft er niets aan de VPC te veranderen.
Wat de tunnel doet, en wat hij weigert te doen
De eigenschappen die bepalen of dit veilig ingesteld kan blijven staan op een laptop.
Alleen loopback
De doorgestuurde poort is gebonden aan 127.0.0.1 en aan niets anders. Een database die je zo bereikt wordt nooit opnieuw gepubliceerd op het lokale netwerk, dus de wifi van een koffiebar maakt van je laptop geen open proxy naar productie.
Een poort die het OS kiest
AgentsRoom vraagt het besturingssysteem om een vrije poort en geeft die door aan de sessie. Er is geen vaste poort om te raden, niets om vooraf te reserveren, en geen botsing met wat je verder draait.
Gereed betekent gereed
De tunnel is pas gereed zodra de lokale poort daadwerkelijk een TCP-verbinding accepteert, en geeft op met de fout die de CLI heeft geprint als dat nooit gebeurt. Geen willekeurige wachttijd, geen client die verbindt met een poort die nog niet luistert.
Geen sleutel, geen wachtwoord voor de hop
De SSM-sessie wordt geautoriseerd door je AWS-profiel of SSO-sessie. AgentsRoom bewaart het instance-ID, de profielnaam en de regio, en niets dat opnieuw te gebruiken is door wie die configuratie leest.
De database blijft alleen-lezen
Een databaseverbinding is alleen-lezen zodra ze wordt aangemaakt. Een schrijfactie vraagt erom dat juist die verbinding schrijfbaar wordt gemaakt, plus een expliciete bevestiging, en een verbinding die als productie is gemarkeerd zegt dat luid en duidelijk in die bevestiging.
Één statement per aanroep
Elke aanroep draagt precies één statement, zodat er niets achter een puntkomma schuilgaat, en resultaatsets worden begrensd zodat een brede query geen venster of agentcontext kan overspoelen.
Waarom dit minder toegang is, niet meer
Een tunnel klinkt als een gat, en die reflex klopt: de meeste manieren om een private database te bereiken vergroten het aanvalsoppervlak wel degelijk. Deze verkleint het. Aan de databasekant wordt niets opengezet, nergens in de VPC ontstaat een inkomende poort, en de beheerde node heeft zelf geen SSH-listener nodig. Het verkeer gaat vanaf de node naar de Systems Manager-dienst, en jouw machine treft het daar.
De autorisatie blijft waar je organisatie die al beheert. De sessie wordt verleend door je AWS-identiteit, via het profiel of de SSO-login die al op de machine staat, wat betekent dat ze wordt gelogd als elke andere Session Manager-sessie, wordt ingetrokken op de dag dat die identiteit wordt ingetrokken, en wordt afgebakend door een IAM-policy in plaats van door wie toevallig een sleutel in handen heeft. AgentsRoom bewaart het instance-ID, de profielnaam en de regio: geen daarvan is een inloggegeven.
Aan de databasekant zijn de veiligheidsmaatregelen dezelfde die elke AgentsRoom-verbinding krijgt. Standaard alleen-lezen, één statement per aanroep, begrensde resultaatsets, en een productiemarkering die de schrijfbevestiging strenger maakt. Een AI-agent die via MCP bevraagt krijgt een resultaatset en nooit het wachtwoord, en de tool waarmee hij bevraagt weigert alles behalve een leesactie, wat die verbinding een mens ook toestaat.
Alleen MySQL en MariaDB, en PostgreSQL hoort daar niet bij
De databaseclient spreekt het MySQL wire protocol, dus de engines die werken zijn MySQL en MariaDB. Op RDS betekent dat RDS for MySQL, RDS for MariaDB en de Aurora MySQL-compatibele edities. RDS for PostgreSQL en Aurora PostgreSQL worden niet ondersteund, en SQL Server, Oracle, MongoDB en SQLite evenmin. Je verdient het dat te weten voor de download in plaats van erna.
Het SSM-transport zelf is engine-onafhankelijk, want het stuurt gewoon een TCP-poort door. Wat voor PostgreSQL ontbreekt is de client erbovenop, niet de tunnel eronder. Welke engine als volgende komt, wordt bepaald door wat mensen vragen, dus ontbreekt de jouwe, zeg dan op de openbare backlog om welke het gaat en hij wordt meegeteld.
Vraag je database-engine aanEen agent kan hem ook bevragen, alleen-lezen
Zodra de verbinding bestaat, kan een AI-coderingsagent hem via AgentsRoom MCP gebruiken door hem bij naam te noemen. db_list geeft de opgeslagen verbindingen en hun metadata terug, db_schema doorloopt de schema's, de tabellen en de kolommen zonder één regel SQL, db_query voert één statement uit en geeft begrensde rijen terug, en db_connection_new stelt een database voor die nog niet is opgeslagen door het formulier vooraf in te vullen dat jij controleert en bewaart.
AgentsRoom opent de SSM-sessie zelf wanneer de agent erom vraagt, dus de agent hanteert nooit een AWS-inloggegeven, een databasewachtwoord of een poortnummer. Wat er terugreist is een resultaatset. db_query is alleen-lezen wat de verbinding ook toestaat, en die regel zit in de desktop-app in plaats van in het MCP-proces, dus hij houdt stand, zelfs als de agent wordt overgehaald om iets anders te vragen.
Dat is precies waarom je dit goed wilt doen. Een agent die debugt tegen een productiereplica in een privaat subnet leest de rijen die de bug verklaren, en heeft geen enkele weg om ze te wijzigen, geen inloggegeven om in zijn context te lekken, en geen manier om die database te bereiken zodra de app dicht is.
FAQ
Hoe maak ik verbinding met een RDS-instance die geen publiek eindpunt heeft?
Via een AWS SSM port-forwardingsessie. Bewaar een AWS SSM-verbinding die wijst naar een beheerde EC2-node die de database kan bereiken, maak daarna de MySQL- of MariaDB-verbinding aan met het RDS-eindpunt als host en kies die SSM-verbinding in het veld Bereiken via. AgentsRoom opent de sessie met aws ssm start-session en verbindt de SQL-client met de doorgestuurde loopback-poort. De database krijgt geen publiek eindpunt en zijn beveiligingsgroep blijft ongewijzigd.
Welk SSM-document gebruikt AgentsRoom?
AWS-StartPortForwardingSessionToRemoteHost, met host op het database-eindpunt, portNumber op de databasepoort en localPortNumber op de loopback-poort die op jouw machine is gereserveerd. Dat document stuurt via de beheerde node door naar een derde host, en dat is precies het geval van een RDS-instance in een privaat subnet. Doorsturen naar de node zelf is hetzelfde document met host=localhost.
Heb ik nog steeds een bastionhost nodig?
Nee. Session Manager vervangt de jump box voor dit gebruik: de beheerde node heeft geen inkomende SSH-poort en geen publiek IP nodig, het verkeer vertrekt vanaf de node richting de Systems Manager-dienst, en jouw machine sluit van buitenaf aan op de sessie. Er is geen sleutellijst om te onderhouden en geen publiek subnet om in de gaten te houden.
Wat moet er op mijn machine geïnstalleerd zijn?
De AWS CLI en de session-manager-plugin, plus een werkend AWS-profiel of SSO-login. AgentsRoom roept het aws-binary rechtstreeks aan, dus werkt aws ssm start-session in je terminal, dan werkt het hier. Ontbreekt de plugin, dan stopt de sessie meteen en toont AgentsRoom je de fout die de CLI heeft geprint, in plaats van te blijven hangen op een onzichtbare prompt.
Bewaart AgentsRoom hiervoor een AWS-sleutel?
Nee. De sessie wordt geautoriseerd door de AWS-inloggegevens die al op je machine zijn geconfigureerd, meegegeven aan de CLI als --profile en --region. AgentsRoom bewaart het instance-ID, de profielnaam en de regio, en dat zijn geen inloggegevens. Het databasewachtwoord staat daar los van: dat blijft versleuteld in de kluis via je OS-sleutelhanger, en het wordt nooit teruggegeven aan een AI-agent.
Welke lokale poort gebruikt de tunnel, en wie kan erbij?
Het besturingssysteem kiest bij het openen een vrije poort, en de tunnel bindt die alleen aan 127.0.0.1. Niets op het lokale netwerk kan erbij, en er is geen vaste poort om te raden. De tunnel geldt pas als gereed zodra die poort daadwerkelijk een TCP-verbinding accepteert, en hij wordt samen met de verbinding gesloten.
Werkt dit met RDS for PostgreSQL?
Nee. De databaseclient ondersteunt alleen MySQL en MariaDB, dus op RDS betekent dat RDS for MySQL, RDS for MariaDB en de Aurora MySQL-compatibele edities. RDS for PostgreSQL en Aurora PostgreSQL worden vandaag niet ondersteund, en SQL Server, Oracle, MongoDB en SQLite evenmin. De SSM-tunnel zelf stuurt een TCP-poort door en trekt zich niets aan van de engine: wat ontbreekt is de client erbovenop. Vraag een engine aan op de openbare backlog en hij wordt meegeteld.
Kan ik doorsturen naar de EC2-instance zelf in plaats van naar een database?
Ja. Het is hetzelfde document met host=localhost, dus een dienst die op de beheerde node luistert is op dezelfde manier bereikbaar. Diezelfde AWS SSM-verbinding opent ook gewoon een terminalsessie op die instance, en zo voer je een agent-CLI uit op een machine die helemaal geen inkomende SSH-poort heeft.
Kan een AI-agent de database via de tunnel bevragen?
Ja, alleen-lezen. Een agent noemt een opgeslagen verbinding via AgentsRoom MCP, de app opent de SSM-sessie en voert het statement zelf uit, en alleen de resultaatset reist terug. De agent krijgt nooit het AWS-profiel, de inloggegevens van het eindpunt of het databasewachtwoord, en db_query weigert alles behalve een leesactie, wat die verbinding een mens ook toestaat.
Je vindt misschien ook leuk
Databaseverbindingen
Bewaar je MySQL- en MariaDB-verbindingen, bereik een database in een privaat subnet via een SSH-tunnel of een AWS SSM-sessie, en laat je AI-agenten er via MCP query's op uitvoeren. Standaard alleen-lezen, één statement per aanroep, begrensde resultaatsets, en het wachtwoord bereikt de agent nooit.
SSH-verbindingen
Bewaar je SSH-verbindingen, open een ingebouwde terminal via SSH, en voer Claude Code, Codex of Antigravity CLI direct uit op je externe server of VPS. SSH-sleutel of wachtwoordauthenticatie, verbindingprofielen per project, geen aparte SSH-client nodig.
Geheimenbeheer
Bewaar API-sleutels, tokens en wachtwoorden in de sleutelhanger van je besturingssysteem, verwijs ernaar met {{secret:NAME}} in dev-commando's en agentomgevingen, en laat AgentsRoom ze invullen bij het starten. Agenten zien de namen, nooit de waarden, en er wordt niets naar een server gesynchroniseerd.
Remote Fleet
Voer Claude-, Codex- en Antigravity-coderingsagenten uit op elke Mac die je bezit, en nodig teamgenoten uit om in realtime samen te werken aan dezelfde agenten. Kantoormachine, thuismachine, buildserver, gedeelde teamprojecten: alles in één enkele, end-to-end versleutelde weergave.
Bevraag de database die niemand kan bereiken
Download AgentsRoom, bewaar een AWS SSM-verbinding, wijs er een MySQL- of MariaDB-database naartoe, en bevraag je private RDS-instance zonder bastion, zonder VPN en zonder gedeeld wachtwoord.
Companion-app: houd je agents onderweg in de gaten
Breng je eigen: Claude, Codex, Antigravity CLI of andere AI-provider.
Stuur bugs en verzoeken direct naar je openbare backlog.
Een glimp van AgentsRoom in actie.