Le chiavi di AWS Bedrock sono ora protette da un gateway LLM interno che consente a ogni team di una società fintech di chiamare i modelli, ma ogni richiesta è legata a un budget di token per team. Il cambiamento interrompe la pratica di disperdere le credenziali IAM tra repository e notebook, un'abitudine che aveva già minacciato di esaurire la spesa per l'IA dell'azienda in un solo pomeriggio.

Perché distribuire le chiavi AWS diventa rapidamente un caos

I gruppi non tecnici dell'organizzazione hanno richiesto l'accesso diretto ai modelli linguistici dell'azienda. Sulla carta, la soluzione più semplice era abilitare i modelli in AWS e concedere a ogni gruppo un permesso IAM. Dieci minuti di lavoro, alcune modifiche alle policy e il lavoro era fatto — almeno in teoria.

In pratica, distribuire credenziali IAM crea tre costi nascosti:

  • Credential sprawl (dispersione delle credenziali) – Le chiavi finiscono in file .env, pipeline CI, notebook Jupyter e script ad hoc. Ogni copia diventa un punto di vulnerabilità quando è necessaria la rotazione.
  • Zero visibilità – Una singola chiave condivisa non fornisce indizi su quale team o quale frammento di codice stia generando l'utilizzo. Quando parte un loop incontrollato, l'intero budget può essere consumato prima che qualcuno se ne accorga.
  • Overhead operativo – Monitorare chi ha quale permesso, revocare l'accesso e controllare l'utilizzo si trasforma rapidamente in un processo manuale e soggetto a errori.

Il team fintech ha capito che la "soluzione rapida" sarebbe presto diventata un incubo in termini di sicurezza e costi.

Costruire invece un gateway reverse-proxy

La soluzione è stata quella di inserire un leggero reverse proxy tra ogni applicazione interna e AWS Bedrock. Il proxy conserva le vere credenziali AWS in un unico luogo protetto da vault e rilascia token a breve scadenza e leggibili dall'uomo (ad esempio, lllkey_9f3c) ai chiamanti.

Punti chiave del design:

  • Nessuna credenziale AWS lascia il gateway – Sviluppatori e servizi non vedono mai le chiavi IAM effettive.
  • Applicazione delle policy per token – Ogni token può essere limitato a una specifica famiglia di modelli o a un numero massimo di token.
  • Tracciabilità completa (audit trail) – Ogni richiesta viene registrata con un nome.

Come il gateway elabora una richiesta

  1. Ricezione del token – Il client include il proprio token llmkey_… nell'header HTTP.
  2. Validazione del token – Il gateway controlla lo stato del token (attivo, non scaduto) e se la richiesta rientra nel budget allocato.
  3. Whitelist dei modelli – Conferma che il modello richiesto sia consentito per quel token.
  4. Inoltro a Bedrock – La richiesta viene inviata ad AWS utilizzando le credenziali IAM memorizzate.
  5. Registrazione e fatturazione – L'utilizzo dei token, il nome del modello e la stima dei costi vengono scritti in un database centrale per la reportistica.

Poiché la società fintech deve mantenere tutti i dati all'interno della propria rete, un'offerta SaaS di terze parti è stata esclusa.

Cosa ha guadagnato l'azienda

  • Controllo dei modelli – I team che necessitano solo di un modello a basso costo possono essere limitati a quello, evitando l'uso accidentale di varianti costose e ad alta capacità.
  • Protezione del budget – I token hanno un limite massimo di token. Quando viene raggiunto il limite, il gateway restituisce un errore invece di consumare silenziosamente altri crediti.
  • Attribuzione per l'ufficio finanziario – Una dashboard basata sui log di utilizzo mostra esattamente quale team o servizio ha speso quanto per l'IA, trasformando un foglio di calcolo vago in un report trasparente.

Anche il flusso di lavoro operativo è cambiato. Nessuna nuova policy IAM, nessuna rotazione di segreti e nessun rischio che le chiavi finiscano nel controllo di versione.

Controargomentazione: perché non usare un servizio gestito

Un'obiezione comune è che la costruzione di un gateway personalizzato comporti sforzi di ingegneria e manutenzione aggiuntivi. Nel caso della fintech, la necessità di mantenere tutto il traffico IA e i dati di utilizzo dietro il firewall aziendale ha superato la comodità di una soluzione di terze parti. Il proxy interno ha richiesto un weekend di sviluppo, ma ha eliminato mesi di pulizia delle credenziali e sforamenti di budget che sarebbero seguiti all'approccio ingenuo della distribuzione delle chiavi.

In sintesi

Distribuire le chiavi di AWS Bedrock è una scorciatoia che si trasforma rapidamente in un incubo per la sicurezza e il budget. Un modesto gateway reverse-proxy — costruito in un weekend — centralizza le credenziali, impone limiti per team e fornisce la tracciabilità di cui l'ufficio finanziario ha bisogno. Per qualsiasi organizzazione che voglia permettere a più gruppi di sperimentare con gli LLM senza rinunciare al controllo, l'approccio gateway si ripaga da solo grazie agli incidenti evitati e a una maggiore visibilità della spesa.