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