Quando il cloud costa, ma nessuno sa dire perché

Ambiente AWS da dismettere, direzione già tracciata verso un'altra piattaforma cloud, decisione più o meno presa. Il classico scenario in cui si entra per "accompagnare" un passaggio che, sulla carta, è già stato deciso.

Poi però emerge una frase, detta quasi di lato, che cambia completamente il perimetro del lavoro:

Stiamo pagando AWS, ma non sappiamo esattamente per cosa.

Non "troppo". Non "poco". Proprio non spiegabile.

Ordinaria amministrazione in contesti in cui qualcuno, in solitaria, mette in piedi degli ambienti, non perde tempo a documentare nulla di quello che fa e lascia l'azienda in balia di se stessa.

E quando un costo non è spiegabile, non è un problema di cloud. È un problema di architettura.

L'attenzione cade abbastanza in fretta su S3. Non perché fosse l'unico servizio coinvolto, ma perché era quello che continuava a restituire una sensazione strana:

• consumo stabile
• nessun evento evidente
• nessuna crescita applicativa che lo giustificasse davvero.

Come l'ho scoperto

Il primo passo è stato il Cost Explorer di AWS. Lo strumento ovvio, quello che apri per istinto quando vuoi capire dove vanno i soldi. Ma su un account con decine di bucket e nessun tagging coerente, i numeri erano un muro grigio. Sapevi quanto pagavi al mese per S3, ma non sapevi quale bucket pesava di più, quale progetto stava generando quel consumo, quale parte fosse storage attivo e quale fosse zavorra. Cost Explorer, senza una strategia di tagging a monte, ti dà il totale della spesa ma non ti racconta nulla.

Ho valutato strumenti FinOps di terze parti: CloudHealth, Spot.io, Vantage. Tutti ottimi per un'azienda che vuole un monitoraggio continuo dei costi cloud, con dashboard, raccomandazioni automatiche, allocazione per team. Ma qui il contesto era diverso: serviva un audit puntuale su un account destinato alla dismissione. Configurare un tool FinOps enterprise per un'analisi una tantum significava investire tempo di setup su un'infrastruttura che non sarebbe rimasta in piedi. Era come installare un impianto di domotica in una casa che stai per vendere.

Il passo più utile è stato anche il più artigianale: un'analisi bucket per bucket delle metriche di storage, confrontando lo spazio occupato dalle versioni correnti con quello delle versioni precedenti e dei delete marker. Nessun tool automatico, ma la visibilità più granulare possibile a costo zero di licenza.

Il rapporto era assurdo: in alcuni bucket, le versioni "cancellate" occupavano più spazio di quelle attive. In un caso, il 70% dello storage era composto da versioni precedenti di file che l'applicazione aveva già eliminato mesi prima.

Scavando, viene fuori una configurazione molto comune: bucket con versioning attivo, cancellazioni gestite a livello applicativo, policy di lifecycle incompleta.

I file "sparivano" per chi usava il sistema, ma continuavano a vivere tranquillamente nello storage sotto forma di versioni precedenti.

Il risultato era paradossale solo in apparenza: si stava pagando per dati che, dal punto di vista dell'applicazione, non esistevano più.

A rendere il quadro più opaco c'era anche una scelta perfettamente legittima, ma poco fortunata nel contesto: la regione.

Lo storage era collocato su Milano, regione che al momento dell'assesssment non offriva strumenti adeguati come S3 Storage Lens. Meno visibilità, meno strumenti nativi per capire cosa stesse crescendo, meno possibilità di raccontare quei costi in modo chiaro a chi li doveva approvare.

Senza Storage Lens, ho dovuto costruire la visibilità a mano: export dei dati di inventario S3, aggregazione con script, e un report che per la prima volta metteva nero su bianco quanto spazio fosse "vivo" e quanto fosse inerzia. Il report è diventato il documento che ha cambiato la conversazione: non più "il cloud costa troppo", ma "stiamo pagando X euro al mese per dati che non servono più a nessuno."

