आपके RDS इंस्टेंस का कोई पब्लिक एंडपॉइंट नहीं है।
उस तक AWS SSM से पहुंचें, बिना किसी bastion के।
AgentsRoom आपके डेटाबेस तक एक AWS Session Manager पोर्ट-फ़ॉरवर्डिंग सेशन खोलता है और अपना SQL क्लाइंट उसी से जोड़ता है। यह सेशन aws ssm start-session को AWS-StartPortForwardingSessionToRemoteHost डॉक्यूमेंट के साथ चलाता है, जिसे आपकी मशीन पर पहले से कॉन्फ़िगर की गई AWS प्रोफ़ाइल अधिकृत करती है।
डेटाबेस अपने प्राइवेट सबनेट में ही रहता है, सिक्योरिटी ग्रुप बंद ही रहता है, और इंटरनेट के सामने कुछ भी नया उजागर नहीं होता। बदलता सिर्फ़ इतना है कि आप आख़िरकार उसे क्वेरी कर सकते हैं, और कोई AI कोडिंग एजेंट भी, रीड-ओनली।
AgentsRoom कैसे AWS Systems Manager के ज़रिए किसी प्राइवेट सबनेट के RDS इंस्टेंस तक पहुंचता है, बिना इंटरनेट के सामने कुछ भी खोले।
यह सेटअप इतना आम है कि उबाऊ लगे, और इतना तकलीफ़देह कि एक पूरी दोपहर खा जाए। एक Amazon RDS इंस्टेंस किसी प्राइवेट सबनेट में बैठा है। उसका कोई पब्लिक एंडपॉइंट नहीं है। उसका सिक्योरिटी ग्रुप सिर्फ़ एप्लिकेशन से ट्रैफ़िक स्वीकार करता है, और किसी से नहीं। उस पूरे VPC में कहीं कोई इनबाउंड SSH पोर्ट नहीं है, क्योंकि किसी ने सही काम किया और उसे बंद कर दिया। और अब किसी बग को समझने के लिए आपको तीन पंक्तियां देखनी हैं।
AWS Systems Manager Session Manager ट्रांसपोर्ट की समस्या पहले ही हल कर चुका है। VPC के भीतर मौजूद एक मैनेज्ड EC2 नोड आपकी मशीन के किसी लोकल पोर्ट को उस तीसरे होस्ट तक फ़ॉरवर्ड कर सकता है जहां तक वह पहुंच सकता है, और प्राइवेट सबनेट में बैठा RDS इंस्टेंस ठीक यही है। यह काम करने वाला डॉक्यूमेंट AWS-StartPortForwardingSessionToRemoteHost है, और कमांड है aws ssm start-session। कुछ भी अनोखा नहीं, डेटाबेस पर इंस्टॉल करने के लिए कुछ भी नहीं।
AgentsRoom वह कमांड आपके लिए चलाता है और दूसरे सिरे पर एक SQL क्लाइंट लगा देता है। आप इंस्टेंस, रीजन और प्रोफ़ाइल एक बार चुनते हैं, उससे एक डेटाबेस कनेक्शन जोड़ते हैं, और उसके बाद उस डेटाबेस को खोलना बस एक क्लिक का काम है। सेशन आपकी अपनी AWS प्रोफ़ाइल या SSO लॉगिन से अधिकृत होता है, इसलिए इस हॉप के लिए न कोई की सहेजी जाती है, न कोई पासवर्ड।
इसके आम रास्ते सब कुछ न कुछ वसूलते हैं
एक ही समस्या के तीन जवाब, और हर एक आपसे क्या वसूलता है।
एक bastion होस्ट, जिसका रखरखाव करना पड़ता है
पब्लिक सबनेट में बैठा जंप बॉक्स एक ऐसा सर्वर है जिसे आप पैच करते हैं, मॉनिटर करते हैं, जिसका बिल भरते हैं और आख़िर में भूल जाते हैं। उसके साथ एक इनबाउंड SSH पोर्ट आता है, अधिकृत कीज़ की एक सूची जो लोगों के आने-जाने के साथ खिसकती रहती है, और एक सिक्योरिटी ग्रुप जो एक लापरवाह एडिट भर दूर है पूरी दुनिया के सामने खुल जाने से। वह सिर्फ़ इसलिए मौजूद है ताकि कोई कभी-कभार किसी डेटाबेस तक पहुंच सके।
तीन पंक्तियों के सवाल के लिए एक VPN
क्लाइंट VPN तीन पंक्तियों का जवाब पाने के लिए आपकी पूरी मशीन को नेटवर्क के अंदर डाल देता है। उसे प्रोविज़न करना, बांटना, नवीनीकृत करना और रद्द करना पड़ता है, वह आपकी बाक़ी कनेक्टिविटी से झगड़ता है, और नेटवर्क बदलते रहने वाले लैपटॉप पर सबसे पहले वही टूटता है। जिन टीमों के पास VPN है, उनमें से ज़्यादातर उसके बगल में एक bastion भी रखती हैं।
इधर-उधर कॉपी किए गए क्रेडेंशियल
जिस विकल्प पर हर कोई लौट आता है वह और भी बुरा है : एंडपॉइंट और पासवर्ड किसी चैट मैसेज, किसी साझा नोट, गलती से कमिट हुई किसी स्क्रिप्ट, या किसी AI एजेंट को भेजे गए प्रॉम्प्ट में जा पहुंचते हैं। एक्सेस ऐसी जगहों तक फैल जाता है जिन पर कोई नज़र नहीं रखता, और बाद में उसे वापस लेने का मतलब है क्रेडेंशियल बदलना और उम्मीद करना कि हर कॉपी मिट चुकी है।
एक प्राइवेट RDS इंस्टेंस से रिज़ल्ट सेट तक
चार चरण, एक ही बार के, फिर बस एक क्लिक।
एक AWS SSM कनेक्शन सहेजें
कनेक्शन मैनेजर में एक कनेक्शन जोड़ें और उसका ट्रांसपोर्ट AWS SSM पर सेट करें। आप उसे ऐसे मैनेज्ड EC2 नोड की इंस्टेंस ID देते हैं जो डेटाबेस तक पहुंच सकता है (i-0123456789abcdef0), साथ में अपनी AWS प्रोफ़ाइल और रीजन। यहां न पासवर्ड फ़ील्ड है न की फ़ील्ड, क्योंकि सेशन को आपकी मशीन पर पहले से मौजूद AWS क्रेडेंशियल अधिकृत करते हैं।
डेटाबेस जोड़ें और उसी कनेक्शन के ज़रिए उस तक पहुंचें
RDS एंडपॉइंट को होस्ट बनाकर, पोर्ट, यूज़र और डेटाबेस के साथ एक MySQL या MariaDB कनेक्शन जोड़ें। Reach through फ़ील्ड में Direct connection के बजाय वही AWS SSM कनेक्शन चुनें जो आपने अभी सहेजा है। पूरा कॉन्फ़िगरेशन बस इतना ही है : एंडपॉइंट प्राइवेट रहता है, सिक्योरिटी ग्रुप बंद रहता है।
AgentsRoom सेशन खोलता है
जब आप कनेक्शन खोलते हैं, AgentsRoom ऑपरेटिंग सिस्टम से एक खाली loopback पोर्ट मांगता है, फिर aws ssm start-session को AWS-StartPortForwardingSessionToRemoteHost डॉक्यूमेंट के साथ शुरू करता है, जिसमें RDS एंडपॉइंट host के रूप में, डेटाबेस पोर्ट portNumber के रूप में और आरक्षित पोर्ट localPortNumber के रूप में जाता है। सुरंग को तैयार घोषित करने से पहले वह इंतज़ार करता है कि वह पोर्ट सचमुच TCP कनेक्शन स्वीकार करे, ताकि क्लाइंट कभी बहुत जल्दी न जुड़ जाए।
उसे क्वेरी करें, या किसी एजेंट से करवाएं
SQL कंसोल फ़ॉरवर्ड किए गए पोर्ट पर 127.0.0.1 से जुड़ता है और किसी भी दूसरे कनेक्शन जैसा ही व्यवहार करता है : स्कीमा ब्राउज़र, एक बार में एक स्टेटमेंट, सीमित रिज़ल्ट सेट। कोई AI कोडिंग एजेंट उसी कनेक्शन को MCP पर क्वेरी कर सकता है, रीड-ओनली, बिना कभी पासवर्ड पाए। कनेक्शन बंद करते ही सेशन की प्रोसेस भी उसके साथ ख़त्म हो जाती है।
AgentsRoom जो कमांड चलाता है
यहां कोई प्रोप्राइटरी प्रोटोकॉल नहीं है और JavaScript में कुछ भी दोबारा नहीं लिखा गया। AgentsRoom, AWS CLI को एक चाइल्ड प्रोसेस के रूप में चलाता है, आर्गुमेंट किसी शेल के बजाय सीधे भेजता है, और उसका आउटपुट पढ़ता है। अगर आपने कभी हाथ से कोई पोर्ट-फ़ॉरवर्डिंग सेशन खोला है, तो यह वही लाइन है जो आप पहले से जानते हैं।
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-1इंस्टेंस ID, एंडपॉइंट, रीजन और प्रोफ़ाइल उसी कनेक्शन से आते हैं जो आपने सहेजा है। लोकल पोर्ट खोलने के समय ऑपरेटिंग सिस्टम चुनता है।
किसी डेटाबेस के बजाय मैनेज्ड नोड तक ही फ़ॉरवर्ड करना उसी डॉक्यूमेंट से होता है, बस host=localhost के साथ। इसीलिए एक ही कनेक्शन टाइप प्राइवेट सबनेट के डेटाबेस और उस इंस्टेंस पर चल रही सर्विस, दोनों को कवर करता है जिससे आप जुड़े हैं।
काम करने से पहले क्या-क्या ज़रूरी है
AgentsRoom आपके AWS सेटअप को चलाता है, उसकी जगह नहीं लेता। पांच चीज़ें अपनी जगह होनी चाहिए, और ये वही पांच हैं जो Session Manager को अकेले भी चाहिए।
आपकी मशीन पर AWS CLI
AgentsRoom सीधे aws बाइनरी को कॉल करता है। अगर आपके टर्मिनल में aws ssm start-session चलता है, तो यहां भी चलेगा।
session-manager-plugin
Session Manager को CLI के साथ उसका प्लगइन इंस्टॉल चाहिए। उसके बिना सेशन तुरंत बंद हो जाता है और AgentsRoom अटकने के बजाय आपको वही एरर दिखाता है जो CLI ने छापा।
काम करती हुई AWS प्रोफ़ाइल या SSO लॉगिन
अधिकार आपके अपने क्रेडेंशियल से आता है, जो --profile और --region के रूप में भेजे जाते हैं। AgentsRoom प्रोफ़ाइल का नाम और रीजन सहेजता है, कोई की कभी नहीं, कोई सीक्रेट कभी नहीं।
VPC में एक मैनेज्ड नोड
Systems Manager में रजिस्टर किया गया एक EC2 इंस्टेंस, जिस पर SSM Agent चल रहा हो और जिसका इंस्टेंस प्रोफ़ाइल उस सेशन की अनुमति देता हो। ट्रैफ़िक इसी नोड से होकर गुज़रता है, और उसे अपना कोई इनबाउंड पोर्ट नहीं चाहिए।
नोड से डेटाबेस तक एक रास्ता
डेटाबेस के सिक्योरिटी ग्रुप को डेटाबेस पोर्ट पर उस नोड से ट्रैफ़िक स्वीकार करना होगा, और आपकी IAM पॉलिसी को उस डॉक्यूमेंट के साथ ssm:StartSession की अनुमति देनी होगी। VPC में इसके अलावा कुछ भी बदलने की ज़रूरत नहीं।
सुरंग क्या करती है, और क्या करने से मना करती है
वे गुण जो तय करते हैं कि इसे किसी लैपटॉप पर कॉन्फ़िगर छोड़ देना सुरक्षित है या नहीं।
सिर्फ़ loopback
फ़ॉरवर्ड किया गया पोर्ट सिर्फ़ 127.0.0.1 से बंधा होता है, और किसी से नहीं। इस तरह पहुंचा गया डेटाबेस लोकल नेटवर्क पर दोबारा प्रकाशित नहीं होता, इसलिए किसी कैफ़े का Wi-Fi आपके लैपटॉप को प्रोडक्शन तक खुला प्रॉक्सी नहीं बना देता।
OS का चुना हुआ पोर्ट
AgentsRoom ऑपरेटिंग सिस्टम से एक खाली पोर्ट मांगता है और उसे सेशन को सौंप देता है। अंदाज़ा लगाने के लिए कोई तय पोर्ट नहीं, पहले से आरक्षित करने के लिए कुछ नहीं, और आप जो कुछ और चला रहे हैं उससे कोई टकराव नहीं।
तैयार का मतलब सचमुच तैयार
सुरंग तभी तैयार मानी जाती है जब लोकल पोर्ट सचमुच TCP कनेक्शन स्वीकार करने लगे, और अगर ऐसा कभी न हो तो वह CLI के छापे गए एरर के साथ हार मान लेती है। कोई मनमानी प्रतीक्षा नहीं, कोई क्लाइंट ऐसे पोर्ट से नहीं जुड़ता जो अभी सुन ही नहीं रहा।
इस हॉप के लिए न कोई की, न कोई पासवर्ड
SSM सेशन को आपकी AWS प्रोफ़ाइल या SSO सेशन अधिकृत करता है। AgentsRoom इंस्टेंस ID, प्रोफ़ाइल का नाम और रीजन सहेजता है, और ऐसा कुछ नहीं जिसे वह कॉन्फ़िगरेशन पढ़ने वाला कोई दोबारा इस्तेमाल कर सके।
डेटाबेस रीड-ओनली ही रहता है
डेटाबेस कनेक्शन बनते समय रीड-ओनली होता है। किसी राइट के लिए उसी कनेक्शन को राइटेबल बनाना और एक स्पष्ट पुष्टि, दोनों चाहिए, और प्रोडक्शन के रूप में चिह्नित कनेक्शन उस पुष्टि में यह बात खुलकर कहता है।
प्रति कॉल एक स्टेटमेंट
हर कॉल में ठीक एक स्टेटमेंट जाता है, इसलिए किसी सेमीकोलन के पीछे कुछ नहीं छिपता, और रिज़ल्ट सेट सीमित होते हैं ताकि कोई चौड़ी क्वेरी किसी विंडो या एजेंट कॉन्टेक्स्ट को भर न दे।
यह ज़्यादा नहीं, कम एक्सेस क्यों है
सुरंग सुनते ही छेद का ख़याल आता है, और यह प्रतिक्रिया सही है : किसी प्राइवेट डेटाबेस तक पहुंचने के ज़्यादातर तरीक़े हमले की सतह बढ़ा ही देते हैं। यह वाला उसे घटाता है। डेटाबेस की तरफ़ कुछ नहीं खोला जाता, VPC में कहीं कोई इनबाउंड पोर्ट नहीं बनता, और मैनेज्ड नोड को अपना कोई SSH लिसनर नहीं चाहिए। ट्रैफ़िक नोड से बाहर Systems Manager सर्विस की ओर जाता है, और आपकी मशीन उससे वहीं मिलती है।
अधिकार वहीं रहता है जहां आपका संगठन उसे पहले से संभालता है। सेशन आपकी AWS पहचान से मिलता है, उसी प्रोफ़ाइल या SSO लॉगिन के ज़रिए जो मशीन पर पहले से कॉन्फ़िगर है, यानी वह किसी भी दूसरे Session Manager सेशन की तरह लॉग होता है, उसी दिन रद्द हो जाता है जिस दिन वह पहचान रद्द होती है, और किसी के पास की होने के बजाय एक IAM पॉलिसी से सीमित होता है। AgentsRoom इंस्टेंस ID, प्रोफ़ाइल का नाम और रीजन सहेजता है : इनमें से कोई भी क्रेडेंशियल नहीं है।
डेटाबेस की तरफ़ गार्डरेल वही हैं जो AgentsRoom के हर कनेक्शन को मिलते हैं। डिफ़ॉल्ट रूप से रीड-ओनली, प्रति कॉल एक स्टेटमेंट, सीमित रिज़ल्ट सेट, और एक प्रोडक्शन फ़्लैग जो राइट की पुष्टि को कठिन बना देता है। MCP पर क्वेरी करते किसी AI एजेंट को रिज़ल्ट सेट मिलता है, पासवर्ड कभी नहीं, और वह जिस टूल से क्वेरी करता है वह रीड के अलावा कुछ भी अस्वीकार करता है, चाहे वह कनेक्शन किसी इंसान को कुछ भी करने दे।
सिर्फ़ MySQL और MariaDB, और PostgreSQL उनमें नहीं है
डेटाबेस क्लाइंट MySQL वायर प्रोटोकॉल बोलता है, इसलिए जो इंजन काम करते हैं वे MySQL और MariaDB हैं। RDS पर इसका मतलब है RDS for MySQL, RDS for MariaDB और Aurora MySQL-compatible एडिशन। RDS for PostgreSQL और Aurora PostgreSQL समर्थित नहीं हैं, और न ही SQL Server, Oracle, MongoDB या SQLite। यह जानने का हक़ आपको डाउनलोड के बाद नहीं, उससे पहले है।
SSM ट्रांसपोर्ट खुद इंजन से बेपरवाह है, क्योंकि वह सिर्फ़ एक TCP पोर्ट फ़ॉरवर्ड करता है। PostgreSQL के लिए जो कमी है वह उसके ऊपर बैठने वाला क्लाइंट है, नीचे की सुरंग नहीं। अगला इंजन कौन सा आएगा यह इससे तय होता है कि लोग क्या मांगते हैं, इसलिए अगर आपका इंजन नदारद है, तो सार्वजनिक बैकलॉग पर बताएं कि कौन सा, और वह गिना जाएगा।
अपने डेटाबेस इंजन की मांग करेंकोई एजेंट भी उसे क्वेरी कर सकता है, रीड-ओनली
कनेक्शन बन जाने के बाद, कोई AI कोडिंग एजेंट उसका नाम लेकर AgentsRoom MCP के ज़रिए उसका इस्तेमाल कर सकता है। db_list सहेजे गए कनेक्शन और उनका मेटाडेटा लौटाता है, db_schema एक लाइन SQL के बिना स्कीमा, टेबल और कॉलम में घूमता है, db_query एक स्टेटमेंट चलाता है और सीमित पंक्तियां लौटाता है, और db_connection_new ऐसा डेटाबेस सुझाता है जो अभी सहेजा नहीं गया है, वह फ़ॉर्म पहले से भरकर जिसकी आप समीक्षा करते हैं और सहेजते हैं।
एजेंट के मांगने पर SSM सेशन AgentsRoom खुद खोलता है, इसलिए एजेंट के हाथ में न कोई AWS क्रेडेंशियल आता है, न डेटाबेस पासवर्ड, न कोई पोर्ट नंबर। वापस सिर्फ़ एक रिज़ल्ट सेट जाता है। db_query रीड-ओनली है, चाहे कनेक्शन कुछ भी होने दे, और यह नियम MCP प्रोसेस के बजाय डेस्कटॉप ऐप में रहता है, इसलिए वह तब भी टिका रहता है जब एजेंट को कुछ और मांगने के लिए बहला लिया जाए।
इसे ठीक से करने का पूरा मतलब यही है। प्राइवेट सबनेट के किसी प्रोडक्शन रेप्लिका पर डिबग कर रहा एजेंट वे पंक्तियां पढ़ता है जो बग समझाती हैं, और उसके पास उन्हें बदलने का कोई रास्ता नहीं है, अपने कॉन्टेक्स्ट में लीक करने के लिए कोई क्रेडेंशियल नहीं, और ऐप बंद होने के बाद उस डेटाबेस तक पहुंचने का कोई ज़रिया नहीं।
अक्सर पूछे जाने वाले सवाल
बिना पब्लिक एंडपॉइंट वाले RDS इंस्टेंस से मैं कैसे जुड़ूं?
एक AWS SSM पोर्ट-फ़ॉरवर्डिंग सेशन के ज़रिए। ऐसे मैनेज्ड EC2 नोड की ओर इशारा करता AWS SSM कनेक्शन सहेजें जो डेटाबेस तक पहुंच सकता हो, फिर RDS एंडपॉइंट को होस्ट बनाकर MySQL या MariaDB कनेक्शन बनाएं और Reach through फ़ील्ड में वही SSM कनेक्शन चुनें। AgentsRoom aws ssm start-session से सेशन खोलता है और SQL क्लाइंट को फ़ॉरवर्ड किए गए loopback पोर्ट से जोड़ता है। डेटाबेस का कोई पब्लिक एंडपॉइंट नहीं बनता और उसका सिक्योरिटी ग्रुप ज्यों का त्यों रहता है।
AgentsRoom कौन सा SSM डॉक्यूमेंट इस्तेमाल करता है?
AWS-StartPortForwardingSessionToRemoteHost, जिसमें host डेटाबेस एंडपॉइंट पर, portNumber डेटाबेस पोर्ट पर और localPortNumber आपकी मशीन पर आरक्षित loopback पोर्ट पर सेट होता है। वह डॉक्यूमेंट मैनेज्ड नोड के ज़रिए किसी तीसरे होस्ट तक फ़ॉरवर्ड करता है, जो ठीक प्राइवेट सबनेट के RDS इंस्टेंस वाला मामला है। नोड तक ही फ़ॉरवर्ड करना उसी डॉक्यूमेंट से होता है, बस host=localhost के साथ।
क्या मुझे अब भी किसी bastion होस्ट की ज़रूरत है?
नहीं। इस इस्तेमाल के लिए Session Manager जंप बॉक्स की जगह ले लेता है : मैनेज्ड नोड को न कोई इनबाउंड SSH पोर्ट चाहिए न कोई पब्लिक IP, ट्रैफ़िक नोड से बाहर Systems Manager सर्विस की ओर जाता है, और आपकी मशीन बाहर से उस सेशन में शामिल होती है। न कोई की सूची संभालनी है, न किसी पब्लिक सबनेट पर नज़र रखनी है।
मेरी मशीन पर क्या इंस्टॉल होना चाहिए?
AWS CLI और session-manager-plugin, साथ में एक काम करती AWS प्रोफ़ाइल या SSO लॉगिन। AgentsRoom सीधे aws बाइनरी को कॉल करता है, इसलिए अगर आपके टर्मिनल में aws ssm start-session चलता है तो यहां भी चलेगा। प्लगइन न होने पर सेशन तुरंत बंद हो जाता है और AgentsRoom किसी अदृश्य प्रॉम्प्ट पर अटकने के बजाय आपको वही एरर दिखाता है जो CLI ने छापा।
क्या AgentsRoom इसके लिए कोई AWS की सहेजता है?
नहीं। सेशन को आपकी मशीन पर पहले से कॉन्फ़िगर किए गए AWS क्रेडेंशियल अधिकृत करते हैं, जो CLI को --profile और --region के रूप में भेजे जाते हैं। AgentsRoom इंस्टेंस ID, प्रोफ़ाइल का नाम और रीजन सहेजता है, जो क्रेडेंशियल नहीं हैं। डेटाबेस पासवर्ड अलग बात है : वह आपके OS कीचेन से एन्क्रिप्ट होकर वॉल्ट में रखा जाता है, और किसी AI एजेंट को कभी नहीं लौटाया जाता।
सुरंग कौन सा लोकल पोर्ट इस्तेमाल करती है, और उस तक कौन पहुंच सकता है?
खोलते समय ऑपरेटिंग सिस्टम एक खाली पोर्ट चुनता है, और सुरंग उसे सिर्फ़ 127.0.0.1 से बांधती है। लोकल नेटवर्क की कोई चीज़ उस तक नहीं पहुंच सकती, और अंदाज़ा लगाने के लिए कोई तय पोर्ट भी नहीं है। सुरंग तभी तैयार मानी जाती है जब वह पोर्ट सचमुच TCP कनेक्शन स्वीकार करने लगे, और कनेक्शन बंद होते ही वह भी बंद हो जाती है।
क्या यह RDS for PostgreSQL के साथ काम करता है?
नहीं। डेटाबेस क्लाइंट सिर्फ़ MySQL और MariaDB का समर्थन करता है, इसलिए RDS पर इसका मतलब है RDS for MySQL, RDS for MariaDB और Aurora MySQL-compatible एडिशन। RDS for PostgreSQL और Aurora PostgreSQL आज समर्थित नहीं हैं, और न ही SQL Server, Oracle, MongoDB या SQLite। SSM सुरंग खुद एक TCP पोर्ट फ़ॉरवर्ड करती है और उसे इंजन से कोई मतलब नहीं : कमी उसके ऊपर बैठने वाले क्लाइंट की है। सार्वजनिक बैकलॉग पर किसी इंजन की मांग करें और वह गिना जाएगा।
क्या मैं डेटाबेस के बजाय EC2 इंस्टेंस तक ही फ़ॉरवर्ड कर सकता हूं?
हां। वह उसी डॉक्यूमेंट से होता है, बस host=localhost के साथ, इसलिए मैनेज्ड नोड पर सुन रही किसी सर्विस तक भी उसी तरह पहुंचा जा सकता है। वही AWS SSM कनेक्शन उस इंस्टेंस पर एक सादा टर्मिनल सेशन भी खोलता है, और इसी तरह आप ऐसी मशीन पर कोई एजेंट CLI चलाते हैं जिस पर कोई इनबाउंड SSH पोर्ट है ही नहीं।
क्या कोई AI एजेंट सुरंग के ज़रिए डेटाबेस क्वेरी कर सकता है?
हां, रीड-ओनली। एजेंट AgentsRoom MCP के ज़रिए किसी सहेजे गए कनेक्शन का नाम लेता है, ऐप SSM सेशन खोलता है और स्टेटमेंट खुद चलाता है, और वापस सिर्फ़ रिज़ल्ट सेट जाता है। एजेंट को न AWS प्रोफ़ाइल मिलती है, न एंडपॉइंट के क्रेडेंशियल, न डेटाबेस पासवर्ड, और db_query रीड के अलावा कुछ भी अस्वीकार करता है, चाहे वह कनेक्शन किसी इंसान को कुछ भी करने दे।
आपको यह भी पसंद आ सकता है
डेटाबेस कनेक्शन
अपने MySQL और MariaDB कनेक्शन सहेजें, किसी SSH सुरंग या किसी AWS SSM सेशन के ज़रिए प्राइवेट सबनेट के डेटाबेस तक पहुंचें, और अपने AI एजेंट को MCP पर उसे क्वेरी करने दें। डिफ़ॉल्ट रूप से रीड-ओनली, प्रति कॉल एक स्टेटमेंट, सीमित रिज़ल्ट सेट, और पासवर्ड कभी एजेंट तक नहीं पहुंचता।
SSH कनेक्शन
अपने SSH कनेक्शन सहेजें, बिल्ट-इन SSH टर्मिनल खोलें, और Claude Code, Codex या Antigravity CLI को सीधे अपने रिमोट सर्वर या VPS पर चलाएं। SSH की या पासवर्ड से प्रमाणीकरण, प्रति-प्रोजेक्ट कनेक्शन प्रोफ़ाइल, बिना किसी अलग SSH क्लाइंट के।
सीक्रेट मैनेजर
API की, टोकन और पासवर्ड अपने OS कीचेन में रखें, उन्हें डेव कमांड और एजेंट परिवेश में {{secret:NAME}} के रूप में रेफ़र करें, और AgentsRoom को लॉन्च के समय उन्हें हल करने दें। एजेंट नाम देखते हैं, मान कभी नहीं, और कुछ भी किसी सर्वर पर सिंक नहीं होता।
रिमोट फ़्लीट
अपने सभी मैक पर Claude, Codex और Antigravity कोडिंग एजेंट चलाएँ, और टीम के साथियों को वास्तविक समय में एक ही एजेंट पर सहयोग करने के लिए आमंत्रित करें। ऑफिस मशीन, होम मशीन, बिल्ड सर्वर, साझा टीम प्रोजेक्ट: सभी एक एकीकृत, एंड-टू-एंड एन्क्रिप्टेड दृश्य में।
उस डेटाबेस को क्वेरी करें जिस तक कोई पहुंच नहीं पाता
AgentsRoom डाउनलोड करें, एक AWS SSM कनेक्शन सहेजें, उस पर कोई MySQL या MariaDB डेटाबेस लगाएं, और अपने प्राइवेट RDS इंस्टेंस को बिना किसी bastion, VPN या साझा पासवर्ड के क्वेरी करें।
कंपेनियन ऐप: चलते-फिरते अपने एजेंट्स मॉनिटर करें
Claude, Codex, Antigravity CLI या किसी अन्य AI प्रदाता का उपयोग करें।
बग और अनुरोध सीधे अपने सार्वजनिक बैकलॉग में भेजें।
AgentsRoom को कार्य करते देखें।