AWS Bedrock કીઝ હવે એક આંતરિક LLM gateway દ્વારા સુરક્ષિત છે જે ફિનટેક કંપનીની દરેક ટીમને મોડેલ્સનો ઉપયોગ કરવાની મંજૂરી આપે છે, છતાં દરેક વિનંતી (request) ટીમ-વાર ટોકન બજેટ સાથે જોડાયેલી હોય છે. આ ફેરફાર રિપોઝીટરીઝ અને નોટબુક્સમાં IAM ક્રેડેન્શિયલ્સ વિખેરી દેવાની પ્રથાને અટકાવે છે, જે એક આદત કંપનીના AI ખર્ચને એક જ બપોરમાં ખતમ કરી દેવાની ધમકી આપી રહી હતી.
AWS કીઝ વહેલી તકે કેવી રીતે મુશ્કેલીમાં પરિણમે છે
સંસ્થાના બિન-તકનીકી જૂથોએ કંપનીના લેંગ્વેજ મોડેલ્સ માટે સીધા એક્સેસની માંગ કરી હતી. કાગળ પર સૌથી સરળ જવાબ એ હતો કે AWS માં મોડેલ્સને સક્રિય કરવા અને દરેક જૂથને IAM પરમિશન આપવી. દસ મિનિટનું કામ, થોડા પોલિસી એડિટ્સ, અને કામ પૂરું—ઓછામાં ઓછા સિદ્ધાંત મુજબ તો આવું જ હતું.
વ્યવહારમાં, IAM ક્રેડેન્શિયલ્સ આપવાથી ત્રણ છુપા ખર્ચાઓ ઊભા થાય છે:
- Credential sprawl – કીઝ
.envફાઇલો, CI પાઇપલાઇન્સ, Jupyter notebooks અને એડ-હોક સ્ક્રિપ્ટ્સમાં રહી જાય છે. જ્યારે રોટેશન (rotation) જરૂરી હોય ત્યારે દરેક કોપી નિષ્ફળતાનું કારણ બની શકે છે. - Zero visibility – એક સિંગલ શેર કરેલી કી એવો કોઈ સંકેત આપતી નથી કે કઈ ટીમ અથવા કોડનો કયો ભાગ વપરાશ (usage) પેદા કરી રહ્યો છે. જ્યારે કોઈ અનિયંત્રિત લૂપ (runaway loop) શરૂ થાય છે, ત્યારે કોઈને ખબર પડે તે પહેલાં આખું બજેટ વપરાઈ શકે છે.
- Operational overhead – કોની પાસે કઈ પરમિશન છે તેનું ટ્રેકિંગ કરવું, એક્સેસ રિવોક (revoke) કરવું અને વપરાશનું ઓડિટ કરવું ઝડપથી એક મેન્યુઅલ અને ભૂલ-ભર્યા પ્રક્રિયામાં ફેરવાઈ જાય છે.
ફિનટેક ટીમને સમજાયું કે આ "ક્વિક ફિક્સ" (ઝડપી ઉકેલ) ટૂંક સમયમાં સુરક્ષા અને ખર્ચનું кошાળ બની જશે.
તેના બદલે રિઅર્સ-પ્રોક્સી (reverse-proxy) gateway બનાવવું
ઉકેલ એ હતો કે દરેક આંતરિક એપ્લિકેશન અને AWS Bedrock વચ્ચે એક પાતળું રિઅર્સ પ્રોક્સી મૂકવું. પ્રોક્સી વાલ્ટ-સુરક્ષિત (vault-secured) એક જ સ્થળે અસલી AWS ક્રેડેન્શિયલ્સ રાખે છે અને કોલર્સને ટૂંકા ગાળાના, માનવ-વાંચનક્ષમ ટોકન્સ (દા.ત., lllkey_9f3c) ઇશ્યુ કરે છે.
મુખ્ય ડિઝાઇન પોઈન્ટ્સ:
- કોઈપણ AWS ક્રેડેન્શિયલ્સ gateway છોડતા નથી – ડેવલપર્સ અને સર્વિસીસ ક્યારેય અસલી IAM કીઝ જોતા નથી.
- Per-token policy enforcement – દરેક ટોકનને ચોક્કસ મોડેલ ફેમિલી અથવા મહત્તમ ટોકન કાઉન્ટ સુધી મર્યાદિત કરી શકાય છે.
- Full audit trail – દરેક વિનંતી (request) નામ સાથે લોગ કરવામાં આવે છે.
Gateway વિનંતી (request) કેવી રીતે પ્રોસેસ કરે છે
- Receive token – ક્લાયન્ટ તેના HTTP હેડરમાં
llmkey_…ટોકન સામેલ કરે છે. - Validate token – gateway ટોકનની સ્થિતિ (સક્રિય, એક્સપાયર થયેલ નથી) અને વિનંતી ફાળવેલ બજેટની અંદર છે કે નહીં તે તપાસે છે.
- Model whitelist – તે ખાતરી કરે છે કે વિનંતી કરેલ મોડેલ તે ટોકન માટે માન્ય છે.
- Forward to Bedrock – સંગ્રહિત IAM ક્રેડેન્શિયલ્સનો ઉપયોગ કરીને વિનંતી AWS ને મોકલવામાં આવે છે.
- Log and bill – રિપોર્ટિંગ માટે ટોકન વપરાશ, મોડેલનું નામ અને ખર્ચનો અંદાજ સેન્ટ્રલ ડેટાબેઝમાં લખવામાં આવે છે.
કારણ કે ફિનટેક ફર્મને તમામ ડેટા તેના પોતાના નેટવર્કની અંદર રાખવો જરૂરી છે, તેથી થર્ડ-પાર્ટી SaaS ઓફરિંગનો વિકલ્પ શક્ય નહોતો.
કંપનીને શું ફાયદો થયો
- Model control – જે ટીમોને માત્ર ઓછા ખર્ચવાળા મોડેલની જરૂર હોય તેમને તેના સુધી મર્યાદિત કરી શકાય છે, જેનાથી મોંઘા, ઉચ્ચ-ક્ષમતાવાળા વેરિઅન્ટ્સનો અકસ્માતવશ ઉપયોગ અટકાવી શકાય છે.
- Budget protection – ટોકન્સની એક કડક ટોકન મર્યાદા હોય છે. જ્યારે મર્યાદા પૂરી થાય છે, ત્યારે gateway વધુ ક્રેડિટ્સનો ચુપચાપ વપરાશ કરવાને બદલે એરર (error) રિટર્ન કરે છે.
- Attribution for finance – વપરાશના લોગ્સ પર બનેલું ડેશબોર્ડ બરાબર બતાવે છે કે કઈ ટીમ અથવા સર્વિસે AI પર કેટલો ખર્ચ કર્યો છે, જે અસ્પષ્ટ સ્પ્રેડશીટને પારદર્શક રિપોર્ટમાં ફેરવે છે.
ઓપરેશનલ વર્કફ્લો પણ બદલાયો. કોઈ નવી IAM પોલિસીઓ નહીં, કોઈ સિક્રેટ રોટેશન નહીં, અને કીઝ વર્ઝન કંટ્રોલમાં લીક થવાનું કોઈ જોખમ નહીં.
વિરોધ પક્ષનો તર્ક: મેનેજ્ડ સર્વિસનો ઉપયોગ કેમ ન કરવો
એક સામાન્ય વાંધો એ છે કે કસ્ટમ gateway બનાવવાથી એન્જિનિયરિંગ પ્રયાસ અને મેન્ટેનન્સ વધે છે. ફિનટેક ના કિસ્સામાં, તમામ AI ટ્રાફિક અને વપરાશના ડેટાને કોર્પોરેટ ફાયરવોલ પાછળ રાખવાની જરૂરિયાત થર્ડ-પાર્ટી સોલ્યુશનની સુવિધા કરતા વધુ મહત્વની હતી. આંતરિક પ્રોક્સી માટે એક વીકેન્ડના ડેવલપમેન્ટની જરૂર હતી, પરંતુ તેણે મહિનાઓ સુધી ચાલનારા ક્રેડેન્શિયલ ક્લીનઅપ અને બજેટ વધારાને દૂર કર્યો જે સીધી કી-ડિસ્ટ્રિબ્યુશન પદ્ધતિને કારણે થાત.
સારાંશ
AWS Bedrock કીઝ વહેલી તકે આપવી એ એક શોર્ટકટ છે જે ઝડપથી સુરક્ષા અને બજેટિંગના кошાળમાં ફેરવાઈ જાય છે. એક સામાન્ય રિઅર્સ-પ્રોક્સી gateway—જે એક વીકેન્ડમાં બનાવવામાં આવ્યું હોય—ક્રેડેન્શિયલ્સને કેન્દ્રીય બનાવે છે, ટીમ-વાર મર્યાદાઓ લાગુ કરે છે અને ફાઇનાન્સને જરૂરી ઓડિટ ટ્રેલ પૂરો પાડે છે. જે કોઈપણ સંસ્થા LLMs સાથે પ્રયોગ કરવા માટે નિયંત્રણ છોડ્યા વિના અનેક જૂથોને મંજૂરી આપવા માંગતી હોય, તેના માટે gateway અભિગમ અકસ્માત ટાળીને અને ખર્ચની સ્પષ્ટ વિઝિબિલિટી આપીને પોતાનો ખર્ચ વસૂલ કરી લે છે.