AWS Bedrock keys अब एक आंतरिक LLM गेटवे द्वारा सुरक्षित हैं जो एक फिनटेक फर्म की प्रत्येक टीम को मॉडल कॉल करने की अनुमति देता है, फिर भी प्रत्येक अनुरोध एक प्रति-टीम टोकन बजट से जुड़ा होता है। यह बदलाव रिपॉजिटरी और नोटबुक में IAM क्रेडेंशियल्स को बिखेरने की प्रथा को रोकता है, जो एक ऐसी आदत थी जिसने कंपनी के AI खर्च को एक ही दोपहर में खत्म करने की धमकी दे दी थी।
AWS कीज़ (keys) बांटना जल्दी ही समस्या क्यों बन जाता है
संगठन के गैर-तकनीकी समूहों ने कंपनी के लैंग्वेज मॉडल्स तक सीधी पहुंच मांगी। कागज़ पर सबसे सरल उत्तर AWS में मॉडल्स को सक्षम करना और प्रत्येक समूह को एक IAM अनुमति देना था। दस मिनट का काम, कुछ पॉलिसी संपादन, और काम हो गया—कम से कम सिद्धांत रूप में।
व्यवहार में, IAM क्रेडेंशियल्स देने से तीन छिपी हुई लागतें पैदा होती हैं:
- क्रेडेंशियल स्प्रावल (Credential sprawl) – कीज़
.envफाइलों, CI पाइपलाइनों, Jupyter नोटबुक और एड-हॉक स्क्रिप्ट में चली जाती हैं। रोटेशन की आवश्यकता होने पर प्रत्येक कॉपी विफलता का एक बिंदु बन जाती है। - शून्य दृश्यता (Zero visibility) – एक ही साझा की (key) से यह पता नहीं चलता कि कौन सी टीम या कोड का कौन सा हिस्सा उपयोग उत्पन्न कर रहा है। जब कोई अनियंत्रित लूप शुरू होता है, तो किसी के ध्यान देने से पहले ही पूरा बजट समाप्त हो सकता है।
- परिचालन ओवरहेड (Operational overhead) – किसके पास क्या अनुमति है, इसकी ट्रैकिंग करना, एक्सेस वापस लेना और उपयोग का ऑडिट करना जल्दी ही एक मैन्युअल और त्रुटिपूर्ण प्रक्रिया बन जाता है।
फिनटेक टीम को एहसास हुआ कि यह "त्वरित समाधान" जल्द ही सुरक्षा और लागत का दुस्वप्न बन जाएगा।
इसके बजाय एक रिवर्स-प्रॉक्सी गेटवे बनाना
समाधान हर आंतरिक एप्लिकेशन और AWS Bedrock के बीच एक पतला रिवर्स प्रॉक्सी डालना था। प्रॉक्सी वास्तविक AWS क्रेडेंशियल्स को एक वॉल्ट-सुरक्षित स्थान में रखती है और कॉलर्स को अल्पकालिक, मानव-पठनीय टोकन (उदाहरण के लिए, lllkey_9f3c) जारी करती है।
मुख्य डिज़ाइन बिंदु:
- कोई भी AWS क्रेडेंशियल गेटवे से बाहर नहीं जाता – डेवलपर्स और सेवाएं वास्तविक IAM कीज़ को कभी नहीं देख पाती हैं।
- प्रति-टोकन पॉलिसी प्रवर्तन – प्रत्येक टोकन को एक विशिष्ट मॉडल फैमिली या अधिकतम टोकन काउंट तक सीमित किया जा सकता है।
- पूर्ण ऑडिट ट्रेल – प्रत्येक अनुरोध को एक नाम के साथ लॉग किया जाता है।
गेटवे एक अनुरोध को कैसे प्रोसेस करता है
- टोकन प्राप्त करना – क्लाइंट HTTP हेडर में अपना
llmkey_…टोकन शामिल करता है। - टोकन को मान्य करना – गेटवे टोकन की स्थिति (सक्रिय, समाप्त नहीं हुआ) और यह जांचता है कि क्या अनुरोध आवंटित बजट के भीतर है।
- मॉडल व्हाइटलिस्ट – यह पुष्टि करता है कि अनुरोधित मॉडल उस टोकन के लिए अनुमत है।
- Bedrock को फॉरवर्ड करना – अनुरोध को संग्रहीत IAM क्रेडेंशियल्स का उपयोग करके AWS को भेजा जाता है।
- लॉग और बिलिंग – रिपोर्टिंग के लिए टोकन उपयोग, मॉडल का नाम और लागत का अनुमान एक केंद्रीय डेटाबेस में लिखा जाता है।
चूंकि फिनटेक फर्म को अपना सारा डेटा अपने स्वयं के नेटवर्क के भीतर रखना चाहिए, इसलिए तीसरे पक्ष (third-party) के SaaS विकल्प को खारिज कर दिया गया था।
कंपनी को क्या लाभ हुआ
- मॉडल नियंत्रण – जिन टीमों को केवल कम लागत वाले मॉडल की आवश्यकता है, उन्हें केवल उसी तक सीमित किया जा सकता है, जिससे महंगे, उच्च-क्षमता वाले वेरिएंट का आकस्मिक उपयोग रोका जा सके।
- बजट सुरक्षा – टोकन की एक सख्त सीमा होती है। जब सीमा समाप्त हो जाती है, तो गेटवे चुपचाप अधिक क्रेडिट खर्च करने के बजाय त्रुटि (error) लौटाता है।
- फाइनेंस के लिए एट्रिब्यूशन – उपयोग लॉग पर बना एक डैशबोर्ड ठीक से दिखाता है कि किस टीम या सेवा ने AI पर कितना खर्च किया, जिससे एक अस्पष्ट स्प्रेडशीट एक पारदर्शी रिपोर्ट में बदल जाती है।
परिचालन वर्कफ़्लो भी बदल गया। कोई नई IAM नीतियां नहीं, कोई सीक्रेट रोटेशन नहीं, और वर्जन कंट्रोल में कीज़ लीक होने का कोई जोखिम नहीं।
प्रति-तर्क: प्रबंधित सेवा (managed service) का उपयोग क्यों नहीं करें
एक सामान्य आपत्ति यह है कि कस्टम गेटवे बनाने से इंजीनियरिंग प्रयास और रखरखाव बढ़ जाता है। फिनटेक के मामले में, सभी AI ट्रैफ़िक और उपयोग डेटा को कॉर्पोरेट फ़ायरवॉल के पीछे रखने की आवश्यकता तीसरे पक्ष के समाधान की सुविधा से अधिक महत्वपूर्ण थी। आंतरिक प्रॉक्सी के लिए सप्ताहांत के विकास की आवश्यकता थी, लेकिन इसने क्रेडेंशियल सफाई और बजट ओवररन के महीनों के काम को खत्म कर दिया जो सरल की-वितरण दृष्टिकोण के बाद होते।
मुख्य निष्कर्ष (Takeaway)
AWS Bedrock कीज़ बांटना एक शॉर्टकट है जो जल्दी ही सुरक्षा और बजट का दुस्वप्न बन जाता है। एक मामूली रिवर्स-प्रॉक्सी गेटवे—जो एक सप्ताहांत में बनाया गया हो—क्रेडेंशियल्स को केंद्रीकृत करता है, प्रति-टीम सीमाएं लागू करता है, और वह ऑडिट ट्रेल प्रदान करता है जिसकी फाइनेंस टीम को आवश्यकता होती है। किसी भी संगठन के लिए जो नियंत्रण खोए बिना कई समूहों को LLMs के साथ प्रयोग करने देना चाहता है, गेटवे दृष्टिकोण होने वाली घटनाओं को रोककर और खर्च की स्पष्ट दृश्यता प्रदान करके खुद की लागत वसूल कर लेता है।