La fattura cloud che arriva il primo del mese e ti fa rileggere due volte la riga del totale: nel 2026 è una scena ricorrente in molte PMI europee. Mobile app, web application, data platform, qualche servizio AI in produzione — e di colpo l'OpEx cloud diventa una delle prime tre voci di costo del business. GPU che girano a vuoto, storage cresciuto del 40% senza che nessuno l'abbia notato, CDN configurate male, database "managed" sovra-dimensionati per principio.
La reazione istintiva, in queste situazioni, è tagliare. È quasi sempre l'errore più costoso. La risposta seria si chiama FinOps: un modo di lavorare che mette finance, tech e prodotto allo stesso tavolo per misurare, assegnare, ottimizzare e governare la spesa cloud — senza svendere velocità di sviluppo e qualità del prodotto.
Questa guida è pensata per chi guida una PMI o una scale-up digitale e vuole capire da dove iniziare. Trovate dentro: i concetti chiave, le leve concrete per app e per AI/LLM, gli strumenti che usiamo davvero, i KPI che parlano al business, una roadmap a 90 giorni e un caso reale con numeri.
FinOps è una disciplina collaborativa per rendere governabile la spesa cloud. L'obiettivo non è "spendere meno a tutti i costi" — è una distinzione importante. L'obiettivo è allineare la spesa al valore: pagare il giusto per le risorse che generano impatto su ricavi, clienti, roadmap. In pratica significa quattro cose:
Detto in modo brutale: FinOps esiste per evitare che il giovedì sera, alle 23, qualcuno scopra che un endpoint AI di test girava su H100 da tre settimane.
Quattro forze convergono e rendono il tema urgente, oggi più che ieri:
Lavorando con realtà di dimensioni e settori diversi, gli sprechi che vediamo si ripetono con disarmante regolarità. Sei pattern, in ordine di frequenza:
Quasi sempre, le prime sei settimane di un assessment FinOps si concentrano qui. È dove si recuperano i quick win che finanziano tutto il resto.
Il right-sizing è la prima azione e quasi sempre la più redditizia. Si riduce vCPU/RAM a step settimanali, controllando il p95 prima di passare allo step successivo — non si taglia di colpo. Le istanze Arm/Graviton, quando lo stack è compatibile, portano risparmi nell'ordine del 20-40% senza nessun compromesso visibile.
Gli spot/preemptible sono perfetti per batch e job non critici (ETL, generazione thumbnail, indexing): si parla di -60/80% sul costo, a fronte del rischio di interruzione che per quei carichi è gestibile. Su workload utente, ovviamente, no.
L'autoscaling va impostato sulla metrica giusta: queue depth o RTT, non solo CPU. La CPU è una proxy povera per "il sistema sta soffrendo", e seguendola si finisce a over-provisionare.
Le lifecycle policy dovrebbero essere obbligatorie per ogni bucket: log e file cold passano automaticamente a infrequent access e poi ad archive. Snapshot e oggetti temporanei hanno un TTL definito alla nascita, non "ci penseremo".
Compressione e deduplica fanno la differenza su backup e log — Parquet e ORC per i dati analitici sono lo standard ragionevole. Le repliche cross-region costano: vanno fatte solo per gli RTO/RPO che davvero servono, non per default.
Cache configurate male sono il peccato originale del front-end. TTL ed ETag corretti, formati moderni (AVIF/WebP), minify di CSS e JS, bundle splitting: roba elementare che spesso però non viene fatta. Edge compute per redirect e A/B test riduce gli origin hit e migliora la latenza nello stesso movimento.
Sui costi di egress vale la pena studiare peering e transfer acceleration quando i volumi lo giustificano. Sotto certe soglie, il gioco non vale la candela.
I piani serverless (Aurora Serverless v2, AlloyDB on-demand) sono perfetti per carichi bursty. Il provisioned ha senso solo quando l'utilizzo medio sta costantemente sopra il 60-70% — sotto, state pagando capacità che non usate.
Indici mirati, review dei query plan, caching applicativo con Redis o Memcached: classici, eppure quasi sempre ci sono margini significativi. Sulle code, long polling e batching riducono drasticamente il numero di invocazioni.
Qui è dove vediamo gli scostamenti più drammatici tra "spesa attesa" e "spesa effettiva". Lo dico chiaro: la maggior parte delle PMI che usa LLM in produzione paga 2-3 volte quello che dovrebbe.
Il principio è banale ma viene ignorato: il modello deve essere proporzionato al compito. Non si usa un 70B per ripulire un indirizzo o classificare un'email. Modelli small/medium o instruct da 7-13B bastano per l'80% dei casi reali in azienda. Quantizzazione a INT8/INT4 e modelli distillati riducono RAM, latenza e costo GPU senza che l'utente percepisca differenze — testato in produzione, non solo in benchmark.
La GPU giusta per il carico giusto: L4 o T4 per inferenza leggera, A100 e H100 solo per throughput elevato o modelli grandi. Endpoint con autoscaling e multi-tenancy quando i volumi lo permettono.
Batching e caching cambiano la matematica. Una semantic cache ben fatta su un assistente AI con FAQ ricorrenti taglia facilmente il 30-40% delle chiamate al modello. Gli embedding si fanno in batch, di notte, non on-demand.
Sul prompt engineering "economico" c'è un margine enorme che quasi nessuno coglie: istruzioni precompilate lato app invece che ripetute nel prompt, max_tokens sensati, temperature coerente con il task. Per output deterministici, temperature alta è solo soldi buttati.
Prima di scegliere un vector DB managed, fate i conti: costo per 1.000 token di embedding più storage e ricerca su Qdrant, Weaviate, OpenSearch o pgvector self-hosted, contro API gestite tipo Pinecone. La scelta dipende da volumi e latenza — non c'è una risposta universale, ma per molte PMI sotto certi volumi il self-hosted vince in modo chiaro.
Ingestion in batch notturni, compressione (pruning dei chunk duplicati), retention policy: lo storico tenetelo solo se crea valore. La tentazione di "salviamo tutto, non si sa mai" costa cara.
Consiglio non controverso: si parte sempre da SaaS, per time-to-market. Si valuta il passaggio a self-host o hybrid quando si superano soglie di costo significative — indicativamente sopra i 50-100 milioni di token al mese — oppure per vincoli di privacy o data residency, che con il quadro AI Act + GDPR sono temi sempre più centrali per le PMI europee.
In ogni caso, negoziate. Private pricing e committed use con i provider sono spesso disponibili anche per aziende non enormi. Marketplace cloud e private offer possono valere sconti importanti.
Il viaggio tipico di una PMI passa per tre fasi. All'inizio c'è il foglio Excel del CFO che cerca di mettere insieme le voci di costo del cloud — fase legittima per partire, insostenibile dopo poche settimane.
Si passa quindi agli strumenti nativi del cloud provider: AWS Cost Explorer più Budgets e Anomalies, GCP Billing con CUD insights, Azure Cost Management. Sono gratuiti e fanno tantissimo. Se non li state già usando seriamente, è il primo posto dove guardare.
Il presupposto di tutto è il tagging. Etichettare risorse per product, env, team e feature non è negoziabile. Senza, qualsiasi tool a valle è inutile — Garbage In, Garbage Out, lo schema più vecchio dell'informatica.
Per chi gira su Kubernetes, Kubecost e OpenCost permettono allocazione per namespace o label. CloudZero è un'alternativa interessante. Sopra una certa scala vale la pena valutare i FinOps SaaS specializzati: Finout, Zesty, ProsperOps (ottimo per automatizzare savings plan e RI), nOps.
Ma il vero salto avviene quando si mettono in dashboard le unit economics: costo per MAU, costo per ordine, costo per 1.000 token, costo per ricerca. Sono numeri che parlano al business, non solo al DevOps. Quando il CEO vede "costo per ordine in salita del 12%", la conversazione cambia natura.
La parte contrattuale pesa quanto quella tecnica, e spesso di più. Tre leve concrete:
La governance funziona se è incorporata nel processo, non se è un'attività separata. In concreto:
Una sequenza realistica, testata su più progetti:
Il totale spesa è la metrica meno utile che ci sia. Quello che conta davvero:
Un esempio reale, leggermente anonimizzato. Cliente: e-commerce italiano con app Flutter e front-end React, assistente AI per il supporto clienti integrato a inizio 2025. Spesa cloud al momento dell'engagement: 18.400€/mese, suddivisi tra compute (6.800), DB (3.200), storage (2.100), CDN (1.600) e AI (4.700). Trend in salita del 12% trimestre su trimestre — fatto che aveva attirato l'attenzione della direzione.
In otto settimane abbiamo lavorato su tutta la pila. Sul compute: right-sizing su tutto il fleet (-22%), passaggio a Spot per i job batch (-65% sulla quota interessata), migrazione di due microservizi su Arm/Graviton (-28%). Sullo storage: lifecycle aggressiva sui bucket S3 (hot → IA → archive in base ai pattern di accesso), riduzione dell'egress con cache CDN più aggressiva e conversione asset ad AVIF (-31% di banda).
Sul database, abbiamo spostato a serverless i carichi bursty, aggiunto indici mirati sulle query problematiche, introdotto Redis come cache applicativa per le query ripetitive (-18% sul totale DB).
Sull'AI è stato dove abbiamo lavorato di più, ed è dove abbiamo recuperato di più. Semplificazione dei prompt (-23% token), semantic cache sulle FAQ ricorrenti (-38% chiamate al modello), passaggio a un LLM medium per i task semplici tenendo il modello grande solo per le query complesse (-35% sul costo di inferenza), embedding spostati a batch notturni.
Infine, lato contrattuale, un Savings Plan a un anno sul 45% della baseline compute (-21% sulla quota coperta).
Risultato a due mesi: spesa scesa a 13.250€/mese (-28%). P95 latency invariata. CSAT salito di 2,1 punti (la cache rende anche più veloci alcune risposte). Costo per ordine da 0,34€ a 0,24€, pari al -29%. Numeri reali, replicabili — non magia.
Errori che vediamo ripetersi, in ordine di frequenza:
La parte difficile non è tecnica. È convincere finance, prodotto e tech a usare le stesse metriche. Quando il team UX conosce il "costo per ordine" e il team AI guarda il "costo per 1.000 token risolti", iniziano a progettare con la stessa bussola. La micro-decisione del designer ("aggiungo un'altra chiamata AI qui per migliorare l'esperienza?") cambia natura — perché vede il costo di quella chiamata.
Premiare obiettivi combinati (UX + costo, non uno o l'altro) è l'approccio che stimola i comportamenti giusti. Il team che taglia costi peggiorando il prodotto non vince. Il team che migliora il prodotto facendo esplodere i costi nemmeno. Vince chi tiene insieme entrambi i fronti — ed è esattamente quello che FinOps cerca di rendere sistematico.
Per un esempio concreto di come l'IA generativa stia entrando nei processi aziendali con questa logica di efficienza, abbiamo un approfondimento dedicato.
FinOps non è un progetto una tantum, è un modo di lavorare. È quello che permette a una PMI di innovare più in fretta tenendo il budget sotto controllo — e i due obiettivi, contrariamente a quello che si pensa, non sono in conflitto. Sono lo stesso obiettivo visto da angolazioni diverse.
Con una roadmap a 90 giorni, quick win mirati su compute, storage, CDN e AI, contratti negoziati con criterio e KPI di unit economics in dashboard, è realistico tagliare il 20-40% dei costi cloud senza sacrificare performance né velocità di rilascio. Il risultato è una piattaforma più sana, scalabile, pronta per le sfide del 2026: AI sempre più pervasiva, picchi di traffico, compliance ESG, competizione globale.
Tutto questo, peraltro, è parte integrante del Total Cost of Ownership di un software: ottimizzare il cloud è uno dei modi più diretti per mantenere il TCO sotto controllo nel medio periodo.
Se volete avviare un assessment FinOps sul vostro stack — app mobile, web, AI/LLM, data — possiamo aiutarvi a costruire visibilità, definire le unit metric giuste, raccogliere i quick win e integrare la governance nel ciclo di rilascio. Scriveteci: la prima analisi la facciamo insieme, senza impegno e senza vendite forzate.
