Per gestire i costi di Amazon Bedrock, i team FinOps e di piattaforma devono collegare la spesa a utenti e applicazioni, osservare le richieste prima che arrivino i dati di fatturazione e scegliere come reagire al superamento del budget. Nel playbook pubblicato il 30 ottobre 2026, AWS organizza queste attività in cinque fasi: attribuire, osservare, applicare controlli, ottimizzare e gestire nel tempo.
1. Attribuire la spesa a utenti e applicazioni
Partite dall’identità che genera ogni chiamata. AWS descrive l’attivazione dei dettagli del principal IAM nel Cost and Usage Report (CUR) 2.0, nel campo line_item_iam_principal, e l’uso di tag aziendali per ripartire i costi. I tag di allocazione con prefisso iamPrincipal/ diventano visibili in Cost Explorer entro 24–48 ore dall’attivazione.
Un gateway condiviso può invocare Bedrock con un unico ruolo IAM, facendo apparire il ruolo come identità di spesa. Per conservare l’attribuzione ai singoli utenti, AWS propone di assumere un ruolo per ogni utente: il nome della sessione identifica la persona e i tag di sessione possono contenere dimensioni aziendali, come il team. Nell’esempio AWS, le credenziali possono essere memorizzate nella cache fino a un’ora.
Per raggruppare chiamate applicative, AWS descrive i profili di inferenza per applicazione, modello e Regione, usati dai client tramite l’ARN del profilo su bedrock-runtime. Per i carichi idonei su bedrock-mantle che usano la Responses API o la Chat Completions API, AWS indica invece Projects; un Project può coprire più modelli.
Il tutorial AWS mostra la creazione di profili di inferenza e l’attivazione dei tag di allocazione dei costi nella console. È una dimostrazione in inglese pubblicata nel marzo 2025.
2. Osservare i consumi prima dei dati di fatturazione
Per individuare rapidamente gli aumenti di spesa, affiancate ai dati di fatturazione una telemetria operativa. AWS indica un ritardo di circa 24 ore per l’attribuzione nel CUR; nel proprio esempio, una dashboard basata su CloudWatch e OpenTelemetry mostra la spesa per sviluppatore nell’arco di pochi minuti.
AWS descrive la registrazione dei dati di richiesta, risposta e metadati in CloudWatch Logs, in S3 oppure in entrambi. CloudWatch è indicato per le verifiche operative; per analisi di lungo periodo su S3, il playbook cita Athena. I metadati possono identificare applicazione, flusso di lavoro, tenant o agente, ma Bedrock non impone uno schema uniforme: concordate i campi e i nomi da usare tra i team. I percorsi dei campi nelle query d’esempio possono variare in base al modello, all’operazione API e alla configurazione.
La fatturazione e la telemetria servono quindi a tempi diversi: il CUR aiuta a riconciliare i costi, mentre i log operativi possono segnalare prima un consumo anomalo. Le stime ricavate dai token restano utili per il monitoraggio, ma la fattura si basa sui dati di fatturazione.
3. Scegliere il controllo del budget
La scelta dipende da quanto è importante fermare una richiesta al raggiungimento della soglia e dal percorso che i client possono seguire. AWS distingue gli avvisi, l’applicazione asincrona di regole IAM e il blocco sincrono tramite gateway.
| Controllo | Al superamento del budget | Tempi e limite | Requisito operativo |
| Avvisi AWS Budgets | Notifica il superamento, ma non blocca le chiamate. | L’avviso segnala una spesa già avvenuta; non c’è un arresto forzato. | Adatto quando bastano il monitoraggio e l’intervento del team. |
| Controllo IAM | Può negare l’accesso aggiornando le policy o trattenendo le credenziali. | L’aggiornamento delle policy è asincrono e può richiedere da secondi a minuti; trattenere le credenziali agisce al loro rinnovo. | Consente di intervenire senza inserire software di terze parti nel percorso d’inferenza. |
| Gateway | Può rifiutare sincronicamente la richiesta e restituire HTTP 429 alla soglia. | AWS descrive un’applicazione in meno di un secondo. | I client devono inviare le chiamate tramite il gateway, che va distribuito, dimensionato e sottoposto a revisione di sicurezza. |
Se le applicazioni chiamano Bedrock direttamente, gli avvisi o l’intervento IAM possono adattarsi meglio al percorso esistente, ma non equivalgono a un blocco immediato. Se il requisito è rifiutare la chiamata al superamento della soglia, il gateway è l’opzione descritta da AWS come sincrona, a condizione che i client passino effettivamente da lì.
4. Ottimizzare modelli e prompt caching
Prima di instradare un’attività verso un modello meno costoso, AWS raccomanda di valutarne la qualità sul carico di lavoro interessato. Il risultato va misurato per quel compito: un modello più economico è utile solo se soddisfa i requisiti dell’applicazione.
Per il prompt caching, i moltiplicatori riportati da AWS nell’ottobre 2026 riguardano Anthropic Claude in US East (N. Virginia). Una scrittura in cache costa 1,25 volte la tariffa base dei token di input con TTL di cinque minuti, oppure 2 volte con TTL di un’ora. Le letture in cache sono indicate a 0,1 volte la tariffa base per Claude Sonnet 4.6 e Claude Haiku 4.5, e a 0,05 volte per Claude Sonnet 5.5 e Claude Opus 5.5.
Per capire la stima su dieci chiamate, supponete che tutte usino un prefisso di input della stessa dimensione e che la prima chiamata scriva in cache con TTL di cinque minuti, seguita da nove letture. Con una tariffa di lettura pari a 0,1 volte la base, il calcolo è (1,25 + 9 × 0,1) / 10 = 0,215, cioè il 21,5% del costo dei token di input del prefisso senza cache. Con letture a 0,05 volte la base, (1,25 + 9 × 0,05) / 10 = 0,17, cioè il 17%.
Queste percentuali riguardano soltanto il prefisso di input e dipendono dal riuso ipotizzato. Escludono i token di output e gli altri addebiti; non sono una riduzione della fattura complessiva. Se una scrittura non viene seguita da letture riutilizzate, il costo di scrittura non viene compensato da quelle letture.
5. Rivedere le metriche con FinOps e piattaforma
AWS propone di seguire la spesa giornaliera per sviluppatore, la quota di richieste instradate verso modelli più efficienti, il tasso di lettura della cache e il costo per risultato riuscito. Le soglie indicate nel playbook sono punti di partenza da calibrare sul proprio carico di lavoro, non valori universali. AWS suggerisce una revisione settimanale per flotte con attività elevata e una ogni due settimane negli altri casi.
