Tu instancia RDS no tiene endpoint público.
Llega hasta ella con AWS SSM, sin bastión.
AgentsRoom abre hacia tu base de datos una sesión de reenvío de puertos de AWS Session Manager y conecta su cliente SQL a través de ella. La sesión ejecuta aws ssm start-session con el documento AWS-StartPortForwardingSessionToRemoteHost, autorizada por el perfil de AWS que ya tienes configurado en tu máquina.
La base de datos se queda en su subred privada, el grupo de seguridad sigue cerrado y no se expone nada nuevo a internet. Lo que cambia es que por fin puedes consultarla, y un agente de código con IA también, en solo lectura.
Cómo AgentsRoom llega a una instancia RDS en una subred privada a través de AWS Systems Manager, sin abrir nada a internet.
El montaje es lo bastante habitual como para resultar aburrido, y lo bastante molesto como para costarte una tarde entera. Una instancia Amazon RDS vive en una subred privada. No tiene endpoint público. Su grupo de seguridad acepta tráfico de la aplicación y de nada más. No hay ningún puerto SSH de entrada en toda esa VPC, porque alguien hizo lo correcto y lo cerró. Y ahora necesitas mirar tres filas para entender un bug.
AWS Systems Manager Session Manager ya resuelve el transporte. Un nodo EC2 gestionado dentro de la VPC puede reenviar un puerto local de tu máquina hacia un tercer host al que él sí llega, que es exactamente lo que es una instancia RDS en una subred privada. El documento que lo hace es AWS-StartPortForwardingSessionToRemoteHost, y el comando es aws ssm start-session. Nada exótico, nada que instalar en la base de datos.
AgentsRoom ejecuta ese comando por ti y pone un cliente SQL al otro extremo. Eliges la instancia, la región y el perfil una sola vez, le enganchas una conexión de base de datos, y a partir de ahí abrir esa base es cuestión de un clic. La sesión la autoriza tu propio perfil de AWS o tu login SSO, así que no se guarda ninguna clave ni ninguna contraseña para el salto en sí.
Las salidas habituales tienen todas un precio
Tres respuestas al mismo problema, y lo que te cobra cada una.
Un host bastión que mantener
Una máquina de salto en una subred pública es un servidor que parcheas, supervisas, pagas y acabas olvidando. Arrastra un puerto SSH abierto a la entrada, una lista de claves autorizadas que se va desajustando conforme la gente entra y sale, y un grupo de seguridad que está a una edición descuidada de quedar abierto al mundo entero. Existe solo para que alguien pueda llegar de vez en cuando a una base de datos.
Una VPN para una pregunta de tres filas
Una VPN de cliente mete tu máquina entera dentro de la red para responder a una pregunta sobre tres filas. Hay que aprovisionarla, distribuirla, renovarla y revocarla, se pelea con el resto de tu conectividad, y en un portátil que va cambiando de red es la primera pieza que se rompe. La mayoría de los equipos que tienen una siguen manteniendo un bastión al lado.
Credenciales que circulan de copia en copia
La alternativa a la que todo el mundo acaba recurriendo es peor : el endpoint y la contraseña terminan en un mensaje de chat, en una nota compartida, en un script commiteado por accidente o en un prompt enviado a un agente de IA. El acceso se extiende a sitios que nadie controla, y revocarlo más tarde significa rotar una credencial y confiar en que no quede ninguna copia por ahí.
De una instancia RDS privada a un conjunto de resultados
Cuatro pasos, una sola vez, y a partir de ahí basta un clic.
Guarda una conexión de AWS SSM
En el gestor de conexiones, añade una conexión y elige AWS SSM como transporte. Le das el ID de instancia de un nodo EC2 gestionado que sí llega a la base de datos (i-0123456789abcdef0), tu perfil de AWS y la región. No hay campo de contraseña ni campo de clave, porque la sesión la autorizan las credenciales de AWS que ya están en tu máquina.
Añade la base de datos y llégale por esa conexión
Añade una conexión MySQL o MariaDB con el endpoint de RDS como host, más el puerto, el usuario y la base de datos. En el campo Llegar a través de, elige la conexión de AWS SSM que acabas de guardar en lugar de Conexión directa. Esa es toda la configuración : el endpoint sigue siendo privado y el grupo de seguridad sigue cerrado.
AgentsRoom abre la sesión
Cuando abres la conexión, AgentsRoom pide al sistema operativo un puerto loopback libre y luego lanza aws ssm start-session con el documento AWS-StartPortForwardingSessionToRemoteHost, pasando el endpoint de RDS como host, el puerto de la base de datos como portNumber y el puerto reservado como localPortNumber. Espera a que ese puerto acepte realmente una conexión TCP antes de dar el túnel por listo, así que el cliente nunca se conecta demasiado pronto.
Consúltala, o deja que la consulte un agente
La consola SQL se conecta a 127.0.0.1 en el puerto reenviado y se comporta como cualquier otra conexión : explorador de esquemas, una sentencia cada vez, conjuntos de resultados limitados. Un agente de código con IA puede consultar esa misma conexión por MCP, en solo lectura, sin recibir jamás la contraseña. Al cerrar la conexión, el proceso de la sesión muere con ella.
El comando que lanza AgentsRoom
Aquí no hay ningún protocolo propietario ni nada reimplementado en JavaScript. AgentsRoom lanza la AWS CLI como proceso hijo, con los argumentos pasados directamente y no a través de un shell, y lee su salida. Si alguna vez has abierto a mano una sesión de reenvío de puertos, esta es la línea que ya conoces.
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-1El ID de instancia, el endpoint, la región y el perfil salen de la conexión que guardaste. El puerto local lo elige el sistema operativo en el momento de abrirla.
Reenviar al propio nodo gestionado, en lugar de a una base de datos que está detrás de él, es el mismo documento con host=localhost. Por eso el mismo tipo de conexión cubre tanto una base de datos en una subred privada como un servicio que corre en la instancia a la que te has conectado.
Lo que tiene que estar en su sitio para que funcione
AgentsRoom pilota tu configuración de AWS, no la sustituye. Hacen falta cinco cosas, y son las mismas cinco que Session Manager necesita por su cuenta.
La AWS CLI en tu máquina
AgentsRoom llama directamente al binario aws. Si aws ssm start-session funciona en tu terminal, aquí también funciona.
El session-manager-plugin
Session Manager necesita su plugin instalado junto a la CLI. Sin él, la sesión termina de inmediato y AgentsRoom te muestra el error que ha impreso la CLI en lugar de quedarse colgado.
Un perfil de AWS o un login SSO que funcione
La autorización viene de tus propias credenciales, pasadas como --profile y --region. AgentsRoom guarda el nombre del perfil y la región, nunca una clave, nunca un secreto.
Un nodo gestionado dentro de la VPC
Una instancia EC2 registrada en Systems Manager, con el SSM Agent en marcha y un perfil de instancia que permita la sesión. Es el nodo por el que pasa el tráfico, y no necesita ningún puerto de entrada propio.
Un camino del nodo hasta la base de datos
El grupo de seguridad de la base de datos tiene que aceptar tráfico del nodo en el puerto de la base, y tu política de IAM tiene que permitir ssm:StartSession con ese documento. No hace falta cambiar nada más en la VPC.
Lo que hace el túnel, y lo que se niega a hacer
Las propiedades que deciden si esto se puede dejar configurado en un portátil sin perder el sueño.
Solo loopback
El puerto reenviado se enlaza a 127.0.0.1 y a nada más. Una base de datos a la que llegas así nunca se republica en la red local, así que el Wi-Fi de una cafetería no convierte tu portátil en un proxy abierto hacia producción.
Un puerto que elige el sistema
AgentsRoom pide al sistema operativo un puerto libre y se lo entrega a la sesión. No hay ningún puerto fijo que adivinar, nada que reservar por adelantado y ninguna colisión con lo demás que tengas en marcha.
Listo significa listo
El túnel solo se da por bueno cuando el puerto local acepta de verdad una conexión TCP, y si eso no llega a pasar se rinde mostrando el error que imprimió la CLI. Ninguna espera arbitraria, ningún cliente conectándose a un puerto que todavía no escucha.
Ni clave ni contraseña para el salto
La sesión de SSM la autoriza tu perfil de AWS o tu sesión SSO. AgentsRoom guarda el ID de instancia, el nombre del perfil y la región, y nada que pudiera reutilizar quien llegue a leer esa configuración.
La base de datos se queda en solo lectura
Una conexión de base de datos nace en solo lectura. Una escritura exige haber hecho escribible esa conexión concreta y una confirmación explícita, y una conexión marcada como producción lo deja bien claro en esa confirmación.
Una sentencia por llamada
Cada llamada lleva exactamente una sentencia, así que nada se esconde detrás de un punto y coma, y los conjuntos de resultados están limitados para que una consulta ancha no pueda inundar una ventana ni el contexto de un agente.
Por qué esto es menos acceso, no más
Un túnel suena a agujero, y el reflejo es acertado : la mayoría de las formas de llegar a una base de datos privada sí amplifican la superficie de ataque. Esta la reduce. No se abre nada del lado de la base de datos, no se crea ningún puerto de entrada en ningún punto de la VPC, y el nodo gestionado no necesita ningún servicio SSH a la escucha. El tráfico sale del nodo hacia el servicio Systems Manager, y tu máquina se encuentra con él allí.
La autorización se queda donde tu organización ya la gestiona. La sesión la concede tu identidad de AWS, mediante el perfil o el login SSO ya configurados en la máquina, lo que significa que queda registrada como cualquier otra sesión de Session Manager, se revoca el día en que se revoca esa identidad, y su alcance lo define una política de IAM y no quién tiene una clave en la mano. AgentsRoom guarda el ID de instancia, el nombre del perfil y la región : nada de eso es una credencial.
Del lado de la base de datos, las salvaguardas son las mismas que recibe cualquier conexión de AgentsRoom. Solo lectura por defecto, una sentencia por llamada, conjuntos de resultados limitados y una marca de producción que endurece la confirmación de escritura. Un agente de IA que consulta por MCP obtiene un conjunto de resultados y nunca la contraseña, y la herramienta con la que consulta rechaza cualquier cosa que no sea una lectura, por mucho que la conexión le permita otra cosa a un humano.
Solo MySQL y MariaDB, y PostgreSQL no es uno de ellos
El cliente de base de datos habla el protocolo de red de MySQL, así que los motores que funcionan son MySQL y MariaDB. En RDS eso significa RDS para MySQL, RDS para MariaDB y las ediciones de Aurora compatibles con MySQL. RDS para PostgreSQL y Aurora PostgreSQL no están soportados, y tampoco SQL Server, Oracle, MongoDB ni SQLite. Mereces saberlo antes de descargar y no después.
El transporte SSM en sí es agnóstico del motor, porque lo que reenvía es un puerto TCP. Lo que falta para PostgreSQL es el cliente que va encima, no el túnel que va debajo. Qué motor llega después lo decide lo que pide la gente, así que si falta el tuyo, dilo en el backlog público y se contabiliza.
Pide tu motor de base de datosUn agente también puede consultarla, en solo lectura
Una vez que la conexión existe, un agente de código con IA puede usarla por AgentsRoom MCP nombrándola. db_list devuelve las conexiones guardadas y sus metadatos, db_schema recorre los esquemas, las tablas y las columnas sin una sola línea de SQL, db_query ejecuta una sentencia y devuelve filas limitadas, y db_connection_new propone una base de datos que aún no está guardada rellenando por adelantado el formulario que tú revisas y guardas.
AgentsRoom abre la sesión de SSM por su cuenta cuando el agente lo pide, así que el agente nunca maneja una credencial de AWS, una contraseña de base de datos ni un número de puerto. Lo que vuelve es un conjunto de resultados. db_query es de solo lectura sin importar lo que permita la conexión, y esa regla vive en la app de escritorio y no en el proceso MCP, así que se mantiene aunque alguien convenza al agente de pedir otra cosa.
Ese es justo el sentido de hacer esto bien. Un agente que depura contra una réplica de producción en una subred privada lee las filas que explican el bug, y no tiene forma de modificarlas, ni credencial que filtrar a su contexto, ni manera de llegar a esa base de datos una vez cerrada la app.
FAQ
¿Cómo me conecto a una instancia RDS que no tiene endpoint público?
Con una sesión de reenvío de puertos de AWS SSM. Guarda una conexión de AWS SSM que apunte a un nodo EC2 gestionado que sí llegue a la base de datos, y después crea la conexión MySQL o MariaDB con el endpoint de RDS como host y elige esa conexión SSM en el campo Llegar a través de. AgentsRoom abre la sesión con aws ssm start-session y conecta el cliente SQL al puerto loopback reenviado. La base de datos sigue sin endpoint público y su grupo de seguridad no cambia.
¿Qué documento de SSM usa AgentsRoom?
AWS-StartPortForwardingSessionToRemoteHost, con host apuntando al endpoint de la base de datos, portNumber al puerto de la base y localPortNumber al puerto loopback reservado en tu máquina. Ese documento reenvía a través del nodo gestionado hacia un tercer host, que es exactamente el caso de una instancia RDS en una subred privada. Reenviar al propio nodo es el mismo documento con host=localhost.
¿Sigo necesitando un host bastión?
No. Session Manager sustituye a la máquina de salto en este caso de uso : el nodo gestionado no necesita puerto SSH de entrada ni IP pública, el tráfico sale del nodo hacia el servicio Systems Manager y tu máquina se une a la sesión desde fuera. No hay lista de claves que mantener ni subred pública que vigilar.
¿Qué necesito tener instalado en mi máquina?
La AWS CLI y el session-manager-plugin, además de un perfil de AWS o un login SSO que funcione. AgentsRoom llama directamente al binario aws, así que si aws ssm start-session funciona en tu terminal, aquí también. Si falta el plugin, la sesión termina de inmediato y AgentsRoom te muestra el error que ha impreso la CLI en lugar de quedarse colgado en un prompt invisible.
¿AgentsRoom guarda una clave de AWS para esto?
No. La sesión la autorizan las credenciales de AWS que ya tienes configuradas en tu máquina, pasadas a la CLI como --profile y --region. AgentsRoom guarda el ID de instancia, el nombre del perfil y la región, que no son credenciales. La contraseña de la base de datos es otra cosa : vive en la bóveda, cifrada por el llavero de tu sistema operativo, y nunca se devuelve a un agente de IA.
¿Qué puerto local usa el túnel, y quién puede llegar a él?
El sistema operativo elige un puerto libre en el momento de abrir la sesión, y el túnel lo enlaza únicamente a 127.0.0.1. Nada de la red local puede alcanzarlo, y no hay ningún puerto fijo que adivinar. El túnel solo se considera listo cuando ese puerto acepta de verdad una conexión TCP, y se cierra junto con la conexión.
¿Funciona esto con RDS para PostgreSQL?
No. El cliente de base de datos solo soporta MySQL y MariaDB, así que en RDS eso significa RDS para MySQL, RDS para MariaDB y las ediciones de Aurora compatibles con MySQL. RDS para PostgreSQL y Aurora PostgreSQL no están soportados hoy, y tampoco SQL Server, Oracle, MongoDB ni SQLite. El túnel SSM en sí reenvía un puerto TCP y le da igual el motor : lo que falta es el cliente que va encima. Pide un motor en el backlog público y se contabiliza.
¿Puedo reenviar a la propia instancia EC2 en lugar de a una base de datos?
Sí. Es el mismo documento con host=localhost, así que a un servicio que escucha en el nodo gestionado se llega igual. Esa misma conexión de AWS SSM también abre una sesión de terminal normal en esa instancia, que es la forma de ejecutar un CLI de agente en una máquina que no tiene ningún puerto SSH de entrada.
¿Puede un agente de IA consultar la base de datos a través del túnel?
Sí, en solo lectura. El agente nombra una conexión guardada por AgentsRoom MCP, la app abre la sesión de SSM y ejecuta la sentencia ella misma, y de vuelta solo viaja el conjunto de resultados. El agente nunca recibe el perfil de AWS, las credenciales del endpoint ni la contraseña de la base de datos, y db_query rechaza cualquier cosa que no sea una lectura, por mucho que esa conexión le permita otra cosa a un humano.
También te puede interesar
Conexiones de base de datos
Guarda tus conexiones MySQL y MariaDB, llega a una base de datos en una subred privada a través de un túnel SSH o una sesión de AWS SSM, y deja que tus agentes de IA la consulten por MCP. Solo lectura por defecto, una sentencia por llamada, conjuntos de resultados limitados y la contraseña nunca llega al agente.
Conexiones SSH
Guarda tus conexiones SSH, abre una terminal SSH integrada y ejecuta Claude Code, Codex o Antigravity CLI directamente en tu servidor remoto o VPS. Autenticación por clave SSH o contraseña, perfiles de conexión por proyecto, sin necesidad de un cliente SSH aparte.
Gestor de secretos
Guarda claves de API, tokens y contraseñas en el llavero de tu sistema operativo, referéncialas como {{secret:NAME}} en tus comandos de desarrollo y en el entorno de tus agentes, y deja que AgentsRoom las resuelva al arrancar. Los agentes ven los nombres, nunca los valores, y nada se sincroniza con un servidor.
Flota Remota
Ejecuta agentes de codificación Claude, Codex y Antigravity en cada Mac que poseas, e invita a tus compañeros a colaborar en los mismos agentes en tiempo real. Máquina de oficina, máquina de casa, servidor de construcción, proyectos compartidos del equipo : todo en una única vista unificada y cifrada de extremo a extremo.
Consulta la base de datos a la que nadie puede llegar
Descarga AgentsRoom, guarda una conexión de AWS SSM, apunta hacia ella una base MySQL o MariaDB, y consulta tu instancia RDS privada sin bastión, sin VPN y sin contraseñas compartidas.
App complementaria: supervisa tus agentes en movimiento
Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.
Un vistazo a AgentsRoom en acción.