A quel punto è diventato evidente che la migrazione non c'entrava nulla. O meglio: c'entrava troppo poco per essere la prima cosa da fare.

Portarsi dietro quello storage, così com'era, avrebbe significato spostare il problema, non risolverlo. E non in senso astratto: parliamo di terabyte di versioni precedenti che nessuna applicazione avrebbe mai più richiamato. Migrarli significava pagare costi di trasferimento dati in uscita da AWS, tempo di re-ingestion sulla nuova piattaforma, e capacità di rete dedicata a spostare file che non servivano a nessuno. La stima di migrazione, fatta su quel volume, includeva nel perimetro dati che avrebbero dovuto essere già spariti da mesi.

E una volta arrivati dall'altra parte? Lo stesso problema, con un nome diverso. Nessun lifecycle, nessun tagging, nessuna visibilità. Solo un nuovo provider e la stessa governance assente. Cambiare cloud non avrebbe magicamente trasformato dati non governati in dati ordinati. Avrebbe solo reso il debito meno familiare, ma identico nella sostanza.

Il web è pieno di persone che si lamentano dei "costi improbabili di AWS (o piattaforme cloud in generale)" anche dopo aver spento tutti i servizi.

La decisione reale, quindi, non è stata "come migriamo", ma se aveva senso migrare senza prima rimettere sotto controllo lo storage. Rendere osservabile ciò che fino a quel momento non lo era. Capire quanto spazio fosse realmente vivo, quanto fosse solo inerzia tecnica, quanta parte di quel costo fosse una conseguenza diretta di decisioni prese anni prima e mai più riviste.

È uno di quei casi in cui il cloud non è caro, né sbagliato. È semplicemente non governato.

E quando manca una governance del dato, ogni euro speso diventa difficile da difendere, prima ancora che da ottimizzare.

Cosa significa "governance" in pratica

Non è una parola da consulente. È una lista di cose concrete:

• Lifecycle policy complete: non solo "cancella dopo X giorni", ma regole per ogni fase del ciclo di vita del dato. Versioni correnti, versioni precedenti, delete marker, upload incompleti. Ognuno con la sua scadenza. In pratica, una policy ben fatta assomiglia a qualcosa del genere: le versioni precedenti scadono dopo 30 giorni, i delete marker vengono rimossi dopo 7 giorni, gli upload incompleti (quelli che restano a metà per un errore o un timeout) vengono cancellati dopo 1 giorno. Senza queste regole, ogni operazione di cancellazione o sovrascrittura lascia dietro di sé un residuo che si accumula nel tempo, invisibile all'applicazione ma perfettamente visibile in fattura.
• Tagging dei bucket: ogni bucket associato a un team, un progetto, un ambiente. Senza tag, i costi sono un numero. Con i tag, diventano una conversazione.
• Alert sui costi: soglie configurate in AWS Budgets. Non per bloccare la spesa, ma per eliminare le sorprese. Quando superi il budget previsto, lo sai prima della fattura.
• Revisione periodica: non una tantum, ma un processo ricorrente. Ogni trimestre, qualcuno guarda i numeri e si chiede se hanno ancora senso.

È lo stesso principio di base di Terraform: se non è descritto, non è governato. Se non è governato, prima o poi diventa debito.

Questo tipo di situazione ritorna spesso:

• versioning attivato "per sicurezza"; ottima idea
• cancellazioni delegate all'applicazione; comprensibile
• nessuno che si prenda carico del ciclo di vita completo; disastro garantito.

Finché i costi sono bassi non se ne parla. Quando iniziano a pesare, però, manca il linguaggio per spiegarli.

Ed è lì che, prima di qualsiasi migrazione, serve fermarsi e decidere.

Se vuoi parlarne, parliamone. Ti dico se serve davvero cambiare strada, o se è sufficiente sistemare quella su cui stai già camminando.