La tua istanza RDS non ha endpoint pubblico.
Raggiungila tramite AWS SSM, senza bastion.
AgentsRoom apre una sessione di port forwarding AWS Session Manager verso il tuo database e ci collega attraverso il suo client SQL. La sessione esegue aws ssm start-session con il documento AWS-StartPortForwardingSessionToRemoteHost, autorizzata dal profilo AWS già configurato sulla tua macchina.
Il database resta nella sua subnet privata, il security group resta chiuso e nulla di nuovo viene esposto a internet. Ciò che cambia è che puoi finalmente interrogarlo, e può farlo anche un agente di coding IA, in sola lettura.
Come AgentsRoom raggiunge un'istanza RDS in una subnet privata tramite AWS Systems Manager, senza aprire nulla verso internet.
La situazione è abbastanza comune da risultare banale, e abbastanza fastidiosa da costare un pomeriggio. Un'istanza Amazon RDS sta in una subnet privata. Non ha endpoint pubblico. Il suo security group accetta traffico dall'applicazione, e da nient'altro. In quel VPC non c'è nessuna porta SSH in ingresso, perché qualcuno ha fatto la cosa giusta e l'ha chiusa. E adesso ti servono tre righe di tabella per capire un bug.
AWS Systems Manager Session Manager risolve già il trasporto. Un nodo gestito EC2 dentro il VPC può inoltrare una porta locale della tua macchina verso un terzo host che riesce a raggiungere, ed è esattamente ciò che è un'istanza RDS in una subnet privata. Il documento che se ne occupa è AWS-StartPortForwardingSessionToRemoteHost, e il comando è aws ssm start-session. Niente di esotico, niente da installare sul database.
AgentsRoom esegue quel comando al posto tuo e mette un client SQL all'altro capo. Scegli una volta l'istanza, la regione e il profilo, ci colleghi una connessione al database, e da lì in poi aprire quel database è questione di un clic. La sessione è autorizzata dal tuo profilo AWS o dal tuo accesso SSO, quindi per il salto in sé non viene conservata nessuna chiave e nessuna password.
Le solite scorciatoie hanno tutte un prezzo
Tre risposte allo stesso problema, e quello che ciascuna ti fa pagare.
Un bastion host da mantenere
Una jump box in una subnet pubblica è un server che aggiorni, monitori, paghi e prima o poi dimentichi. Si porta dietro una porta SSH in ingresso, una lista di chiavi autorizzate che si sfilaccia man mano che le persone arrivano e se ne vanno, e un security group che dista una modifica distratta dall'essere aperto al mondo. Esiste solo perché ogni tanto qualcuno possa raggiungere un database.
Una VPN per una domanda da tre righe
Una VPN client mette tutta la tua macchina dentro la rete per rispondere a una domanda su tre righe. Va predisposta, distribuita, rinnovata e revocata, litiga con il resto della tua connettività, e su un portatile che passa da una rete all'altra è il pezzo che si rompe per primo. La maggior parte dei team che ne ha una si tiene comunque un bastion accanto.
Credenziali copiate in giro
L'alternativa a cui tutti ripiegano è peggiore: l'endpoint e la password finiscono in un messaggio di chat, in una nota condivisa, in uno script committato per sbaglio o in un prompt inviato a un agente IA. L'accesso si diffonde in posti che nessuno sta tracciando, e revocarlo dopo significa ruotare una credenziale e sperare che ogni copia sia sparita.
Da un'istanza RDS privata a un insieme di risultati
Quattro passaggi, fatti una volta sola, poi basta un clic.
Salva una connessione AWS SSM
Nel gestore di connessioni, aggiungi una connessione e imposta il suo trasporto su AWS SSM. Le dai l'ID istanza di un nodo gestito EC2 in grado di raggiungere il database (i-0123456789abcdef0), il tuo profilo AWS e la regione. Non c'è nessun campo password e nessun campo chiave, perché la sessione è autorizzata dalle credenziali AWS già presenti sulla tua macchina.
Aggiungi il database e raggiungilo tramite quella connessione
Aggiungi una connessione MySQL o MariaDB con l'endpoint RDS come host, la porta, l'utente e il database. Nel campo Raggiungi tramite, scegli la connessione AWS SSM appena salvata invece di Connessione diretta. È tutta qui la configurazione: l'endpoint resta privato, il security group resta chiuso.
AgentsRoom apre la sessione
Quando apri la connessione, AgentsRoom chiede al sistema operativo una porta di loopback libera, poi avvia aws ssm start-session con il documento AWS-StartPortForwardingSessionToRemoteHost, passando l'endpoint RDS come host, la porta del database come portNumber e la porta riservata come localPortNumber. Aspetta che quella porta accetti davvero una connessione TCP prima di dichiarare pronto il tunnel, così il client non si collega mai troppo presto.
Interrogalo, o lascia che lo interroghi un agente
La console SQL si collega a 127.0.0.1 sulla porta inoltrata e si comporta come qualsiasi altra connessione: esplorazione dello schema, una istruzione alla volta, risultati limitati. Un agente di coding IA può interrogare la stessa connessione via MCP, in sola lettura, senza ricevere mai la password. Chiudere la connessione termina con sé il processo della sessione.
Il comando che AgentsRoom lancia
Qui non c'è nessun protocollo proprietario e nulla viene reimplementato in JavaScript. AgentsRoom lancia la AWS CLI come processo figlio, con gli argomenti passati direttamente invece che attraverso una shell, e ne legge l'output. Se hai già aperto a mano una sessione di port forwarding, questa è la riga che conosci già.
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-1L'ID istanza, l'endpoint, la regione e il profilo vengono dalla connessione che hai salvato. La porta locale viene scelta dal sistema operativo al momento dell'apertura.
Inoltrare verso il nodo gestito stesso, invece che verso un database dietro di esso, è lo stesso documento con host=localhost. Ecco perché lo stesso tipo di connessione copre sia un database in una subnet privata sia un servizio in esecuzione sull'istanza a cui sei connesso.
Cosa deve essere vero perché funzioni
AgentsRoom pilota la tua configurazione AWS, non la sostituisce. Cinque cose devono essere al loro posto, e sono le stesse cinque che Session Manager richiede per conto suo.
La AWS CLI sulla tua macchina
AgentsRoom richiama direttamente il binario aws. Se aws ssm start-session funziona nel tuo terminale, funziona anche qui.
Il session-manager-plugin
Session Manager ha bisogno del suo plugin installato accanto alla CLI. Senza, la sessione termina subito e AgentsRoom ti mostra l'errore stampato dalla CLI invece di restare bloccato.
Un profilo AWS o un accesso SSO funzionante
L'autorizzazione arriva dalle tue credenziali, passate come --profile e --region. AgentsRoom conserva il nome del profilo e la regione, mai una chiave, mai un segreto.
Un nodo gestito nel VPC
Un'istanza EC2 registrata in Systems Manager, con l'SSM Agent in esecuzione e un profilo istanza che autorizza la sessione. È il nodo attraverso cui passa il traffico, e non ha bisogno di nessuna porta in ingresso propria.
Un percorso dal nodo al database
Il security group del database deve accettare il traffico del nodo sulla porta del database, e la tua policy IAM deve autorizzare ssm:StartSession con quel documento. Nel VPC non deve cambiare nient'altro.
Cosa fa il tunnel, e cosa si rifiuta di fare
Le proprietà che decidono se è prudente lasciarlo configurato su un portatile.
Solo loopback
La porta inoltrata è associata a 127.0.0.1 e a nient'altro. Un database raggiunto in questo modo non viene mai ripubblicato sulla rete locale, quindi il Wi-Fi di un bar non trasforma il tuo portatile in un proxy aperto verso la produzione.
Una porta scelta dal sistema operativo
AgentsRoom chiede al sistema operativo una porta libera e la passa alla sessione. Non c'è nessuna porta fissa da indovinare, niente da riservare in anticipo e nessuna collisione con quello che stai già eseguendo.
Pronto vuol dire pronto
Il tunnel si considera aperto solo quando la porta locale accetta davvero una connessione TCP, e rinuncia mostrando l'errore stampato dalla CLI se questo non accade mai. Nessuna attesa arbitraria, nessun client che si collega a una porta non ancora in ascolto.
Nessuna chiave, nessuna password per il salto
La sessione SSM è autorizzata dal tuo profilo AWS o dalla tua sessione SSO. AgentsRoom conserva l'ID istanza, il nome del profilo e la regione, e nulla che possa essere riutilizzato da chiunque legga quella configurazione.
Il database resta in sola lettura
Una connessione al database nasce in sola lettura. Una scrittura richiede che quella specifica connessione sia stata resa scrivibile e una conferma esplicita, e una connessione contrassegnata come produzione lo dichiara ad alta voce in quella conferma.
Una sola istruzione per chiamata
Ogni chiamata porta esattamente un'istruzione, quindi nulla si nasconde dietro un punto e virgola, e i risultati sono limitati perché una query troppo ampia non possa sommergere una finestra o il contesto di un agente.
Perché questo è meno accesso, non di più
Un tunnel suona come un buco, e il riflesso è giusto: la maggior parte dei modi di raggiungere un database privato allarga davvero la superficie di attacco. Questo la restringe. Sul lato del database non viene aperto nulla, in nessun punto del VPC viene creata una porta in ingresso, e il nodo gestito non ha bisogno di un proprio listener SSH. Il traffico esce dal nodo verso il servizio Systems Manager, e la tua macchina lo raggiunge lì.
L'autorizzazione resta dove la tua organizzazione la gestisce già. La sessione è concessa dalla tua identità AWS, tramite il profilo o l'accesso SSO già configurato sulla macchina, il che significa che viene registrata come qualsiasi altra sessione Session Manager, revocata il giorno in cui quell'identità viene revocata, e delimitata da una policy IAM invece che da chi si trova ad avere una chiave in mano. AgentsRoom conserva l'ID istanza, il nome del profilo e la regione: niente di tutto questo è una credenziale.
Sul lato del database le protezioni sono le stesse che riceve ogni connessione AgentsRoom. Sola lettura per impostazione predefinita, una sola istruzione per chiamata, risultati limitati e un contrassegno di produzione che irrigidisce la conferma di scrittura. Un agente IA che interroga via MCP ottiene un insieme di risultati e mai la password, e lo strumento con cui interroga rifiuta tutto ciò che non è una lettura, qualunque cosa la connessione permetta di fare a una persona.
Solo MySQL e MariaDB, e PostgreSQL non è tra questi
Il client database parla il protocollo di rete MySQL, quindi i motori che funzionano sono MySQL e MariaDB. Su RDS questo significa RDS for MySQL, RDS for MariaDB e le edizioni Aurora compatibili con MySQL. RDS for PostgreSQL e Aurora PostgreSQL non sono supportati, e nemmeno SQL Server, Oracle, MongoDB o SQLite. Meriti di saperlo prima del download, non dopo.
Il trasporto SSM in sé è indipendente dal motore, dato che inoltra una porta TCP. Quello che manca per PostgreSQL è il client sopra di esso, non il tunnel sotto. Quale motore arriva dopo lo decide ciò che le persone chiedono, quindi se manca il tuo, dì quale sul backlog pubblico e verrà conteggiato.
Richiedi il tuo motore di databaseAnche un agente può interrogarlo, in sola lettura
Una volta creata la connessione, un agente di coding IA può usarla tramite AgentsRoom MCP nominandola. db_list restituisce le connessioni salvate e i loro metadati, db_schema percorre gli schemi, le tabelle e le colonne senza una riga di SQL, db_query esegue una sola istruzione e restituisce righe limitate, e db_connection_new propone un database non ancora salvato precompilando il modulo che tu rivedi e salvi.
Quando l'agente lo chiede, è AgentsRoom ad aprire la sessione SSM, quindi l'agente non maneggia mai una credenziale AWS, una password di database o un numero di porta. Ciò che torna indietro è un insieme di risultati. db_query è in sola lettura qualunque cosa la connessione permetta, e quella regola vive nell'app desktop invece che nel processo MCP, quindi tiene anche se l'agente viene convinto a chiedere qualcos'altro.
È tutto qui il senso di farlo per bene. Un agente che indaga su una replica di produzione in una subnet privata legge le righe che spiegano il bug, e non ha nessuna strada per modificarle, nessuna credenziale da far trapelare nel suo contesto e nessun modo di raggiungere quel database una volta chiusa l'app.
FAQ
Come mi connetto a un'istanza RDS che non ha endpoint pubblico?
Tramite una sessione di port forwarding AWS SSM. Salva una connessione AWS SSM che punta a un nodo gestito EC2 in grado di raggiungere il database, poi crea la connessione MySQL o MariaDB con l'endpoint RDS come host e scegli quella connessione SSM nel campo Raggiungi tramite. AgentsRoom apre la sessione con aws ssm start-session e collega il client SQL alla porta di loopback inoltrata. Il database non acquisisce nessun endpoint pubblico e il suo security group resta invariato.
Quale documento SSM usa AgentsRoom?
AWS-StartPortForwardingSessionToRemoteHost, con host impostato sull'endpoint del database, portNumber sulla porta del database e localPortNumber sulla porta di loopback riservata sulla tua macchina. Quel documento inoltra attraverso il nodo gestito verso un terzo host, che è esattamente il caso di un'istanza RDS in una subnet privata. Inoltrare verso il nodo stesso è lo stesso documento con host=localhost.
Mi serve ancora un bastion host?
No. Session Manager sostituisce la jump box per questo caso d'uso: il nodo gestito non ha bisogno di nessuna porta SSH in ingresso né di un IP pubblico, il traffico esce dal nodo verso il servizio Systems Manager e la tua macchina si unisce alla sessione dall'esterno. Non c'è nessuna lista di chiavi da mantenere e nessuna subnet pubblica da tenere d'occhio.
Cosa devo avere installato sulla mia macchina?
La AWS CLI e il session-manager-plugin, più un profilo AWS o un accesso SSO funzionante. AgentsRoom richiama direttamente il binario aws, quindi se aws ssm start-session funziona nel tuo terminale funziona anche qui. Se il plugin manca, la sessione termina subito e AgentsRoom ti mostra l'errore stampato dalla CLI invece di restare appeso a un prompt invisibile.
AgentsRoom conserva una chiave AWS per tutto questo?
No. La sessione è autorizzata dalle credenziali AWS già configurate sulla tua macchina, passate alla CLI come --profile e --region. AgentsRoom conserva l'ID istanza, il nome del profilo e la regione, che non sono credenziali. La password del database è un'altra cosa: resta nella cassaforte, cifrata tramite il portachiavi del tuo sistema operativo, e non viene mai restituita a un agente IA.
Quale porta locale usa il tunnel, e chi può raggiungerla?
Il sistema operativo sceglie una porta libera al momento dell'apertura, e il tunnel la associa solo a 127.0.0.1. Nulla sulla rete locale può raggiungerla, e non c'è nessuna porta fissa da indovinare. Il tunnel è considerato pronto solo quando quella porta accetta davvero una connessione TCP, e viene chiuso insieme alla connessione.
Funziona con RDS for PostgreSQL?
No. Il client database supporta solo MySQL e MariaDB, quindi su RDS significa RDS for MySQL, RDS for MariaDB e le edizioni Aurora compatibili con MySQL. RDS for PostgreSQL e Aurora PostgreSQL oggi non sono supportati, e nemmeno SQL Server, Oracle, MongoDB o SQLite. Il tunnel SSM in sé inoltra una porta TCP e del motore non si cura: quello che manca è il client sopra di esso. Chiedi un motore sul backlog pubblico e verrà conteggiato.
Posso inoltrare verso l'istanza EC2 stessa invece che verso un database?
Sì. È lo stesso documento con host=localhost, quindi un servizio in ascolto sul nodo gestito è raggiungibile allo stesso modo. La stessa connessione AWS SSM apre anche una normale sessione di terminale su quell'istanza, ed è così che esegui una CLI di agente su una macchina che non ha alcuna porta SSH in ingresso.
Un agente IA può interrogare il database attraverso il tunnel?
Sì, in sola lettura. Un agente nomina una connessione salvata tramite AgentsRoom MCP, l'app apre la sessione SSM ed esegue l'istruzione da sé, e torna indietro solo l'insieme dei risultati. L'agente non riceve mai il profilo AWS, le credenziali dell'endpoint o la password del database, e db_query rifiuta tutto ciò che non è una lettura, qualunque cosa quella connessione permetta di fare a una persona.
Potrebbe interessarti anche
Connessioni database
Salva le tue connessioni MySQL e MariaDB, raggiungi un database in una subnet privata tramite un tunnel SSH o una sessione AWS SSM, e lascia che i tuoi agenti IA lo interroghino via MCP. In sola lettura per impostazione predefinita, una sola istruzione per chiamata, risultati limitati, e la password non arriva mai all'agente.
Connessioni SSH
Salva le tue connessioni SSH, apri un terminale SSH integrato ed esegui Claude Code, Codex o Antigravity CLI direttamente sul tuo server remoto o VPS. Autenticazione con chiave SSH o password, profili di connessione per progetto, senza un client SSH separato.
Gestore di segreti
Conserva chiavi API, token e password nel portachiavi del tuo sistema operativo, richiamali come {{secret:NAME}} nei comandi di sviluppo e negli ambienti degli agenti, e lascia che AgentsRoom li risolva all'avvio. Gli agenti vedono i nomi, mai i valori, e nulla viene mai sincronizzato su un server.
Remote Fleet
Esegui agenti di codifica Claude, Codex e Antigravity su ogni Mac che possiedi e invita i membri del team a collaborare sugli stessi agenti in tempo reale. Mac da ufficio, Mac da casa, server di build, progetti di team condivisi : tutto in un'unica vista unificata e crittografata end-to-end.
Interroga il database che nessuno riesce a raggiungere
Scarica AgentsRoom, salva una connessione AWS SSM, puntaci un database MySQL o MariaDB e interroga la tua istanza RDS privata senza un bastion, una VPN o una password condivisa.
App companion: monitora i tuoi agenti in movimento
Usa Claude, Codex, Antigravity CLI o un altro provider IA.
Invia bug e richieste direttamente nel tuo backlog pubblico.
Uno sguardo ad AgentsRoom in azione.