Data Lifecycle and Storage Management

Benvenuti nel binario ml-tabellare: qui ragioniamo per classi di dato, soglie e costi. Un bucket cresce ogni giorno con log grezzi, file intermedi, snapshot e output analytics, ma quei dati non hanno lo stesso valore dopo 7, 90 o 365 giorni. Il lifecycle corretto non è solo risparmio di storage: decide quali dati restano disponibili, quali diventano freddi e quali non dovrebbero più esistere.

L’idea in una frase

Il ciclo di vita dei dati decide quando ogni prefisso del lake passa dal caldo al freddo e quando sparisce, in base a uso reale, obblighi e costo. Il resto della lezione è applicare questa frase ai tuoi bucket senza sbagliare soglie.

Il metodo, in sei passi

1. Dividi il bucket per classi di dato con retention diversa: raw, curated e compliance.
2. Misura la frequenza di lettura di ogni prefisso e annota gli obblighi di retention.
3. Assegna a ogni classe la sequenza Standard, Infrequent Access e Glacier con giorni espliciti.
4. Scrivi la policy con transizioni ed expiration e applicala per prefisso, mai unica per tutto il bucket.
5. Verifica che i dati interrogati spesso restino fuori da Glacier e che le dashboard leggano solo classi calde.
6. Riesamina la spesa per classe e i tempi di restore prima di alzare o abbassare una soglia.

S3 storage classes: from hot to cold

Le classi S3 si distinguono per costo, latenza e prezzo di recupero. La regola pratica è semplice: più un dato è freddo, meno costa tenerlo ma più costa e più è lento rileggerlo. La tabella sottostante è quella che ti servirà nelle decisioni di progetto:

Class	Cost/GB/month	Access latency	Recovery	For data...
S3 Standard	~$0.023	Milliseconds	Free	Last 30-90 days
S3 IA (Infrequent Access)	~$0.0125	Milliseconds	$0.01/GB	3-12 months, rare access
S3 Glacier	~$0.004	Minutes/hours	$0.01-0.03/GB	>12 months, compliance only
S3 Deep Archive	~$0.00099	Hours	$0.02/GB	Obsolete history, almost never read

Lifecycle policy in practice

Una policy concreta sposta i dati lungo le classi man mano che invecchiano e li cancella alla fine del periodo di retention. Il file JSON qui sotto è un esempio realistico: trenta giorni verso Infrequent Access, novanta verso Glacier, e dopo sette anni la cancellazione definitiva.

{
  "Rules": [
    {"Transition": {"Days": 30, "StorageClass": "STANDARD_IA"}},
    {"Transition": {"Days": 90, "StorageClass": "GLACIER"}},
    {"Expiration": {"Days": 2555}}  // 7 anni
  ]
}

Dopo trenta giorni i dati passano in Infrequent Access, dopo novanta giorni in Glacier, dopo sette anni vengono cancellati. Su un data lake di grandi dimensioni una policy del genere sposta la spesa dallo storage caldo a quello freddo in modo misurabile.

Query su dati archiviati: la trappola

Qui sta la trappola più comune. Athena non può interrogare direttamente i dati in Glacier: vanno ripristinati prima, con ore di attesa. Per dati storici che potresti dover interrogare, lasciali in S3 IA invece che in Glacier. Riserva Glacier alla pura compliance, per esempio dati fiscali di cinque anni fa che quasi certamente non leggerai mai.

Il pattern che funziona: tieni in S3 Standard i dati degli ultimi novanta giorni, in IA quelli tra tre e ventiquattro mesi, in Glacier il resto. Le dashboard leggono solo Standard, le query di audit richiedono un restore da Glacier con preavviso.

In sintesi: Standard per gli ultimi novanta giorni, Infrequent Access per l’anno successivo e Glacier solo per la pura compliance mai interrogata.

References:

• AWS. (2024). “S3 Storage Classes.” aws.amazon.com/s3/storage-classes/.

Gli errori che costano cari

Il primo errore è applicare una sola regola di lifecycle a tutto il bucket, ignorando che raw, curated e dati di compliance hanno valore e obblighi diversi. Il secondo è mandare in Glacier dati che potresti dover interrogare, scoprendo solo durante un incidente che il restore richiede ore. Il terzo è confondere risparmio di storage con risparmio reale: una policy che cancella dati ancora soggetti a obbligo di retention sposta il costo dal cloud alla multa.

Un pezzo di storia: Glacier arriva nel 2012

Amazon S3 debutta nel 2006 come storage a oggetti con una sola classe calda e i lake crescono fino a pagare ogni gigabyte come se fosse sempre urgente. Nel 2012 Amazon introduce Glacier, una classe di archiviazione con recupero in ore a costo molto più basso, pensata per dati quasi mai riletti. Da allora la gestione del ciclo di vita diventa una leva di costo standard: i dati recenti restano interrogabili in millisecondi e lo storico scivola verso classi fredde. La regola che resta valida è quella della trappola di Athena: ciò che finisce in archivio freddo non si interroga più a freddo.

Verdetto: Standard per gli ultimi novanta giorni, Infrequent Access per l’anno successivo e Glacier solo per la pura compliance mai interrogata: se un dato potrebbe servire a una query, lascialo in IA invece che in Glacier, perché ciò che finisce in archivio freddo non si interroga più a freddo.

Tre domande per verificare

1. Dopo quanti giorni un prefisso raw smette di meritare la classe Standard?
2. Quando conviene tenere un dato in Infrequent Access invece di spostarlo in Glacier?
3. Quale vincolo di Athena ti impedisce di interrogare direttamente i dati archiviati?
4. Quale controllo sugli obblighi di retention fai prima di impostare una expiration?