{"id":8832,"date":"2026-08-26T14:37:56","date_gmt":"2026-08-26T12:37:56","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=8832"},"modified":"2026-08-26T14:39:08","modified_gmt":"2026-08-26T12:39:08","slug":"la-tua-bolletta-aws-non-e-uno-strumento-di-observability-come-monitorare-lutilizzo-dei-token-per-amazon-bedrock","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/la-tua-bolletta-aws-non-e-uno-strumento-di-observability-come-monitorare-lutilizzo-dei-token-per-amazon-bedrock\/","title":{"rendered":"La tua bolletta AWS non \u00e8 uno strumento di observability: come monitorare l’utilizzo dei token per Amazon Bedrock"},"content":{"rendered":"\n
\n

Every single day<\/em>
And every word you say<\/em>
Every game you play<\/em>
Every night you stay<\/em>
I’ll be watching you<\/em>

The Police, I\u2019ll be watching you<\/p>\n<\/blockquote>\n\n\n\n

Un team che gestisce workload di intelligenza artificiale generativa dovrebbe poter rispondere a questa domanda in qualsiasi momento della giornata: quanti token stiamo consumando e quanto ci costano?<\/strong><\/p>\n\n\n\n

Se la risposta a questa domanda \u00e8 “fammi controllare il billing”, allora questo articolo fa al caso tuo. <\/p>\n\n\n\n

Di recente ho imparato, nel modo peggiore possibile, che la billing console \u00e8 uno strumento di reconciliation, non di observability. \u00c8 in ritardo, \u00e8 aggregata e, in casi rari ma molto reali, pu\u00f2 anche sbagliare.<\/em><\/p>\n\n\n\n

Quanto sbagliata? Nel mio caso, di un fattore mille. <\/p>\n\n\n\n

Mi sono svegliato (beh, tecnicamente, avevo appena finito di pranzare) davanti a una bolletta da 58.000 dollari per un workload che sarebbe dovuto costare una cinquantina di dollari. <\/a>L’unico motivo per cui sono riuscito a dimostrare l’errore, a farlo correggere in pochi giorni e a far sistemare il bug sottostante per tutti \u00e8 che avevo una telemetria dei token mantenuta dall\u2019applicazione, che non dipendeva dal metering di AWS.<\/p>\n\n\n\n

Ma niente spoiler: vediamo cos’\u00e8 successo e come sono sopravvissuto.<\/p>\n\n\n\n

L’incidente<\/h2>\n\n\n\n

Per prima cosa, un po\u2019 di contesto. Magari sapete gi\u00e0 che mi piace testare nuovi servizi e condividere quello che imparo: a febbraio 2026, da Community Builder (adesso sono Hero!), stavo sperimentando con agent autonomi su Amazon Bedrock usando OpenClaw, confrontando diversi foundation model: DeepSeek v3.2, Amazon Nova Lite e, pi\u00f9 avanti, Kimi K2.5 di Moonshot AI, arrivato nel catalogo Bedrock giusto in tempo.<\/p>\n\n\n\n

Il pricing di Kimi sembrava ottimo: $0.60 per milione di input token e $3.00 per milione di output token. Ma la libreria Node.js di OpenClaw non andava d’accordo con l’implementazione del tool-calling di Kimi sulle API native di Bedrock Converse: ottenevo chiamate fallite, risposte incoerenti e azioni che semplicemente non venivano eseguite, il tutto senza errori evidenti.<\/p>\n\n\n\n

Ho iniziato a fare debug della libreria, ma alla fine ho fatto ricorso a un altro metodo: leggere la documentazione (una tecnica di debug sorprendentemente efficace), che mi ha portato a trovare un workaround: Project Mantle<\/strong>, il motore di distributed inference di Bedrock annunciato al re:Invent 2025, che espone endpoint con API OpenAI-compatible<\/strong> come sostituto drop-in, senza dover modificare il codice applicativo.<\/p>\n\n\n\nBasta puntare il proprio client OpenAI all\u2019endpoint https:\/\/bedrock-mantle..api.aws\/v1<\/code><\/strong>, generare un access token per Bedrock, e tutto funziona. Ed \u00e8 stato proprio cos\u00ec: sono passato a Mantle il 17 febbraio, e i problemi di tool-calling sono spariti.\n\n\n\n\n

<\/p>\n\n\n\n

Ovviamente, trattandosi di esperimenti, ho mantenuto un approccio da \u201ccittadino del cloud\u201d responsabile, con controlli giornalieri del billing nell’account di management dell’organizzazione. Ho impostato un budget alarm da $100 sull’account sandbox e un forecast alarm, ovviamente. Il 23 febbraio, la bolletta mensile dell’intera organizzazione era di circa $140, comodamente coperta dai crediti AWS, con gli esperimenti su Bedrock che contribuivano ai costi con i soliti $3-5 al giorno.<\/p>\n\n\n\n

Poi, il 24 febbraio, subito dopo pranzo, sono arrivate due notifiche di AWS Budgets contemporaneamente: la spesa reale era di $56.265,59<\/strong>, mentre la previsione di fine mese era di $70.161,62<\/strong>, senza alcuna crescita graduale n\u00e9 alcun alert intermedio. La bolletta \u00e8 passata da $140 a oltre $56.000 dall’oggi al domani, per poi assestarsi oltre i $58K, tasse incluse.<\/p>\n\n\n\n

Dopo il fisiologico attacco di panico e il conseguente mezzo infarto, ho fatto quello che facciamo in beSharp quando un cliente ci chiama con una bolletta spaventosa: ho iniziato a misurare.<\/p>\n\n\n\n

Individuare il problema<\/h2>\n\n\n\n

Il breakdown del billing per us-east-1 mostrava il problema, ma in modo sottile, e c’\u00e8 voluto un attimo per crederci davvero. Gli input token di Kimi K2.5 attraverso Mantle erano 77.228.206 unit\u00e0 da 1K token<\/strong>, fatturate a $0,0006 per 1K, per un totale di $46.336,92<\/strong>. Gli output token erano 195.679 unit\u00e0 da 1K token a $0,003, per un totale di altri $587,04.<\/p>\n\n\n\n

77 milioni di migliaia di token. Cio\u00e8, 77 miliardi<\/strong> di token: una quantit\u00e0 di testo che non potresti, da solo, far passare attraverso un workflow di agenti interattivi in una settimana, nemmeno provandoci apposta.<\/p>\n\n\n\n

La telemetria lato applicazione mi ha salvato, perch\u00e9 OpenClaw traccia autonomamente l’utilizzo dei token, a partire dai campi usage restituiti dall’API. I suoi numeri per Kimi K2.5 via Mantle erano di circa 72,1 milioni di token su 547 messaggi<\/strong>. Non 72 milioni di migliaia di token, ma 72 milioni, e basta.<\/p>\n\n\n\n

Per essere sicuro che i numeri di OpenClaw fossero affidabili, ho verificato l’utilizzo dei token anche sugli altri modelli che avevo usato accedendo alle API native di Bedrock:<\/p>\n\n\n\n

Modello<\/strong><\/td>Percorso API<\/strong><\/td>Telemetria lato app<\/strong><\/td>Billing console<\/strong><\/td>Corrispondenza?<\/strong><\/td><\/tr>
DeepSeek v3.2<\/td>Bedrock nativa (Converse)<\/td>~61,8M token \/ 844 messaggi<\/td>61.910 x 1K token<\/td>S\u00ec<\/td><\/tr>
Amazon Nova Lite<\/td>Bedrock nativa (Converse)<\/td>Coerente<\/td>Coerente<\/td>S\u00ec<\/td><\/tr>
Kimi K2.5<\/td>Mantle (OpenAI-compatible)<\/td>~72,1M token \/ 547 messaggi<\/td>77.228.206 x 1K token<\/td>Scarto di ~1000x<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Era chiaro che qualcosa nel billing di Mantle trattava i token come unit\u00e0 da 1K, moltiplicando la mia bolletta per 1000; quindi, invece di $46,34, il mio debito era di $46.336,92. Si trattava di una semplice virgola fuori posto che mi stava costando quanto un’auto nuova (e nemmeno delle pi\u00f9 economiche!).<\/p>\n\n\n\n

La bolletta gonfiata era il bug, ma \u00e8 stata l’assenza di segnali \u201cpremonitori\u201d a peggiorare la situazione:<\/p>\n\n\n\n