A sua instância RDS não tem endpoint público.
Alcance-a via AWS SSM, sem bastion.
O AgentsRoom abre até o seu banco de dados uma sessão de redirecionamento de porta do AWS Session Manager e conecta o cliente SQL dele através dela. A sessão roda aws ssm start-session com o documento AWS-StartPortForwardingSessionToRemoteHost, autorizada pelo perfil AWS já configurado na sua máquina.
O banco de dados continua na sub-rede privada dele, o security group continua fechado, e nada de novo é exposto na internet. O que muda é que você finalmente consegue consultá-lo, e um agente de IA de programação também, somente leitura.
Como o AgentsRoom alcança uma instância RDS em uma sub-rede privada pelo AWS Systems Manager, sem abrir nada para a internet.
A situação é comum o bastante para ser entediante, e dolorosa o bastante para custar uma tarde. Uma instância Amazon RDS fica em uma sub-rede privada. Ela não tem endpoint público. O security group dela aceita tráfego da aplicação, e de mais nada. Não existe nenhuma porta SSH de entrada em lugar nenhum daquela VPC, porque alguém fez a coisa certa e a fechou. E agora você precisa olhar três linhas para entender um bug.
O AWS Systems Manager Session Manager já resolve o transporte. Um nó EC2 gerenciado dentro da VPC consegue redirecionar uma porta local da sua máquina para um terceiro host que ele alcança, que é exatamente o que é uma instância RDS em uma sub-rede privada. O documento que faz isso é o AWS-StartPortForwardingSessionToRemoteHost, e o comando é aws ssm start-session. Nada exótico, nada para instalar no banco de dados.
O AgentsRoom roda esse comando por você e coloca um cliente SQL do outro lado. Você escolhe a instância, a região e o perfil uma vez, associa uma conexão de banco de dados a ela, e a partir daí abrir esse banco de dados é um clique. A sessão é autorizada pelo seu próprio perfil AWS ou login SSO, então nenhuma chave e nenhuma senha são armazenadas para o salto em si.
Todas as saídas de sempre custam alguma coisa
Três respostas para o mesmo problema, e o que cada uma delas cobra de você.
Um host bastion para manter
Um servidor de salto em uma sub-rede pública é uma máquina que você atualiza, monitora, paga e acaba esquecendo. Ele carrega uma porta SSH de entrada, uma lista de chaves autorizadas que se desatualiza conforme as pessoas entram e saem, e um security group que está a uma edição descuidada de ficar aberto para o mundo. Ele existe só para que alguém consiga alcançar um banco de dados de vez em quando.
Uma VPN para uma pergunta de três linhas
Uma VPN cliente coloca a sua máquina inteira dentro da rede para responder a uma pergunta sobre três linhas. Ela precisa ser provisionada, distribuída, renovada e revogada, briga com o resto da sua conectividade, e em um notebook que troca de rede o tempo todo é a peça que quebra primeiro. A maioria das equipes que tem uma ainda mantém um bastion do lado.
Credenciais copiadas para todo lado
A alternativa para a qual todo mundo apela é pior: o endpoint e a senha acabam em uma mensagem de chat, em uma nota compartilhada, em um script commitado sem querer, ou em um prompt enviado a um agente de IA. O acesso se espalha por lugares que ninguém acompanha, e revogá-lo depois significa rotacionar uma credencial e torcer para que toda cópia tenha sumido.
De uma instância RDS privada a um conjunto de resultados
Quatro passos, feitos uma vez, e depois é um clique.
Salve uma conexão AWS SSM
No gerenciador de conexões, adicione uma conexão e defina o transporte dela como AWS SSM. Você informa o ID da instância de um nó EC2 gerenciado que consegue alcançar o banco de dados (i-0123456789abcdef0), o seu perfil AWS e a região. Não existe campo de senha nem campo de chave, porque a sessão é autorizada pelas credenciais AWS que já estão na sua máquina.
Adicione o banco de dados e alcance-o por essa conexão
Adicione uma conexão MySQL ou MariaDB com o endpoint RDS como host, a porta, o usuário e o banco de dados. No campo Acessar através de, escolha a conexão AWS SSM que você acabou de salvar em vez de Conexão direta. Essa é toda a configuração: o endpoint continua privado, o security group continua fechado.
O AgentsRoom abre a sessão
Quando você abre a conexão, o AgentsRoom pede ao sistema operacional uma porta loopback livre e então inicia o aws ssm start-session com o documento AWS-StartPortForwardingSessionToRemoteHost, passando o endpoint RDS como host, a porta do banco de dados como portNumber e a porta reservada como localPortNumber. Ele espera até que essa porta realmente aceite uma conexão TCP antes de declarar o túnel pronto, para que o cliente nunca se conecte cedo demais.
Consulte, ou deixe um agente consultar
O console SQL se conecta a 127.0.0.1 na porta redirecionada e se comporta como qualquer outra conexão: navegador de esquema, uma instrução por vez, resultados limitados. Um agente de IA de programação pode consultar a mesma conexão por MCP, somente leitura, sem nunca receber a senha. Fechar a conexão encerra o processo da sessão junto.
O comando que o AgentsRoom dispara
Não existe protocolo proprietário aqui e nada é reimplementado em JavaScript. O AgentsRoom dispara a AWS CLI como um processo filho, com os argumentos passados diretamente em vez de por um shell, e lê a saída dela. Se você já abriu uma sessão de redirecionamento de porta na mão, esta é a linha que você já conhece.
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-1O ID da instância, o endpoint, a região e o perfil vêm da conexão que você salvou. A porta local é escolhida pelo sistema operacional na hora de abrir.
Redirecionar para o próprio nó gerenciado, em vez de para um banco de dados atrás dele, é o mesmo documento com host=localhost. É por isso que o mesmo tipo de conexão cobre tanto um banco de dados em uma sub-rede privada quanto um serviço rodando na instância à qual você está conectado.
O que precisa estar no lugar para isso funcionar
O AgentsRoom pilota a sua configuração AWS, ele não a substitui. Cinco coisas precisam estar prontas, e são as mesmas cinco de que o Session Manager precisa por conta própria.
A AWS CLI na sua máquina
O AgentsRoom chama o binário aws diretamente. Se aws ssm start-session funciona no seu terminal, funciona aqui.
O session-manager-plugin
O Session Manager precisa do plugin dele instalado ao lado da CLI. Sem ele, a sessão encerra na hora e o AgentsRoom mostra o erro que a CLI imprimiu em vez de ficar travado.
Um perfil AWS ou login SSO funcionando
A autorização vem das suas próprias credenciais, passadas como --profile e --region. O AgentsRoom armazena o nome do perfil e a região, nunca uma chave, nunca um segredo.
Um nó gerenciado na VPC
Uma instância EC2 registrada no Systems Manager, rodando o SSM Agent, com um perfil de instância que permite a sessão. É o nó por onde o tráfego passa, e ele não precisa de nenhuma porta de entrada própria.
Um caminho do nó até o banco de dados
O security group do banco de dados precisa aceitar tráfego do nó na porta do banco, e a sua política IAM precisa permitir ssm:StartSession com esse documento. Nada mais na VPC precisa mudar.
O que o túnel faz, e o que ele se recusa a fazer
As propriedades que decidem se dá para deixar isso configurado em um notebook com segurança.
Apenas loopback
A porta redirecionada fica vinculada a 127.0.0.1 e a mais nada. Um banco de dados alcançado assim nunca é republicado na rede local, então o Wi-Fi de uma cafeteria não transforma o seu notebook em um proxy aberto para a produção.
Uma porta escolhida pelo sistema
O AgentsRoom pede uma porta livre ao sistema operacional e a entrega à sessão. Não há porta fixa para adivinhar, nada para reservar de antemão, e nenhuma colisão com o que mais você estiver rodando.
Pronto significa pronto
O túnel só é dado como pronto quando a porta local aceita de fato uma conexão TCP, e desiste com o erro que a CLI imprimiu se isso nunca acontecer. Sem espera arbitrária, sem cliente se conectando a uma porta que ainda não está escutando.
Sem chave e sem senha para o salto
A sessão SSM é autorizada pelo seu perfil AWS ou pela sua sessão SSO. O AgentsRoom armazena o ID da instância, o nome do perfil e a região, e nada que possa ser reproduzido por quem tenha lido essa configuração.
O banco de dados continua somente leitura
Uma conexão de banco de dados nasce somente leitura. Uma escrita exige que aquela conexão específica seja tornada gravável e uma confirmação explícita, e uma conexão marcada como produção diz isso em alto e bom som nessa confirmação.
Uma instrução por chamada
Cada chamada carrega exatamente uma instrução, então nada se esconde atrás de um ponto e vírgula, e os resultados são limitados para que uma consulta ampla não inunde uma janela nem o contexto de um agente.
Por que isso é menos acesso, e não mais
Um túnel soa como um buraco, e o reflexo está certo: a maioria das formas de alcançar um banco de dados privado de fato amplia a superfície de ataque. Esta reduz. Nada é aberto do lado do banco de dados, nenhuma porta de entrada é criada em lugar nenhum da VPC, e o nó gerenciado não precisa de um listener SSH próprio. O tráfego sai do nó em direção ao serviço do Systems Manager, e a sua máquina o encontra lá.
A autorização fica onde a sua organização já a gerencia. A sessão é concedida pela sua identidade AWS, através do perfil ou do login SSO já configurado na máquina, o que significa que ela é registrada como qualquer outra sessão do Session Manager, revogada no dia em que aquela identidade for revogada, e delimitada por uma política IAM em vez de por quem por acaso tem uma chave. O AgentsRoom armazena o ID da instância, o nome do perfil e a região: nada disso é uma credencial.
Do lado do banco de dados, as travas são as mesmas que toda conexão do AgentsRoom recebe. Somente leitura por padrão, uma instrução por chamada, resultados limitados, e uma marcação de produção que endurece a confirmação de escrita. Um agente de IA que consulta por MCP recebe um conjunto de resultados e nunca a senha, e a ferramenta com que ele consulta recusa tudo que não seja leitura, não importa o que a conexão permita a um humano.
Somente MySQL e MariaDB, e PostgreSQL não é um deles
O cliente de banco de dados fala o protocolo de comunicação do MySQL, então os motores que funcionam são MySQL e MariaDB. No RDS, isso quer dizer RDS para MySQL, RDS para MariaDB e as edições Aurora compatíveis com MySQL. RDS para PostgreSQL e Aurora PostgreSQL não são suportados, e SQL Server, Oracle, MongoDB e SQLite também não. Você merece saber disso antes do download, e não depois.
O transporte SSM em si é agnóstico ao motor, já que ele redireciona uma porta TCP. O que falta para o PostgreSQL é o cliente em cima dele, não o túnel embaixo. Qual motor vem em seguida é decidido pelo que as pessoas pedem, então, se o seu está faltando, diga qual no backlog público e ele entra na conta.
Peça o seu motor de banco de dadosUm agente também pode consultá-lo, somente leitura
Assim que a conexão existe, um agente de IA de programação pode usá-la pelo AgentsRoom MCP nomeando-a. db_list devolve as conexões salvas e os metadados delas, db_schema percorre os esquemas, as tabelas e as colunas sem uma linha de SQL, db_query executa uma instrução e devolve linhas limitadas, e db_connection_new propõe um banco de dados que ainda não foi salvo preenchendo previamente o formulário que você revisa e salva.
O AgentsRoom abre a sessão SSM ele mesmo quando o agente pede, então o agente nunca manipula uma credencial AWS, uma senha de banco de dados ou um número de porta. O que volta é um conjunto de resultados. O db_query é somente leitura não importa o que a conexão permita, e essa regra vive no aplicativo desktop e não no processo MCP, então ela se mantém mesmo que alguém convença o agente a pedir outra coisa.
É esse o sentido de fazer isso direito. Um agente depurando contra uma réplica de produção em uma sub-rede privada lê as linhas que explicam o bug, e não tem caminho para mudá-las, nenhuma credencial para vazar no contexto dele, e nenhuma forma de alcançar aquele banco de dados depois que o aplicativo é fechado.
Perguntas frequentes
Como me conecto a uma instância RDS que não tem endpoint público?
Por uma sessão de redirecionamento de porta AWS SSM. Salve uma conexão AWS SSM apontando para um nó EC2 gerenciado que consegue alcançar o banco de dados, depois crie a conexão MySQL ou MariaDB com o endpoint RDS como host e escolha essa conexão SSM no campo Acessar através de. O AgentsRoom abre a sessão com aws ssm start-session e conecta o cliente SQL à porta loopback redirecionada. O banco de dados continua sem endpoint público e o security group dele não muda.
Qual documento SSM o AgentsRoom usa?
O AWS-StartPortForwardingSessionToRemoteHost, com host apontando para o endpoint do banco de dados, portNumber para a porta do banco e localPortNumber para a porta loopback reservada na sua máquina. Esse documento redireciona através do nó gerenciado até um terceiro host, que é exatamente o caso de uma instância RDS em uma sub-rede privada. Redirecionar para o próprio nó é o mesmo documento com host=localhost.
Ainda preciso de um host bastion?
Não. O Session Manager substitui o servidor de salto neste caso de uso: o nó gerenciado não precisa de porta SSH de entrada nem de IP público, o tráfego sai do nó em direção ao serviço do Systems Manager, e a sua máquina entra na sessão pelo lado de fora. Não há lista de chaves para manter nem sub-rede pública para ficar de olho.
O que preciso ter instalado na minha máquina?
A AWS CLI e o session-manager-plugin, além de um perfil AWS ou login SSO funcionando. O AgentsRoom chama o binário aws diretamente, então, se aws ssm start-session funciona no seu terminal, funciona aqui. Se o plugin estiver faltando, a sessão encerra na hora e o AgentsRoom mostra o erro que a CLI imprimiu em vez de travar em um prompt invisível.
O AgentsRoom armazena uma chave AWS para isso?
Não. A sessão é autorizada pelas credenciais AWS já configuradas na sua máquina, passadas à CLI como --profile e --region. O AgentsRoom armazena o ID da instância, o nome do perfil e a região, que não são credenciais. A senha do banco de dados é outra coisa: ela fica guardada no cofre, criptografada pelo chaveiro do seu sistema operacional, e nunca é devolvida a um agente de IA.
Qual porta local o túnel usa, e quem consegue alcançá-la?
O sistema operacional escolhe uma porta livre na hora de abrir, e o túnel a vincula apenas a 127.0.0.1. Nada na rede local consegue alcançá-la, e não há porta fixa para adivinhar. O túnel só é considerado pronto quando essa porta aceita de fato uma conexão TCP, e ele é fechado junto com a conexão.
Isso funciona com RDS para PostgreSQL?
Não. O cliente de banco de dados suporta somente MySQL e MariaDB, então, no RDS, isso quer dizer RDS para MySQL, RDS para MariaDB e as edições Aurora compatíveis com MySQL. RDS para PostgreSQL e Aurora PostgreSQL não são suportados hoje, e SQL Server, Oracle, MongoDB e SQLite também não. O túnel SSM em si redireciona uma porta TCP e não se importa com o motor: o que falta é o cliente em cima dele. Peça um motor no backlog público e ele entra na conta.
Posso redirecionar para a própria instância EC2 em vez de um banco de dados?
Sim. É o mesmo documento com host=localhost, então um serviço escutando no nó gerenciado é alcançável da mesma forma. A mesma conexão AWS SSM também abre uma sessão de terminal comum nessa instância, que é como você roda um CLI de agente em uma máquina que não tem nenhuma porta SSH de entrada.
Um agente de IA pode consultar o banco de dados pelo túnel?
Sim, somente leitura. Um agente nomeia uma conexão salva pelo AgentsRoom MCP, o aplicativo abre a sessão SSM e executa a instrução ele mesmo, e só o conjunto de resultados volta. O agente nunca recebe o perfil AWS, as credenciais do endpoint ou a senha do banco de dados, e o db_query recusa tudo que não seja leitura, não importa o que aquela conexão permita a um humano.
Você também pode gostar
Conexões de banco de dados
Salve suas conexões MySQL e MariaDB, alcance um banco de dados em uma sub-rede privada por um túnel SSH ou uma sessão AWS SSM, e deixe seus agentes de IA consultá-lo por MCP. Somente leitura por padrão, uma instrução por chamada, resultados limitados, e a senha nunca chega ao agente.
Conexões SSH
Salve suas conexões SSH, abra um terminal integrado via SSH e execute o Claude Code, o Codex ou o Antigravity CLI diretamente no seu servidor remoto ou VPS. Autenticação por chave SSH ou senha, perfis de conexão por projeto, sem precisar de um cliente SSH separado.
Gerenciador de segredos
Armazene chaves de API, tokens e senhas no chaveiro do seu sistema operacional, referencie-os como {{secret:NAME}} nos comandos de dev e nos ambientes dos agentes, e deixe o AgentsRoom resolvê-los na inicialização. Os agentes veem os nomes, nunca os valores, e nada é sincronizado com um servidor.
Frota Remota
Execute agentes de codificação Claude, Codex e Antigravity em todos os Macs que você possui e convide colegas para colaborar nos mesmos agentes em tempo real. Máquina de escritório, máquina de casa, servidor de construção, projetos compartilhados da equipe : tudo em uma única visão unificada e criptografada de ponta a ponta.
Consulte o banco de dados que ninguém alcança
Baixe o AgentsRoom, salve uma conexão AWS SSM, aponte um banco de dados MySQL ou MariaDB para ela, e consulte a sua instância RDS privada sem um bastion, uma VPN ou uma senha compartilhada.
App complementar: acompanhe seus agentes em qualquer lugar
Use Claude, Codex, Antigravity CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.
Uma visão do AgentsRoom em ação.