Amazon Bedrock applica una tariffa per ogni token di input e di output elaborato, con costi che variano in base al modello, alla modalità di pricing e al profilo del workload. La modalità on-demand è indicata per un utilizzo imprevedibile o a basso volume; il provisioned throughput offre capacità garantita per workloads di produzione costanti e ad alto volume; la batch inference consente sconti fino al 50% per i job che non richiedono tempo reale. Personalizzazione e fine-tuning dei modelli comportano costi distinti di training, storage e inferenza. Poiché la dinamica dei costi dell'AI è diversa da quella del compute tradizionale, i team CloudOps hanno bisogno di visibilità a livello di token e di controlli di budget automatizzati per mantenere prevedibile la spesa su Bedrock.
Il budgeting cloud tradizionale si è sempre basato su unità prevedibili: ore di istanza, gigabyte di storage, traffico di rete in uscita. Amazon Bedrock non rientra in questo schema. La fattura dipende da quante parole digitano i suoi utenti, da quanto sono prolissi i prompt, da quale foundation model è stato scelto e da quante volte la sua applicazione ritenta le chiamate fallite. Una singola scelta architetturale, come optare per Claude 3 Opus invece di Claude 3 Haiku, può modificare i costi di un ordine di grandezza su larga scala.
Non è una critica a Bedrock: è la realtà strutturale del pricing basato sull'inferenza, un terreno con cui la maggior parte dei team CloudOps e FinOps non si è ancora dovuta confrontare. Gli ingegneri che sviluppano le funzionalità AI conoscono i token. Chi approva il budget cloud, quasi sempre no. Colmare questo divario è urgente: il report 2026 State of FinOps della FinOps Foundation indica che oggi il 98% delle organizzazioni gestisce attivamente la spesa AI, contro appena il 31% di due anni fa. La visibilità sui costi non è un optional: è la condizione che rende possibile parlare seriamente di crescita dell'AI.
Questa guida illustra come funziona il pricing di Bedrock, come stimare i costi prima che arrivino in fattura e come costruire monitoraggio e controlli capaci di rendere difendibile la spesa AI.
Come funziona il pricing di Amazon Bedrock?
Amazon Bedrock fattura l'inferenza, ovvero il processo di invio di un prompt a un foundation model e di ricezione della relativa risposta. L'unità di pricing principale è il token, un frammento di testo equivalente, in linea di massima, a quattro caratteri o tre quarti di una parola. Ogni richiesta comprende token di input (prompt, messaggio di sistema ed eventuale cronologia della conversazione) e token di output (la risposta del modello). Si paga per entrambi, a tariffe differenti.
Ciò che rende i costi di Bedrock più difficili da prevedere rispetto al compute è la natura variabile dei token. Un utente che pone una domanda di due frasi consuma molti meno token di input rispetto a chi incolla un documento di 3.000 parole. Un'applicazione che chiede al modello di "riassumere brevemente" genera meno token di output rispetto a una che richiede un'analisi dettagliata. Moltiplichi questa variabilità per migliaia di richieste giornaliere e la previsione di budget diventa davvero ardua senza una strumentazione adeguata.
Due ulteriori fattori complicano il quadro. Primo: in molti modelli i token di output costano più di quelli di input, perché generare testo è computazionalmente più oneroso che elaborarlo. La situazione varia da provider a provider: alcuni modelli applicano la stessa tariffa a input e output, altri fanno pagare l'output sensibilmente di più. Secondo: la scelta del modello incide in modo enorme sulle tariffe per token. Un modello leggero costa una frazione di quanto costa un frontier model della stessa famiglia per milione di token. Il modello giusto per un task di classificazione spesso è quello sbagliato per un task di reasoning complesso, e viceversa. Selezionare basandosi solo sulle capacità, senza considerare il costo, è una delle fonti più ricorrenti di spesa Bedrock superflua.
Modelli di pricing e strutture tariffarie di Amazon Bedrock
Bedrock prevede tre modalità di pricing principali: on-demand, provisioned throughput e batch inference. Ciascuna risponde a un profilo di workload diverso. Comprenderne i compromessi è il presupposto sia per il controllo dei costi sia per l'affidabilità operativa.
Modalità di pricing
Come si paga
Impegno
Latenza
Ideale per
On-demand
Per token elaborato
Nessuno
Variabile; rischio di throttling nei picchi
Workloads con picchi, sperimentali o a basso volume
Provisioned throughput
Tariffa oraria fissa per model unit
1 o 6 mesi
Garantita; nessun throttling
Workloads ad alto volume e costanti; obbligatorio per i modelli custom
Batch inference
Per token (sconto fino al 50% rispetto all'on-demand)
Nessuno
Asincrona; non in tempo reale
Elaborazione documentale, job notturni, pipeline di arricchimento asincrone
Pricing on-demand per i foundation model
L'on-demand è la modalità predefinita: si paga per ogni 1.000 token elaborati, senza impegno iniziale né spesa minima. È ideale per workloads esplorativi, soggetti a picchi o non ancora abbastanza prevedibili da giustificare una riserva di capacità.
Il rischio operativo dell'on-demand è il throttling. AWS impone limiti di concorrenza sull'accesso ai foundation model e, durante i picchi di domanda, le richieste possono essere accodate o fallire. Per strumenti interni o applicazioni a basso impatto è un compromesso accettabile. Per funzionalità rivolte al cliente con requisiti di latenza, non lo è.
Le tariffe per token variano in modo significativo per famiglia di modelli e generazione. Nella linea Anthropic Claude su Bedrock, ad esempio, i modelli più leggeri possono costare un ordine di grandezza in meno per milione di token rispetto ai frontier model della stessa famiglia. Per la maggior parte dei modelli le tariffe differiscono anche tra token di input e di output, sebbene alcuni provider applichino lo stesso prezzo. Scegliere il modello giusto per il task, e non semplicemente quello più potente disponibile, è la singola decisione di costo a maggior leva che un team possa prendere. Verifichi sempre le tariffe correnti sulla pagina dei prezzi di AWS Bedrock prima di consolidare una strategia di selezione del modello, perché tariffe e versioni disponibili cambiano di frequente.*
Opzioni di pricing del provisioned throughput
Il provisioned throughput funziona come una reserved instance applicata all'inferenza. Si acquistano model unit, ognuna delle quali garantisce un throughput specifico in token al minuto, e si paga una tariffa oraria fissa indipendentemente dall'utilizzo effettivo. Gli impegni durano uno o sei mesi, con tariffe migliori sui termini più lunghi.
La convenienza economica del provisioned throughput dipende dall'utilizzo. Se il suo workload gira a volume costante durante l'orario di lavoro, la tariffa oraria fissa può generare risparmi significativi rispetto all'on-demand a parità di throughput. Ma l'impegno è vincolante: la capacità riservata non utilizzata costa quanto quella sfruttata al massimo. I team che la dimensionano sul carico di picco e poi operano al 30% di utilizzo medio non risparmiano nulla.
Il provisioned throughput è inoltre l'unica opzione di inferenza per i modelli custom e fine-tuned. Se il suo team intende deployare un foundation model adattato a un dominio specifico, il provisioned throughput è obbligatorio a prescindere dal profilo di volume.
Costi di personalizzazione e fine-tuning dei modelli
Il fine-tuning di un foundation model su Bedrock genera tre eventi di costo distinti: training, storage e inferenza. I costi di training si basano sul totale dei token elaborati nel dataset e sul numero di epoche di addestramento. Una volta concluso l'addestramento, il modello custom resta in storage con una tariffa mensile. Per servire il modello fine-tuned occorre il provisioned throughput, con almeno una model unit richiesta anche senza impegno a lungo termine.
Prima di intraprendere un percorso di personalizzazione, conviene realizzare una proof of concept su un dataset ridotto per verificare se i miglioramenti di performance giustifichino la struttura di costi aggiuntiva. La distillazione del modello, che comprime le capacità di un modello grande in uno più piccolo e veloce, può ridurre i costi di inferenza nel lungo periodo. Ma anche i modelli distillati portano con sé propri costi di training e richiedono comunque il provisioned throughput per il deployment.
Come calcolare e stimare i costi di Amazon Bedrock
Una stima accurata dei costi richiede di passare da supposizioni vaghe a volumi di token effettivamente misurati. I team che prevedono la spesa Bedrock partendo dal "numero di chiamate API" sbaglieranno. Il numero di token per chiamata, e il rapporto tra input e output, contano molto più del conteggio delle chiamate.
Calcolo dei prezzi dei token di input e output
La formula di base è semplice. Il costo mensile è pari ai token di input moltiplicati per la tariffa input, sommati ai token di output moltiplicati per la tariffa output, entrambe espresse per milione di token. La sfida sta nello stimare quei volumi con precisione prima ancora di disporre di dati di produzione.
Parta dall'architettura dei prompt della sua applicazione. Un prompt di sistema da 500 token viene addebitato su ogni singola richiesta. Una configurazione retrieval-augmented generation (RAG) che inietta 2.000 token di contesto per query estende quel costo a ogni invocazione. Esamini i template dei suoi prompt e conti i token con il tokenizer di Bedrock o con un counter specifico per modello prima del lancio.
Per la stima dell'output, analizzi cosa la sua applicazione chiede al modello di produrre. I task di classificazione a risposta singola generano molti meno token di output rispetto a risposte conversazionali o contenuti long-form. Costruisca un campione rappresentativo di richieste, misuri il numero reale di token di input e output e lo usi come baseline. Poi applichi un moltiplicatore per il volume di richieste atteso.
Un esempio concreto: un'applicazione che invia 100.000 richieste al giorno a un foundation model di fascia media, con una media di 800 token di input e 400 di output, genera 80 milioni di token di input e 40 milioni di token di output al giorno. A seconda del modello e della relativa tariffa di output, la spesa giornaliera può andare da decine a centinaia di dollari, fino a comporre cifre a cinque zeri al mese. Il costo dei token di output, spesso superiore a quello dei token di input dello stesso modello, rappresenta la quota maggiore di quella cifra.* Per le tariffe correnti su tutti i foundation model disponibili, consulti la pagina dei prezzi di AWS Bedrock.
Strumenti e metodi per stimare i costi
AWS mette a disposizione un calcolatore dei prezzi di Bedrock e uno strumento di stima dei token nella console: entrambi utili per la modellazione iniziale. Per una visibilità continuativa, AWS Cost Explorer mostra la spesa Bedrock ma non la scompone per modello, applicazione o team senza il tagging delle risorse. I tag sono essenziali. Tagghi ogni invocazione di Bedrock con gli identificatori di applicazione, team e ambiente coerenti con la sua struttura di allocazione dei costi, prima che i workloads vadano in produzione.
DoiT Cloud Intelligence va oltre il tagging e i dashboard. Offre visibilità in tempo reale sui costi AI legati al suo utilizzo di Bedrock, con analytics che mostrano nel dettaglio come scelta del modello, pattern dei prompt e picchi di utilizzo guidino la spesa. Una visibilità che collega i dati di costo alle decisioni di engineering in un modo che i report statici non consentono.
In ambienti multi-modello, dove applicazioni diverse usano foundation model differenti, definisca budget e soglie di alert distinti per ciascun modello. Un picco di costo su un frontier model ha una fisionomia molto diversa da un picco su un modello leggero, e accorparli in un'unica voce di budget rende più difficile l'analisi delle cause.
Strategie di ottimizzazione dei costi Amazon Bedrock per i team CloudOps
L'ottimizzazione su Bedrock non è un audit una tantum: è una disciplina operativa. I workloads AI evolvono in fretta. Un prompt efficiente al lancio può diventare costoso man mano che i casi d'uso si ampliano, le finestre di contesto crescono e le cronologie di conversazione si accumulano. I team che governano i costi di Bedrock lo trattano come trattano il right-sizing del compute: in modo continuo, con segnali automatizzati che guidano l'azione.
Right-sizing della scelta del modello in base ai workloads
Il right-sizing del modello è l'ottimizzazione a maggior leva disponibile, eppure è quella su cui la maggior parte dei team investe meno. L'impostazione predefinita è scegliere il modello più potente della famiglia e usarlo per tutti i casi d'uso. L'approccio corretto è invece allineare la capacità del modello alla complessità del task.
Classifichi i suoi casi d'uso in base a ciò che richiedono davvero. Estrazione semplice, classificazione e summarization non hanno bisogno di un frontier model: un modello più piccolo ed economico li gestisce con accuratezza a una frazione del costo. Riservi i modelli grandi al reasoning complesso, al problem solving multi-step e ai task in cui la qualità dell'output incide concretamente sui risultati di business.
Lo verifichi con rigore. Esegua i suoi workloads reali su un set di modelli a più livelli, misuri la qualità dell'output rispetto ai criteri di accettazione e calcoli la differenza di costo. In molti casi una soglia di qualità del 90% è raggiungibile con un modello che costa da 10 a 20 volte meno dell'alternativa di fascia alta. Non è un guadagno di efficienza marginale: su larga scala è una vera trasformazione del budget.
Valuti inoltre la batch inference per workloads che non richiedono risposte in tempo reale. La modalità batch di Bedrock riduce i costi dei token fino al 50% sui modelli supportati. Elaborazione documentale, job di analisi notturni e pipeline di arricchimento asincrone sono ottimi candidati. Il compromesso è la latenza: i job batch girano in modo asincrono e non sono quindi adatti a funzionalità rivolte all'utente che richiedono risposte immediate.
Implementare monitoraggio dell'utilizzo e controlli di budget
Monitorare Bedrock senza telemetria a livello di token è come monitorare EC2 senza metriche di CPU. AWS CloudWatch espone i conteggi delle invocazioni Bedrock e gli errori. Aggiunga metriche custom per il consumo di token per modello, per applicazione e per ambiente. Imposti allarmi su soglie di token che scattino prima che i costi diventino un problema, e non quando la fattura è già arrivata.
Il prompt caching riduce gli addebiti dei token di input per i contenuti ripetuti o statici. Prompt di sistema, documenti di riferimento e contesto condiviso che non variano da una richiesta all'altra possono essere messi in cache. La porzione cachata viene fatturata a tariffa ridotta, generando risparmi reali nelle applicazioni in cui lo stesso prompt di sistema compare in ogni chiamata. Abiliti il prompt caching per qualsiasi contenuto che rientri in questo schema.
La cross-region inference instrada le richieste verso la capacità modello disponibile in altre region AWS quando la region primaria è soggetta a throttling o satura. Migliora l'affidabilità sotto carico senza richiedere impegni separati di provisioned throughput. La valuti per i workloads di produzione in cui la tolleranza al throttling è bassa.
I controlli di budget in AWS Budgets possono lanciare alert sulla spesa Bedrock, ma reagiscono a una spesa ormai avvenuta. Un controllo più solido è il rate limiting a livello applicativo, che blocca un utilizzo fuori controllo prima che arrivi in fattura. Imposti limiti di token per utente, per sessione e per applicazione direttamente nel suo livello applicativo e li applichi prima che le richieste raggiungano l'API di Bedrock. È la differenza tra un segnale di monitoraggio e un vero guardrail.
DoiT Cloud Intelligence offre rilevamento automatico delle anomalie sulla spesa AI, segnalando in tempo reale gli scostamenti dai pattern di costo attesi. Significa che i team CloudOps vengono a conoscenza dei problemi nell'arco di poche ore, non alla chiusura di fine mese.
Renda i costi di Amazon Bedrock prevedibili e difendibili
Una spesa AI imprevedibile non è solo un problema finanziario: è un problema di credibilità. Quando i responsabili di engineering non sanno spiegare cosa abbia provocato un aumento del 40% dei costi Bedrock da un mese all'altro, si crea attrito con la finanza, si rallentano le decisioni di investimento sull'AI e si indebolisce la motivazione a espandere le iniziative AI. La visibilità sui costi non è un costo accessorio: è ciò che rende possibile parlare seriamente di crescita dell'AI.
I team che gestiscono bene questa partita trattano il cost management di Bedrock come una pratica di engineering, non come una funzione finanziaria. Strumentano l'uso dei token in fase di build, non dopo la prima fattura inattesa. Validano la scelta del modello rispetto ai trade-off costo-qualità prima del lancio. Costruiscono guardrail automatizzati che impongono i limiti di spesa senza richiedere intervento manuale. E tracciano il costo per outcome, non solo il costo per chiamata, così da poter dimostrare il ROI in termini comprensibili sia agli ingegneri sia all'executive team.
Questa è la maturità operativa che trasforma Bedrock da rischio di costo a capability sostenibile.
DoiT aiuta i team CloudOps e FinOps a colmare il divario tra dati di costo AI e azione. DoiT Cloud Intelligence mette in evidenza la spesa Bedrock in tempo reale per modello, applicazione e team, con alert e raccomandazioni automatizzate che non richiedono un esperto FinOps per essere interpretate. DoiT detiene la AWS Generative AI Competency ed è disponibile direttamente sull'AWS Marketplace: i team possono così adottare Cloud Intelligence all'interno del proprio workflow di Procurement AWS esistente, senza dover gestire una nuova relazione con un fornitore.
Scopra DoiT Cloud Intelligence per la gestione dei costi AI e veda come la visibilità sui prezzi di Bedrock possa passare da reattiva a predittiva.
Domande frequenti sui prezzi di Amazon Bedrock
Qual è il modo più economico per usare Amazon Bedrock?
L'approccio più economico combina il right-sizing del modello con la batch inference, dove possibile. Usare un modello più piccolo e adeguato al task al posto di un frontier model può ridurre il costo per token di 10-20 volte. Abilitare la batch inference per i workloads che non richiedono tempo reale aggiunge fino al 50% di risparmio. Il prompt caching su prompt di sistema e contesti ripetuti riduce ulteriormente gli addebiti dei token di input. Inizi verificando quali casi d'uso richiedono davvero un modello grande e migri tutto il resto al modello più piccolo che soddisfi la sua soglia di qualità.
Come si confronta il provisioned throughput di Amazon Bedrock con il pricing on-demand?
L'on-demand fattura per token elaborato senza impegno. Il provisioned throughput riserva capacità dedicata a una tariffa oraria fissa, fatturata indipendentemente dall'utilizzo. Diventa conveniente con livelli di utilizzo elevati e costanti, in genere quando i costi on-demand supererebbero la tariffa oraria di impegno. Per i modelli custom e fine-tuned è obbligatorio a prescindere dal volume. L'on-demand è invece la scelta predefinita giusta per workloads variabili, applicazioni in fase iniziale e qualsiasi caso d'uso in cui i pattern di utilizzo non siano ancora prevedibili.
In che modo i token di input e di output influenzano i costi di Amazon Bedrock?
I token di input e di output hanno prezzi distinti, e i token di output costano in genere da tre a cinque volte di più per milione rispetto a quelli di input. Significa che la verbosità dell'output, ovvero quanto si chiede al modello di produrre per richiesta, ha un impatto sproporzionato sulla fattura. Le applicazioni che richiedono spiegazioni dettagliate, contenuti long-form o output strutturati prolissi peseranno fortemente sul lato dei costi di output. Progettare prompt che vincolino la lunghezza dell'output senza sacrificare la qualità è una leva diretta di controllo dei costi.
Amazon Bedrock fattura le chiamate API fallite?
Bedrock fattura i token elaborati con successo. Le richieste che falliscono prima dell'avvio dell'inferenza, come errori di autenticazione o richieste throttled, non generano addebiti per token. I retry su chiamate che invece raggiungono l'inferenza prima di fallire, ad esempio per violazioni della lunghezza del contesto, possono però generare addebiti parziali. Monitorare i tassi di retry e le modalità di failure fa parte di un cost management responsabile.
Quali strumenti aiutano a tracciare e controllare la spesa Amazon Bedrock?
AWS Cost Explorer mostra la spesa Bedrock a livello di servizio e AWS Budgets può lanciare alert su soglie di costo. CloudWatch raccoglie le metriche di invocazione. Per la visibilità a livello di token è essenziale il logging applicativo dei conteggi di token di input e output per ogni richiesta. Il tagging delle risorse per applicazione, team e ambiente abilita l'allocazione dei costi. Piattaforme come DoiT Cloud Intelligence offrono analytics in tempo reale sui costi AI e rilevamento automatico delle anomalie sull'utilizzo di Bedrock.