In sintesi
- Classi di storage, costi di egress, costi delle richieste API e fee di transizione aggiungono ciascuno un livello di fatturazione a sé stante: la tariffa per GB è solo il punto di partenza.
- AWS S3 Standard costa circa 23 $/TB al mese; Glacier Deep Archive scende a circa 1 $/TB. Il divario si traduce in un risparmio reale solo se le lifecycle policy instradano correttamente i dati.
- L'egress è spesso la singola voce variabile più alta negli ambienti multi-cloud. La replica cross-region e i trasferimenti tra provider generano costi che si accumulano in fretta.
- Il tiering intelligente (S3 Intelligent-Tiering, GCP Autoclass) ha senso per workloads con pattern di accesso imprevedibili. Per workloads prevedibili, le regole di lifecycle manuali producono risparmi maggiori.
- Il rilevamento delle anomalie in tempo reale intercetta job fuori controllo e policy mal configurate prima che diventino un problema di budget. La revisione mensile della fattura, invece, li scopre quando ormai il danno è fatto.
Quando iniziano a distribuire i dati su più provider, la maggior parte dei team ha solo un'idea approssimativa di quanto costerà il cloud storage. Le tariffe per gigabyte di AWS, Azure e Google Cloud sono facili da reperire e confrontare, ma la fattura effettiva dipende da molto più delle sole tariffe di storage. Costi di egress, costi delle richieste API, transizioni tra classi di storage e fee di recupero si sommano, spesso in modi che non emergono finché non arriva la fattura. Senza visibilità in tempo reale, queste voci possono crescere per mesi prima che qualcuno se ne accorga.
Questo articolo analizza i principali fattori di costo nel multi-cloud storage, mette a confronto le diverse logiche di pricing di AWS, Azure e Google Cloud e illustra le strategie che riportano davvero la spesa sotto controllo.
Cosa determina davvero i costi del cloud storage?
La fatturazione dello storage si articola su quattro livelli di costo distinti, che interagiscono in modi tali da rendere il totale davvero difficile da prevedere a partire dalla sola tariffa per GB.
Classi di storage
La maggior parte dei team paga troppo perché i dati finiscono nel tier sbagliato. Ogni grande cloud provider offre più classi di storage tariffate in base alla frequenza di accesso: AWS S3 Standard per i dati hot, Glacier Deep Archive per l'archiviazione e diversi tier intermedi. Google Cloud Storage e Azure Blob Storage seguono lo stesso modello.
Il divario di prezzo tra i tier è notevole. Un terabyte in S3 Standard costa circa 23 $ al mese. Lo stesso terabyte in Glacier Deep Archive scende a circa 1 $. Quel risparmio, però, si concretizza solo quando i dati vengono effettivamente instradati nel tier giusto. Nella pratica, i backup restano per mesi nello storage premium, i file di log che nessuno consulta rimangono in Standard per un anno e le copie di disaster recovery finiscono nello stesso tier costoso dei dati attivi.
Trasferimento dati e costi di egress
I cloud provider non addebitano il trasferimento dei dati in ingresso, anche se l'ingestion su larga scala comporta comunque costi reali in termini di lavoro, strumenti e richieste API in scrittura. Spostare i dati in uscita, invece, genera un addebito da parte del provider. Le fee di egress si applicano ogni volta che i dati vengono trasferiti tra regioni, tra provider o verso internet.
Negli ambienti multi-cloud questi costi si accumulano in fretta. Una configurazione di disaster recovery che replica i dati da AWS ad Azure genera costi di trasferimento ricorrenti che i team sottostimano regolarmente in fase di pianificazione. Le pipeline di analytics che estraggono grandi dataset dal cloud storage per elaborarli altrove presentano lo stesso problema, così come le pipeline di content delivery che servono file a utenti in più aree geografiche.
Costi delle richieste e delle API
Su larga scala, i costi delle richieste API diventano una voce di spesa concreta. Ogni operazione di lettura, scrittura, elenco o eliminazione su un bucket di cloud storage genera una chiamata API fatturabile. La tariffa per richiesta è minima — frazioni di centesimo — ma migrazioni, job di batch processing e test di disaster recovery possono spingere il volume delle richieste a milioni nell'arco di un singolo periodo di fatturazione.
Un job di backup mal ottimizzato che genera richieste LIST o GET superflue può produrre centinaia o migliaia di dollari in costi di richieste prima che qualcuno se ne accorga. Sulla singola richiesta il costo non desta alcun allarme: emerge solo quando si aggrega l'intera esecuzione del job.
Overhead operativo
Lo storage multi-cloud crea una "tassa" gestionale che non compare in nessuna fattura del provider. Monitorare l'utilizzo, configurare le lifecycle policy, rivedere le fatture, indagare sulle anomalie e coordinarsi tra account: tutto questo consuma tempo del team di engineering, e quel tempo si moltiplica con ogni cloud aggiuntivo.
Ogni provider ha i propri strumenti, dashboard e formati di fatturazione. Questa frammentazione rende più difficile cogliere il quadro d'insieme e più facile l'accumulo di sprechi. Per i team senza una solida automazione e pratiche FinOps chiare, l'overhead operativo finisce spesso per essere uno dei maggiori costi nascosti dello storage multi-cloud.
Come si confrontano AWS, Azure e Google Cloud sul pricing dello storage?
Tutti e tre i provider tariffano l'object storage in modo simile sul prezzo di listino, ma le differenze su transizioni, egress e richieste creano reali opportunità di ottimizzazione per i team che eseguono workloads su più cloud.
Provider
Storage standard
Storage di archivio
Egress (primo tier)
Durata minima archivio
AWS S3
0,023 $/GB
~0,004 $/GB (Glacier Deep Archive)
~0,09 $/GB
180 giorni
Azure Blob
0,018 $/GB (tier Hot)
~0,002 $/GB (tier Archive)
~0,087 $/GB
180 giorni
Google Cloud
0,020 $/GB (Standard)
~0,001 $/GB (Archive)
~0,12 $/GB
Nessuna
I prezzi indicati sono quelli di listino per le regioni USA aggiornati a marzo 2025. Verifichi le tariffe correnti sulle pagine di pricing di AWS, Azure e Google Cloud prima di pianificare il budget.
Per lo storage ad accesso frequente nelle regioni USA: AWS S3 Standard parte da 0,023 $ per GB al mese, il tier Hot di Azure Blob è a 0,018 $ per GB e Google Cloud Storage Standard si attesta intorno a 0,020 $ per GB. Tutte e tre le tariffe diminuiscono al crescere dei volumi.
In cosa differiscono le transizioni tra classi di storage?
AWS addebita una tariffa per ogni 1.000 oggetti spostati tra classi di storage. Trasferire milioni di file di piccole dimensioni può costare più del risparmio sullo storage che la migrazione avrebbe dovuto generare. Azure e Google Cloud applicano fee di transizione analoghe, con strutture tariffarie e durate minime di storage diverse.
Le lifecycle policy che spostano i dati verso tier più freddi senza considerare i costi di transizione possono produrre un risultato netto negativo. Faccia i conti sul numero di oggetti prima di automatizzare qualsiasi migrazione di tier su larga scala.
Quando il pricing dell'egress diventa costoso?
L'egress è il punto in cui le operazioni multi-cloud diventano costose. All'interno dello stesso provider, i trasferimenti same-region tra servizi sono gratuiti. La replica cross-region e i trasferimenti tra servizi in regioni diverse sono invece sempre a pagamento.
Sia AWS sia Azure addebitano il traffico in uscita dalle proprie reti, con tariffe che diminuiscono al crescere dei volumi — ma i primi terabyte mensili scontano la tariffa per GB più alta. Google Cloud ha storicamente offerto un pricing dell'egress più competitivo e franchigie free-tier più generose per alcune tipologie di trasferimento.
Per i team che spostano dati tra cloud per disaster recovery o analytics, l'egress diventa regolarmente la singola voce variabile più alta della fattura. È uno dei motivi principali per cui il cloud financial planning conta così tanto negli ambienti multi-cloud.
Come varia il pricing delle richieste tra i provider?
I costi delle richieste API variano in base al provider e alla classe di storage. Una richiesta GET su S3 Standard costa una frazione di centesimo. La stessa richiesta su Glacier Flexible Retrieval costa molto di più. Azure e Google Cloud hanno ciascuno le proprie curve di pricing, e le differenze emergono con maggiore chiarezza durante eventi ad alto volume: migrazioni, elaborazione di dati in bulk o reportistica di fine trimestre.
La piattaforma Cloud Intelligence di DoiT aggrega i costi di storage di AWS, Azure e Google Cloud in un'unica vista, consentendo di individuare dove si concentra la spesa e dove uno spostamento di tier o un cambio di workload genererebbero risparmi reali — senza vincolarsi agli strumenti di un singolo vendor.
Come stimare e ridurre i costi del cloud storage
L'ottimizzazione del cloud storage produce risparmi duraturi quando viene gestita come una pratica continua e non come una pulizia una tantum. Parta da una baseline affidabile, automatizzi ciò che può e introduca revisioni periodiche, in modo che la deriva dei pattern di accesso non vanifichi silenziosamente i risultati ottenuti.
Parta da una baseline chiara
Non si può ottimizzare ciò che non si vede. Prima di intervenire su qualsiasi cosa, ottenga un quadro completo della spesa per classe di storage, regione e workload — non solo il totale mensile della fattura.
Ogni provider mette a disposizione strumenti nativi di gestione costi: AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports. In un ambiente multi-cloud, mettere insieme manualmente queste viste produce un quadro incompleto e fa perdere di vista i pattern cross-cloud. La maggior parte dei team scopre che i profili di utilizzo reali divergono in modo significativo dalle ipotesi architetturali iniziali, soprattutto per workloads che si sono evoluti nel tempo.
Cloud Analytics di DoiT aggrega i dati di fatturazione di tutti e tre i provider in un'unica vista, facendo emergere automaticamente i confronti di storage cross-cloud. Affiancare questi dati ai KPI FinOps su utilizzo dello storage e sprechi offre ai team un metodo solido per misurare i progressi, invece di valutare la fattura a occhio ogni mese.
Come implementare le lifecycle policy?
Le regole di lifecycle spostano automaticamente gli oggetti su classi di storage più economiche in base all'età o ai pattern di accesso e li eliminano alla scadenza dei periodi di retention. Tutti e tre i principali provider le supportano. Configurarle correttamente richiede di conoscere i propri dati abbastanza bene da definire tempistiche di transizione che riflettano l'effettivo utilizzo degli oggetti.
Una lifecycle policy ben configurata per i dati di log potrebbe avere questo aspetto:
- Spostare gli oggetti su storage a infrequent-access dopo 30 giorni senza letture
- Trasferirli in storage di archivio dopo 90 giorni
- Eliminare i dati scaduti al limite di retention definito
L'errore più costoso in tema di lifecycle non è l'assenza di una policy, ma un filtro mal configurato che impedisce a una policy esistente di scattare. Gli oggetti si accumulano nello storage premium per mesi prima che qualcuno risalga dalla fattura alla regola che ha smesso di funzionare in silenzio.
Inserisca una revisione trimestrale delle configurazioni di lifecycle nel suo workflow FinOps. I pattern di accesso cambiano con l'evoluzione delle applicazioni e una policy adatta ai suoi dati un anno fa potrebbe non corrispondere più al modo in cui quegli oggetti vengono effettivamente letti oggi.
Quando ha senso il tiering intelligente?
Il tiering intelligente si ripaga sui workloads in cui i pattern di accesso sono davvero imprevedibili. AWS S3 Intelligent-Tiering sposta automaticamente gli oggetti tra i tier di accesso in base all'utilizzo, senza fee di recupero quando i dati tornano a un tier più hot. Autoclass di Google Cloud funziona in modo simile, spostando gli oggetti senza penali per cancellazione anticipata. Azure ha introdotto Smart Tier con lo stesso approccio, anche se a inizio 2026 resta in public preview.
Queste funzionalità non sono gratuite. S3 Intelligent-Tiering applica una fee di monitoraggio per oggetto, mentre Autoclass di Google aggiunge una fee di gestione. Per workloads con pattern di accesso prevedibili, le regole di lifecycle configurate manualmente producono risparmi migliori. Per bucket di grandi dimensioni a uso misto, in cui alcuni oggetti ricevono traffico regolare e altri restano intatti per mesi, il tiering intelligente elimina le incertezze e tipicamente recupera in fretta il proprio costo.
Comprima e deduplichi
Compressione e deduplicazione riducono il volume dei dati archiviati prima ancora che entri in gioco il pricing del cloud. La maggior parte degli strumenti di backup e dei framework di data pipeline supporta nativamente la compressione: abilitarla richiede spesso una sola modifica di configurazione.
La deduplicazione produce i guadagni maggiori quando più sistemi scrivono dati simili in posizioni di storage diverse. Identificare e consolidare quelle copie ridondanti può ridurre il volume archiviato del 30% o più in ambienti con flussi di backup e archiviazione sovrapposti.
Monitori in tempo reale, non a posteriori
Le revisioni mensili della fattura lasciano ai problemi 30 giorni per accumularsi prima che qualcuno li veda. Un job di migrazione fuori controllo che genera milioni di chiamate API impreviste o una lifecycle policy mal configurata che spinge i dati in un tier costoso possono andare avanti per settimane senza emergere in un controllo di fatturazione mensile.
La piattaforma DoiT offre rilevamento delle anomalie in tempo reale e raccomandazioni di ottimizzazione automatizzate sui tre principali cloud. È questa visibilità continua a separare i team che controllano i costi cloud da quelli che li subiscono.
Quali costi nascosti sfuggono ai team CloudOps?
Anche i team con solide abitudini FinOps si lasciano sfuggire sistematicamente le stesse tre categorie di costo. Tutte e tre compaiono da qualche parte nella documentazione dei provider, ma non entrano nelle conversazioni sul budget finché non hanno già generato una fattura significativa.
Trasferimento dati cross-region
I costi di replica cross-region colgono di sorpresa la maggior parte dei team perché il costo per evento sembra piccolo, mentre l'aggregato è elevato. Aggiornamenti frequenti dei dataset generano costi di egress a ogni ciclo di replica e, per i dati attivi, possono arrivare a rivaleggiare con il costo dello storage stesso.
Su AWS, la replica cross-region comporta due addebiti: la fee di trasferimento dati e le richieste PUT che scrivono le repliche nella regione di destinazione. Molti team configurano la replica cross-region in fase di deployment iniziale e poi se ne dimenticano, anche quando la giustificazione di business originaria è cambiata o quei dati hanno smesso di essere rilevanti.
Costi delle API durante le migrazioni
Le grandi migrazioni tra classi di storage, provider o regioni generano volumi di richieste API che la maggior parte delle proiezioni di costo sottostima. Una migrazione che coinvolge decine di milioni di oggetti di piccole dimensioni può produrre migliaia di dollari in costi di richieste, oltre alle fee di trasferimento.
I calcoli basati su campionamento e proiezione tendono a sottostimare i costi reali, perché il volume delle chiamate API cresce più rapidamente del volume dei dati man mano che la migrazione scala. Esegua una stima dei costi in dry-run completa sull'effettivo numero di oggetti prima di impegnarsi in una migrazione di grandi dimensioni.
Fee di transizione tra classi di storage
Le fee di transizione possono trasformare uno spostamento di lifecycle pensato per risparmiare in una spesa netta. Quando i dati passano a un tier freddo e poi vengono recuperati di frequente, la combinazione di fee di transizione e costi di recupero può superare quanto sarebbe costato restare nel tier originale.
Le penali per cancellazione anticipata aggiungono un ulteriore livello di rischio. Glacier prevede una durata minima di storage di 90 giorni; Azure Archive di 180. Eliminare i dati prima di quei minimi significa pagare comunque l'intero periodo. Questi minimi si applicano anche quando una regola di lifecycle sposta i dati in un tier di eliminazione in anticipo rispetto al previsto.
Tutte e tre queste categorie di costo condividono lo stesso schema: si accumulano gradualmente su decine di voci di piccole dimensioni e restano invisibili nelle revisioni mensili di fatturazione. Quando si manifestano come picco evidente, hanno già avuto settimane per gonfiarsi. Il monitoraggio in tempo reale le intercetta alla fonte.
Riprendere il controllo della spesa di cloud storage
I costi del multi-cloud storage restano gestibili quando tre elementi procedono in parallelo: monitoraggio continuo che intercetta le anomalie in tempo reale, policy di lifecycle e tiering automatizzate che instradano correttamente i dati senza intervento manuale e una contabilità chiara di come le decisioni architetturali si traducono in voci di fatturazione.
La piattaforma Cloud Intelligence di DoiT offre ai team FinOps e CloudOps una vista unificata dei costi di storage su AWS, Azure e Google Cloud, insieme a raccomandazioni automatizzate che funzionano su tutti e tre i provider. Combinata con una strategia disciplinata di cloud financial planning, è una via concreta per riportare sotto controllo i costi del multi-cloud storage e mantenerli tali nel tempo.
Se le sue fatture di storage stanno crescendo più rapidamente dei suoi dati, vale la pena guardarle più da vicino. Parli con DoiT per ottenere visibilità e controllo in tempo reale sulla spesa di cloud storage multi-cloud.