AWS Bedrock কী (keys) এখন একটি অভ্যন্তরীণ LLM গেটওয়ে দ্বারা সুরক্ষিত, যা একটি ফিনটেক ফার্মের প্রতিটি টিমকে মডেলগুলো কল করার সুযোগ দেয়, তবুও প্রতিটি রিকোয়েস্ট একটি নির্দিষ্ট টিম-ভিত্তিক টোকেন বাজেটের সাথে যুক্ত। এই পরিবর্তনটি রিপোজিটরি এবং নোটবুকে IAM ক্রেডেনশিয়াল ছড়িয়ে দেওয়ার অভ্যাস বন্ধ করে দিয়েছে, যা ইতিমধ্যে একটি মাত্র বিকেলে কোম্পানির AI খরচ শেষ করে দেওয়ার হুমকি দিচ্ছিল।
কেন AWS কী প্রদান করা দ্রুত একটি বিশৃঙ্খলায় পরিণত হয়
প্রতিষ্ঠানের অ-প্রযুক্তিগত গ্রুপগুলো কোম্পানির ল্যাঙ্গুয়েজ মডেলগুলোতে সরাসরি অ্যাক্সেসের অনুরোধ করেছিল। কাগজে-কলমে সবচেয়ে সহজ সমাধান ছিল AWS-এ মডেলগুলো সক্রিয় করা এবং প্রতিটি গ্রুপকে একটি IAM পারমিশন প্রদান করা। মাত্র দশ মিনিটের কাজ, কয়েকটি পলিসি এডিট, এবং কাজ শেষ—অন্তত তাত্ত্বিকভাবে।
বাস্তবে, IAM ক্রেডেনশিয়াল প্রদান করা তিনটি লুকানো খরচ তৈরি করে:
- Credential sprawl – কীগুলো
.envফাইল, CI পাইপলাইন, Jupyter নোটবুক এবং অ্যাড-হক স্ক্রিপ্টে ছড়িয়ে পড়ে। রোটেশন (rotation) করার প্রয়োজন হলে প্রতিটি কপি একটি ব্যর্থতার কারণ (point of failure) হয়ে দাঁড়ায়। - Zero visibility – একটি মাত্র শেয়ার্ড কী থেকে কোনো ধারণা পাওয়া যায় না যে কোন টিম বা কোডের কোন অংশ ব্যবহার তৈরি করছে। যখন একটি আনকন্ট্রোলড লুপ (runaway loop) শুরু হয়, কেউ লক্ষ্য করার আগেই পুরো বাজেট শেষ হয়ে যেতে পারে।
- Operational overhead – কার কাছে কী পারমিশন আছে তা ট্র্যাক করা, অ্যাক্সেস বাতিল করা এবং ব্যবহারের অডিট করা দ্রুত একটি ম্যানুয়াল এবং ভুল-প্রবণ প্রক্রিয়ায় পরিণত হয়।
ফিনটেক টিম বুঝতে পেরেছিল যে এই "দ্রুত সমাধান" শীঘ্রই একটি নিরাপত্তা এবং খরচের দুঃস্বপ্নে পরিণত হবে।
পরিবর্তে একটি রিভার্স-প্রক্সি গেটওয়ে তৈরি করা
সমাধান ছিল প্রতিটি অভ্যন্তরীণ অ্যাপ্লিকেশন এবং AWS Bedrock-এর মাঝে একটি হালকা রিভার্স প্রক্সি স্থাপন করা। প্রক্সিটি একটি ভল্ট-সুরক্ষিত (vault-secured) স্থানে আসল AWS ক্রেডেনশিয়ালগুলো রাখে এবং কলারদের (callers) স্বল্পমেয়াদী, মানুষের পাঠযোগ্য টোকেন (উদাহরণস্বরূপ, lllkey_9f3c) প্রদান করে।
মূল ডিজাইনের পয়েন্টগুলো:
- No AWS credentials leave the gateway – ডেভেলপার এবং সার্ভিসগুলো কখনোই আসল IAM কী দেখতে পায় না।
- Per-token policy enforcement – প্রতিটি টোকেনকে একটি নির্দিষ্ট মডেল ফ্যামিলি বা সর্বোচ্চ টোকেন সংখ্যার মধ্যে সীমাবদ্ধ করা যেতে পারে।
- Full audit trail – প্রতিটি রিকোয়েস্ট একটি নামের সাথে লগ করা হয়।
গেটওয়ে কীভাবে একটি রিকোয়েস্ট প্রসেস করে
- Receive token – ক্লায়েন্ট তার
llmkey_…টোকেনটি HTTP হেডারে অন্তর্ভুক্ত করে। - Validate token – গেটওয়ে টোকেনের স্ট্যাটাস (সক্রিয়, মেয়াদোত্তীর্ণ নয়) এবং রিকোয়েস্টটি বরাদ্দকৃত বাজেটের মধ্যে আছে কিনা তা পরীক্ষা করে।
- Model whitelist – এটি নিশ্চিত করে যে অনুরোধ করা মডেলটি সেই টোকেনের জন্য অনুমোদিত কিনা।
- Forward to Bedrock – সংরক্ষিত IAM ক্রেডেনশিয়াল ব্যবহার করে রিকোয়েস্টটি AWS-এ পাঠানো হয়।
- Log and bill – রিপোর্টিংয়ের জন্য টোকেন ব্যবহার, মডেলের নাম এবং খরচের আনুমানিক হিসাব একটি কেন্দ্রীয় ডাটাবেসে লেখা হয়।
যেহেতু ফিনটেক ফার্মটিকে অবশ্যই সমস্ত ডেটা তাদের নিজস্ব নেটওয়ার্কের ভেতরে রাখতে হবে, তাই কোনো থার্ড-পার্টি SaaS অফার ব্যবহারের সুযোগ ছিল না।
কোম্পানি কী অর্জন করেছে
- Model control – যে টিমগুলোর শুধুমাত্র স্বল্পমূল্যের মডেল প্রয়োজন তাদের জন্য তা সীমাবদ্ধ করা যেতে পারে, যা ভুলবশত দামী এবং উচ্চ-ক্ষমতাসম্পন্ন ভেরিয়েন্ট ব্যবহারের ঘটনা রোধ করে।
- Budget protection – টোকেনগুলোর একটি কঠোর টোকেন লিমিট রয়েছে। লিমিট শেষ হয়ে গেলে, গেটওয়ে নীরবে আরও ক্রেডিট খরচ করার পরিবর্তে একটি এরর (error) প্রদান করে।
- Attribution for finance – ব্যবহারের লগ-এর ওপর ভিত্তি করে তৈরি একটি ড্যাশবোর্ড দেখায় ঠিক কোন টিম বা সার্ভিস AI-তে কত খরচ করেছে, যা একটি অস্পষ্ট স্প্রেডশিটকে একটি স্বচ্ছ রিপোর্টে রূপান্তরিত করে।
অপারেশনাল ওয়ার্কফ্লো-ও পরিবর্তিত হয়েছে। কোনো নতুন IAM পলিসি, কোনো সিক্রেট রোটেশন এবং ভার্সন কন্ট্রোলে কী লিক হওয়ার কোনো ঝুঁকি নেই।
পাল্টা যুক্তি: কেন একটি ম্যানেজড সার্ভিস ব্যবহার করা হবে না
একটি সাধারণ আপত্তি হলো যে কাস্টম গেটওয়ে তৈরি করা মানে অতিরিক্ত ইঞ্জিনিয়ারিং প্রচেষ্টা এবং রক্ষণাবেক্ষণ। ফিনটেক ফার্মের ক্ষেত্রে, সমস্ত AI ট্রাফিক এবং ব্যবহারের ডেটা কর্পোরেট ফায়ারওয়ালের পেছনে রাখার প্রয়োজনীয়তা থার্ড-পার্টি সমাধানের সুবিধার চেয়ে বেশি গুরুত্বপূর্ণ ছিল। অভ্যন্তরীণ প্রক্সিটি তৈরি করতে একটি সপ্তাহান্তের (weekend) প্রয়োজন ছিল, কিন্তু এটি ক্রেডেনশিয়াল পরিষ্কার করা এবং বাজেটের অতিরিক্ত খরচের সেই মাসের পর মাস দীর্ঘ প্রক্রিয়াকে দূর করেছে যা সাধারণ কী-বিতরণ পদ্ধতির ফলে হতো।
সারসংক্ষেপ
AWS Bedrock কী প্রদান করা একটি শর্টকাট যা দ্রুত নিরাপত্তা এবং বাজেটিংয়ের দুঃস্বপ্নে পরিণত হয়। একটি সাধারণ রিভার্স-প্রক্সি গেটওয়ে—যা একটি সপ্তাহান্তে তৈরি করা সম্ভব—ক্রেডেনশিয়ালগুলোকে কেন্দ্রীভূত করে, প্রতিটি টিমের জন্য সীমা নির্ধারণ করে এবং ফিন্যান্স টিমের প্রয়োজনীয় অডিট ট্রেইল প্রদান করে। যে কোনো প্রতিষ্ঠান যারা নিয়ন্ত্রণ না হারিয়ে একাধিক গ্রুপকে LLM নিয়ে পরীক্ষা-নিরীক্ষা করতে দিতে চায়, তাদের জন্য এই গেটওয়ে পদ্ধতিটি দুর্ঘটনা এড়ানো এবং খরচের স্বচ্ছতা বৃদ্ধির মাধ্যমে নিজের খরচ নিজেই তুলে আনে।