Funguo za AWS Bedrock sasa zinalindwa na lango la ndani la LLM ambalo linaruhusu kila timu katika kampuni ya fintech kuita modeli hizo, lakini kila ombi limeunganishwa na bajeti ya tokeni kwa kila timu. Mabadiliko haya yanazuia tabia ya kusambaza utambulisho wa IAM kwenye repos na notebooks, tabia ambayo tayari ilikuwa imetishia kumaliza matumizi ya AI ya kampuni ndani ya mchana mmoja.

Kwa nini kutoa funguo za AWS haraka kunakuwa vurugu

Makundi yasiyo ya kiufundi katika shirika yaliiomba ufikiaji wa moja kwa moja wa modeli za lugha za kampuni. Kwenye karatasi, jibu rahisi zaidi lilikuwa kuwezesha modeli hizo katika AWS na kumpa kila kikundi ruhusa ya IAM. Dakika kumi za kazi, marekebisho machache ya sera (policy edits), na kazi ilikuwa imekamilika—angalau katika nadharia.

Katika utendaji, kutoa utambulisho wa IAM kunasababisha gharama tatu zilizofichika:

  • Uenezaji wa utambulisho (Credential sprawl) – Funguo huishia kwenye faili za .env, CI pipelines, Jupyter notebooks, na skripti za ad-hoc. Kila nakala inakuwa hatari ya kufeli wakati mzunguko wa kubadilisha funguo (rotation) unapohitajika.
  • Kutokuwa na uwezo wa kuona (Zero visibility) – Funguo moja inayoshirikiwa haitoi dalili yoyote kuhusu ni timu gani au kipande gani cha kodi kinachozalisha matumizi hayo. Mzunguko usiozuilika (runaway loop) unapozinduliwa, bajeti nzima inaweza kutumika kabla ya mtu yeyote kugundua.
  • Gharama kubwa za uendeshaji (Operational overhead) – Kufuatilia nani ana ruhusa gani, kufuta ufikiaji, na kukagua matumizi kunageuka haraka kuwa mchakato wa manual na unaoweza kusababisha makosa.

Timu ya fintech iligundua kuwa "suluhisho la haraka" lingekuwa jinamizi la usalama na gharama hivi karibuni.

Kujenga lango la reverse-proxy badala yake

Suluhisho lilikuwa kuingiza reverse proxy nyembamba kati ya kila programu ya ndani na AWS Bedrock. Proxy hiyo inahifadhi utambulisho halisi wa AWS mahali pamoja palilolindwa na vault na kutoa tokeni za muda mfupi zinazoweza kusomwa na binadamu (kwa mfano, lllkey_9f3c) kwa watumiaji.

Mambo muhimu ya usanifu:

  • Hakuna utambulisho wa AWS unaotoka kwenye lango – Watengenezaji na huduma hazioni kamwe funguo halisi za IAM.
  • Utekelezaji wa sera kwa kila tokeni – Kila tokeni inaweza kuwekewa kikomo cha familia fulani ya modeli au idadi ya juu ya tokeni.
  • Kumbukumbu kamili ya ukaguzi (Full audit trail) – Kila ombi linarekodiwa pamoja na jina.

Jinsi lango linavyochakata ombi

  1. Pokea tokeni – Mteja anajumuisha tokeni yake ya llmkey_… kwenye kichwa cha HTTP (HTTP header).
  2. Thibitisha tokeni – Lango linakagua hali ya tokeni (iko hai, haijapita muda wake) na ikiwa ombi linabaki ndani ya bajeti iliyotengwa.
  3. Orodha nyeupe ya modeli (Model whitelist) – Linathibitisha kuwa modeli inayohitajika imeruhusiwa kwa tokeni hiyo.
  4. Tuma kwenda Bedrock – Ombi linatumwa kwenda AWS kwa kutumia utambulisho wa IAM uliohifadhiwa.
  5. Rekodi na utume – Matumizi ya tokeni, jina la modeli, na makadirio ya gharama huandikwa kwenye hifadhidata kuu kwa ajili ya ripoti.

Kwa sababu kampuni ya fintech lazima iweke data zote ndani ya mtandao wake wenyewe, kutoa huduma ya SaaS ya upande wa tatu haikuwa chaguo linalowezekana.

Kile kampuni ilichopata

  • Udhibiti wa modeli – Timu ambazo zinahitaji tu modeli ya gharama nafuu zinaweza kuwekewa kikomo kwenye hiyo, kuzuia matumizi ya bahati mbaya ya matoleo ya gharama kubwa yenye uwezo mkubwa.
  • Ulinzi wa bajeti – Tokeni zina kikomo kigumu cha tokeni. Kikomo kinapofikiwa, lango linarudisha kosa badala ya kutumia mikopo zaidi kimyakimya.
  • Uwajibikaji kwa idara ya fedha – Dashibodi iliyojengwa juu ya kumbukumbu za matumizi inaonyesha kwa usahihi ni timu gani au huduma gani ilitumia kiasi gani kwenye AI, ikigeuza jedwali lisilo na uwazi kuwa ripoti inayoeleweka.

Mtiririko wa kazi pia ulibadilika. Hakuna sera mpya za IAM, hakuna mzunguko wa siri (secret rotation), na hakuna hatari ya funguo kuvuja kwenye udhibiti wa toleo (version control).

Hoja kinyume: kwa nini usitumie huduma inayodhibitiwa (managed service)

Pingamizi la kawaida ni kwamba kujenga lango la kipekee kunaongeza juhudi za uhandisi na matengenezo. Katika kesi ya fintech hii, hitaji la kuweka trafiki yote ya AI na data ya matumizi nyuma ya ukuta wa moto (firewall) wa kampuni lilikuwa kubwa kuliko urahisi wa suluhisho la upande wa tatu. Proxy ya ndani ilihitaji wikendi moja ya maendeleo, lakini iliondoa miezi kadhaa ya usafishaji wa utambulisho na ulijiendeshaji wa bajeti ambao ungefuata mbinu rahisi ya usambazaji wa funguo.

Hitimisho

Kutoa funguo za AWS Bedrock ni njia ya mkato ambayo haraka inageuka kuwa jinamizi la usalama na bajeti. Lango la reverse-proxy la wastani—lililojengwa kwa wikendi moja—linaweka utambulisho sehemu moja, linatekeleza mipaka ya kila timu, na kutoa kumbukumbu ya ukaguzi inayohitajika na idara ya fedha. Kwa shirika lolote linalotaka kuruhusu makundi mengi kufanya majaribio na LLMs bila kupoteza udhibiti, mbinu ya lango inajilipa kupitia kuepuka matukio na kuleta uwazi zaidi wa matumizi.