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 Datenbank-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 Datenbank-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 Datenbankverbindung an, mit dem RDS-Endpunkt als Host, dazu Port, Benutzer und Datenbank, und wähle die Engine. 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 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, es sei denn, du hast diese Verbindung schreibbar gemacht und „Agenten Schreibzugriff erlauben“ für sie eingeschaltet.
Vier Engines durch den Tunnel, und die, die noch fehlen
Der Tunnel leitet einen TCP-Port weiter und kümmert sich nicht um die Engine; entscheidend ist der Client darüber. AgentsRoom bringt vier mit: MySQL und MariaDB, PostgreSQL, SQL Server und MongoDB. Auf RDS deckt das RDS for MySQL, RDS for MariaDB, RDS for PostgreSQL, RDS for SQL Server, die mit MySQL oder PostgreSQL kompatiblen Aurora-Editionen und Amazon DocumentDB auf der MongoDB-Seite ab. Oracle wird nicht unterstützt. 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. Entscheidend ist der Client darüber, und genau dort fehlt Oracle noch. 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. Schreibvorgänge erfordern eine schreibbare Verbindung und die ausdrückliche Einstellung „Agenten Schreibzugriff erlauben“ des Nutzers; die Option ist standardmäßig aus, und Schreibvorgänge werden sofort ausgeführt, sobald sie aktiv ist.
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, solange du diese Verbindung nicht für Schreibvorgänge von Agenten geöffnet hast, keine Zugangsdaten, die in seinen Kontext lecken könnten, und keine Möglichkeit, diese Datenbank noch zu erreichen, sobald die App geschlossen ist.
Wie verbinde ich mich mit einer RDS-Instanz, die keinen öffentlichen Endpunkt hat?
Welches SSM Dokument verwendet AgentsRoom?
Brauche ich trotzdem noch einen Bastion-Host?
Was muss auf meiner Maschine installiert sein?
Speichert AgentsRoom dafür einen AWS-Schlüssel?
Welchen lokalen Port nutzt der Tunnel, und wer kann ihn erreichen?
Funktioniert das mit RDS for PostgreSQL?
Kann ich statt auf eine Datenbank auf die EC2-Instanz selbst weiterleiten?
Kann ein KI-Agent die Datenbank durch den Tunnel abfragen?
Das könnte dir auch gefallen
Datenbankverbindungen
Speichere deine MySQL-, PostgreSQL-, SQL Server-, MongoDB-, SQLite- und Google BigQuery-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. Export, Import und Kopie von Datenbank zu Datenbank für MySQL, PostgreSQL und MongoDB.
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ühre Claude, Codex und Antigravity-Coding-Agenten auf jedem Rechner aus, den du besitzt, und lade 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-, PostgreSQL-, SQL Server- oder MongoDB-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
Nutze Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Agenten, die du wie eine Unterhaltung liest
Jeder Agent hat eine Rolle, ein Gesicht und einen Verlauf, den du wie in einer Messaging-App liest.
