Un application inference profile è un wrapper taggato attorno a un ARN di modello, ed è l'unica cosa che si frappone tra te e una bolletta Bedrock che riporta un unico numero per l'intera azienda. Crei un profile che punta a un modello, allega tag di allocazione costi, e invochi l'ARN del profile invece dell'ID modello. I tag viaggiano fino a Cost Explorer e al Cost and Usage Report. Questo è l'intero meccanismo, e richiede un pomeriggio.

Il pomeriggio non è il problema. Il problema è che uno schema di tagging è un impegno organizzativo, e la maggior parte dei team ne sceglie uno in dieci minuti e ci convive per due anni. Quindi l'API vale venti minuti di questo post e il design dei tag vale il resto.

Il problema che risolve

Senza profile, l'utilizzo di Bedrock appare come utilizzo di Bedrock. Ottieni la spesa per modello e per regione, che ti dice che Claude Sonnet è costato molto il mese scorso e niente su quale delle tue nove applicazioni l'abbia causato. Il report predefinito non può rispondere all'unica domanda che finance fa sempre, cioè da quale budget esce questa spesa. Ho scritto della forma più ampia di questo problema in Your LLM Bill Is an Observability Problem. I profile sono il controllo specifico per la metà dell'attribuzione.

Come funziona

Crea un profile che punta a un foundation model o a un profile cross-region definito dal sistema, con tag:

aws bedrock create-inference-profile \
  --inference-profile-name "support-assistant-prod" \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --tags key=team,value=support key=app,value=assistant key=env,value=prod

Poi invoca l'ARN del profile ovunque passassi un ID modello:

response = client.converse(
    modelId="arn:aws:bedrock:eu-central-1:123456789012:application-inference-profile/abc123",
    messages=messages,
)

Tre dettagli operativi facili da perdere:

  • I profile sono specifici per modello. Un profile avvolge un modello. Sei app per quattro modelli fanno ventiquattro profile. Questa moltiplicazione è il motivo per cui il tuo design dei tag conta più di quanto sembri: non stai nominando una risorsa, stai definendo una griglia.
  • I tag non sono retroattivi. Attivare un tag di allocazione costi nella console Billing tagga la spesa da quel momento in poi. Nulla di quello che hai fatto il mese scorso viene etichettato. Attiva le chiavi dei tag prima di averne bisogno, non quando qualcuno te lo chiede.
  • La granularità è giornaliera, per tipo di utilizzo. I profile ti danno dollari fatturati in Cost Explorer e nel CUR a granularità giornaliera. Non ti danno il costo per richiesta. Se vuoi l'economia per richiesta, quello è logging dei token lato applicazione, un sistema diverso con un proprietario diverso.

Progettare lo schema di tag

La trappola è taggare ciò che è facile da vedere invece di ciò su cui qualcuno può agire. Ogni chiave di tag dovrebbe rispondere a una domanda che una persona reale fa in una riunione reale.

Quattro chiavi coprono la maggior parte delle organizzazioni:

  • team: chi paga. Fai corrispondere esattamente la tua tassonomia esistente dei centri di costo. Se finance lo chiama cc-4471, non inventare platform-eng; passerai il prossimo anno a mantenere una tabella di traduzione di cui nessuno si fida.
  • app: quale workload. L'unità che effettivamente spegneresti.
  • env: prod, staging, dev. Questa è quella che si ripaga più in fretta, perché il primo numero genuinamente sorprendente nella maggior parte delle bollette Bedrock è quanto costa dev.
  • feature: opzionale, per app in cui una funzionalità può dominare la spesa. Usala con parsimonia. Ogni chiave in più moltiplica il tuo numero di profile.

Deliberatamente fuori dalla lista: tag per utente. Non creare un profile per utente. Colpirai i limiti di risorsa, e la manutenzione è illimitata. Per l'attribuzione a livello di identità, Bedrock supporta l'allocazione dei costi basata su principal IAM, che attribuisce la spesa all'identità chiamante senza un profile per persona. Usa i profile per la granularità team e app, e l'attribuzione per principal IAM quando devi sapere quale umano o service role ha causato il picco. Si compongono.

Rendilo strutturale

Uno schema di tagging che dipende dalla disciplina decade. Due controlli lo mantengono saldo.

Primo, crea i profile nel tuo IaC, accanto all'app che li usa, e prendi i valori dei tag dalle stesse variabili che taggano il resto delle risorse di quell'app. Un profile creato a mano nella console è un profile che resterà taggato test per sempre.

Secondo, chiudi il percorso diretto. Una volta che i profile esistono, un'app che chiama un ID modello grezzo produce spesa non taggata, e la spesa non taggata è esattamente la voce che nessuno reclama. Una policy IAM che nega bedrock:InvokeModel e bedrock:Converse sugli ARN dei foundation model mentre li consente sugli ARN degli application-inference-profile rende il percorso taggato l'unico percorso. Questo è lo stesso istinto dello scoping di un ruolo a un task, e non ripeterò l'argomento da IAM for LLM Apps: Least Privilege When the Caller Is a Model, noto solo che si applica alla tua bolletta oltre che al tuo raggio d'esplosione.

Fallo il primo giorno. Retrofittare una deny policy su sei app che già chiamano ID modello è una migrazione con un change-freeze allegato.

Cosa ottieni, e cosa continuerai a non avere

Dopo un mese di dati taggati puoi raggruppare Cost Explorer per team e vedere la suddivisione, filtrare per env=dev e trovare il batch job che qualcuno ha lasciato in esecuzione, e interrogare il CUR per il costo per app al giorno e metterlo su una dashboard accanto al volume delle richieste. Anche il rilevamento delle anomalie diventa utile, perché un alert di budget su un'app è segnale dove un alert sulla spesa Bedrock totale è rumore.

Cosa continuerai a non avere: costo per richiesta, costo per cliente in un'app multi-tenant, e nessuna idea se la spesa ne valesse la pena. Il primo è logging dei token. Il secondo richiede contesto del tenant che il sistema di fatturazione non vede mai, ed è per questo che l'attribuzione multi-tenant resta un problema applicativo. Il terzo non è affatto una domanda di fatturazione. I profile ti dicono dove sono finiti i soldi. Non hanno opinioni su se avrebbero dovuto finire lì.

Il punto chiave

Gli application inference profile trasformano una bolletta Bedrock non attribuibile in voci per team e per app al costo di avvolgere un ARN modello. Attiva le chiavi dei tag prima di averne bisogno per lo storico, mantieni lo schema a poche chiavi che corrispondano a come la tua organizzazione budgetta davvero, crea i profile nell'IaC, e nega il percorso non taggato con IAM in modo che l'attribuzione non dipenda dal fatto che qualcuno se lo ricordi. L'API è un pomeriggio. Il design dei tag sopravvive alle persone che l'hanno scelto.

Leggi questo dopo

La disciplina generale di allocazione dei costi da cui questo prende in prestito, la strategia di tagging su un intero estate AWS, è nelle field notes su ercan.cloud. L'hub è su ercanermis.com.