AWS Bedrock keys اب ایک اندرونی LLM gateway کے ذریعے محفوظ ہیں جو ایک فن ٹیک (fintech) فرم کی ہر ٹیم کو ماڈلز استعمال کرنے کی اجازت دیتا ہے، تاہم ہر درخواست ایک ٹیم کے مخصوص ٹوکن بجٹ سے منسلک ہوتی ہے۔ یہ تبدیلی ریپوزٹریز (repos) اور نوٹ بکس میں IAM credentials بکھیرنے کے عمل کو روکتی ہے، ایک ایسی عادت جس نے پہلے ہی کمپنی کے AI اخراجات کو ایک ہی دوپہر میں ختم کرنے کا خطرہ پیدا کر دیا تھا۔
AWS keys بانٹنا تیزی سے ایک مسئلہ کیوں بن جاتا ہے
تنظیم کے غیر تکنیکی گروپس نے کمپنی کے لینگویج ماڈلز تک براہ راست رسائی کی درخواست کی۔ کاغذ پر سب سے سادہ جواب AWS میں ماڈلز کو فعال کرنا اور ہر گروپ کو IAM اجازت (permission) دینا تھا۔ دس منٹ کا کام، چند پالیسی ایڈیٹس، اور کام مکمل ہو گیا—کم از کم نظریاتی طور پر۔
عملی طور پر، IAM credentials فراہم کرنے سے تین پوشیدہ اخراجات پیدا ہوتے ہیں:
- Credential sprawl – چابیاں (Keys)
.envفائلوں، CI پائپ لائنز، Jupyter notebooks، اور ad-hoc اسکرپٹس میں پہنچ جاتی ہیں۔ جب تبدیلی (rotation) کی ضرورت ہوتی ہے تو ہر کاپی ناکامی کا باعث بن سکتی ہے۔ - Zero visibility – ایک ہی مشترکہ کی (key) سے یہ اندازہ نہیں ہوتا کہ کون سی ٹیم یا کوڈ کا کون سا حصہ استعمال کر رہا ہے۔ جب کوئی غیر معمولی لوپ (runaway loop) شروع ہوتا ہے، تو کسی کے نوٹس لینے سے پہلے ہی پورا بجٹ ختم ہو سکتا ہے۔
- Operational overhead – کس کے پاس کیا اجازت ہے، رسائی واپس لینا، اور استعمال کا آڈٹ کرنا تیزی سے ایک دستی اور غلطیوں سے بھرپور عمل بن جاتا ہے۔
فن ٹیک ٹیم کو احساس ہوا کہ یہ "فوری حل" جلد ہی سیکیورٹی اور لاگت کا ڈراونا خواب بن جائے گا۔
اس کے بجائے ایک reverse-proxy gateway بنانا
حل ہر اندرونی ایپلی کیشن اور AWS Bedrock کے درمیان ایک ہلکا پھلکا reverse proxy شامل کرنا تھا۔ یہ پراکسی اصل AWS credentials کو ایک محفوظ والٹ (vault) میں رکھتی ہے اور کالرز کو مختصر مدت کے لیے قابلِ فہم ٹوکنز (مثال کے طور پر، lllkey_9f3c) جاری کرتی ہے۔
اہم ڈیزائن پوائنٹس:
- No AWS credentials leave the gateway – ڈویلپرز اور سروسز اصل IAM keys کبھی نہیں دیکھ پاتے۔
- Per-token policy enforcement – ہر ٹوکن کو ایک مخصوص ماڈل فیملی یا ٹوکن کی زیادہ سے زیادہ تعداد تک محدود کیا جا سکتا ہے۔
- Full audit trail – ہر درخواست کو نام کے ساتھ لاگ (log) کیا جاتا ہے۔
گیٹ وے درخواست کو کیسے پروسیس کرتا ہے
- Receive token – کلائنٹ اپنے
llmkey_…ٹوکن کو HTTP ہیڈر میں شامل کرتا ہے۔ - Validate token – گیٹ وے ٹوکن کی حیثیت (فعال، منسوخ شدہ نہیں) اور یہ چیک کرتا ہے کہ آیا درخواست مختص کردہ بجٹ کے اندر ہے یا نہیں۔
- Model whitelist – یہ تصدیق کرتا ہے کہ مطلوبہ ماڈل اس ٹوکن کے لیے اجازت شدہ ہے۔
- Forward to Bedrock – درخواست کو محفوظ شدہ IAM credentials کا استعمال کرتے ہوئے AWS کو بھیج دیا جاتا ہے۔
- Log and bill – رپورٹنگ کے لیے ٹوکن کا استعمال، ماڈل کا نام، اور لاگت کا تخمینہ ایک مرکزی ڈیٹا بیس میں لکھا جاتا ہے۔
چونکہ فن ٹیک فرم کو تمام ڈیٹا اپنے نیٹ ورک کے اندر رکھنا ضروری ہے، اس لیے تھرڈ پارٹی SaaS پیشکش کا کوئی امکان نہیں تھا۔
کمپنی کو کیا فائدہ ہوا
- Model control – جن ٹیموں کو صرف کم لاگت والے ماڈل کی ضرورت ہے، انہیں اس تک محدود کیا جا سکتا ہے، جس سے مہنگے اور زیادہ صلاحیت والے ورژنز کے حادثاتی استعمال کو روکا جا سکتا ہے۔
- Budget protection – ٹوکنز کی ایک سخت حد (hard limit) ہوتی ہے۔ جب حد ختم ہو جاتی ہے، تو گیٹ وے مزید کریڈٹس خاموشی سے استعمال کرنے کے بجائے ایرر (error) واپس کرتا ہے۔
- Attribution for finance – استعمال کے لاگز پر مبنی ایک ڈیش بورڈ بالکل درست دکھاتا ہے کہ کس ٹیم یا سروس نے AI پر کتنا خرچ کیا، جس سے ایک مبہم اسپریڈ شیٹ ایک شفاف رپورٹ میں بدل جاتی ہے۔
آپریشنل ورک فلو بھی بدل گیا۔ اب نہ نئی IAM پالیسیاں بنانے کی ضرورت ہے، نہ سیکرٹ روٹیشن کی، اور نہ ہی کیز کے ورژن کنٹرول میں لیک ہونے کا کوئی خطرہ ہے۔
مخالف دلیل: مینیجڈ سروس کیوں استعمال نہ کی جائے
ایک عام اعتراض یہ ہے کہ کسٹم گیٹ وے بنانے سے انجینئرنگ کی کوشش اور دیکھ بھال (maintenance) کا بوجھ بڑھ جاتا ہے۔ فن ٹیک کے معاملے میں، تمام AI ٹریفک اور استعمال کے ڈیٹا کو کارپوریٹ فائر وال کے پیچھے رکھنے کی ضرورت، تھرڈ پارٹی حل کی سہولت پر بھاری پڑی۔ اندرونی پراکسی کے لیے صرف ایک ویک اینڈ کی ڈویلپمنٹ درکار تھی، لیکن اس نے مہینوں کے کریڈنشل کلین اپ اور بجٹ کے تجاوز کو ختم کر دیا جو کہ سادہ کی-تقسیم (key-distribution) کے طریقے کے نتیجے میں ہو سکتے تھے۔
خلاصہ
AWS Bedrock keys بانٹنا ایک ایسا شارٹ کٹ ہے جو تیزی سے سیکیورٹی اور بجٹ کے ڈراؤنے خواب میں بدل جاتا ہے۔ ایک معمولی reverse-proxy gateway—جو ایک ویک اینڈ میں تیار کیا گیا ہو—کریڈنشلز کو مرکزی حیثیت دیتا ہے، ہر ٹیم کے لیے حدود نافذ کرتا ہے، اور وہ آڈٹ ٹریل فراہم کرتا ہے جس کی فنانس ٹیم کو ضرورت ہوتی ہے۔ کسی بھی ایسی تنظیم کے لیے جو کنٹرول چھوڑے بغیر متعدد گروپس کو LLMs کے ساتھ تجربات کرنے کی اجازت دینا چاہتی ہے، گیٹ وے کا طریقہ کار حادثات سے بچنے اور اخراجات کی واضح معلومات فراہم کرنے کی صورت میں خود بخود منافع بخش ثابت ہوتا ہے۔