Deine RDS-Instanz hat keinen öffentlichen Endpunkt.
Erreiche sie über AWS SSM, ohne Bastion-Host.
AgentsRoom öffnet eine Port-Forwarding-Session mit AWS Session Manager zu deiner Datenbank und verbindet seinen SQL-Client darüber. Die Session läuft über aws ssm start-session mit dem Dokument AWS-StartPortForwardingSessionToRemoteHost, autorisiert durch das AWS-Profil, das auf deiner Maschine schon eingerichtet ist.
Die Datenbank bleibt in ihrem privaten Subnetz, die Security Group bleibt zu, und nichts Neues wird ins Internet gestellt. Neu ist nur, dass du sie endlich abfragen kannst, und ein KI-Coding-Agent ebenfalls, schreibgeschützt.
Wie AgentsRoom eine RDS-Instanz in einem privaten Subnetz über AWS Systems Manager erreicht, ohne irgendetwas ins Internet zu öffnen.
Das Setup ist verbreitet genug, um langweilig zu sein, und lästig genug, um einen Nachmittag zu kosten. Eine Amazon RDS Instanz liegt in einem privaten Subnetz. Sie hat keinen öffentlichen Endpunkt. Ihre Security Group nimmt Traffic von der Anwendung an und sonst von niemandem. In dieser ganzen VPC gibt es keinen einzigen eingehenden SSH-Port, weil jemand das Richtige getan und ihn geschlossen hat. Und jetzt musst du drei Zeilen ansehen, um einen Bug zu verstehen.
Den Transport löst AWS Systems Manager Session Manager längst. Ein verwalteter EC2-Node innerhalb der VPC kann einen lokalen Port auf deiner Maschine an einen dritten Host weiterleiten, den er erreicht, und genau das ist eine RDS-Instanz in einem privaten Subnetz. Das Dokument dafür heißt AWS-StartPortForwardingSessionToRemoteHost, der Befehl lautet aws ssm start-session. Nichts Exotisches, nichts, was auf der Datenbank installiert werden müsste.
AgentsRoom führt diesen Befehl für dich aus und hängt einen SQL-Client ans andere Ende. Du wählst Instanz, Region und Profil einmal aus, hängst eine Datenbankverbindung daran, und ab dann ist das Öffnen dieser Datenbank ein Klick. Die Session wird durch dein eigenes AWS-Profil oder deinen SSO-Login autorisiert, für den Hop selbst werden also weder ein Schlüssel noch ein Passwort gespeichert.
Die üblichen Umwege kosten alle etwas
Drei Antworten auf dasselbe Problem, und was jede davon dir abverlangt.
Ein Bastion-Host, den man pflegen muss
Ein Jump Host in einem öffentlichen Subnetz ist ein Server, den du patchst, überwachst, bezahlst und irgendwann vergisst. Er trägt einen eingehenden SSH-Port, eine Liste autorisierter Schlüssel, die mit jedem Zu- und Abgang veraltet, und eine Security Group, die einen unachtsamen Klick davon entfernt ist, für die ganze Welt offen zu stehen. Er existiert nur, damit jemand gelegentlich an eine Datenbank kommt.
Ein VPN für eine Frage von drei Zeilen
Ein Client-VPN setzt deine ganze Maschine ins Netzwerk, um eine Frage zu drei Zeilen zu beantworten. Es muss bereitgestellt, verteilt, erneuert und wieder entzogen werden, es kommt dem Rest deiner Konnektivität in die Quere, und auf einem Laptop, der zwischen Netzwerken wechselt, ist es das Teil, das zuerst bricht. Die meisten Teams, die eines haben, halten sich trotzdem noch einen Bastion-Host daneben.
Zugangsdaten, die herumgereicht werden
Die Ausweichlösung, bei der am Ende alle landen, ist schlimmer : Endpunkt und Passwort stehen irgendwann in einer Chat-Nachricht, in einer geteilten Notiz, in einem versehentlich committeten Skript oder in einem Prompt an einen KI-Agenten. Der Zugriff breitet sich an Orte aus, die niemand nachhält, und ihn später zu entziehen heißt, die Zugangsdaten zu rotieren und zu hoffen, dass wirklich jede Kopie verschwunden ist.
Von einer privaten RDS-Instanz zu einer Ergebnismenge
Vier Schritte, einmal erledigt, danach ist es ein Klick.
Eine AWS SSM Verbindung speichern
Füge im Verbindungsmanager eine Verbindung hinzu und stelle ihren Transport auf AWS SSM. Du gibst ihr die Instanz-ID eines verwalteten EC2-Node, der die Datenbank erreicht (i-0123456789abcdef0), dazu dein AWS-Profil und die Region. Es gibt kein Passwortfeld und kein Schlüsselfeld, denn die Session wird durch die AWS-Zugangsdaten autorisiert, die schon auf deiner Maschine liegen.
Die Datenbank hinzufügen und über diese Verbindung erreichen
Lege eine MySQL- oder MariaDB-Verbindung an, mit dem RDS-Endpunkt als Host, dazu Port, Benutzer und Datenbank. Wähle im Feld Erreichen über die gerade gespeicherte AWS SSM Verbindung statt Direkte Verbindung. Das ist die gesamte Konfiguration : Der Endpunkt bleibt privat, die Security Group bleibt zu.
AgentsRoom öffnet die Session
Beim Öffnen der Verbindung fragt AgentsRoom das Betriebssystem nach einem freien Loopback-Port und startet dann aws ssm start-session mit dem Dokument AWS-StartPortForwardingSessionToRemoteHost, mit dem RDS-Endpunkt als host, dem Datenbank-Port als portNumber und dem reservierten Port als localPortNumber. Erst wenn dieser Port tatsächlich eine TCP-Verbindung annimmt, gilt der Tunnel als bereit, der Client verbindet sich also nie zu früh.
Selbst abfragen, oder einen Agenten abfragen lassen
Die SQL-Konsole verbindet sich mit 127.0.0.1 auf dem weitergeleiteten Port und verhält sich wie jede andere Verbindung : Schema-Browser, ein Statement nach dem anderen, begrenzte Ergebnismengen. Ein KI-Coding-Agent kann dieselbe Verbindung über MCP abfragen, schreibgeschützt und ohne je das Passwort zu bekommen. Wird die Verbindung geschlossen, stirbt der Session-Prozess mit ihr.
Der Befehl, den AgentsRoom startet
Hier gibt es kein proprietäres Protokoll, und nichts wird in JavaScript nachgebaut. AgentsRoom startet die AWS CLI als Kindprozess, mit direkt übergebenen Argumenten statt über eine Shell, und liest ihre Ausgabe. Wenn du je von Hand eine Port-Forwarding-Session geöffnet hast, ist das die Zeile, die du längst kennst.
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-1Instanz-ID, Endpunkt, Region und Profil stammen aus der Verbindung, die du gespeichert hast. Der lokale Port wird beim Öffnen vom Betriebssystem gewählt.
Auf den verwalteten Node selbst weiterzuleiten statt auf eine Datenbank dahinter, ist dasselbe Dokument mit host=localhost. Genau deshalb deckt derselbe Verbindungstyp sowohl eine Datenbank in einem privaten Subnetz als auch einen Dienst ab, der auf der Instanz läuft, mit der du verbunden bist.
Was stimmen muss, damit es funktioniert
AgentsRoom steuert dein AWS-Setup, es ersetzt es nicht. Fünf Dinge müssen vorhanden sein, und es sind dieselben fünf, die Session Manager auch allein braucht.
Die AWS CLI auf deiner Maschine
AgentsRoom ruft die Binary aws direkt auf. Wenn aws ssm start-session in deinem Terminal funktioniert, funktioniert es auch hier.
Das session-manager-plugin
Session Manager braucht sein Plugin neben der CLI installiert. Fehlt es, beendet sich die Session sofort, und AgentsRoom zeigt dir den Fehler, den die CLI ausgegeben hat, statt hängen zu bleiben.
Ein funktionierendes AWS-Profil oder ein SSO-Login
Die Autorisierung kommt aus deinen eigenen Zugangsdaten, übergeben als --profile und --region. AgentsRoom speichert den Profilnamen und die Region, nie einen Schlüssel, nie ein Geheimnis.
Ein verwalteter Node in der VPC
Eine EC2-Instanz, die bei Systems Manager registriert ist, den SSM Agent ausführt und ein Instanzprofil besitzt, das die Session erlaubt. Über diesen Node läuft der Traffic, und er braucht dafür keinen eigenen eingehenden Port.
Ein Weg vom Node zur Datenbank
Die Security Group der Datenbank muss Traffic vom Node auf dem Datenbank-Port annehmen, und deine IAM-Policy muss ssm:StartSession mit diesem Dokument erlauben. Sonst muss sich an der VPC nichts ändern.
Was der Tunnel tut, und was er sich weigert zu tun
Die Eigenschaften, die entscheiden, ob man das auf einem Laptop konfiguriert lassen kann.
Nur Loopback
Der weitergeleitete Port ist an 127.0.0.1 gebunden und an sonst nichts. Eine so erreichte Datenbank wird nie ins lokale Netzwerk weitergereicht, ein Café-WLAN macht aus deinem Laptop also keinen offenen Proxy in die Produktion.
Ein Port, den das Betriebssystem wählt
AgentsRoom fragt das Betriebssystem nach einem freien Port und übergibt ihn an die Session. Es gibt keinen festen Port zu erraten, nichts im Voraus zu reservieren und keine Kollision mit dem, was sonst noch bei dir läuft.
Bereit heißt bereit
Der Tunnel gilt erst dann als offen, wenn der lokale Port wirklich eine TCP-Verbindung annimmt, und bricht mit dem Fehler ab, den die CLI ausgegeben hat, falls das nie passiert. Kein willkürliches Warten, kein Client, der sich auf einen Port verbindet, der noch gar nicht lauscht.
Kein Schlüssel, kein Passwort für den Hop
Die SSM Session wird durch dein AWS-Profil oder deine SSO-Session autorisiert. AgentsRoom speichert die Instanz-ID, den Profilnamen und die Region, und nichts, was jemand wiederverwenden könnte, der diese Konfiguration gelesen hat.
Die Datenbank bleibt schreibgeschützt
Eine Datenbankverbindung ist beim Anlegen schreibgeschützt. Ein Schreibvorgang verlangt, dass genau diese Verbindung schreibbar gemacht wird, dazu eine ausdrückliche Bestätigung, und eine als Produktion markierte Verbindung sagt das in dieser Bestätigung deutlich.
Ein Statement pro Aufruf
Jeder Aufruf trägt genau ein Statement, es versteckt sich also nichts hinter einem Semikolon, und Ergebnismengen sind begrenzt, damit eine breite Abfrage weder ein Fenster noch den Kontext eines Agenten überschwemmt.
Warum das weniger Zugriff bedeutet, nicht mehr
Ein Tunnel klingt nach einem Loch, und der Reflex ist richtig : Die meisten Wege zu einer privaten Datenbank vergrößern die Angriffsfläche tatsächlich. Dieser verkleinert sie. Auf der Datenbankseite wird nichts geöffnet, nirgendwo in der VPC entsteht ein eingehender Port, und der verwaltete Node braucht keinen eigenen SSH-Listener. Der Traffic geht vom Node nach außen zum Dienst Systems Manager, und deine Maschine trifft ihn dort.
Die Autorisierung bleibt dort, wo deine Organisation sie ohnehin verwaltet. Die Session wird von deiner AWS-Identität gewährt, über das Profil oder den SSO-Login, der auf der Maschine schon eingerichtet ist. Sie wird also wie jede andere Session Manager Session protokolliert, an dem Tag entzogen, an dem diese Identität entzogen wird, und von einer IAM-Policy begrenzt statt davon, wer zufällig einen Schlüssel besitzt. AgentsRoom speichert die Instanz-ID, den Profilnamen und die Region : nichts davon sind Zugangsdaten.
Auf der Datenbankseite gelten dieselben Leitplanken, die jede AgentsRoom Verbindung bekommt. Standardmäßig schreibgeschützt, ein Statement pro Aufruf, begrenzte Ergebnismengen und eine Produktionsmarkierung, die die Bestätigung vor einem Schreibvorgang verschärft. Ein KI-Agent, der über MCP abfragt, bekommt eine Ergebnismenge und nie das Passwort, und das Werkzeug, mit dem er abfragt, lehnt alles außer einem Lesevorgang ab, egal was die Verbindung einem Menschen erlaubt.
Nur MySQL und MariaDB, und PostgreSQL gehört nicht dazu
Der Datenbank-Client spricht das MySQL Wire Protocol, unterstützt werden also die Engines MySQL und MariaDB. Auf RDS heißt das RDS for MySQL, RDS for MariaDB und die Aurora MySQL-kompatiblen Editionen. RDS for PostgreSQL und Aurora PostgreSQL werden nicht unterstützt, ebenso wenig SQL Server, Oracle, MongoDB oder SQLite. Das solltest du vor dem Download erfahren und nicht danach.
Der SSM Transport selbst ist engine-unabhängig, denn er leitet einen TCP-Port weiter. Was für PostgreSQL fehlt, ist der Client darüber, nicht der Tunnel darunter. Welche Engine als Nächstes kommt, entscheidet die Nachfrage : Fehlt deine, nenne sie im öffentlichen Backlog, und sie wird mitgezählt.
Deine Datenbank-Engine anfragenEin Agent kann sie auch abfragen, schreibgeschützt
Sobald die Verbindung existiert, kann ein KI-Coding-Agent sie über AgentsRoom MCP nutzen, indem er sie benennt. db_list liefert die gespeicherten Verbindungen und ihre Metadaten, db_schema geht Schemas, Tabellen und Spalten durch, ohne eine Zeile SQL, db_query führt ein Statement aus und gibt begrenzte Zeilen zurück, und db_connection_new schlägt eine noch nicht gespeicherte Datenbank vor, indem es das Formular vorausfüllt, das du prüfst und speicherst.
AgentsRoom öffnet die SSM Session selbst, wenn der Agent danach fragt, der Agent hantiert also nie mit AWS-Zugangsdaten, einem Datenbank-Passwort oder einer Portnummer. Zurück wandert eine Ergebnismenge. db_query ist schreibgeschützt, egal was die Verbindung erlaubt, und diese Regel sitzt in der Desktop-App statt im MCP-Prozess, sie hält also selbst dann, wenn man den Agenten dazu überredet, etwas anderes zu verlangen.
Genau darum geht es, wenn man die Sache sauber aufsetzt. Ein Agent, der gegen ein Produktions-Replikat in einem privaten Subnetz debuggt, liest die Zeilen, die den Bug erklären, und hat keinen Weg, sie zu ändern, keine Zugangsdaten, die in seinen Kontext lecken könnten, und keine Möglichkeit, diese Datenbank noch zu erreichen, sobald die App geschlossen ist.
FAQ
Wie verbinde ich mich mit einer RDS-Instanz, die keinen öffentlichen Endpunkt hat?
Über eine AWS SSM Port-Forwarding-Session. Speichere eine AWS SSM Verbindung, die auf einen verwalteten EC2-Node zeigt, der die Datenbank erreicht, lege dann die MySQL- oder MariaDB-Verbindung mit dem RDS-Endpunkt als Host an und wähle im Feld Erreichen über diese SSM Verbindung. AgentsRoom öffnet die Session mit aws ssm start-session und verbindet den SQL-Client mit dem weitergeleiteten Loopback-Port. Die Datenbank behält keinen öffentlichen Endpunkt, und ihre Security Group bleibt unverändert.
Welches SSM Dokument verwendet AgentsRoom?
AWS-StartPortForwardingSessionToRemoteHost, mit host auf den Datenbank-Endpunkt, portNumber auf den Datenbank-Port und localPortNumber auf den Loopback-Port, der auf deiner Maschine reserviert wurde. Dieses Dokument leitet über den verwalteten Node an einen dritten Host weiter, und genau das ist der Fall einer RDS-Instanz in einem privaten Subnetz. Auf den Node selbst weiterzuleiten, ist dasselbe Dokument mit host=localhost.
Brauche ich trotzdem noch einen Bastion-Host?
Nein. Session Manager ersetzt den Jump Host für diesen Anwendungsfall : Der verwaltete Node braucht keinen eingehenden SSH-Port und keine öffentliche IP, der Traffic verlässt den Node in Richtung des Dienstes Systems Manager, und deine Maschine tritt der Session von außen bei. Es gibt keine Schlüsselliste zu pflegen und kein öffentliches Subnetz im Auge zu behalten.
Was muss auf meiner Maschine installiert sein?
Die AWS CLI und das session-manager-plugin, dazu ein funktionierendes AWS-Profil oder ein SSO-Login. AgentsRoom ruft die Binary aws direkt auf, wenn aws ssm start-session also in deinem Terminal funktioniert, funktioniert es auch hier. Fehlt das Plugin, beendet sich die Session sofort, und AgentsRoom zeigt dir den Fehler, den die CLI ausgegeben hat, statt an einer unsichtbaren Eingabeaufforderung hängen zu bleiben.
Speichert AgentsRoom dafür einen AWS-Schlüssel?
Nein. Die Session wird durch die AWS-Zugangsdaten autorisiert, die auf deiner Maschine schon eingerichtet sind, und der CLI als --profile und --region übergeben. AgentsRoom speichert die Instanz-ID, den Profilnamen und die Region, und das sind keine Zugangsdaten. Das Datenbank-Passwort ist eine eigene Sache : Es liegt im Tresor, verschlüsselt über deinen System-Schlüsselbund, und wird nie an einen KI-Agenten zurückgegeben.
Welchen lokalen Port nutzt der Tunnel, und wer kann ihn erreichen?
Das Betriebssystem wählt beim Öffnen einen freien Port, und der Tunnel bindet ihn ausschließlich an 127.0.0.1. Nichts im lokalen Netzwerk kann ihn erreichen, und es gibt keinen festen Port zu erraten. Der Tunnel gilt erst dann als bereit, wenn dieser Port tatsächlich eine TCP-Verbindung annimmt, und er wird mit der Verbindung geschlossen.
Funktioniert das mit RDS for PostgreSQL?
Nein. Der Datenbank-Client unterstützt nur MySQL und MariaDB, auf RDS heißt das also RDS for MySQL, RDS for MariaDB und die Aurora MySQL-kompatiblen Editionen. RDS for PostgreSQL und Aurora PostgreSQL werden heute nicht unterstützt, ebenso wenig SQL Server, Oracle, MongoDB oder SQLite. Der SSM Tunnel selbst leitet einen TCP-Port weiter und kümmert sich nicht um die Engine : Was fehlt, ist der Client darüber. Frag eine Engine im öffentlichen Backlog an, und sie wird mitgezählt.
Kann ich statt auf eine Datenbank auf die EC2-Instanz selbst weiterleiten?
Ja. Es ist dasselbe Dokument mit host=localhost, ein Dienst, der auf dem verwalteten Node lauscht, ist also genauso erreichbar. Dieselbe AWS SSM Verbindung öffnet außerdem eine normale Terminal-Session auf dieser Instanz, und genau so lässt du ein Agenten-CLI auf einer Maschine laufen, die überhaupt keinen eingehenden SSH-Port hat.
Kann ein KI-Agent die Datenbank durch den Tunnel abfragen?
Ja, schreibgeschützt. Ein Agent benennt über AgentsRoom MCP eine gespeicherte Verbindung, die App öffnet die SSM Session und führt das Statement selbst aus, und zurück wandert nur die Ergebnismenge. Der Agent bekommt weder das AWS-Profil noch die Zugangsdaten des Endpunkts noch das Datenbank-Passwort, und db_query lehnt alles außer einem Lesevorgang ab, egal was diese Verbindung einem Menschen erlaubt.
Das könnte dir auch gefallen
Datenbankverbindungen
Speichere deine MySQL- und MariaDB-Verbindungen, erreiche eine Datenbank in einem privaten Subnetz über einen SSH-Tunnel oder eine AWS SSM Session und lass deine KI-Agenten sie über MCP abfragen. Standardmäßig schreibgeschützt, ein Statement pro Aufruf, begrenzte Ergebnismengen, und das Passwort erreicht den Agenten nie.
SSH-Verbindungen
Speichere deine SSH-Verbindungen, öffne ein integriertes Terminal über SSH und starte Claude Code, Codex oder Antigravity CLI direkt auf deinem Remote-Server oder VPS. Authentifizierung per SSH-Schlüssel oder Passwort, Verbindungsprofile pro Projekt, kein separater SSH-Client nötig.
Secret Manager
Speichere API-Keys, Tokens und Passwörter im Schlüsselbund deines Betriebssystems, referenziere sie als {{secret:NAME}} in Dev-Befehlen und Agenten-Umgebungen, und lass AgentsRoom sie beim Start auflösen. Agenten sehen die Namen, nie die Werte, und nichts wird je auf einen Server synchronisiert.
Remote Fleet
Führen Sie Claude, Codex und Antigravity-Coding-Agenten auf jedem Mac aus, den Sie besitzen, und laden Sie Teamkollegen ein, in Echtzeit an denselben Agenten zusammenzuarbeiten. Bürocomputer, Heimcomputer, Build-Server, gemeinsame Teamprojekte : alles in einer einzigen, einheitlichen, Ende-zu-Ende-verschlüsselten Ansicht.
Frag die Datenbank ab, die niemand erreicht
Lade AgentsRoom herunter, speichere eine AWS SSM Verbindung, richte eine MySQL- oder MariaDB-Datenbank darauf aus und frage deine private RDS-Instanz ab, ohne Bastion-Host, ohne VPN und ohne geteiltes Passwort.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen AI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.