Perché i tier esistono

Non tutti i dati hanno lo stesso valore nel tempo: un log applicativo appena scritto viene interrogato spesso, lo stesso log a sei mesi serve quasi solo per audit. Azure Blob Storage permette di allineare il costo alla frequenza di accesso tramite gli access tier, disponibili solo su account StorageV2 (general-purpose v2) o Blob storage e applicabili ai block blob. Il principio da interiorizzare per l’esame è il trade-off inverso: più il tier è “freddo”, più basso è il costo di storage ma più alto è il costo di accesso (transazioni + data retrieval) e la latenza.

Confronto tra Hot, Cool, Cold e Archive

  • Hot — costo di storage più alto, costo di accesso più basso, nessuna latenza. Per dati in uso attivo o in fase di caricamento/elaborazione.
  • Cool — storage più economico di Hot, costi di accesso più alti, minimo 30 giorni di permanenza. Per backup a breve termine e dati acceduti raramente ma che devono restare online (accesso immediato).
  • Cold — introdotto per il gap tra Cool e Archive: storage ancora più basso, accesso ancora più costoso, minimo 90 giorni, ma sempre online con lettura immediata.
  • Archive — costo di storage minimo in assoluto, offline: il blob non è leggibile finché non viene reidratato. Permanenza minima 180 giorni. Ideale per conservazione legale/compliance a lungo termine.

Rehydration dall’Archive

Un blob in Archive va prima riportato online (in Hot, Cool o Cold) con due modalità:

  • copia verso un blob di destinazione in un tier online, oppure
  • cambio di tier in place dell’oggetto stesso.

La rehydration priority è Standard (fino a circa 15 ore) o High (tipicamente sotto l’ora per oggetti piccoli, con costo maggiore). Punto chiave: non esiste lettura “istantanea” dall’Archive; qualsiasi scenario che richiede accesso immediato esclude Archive.

Lifecycle management

Impostare il tier a mano non scala. Le lifecycle management policy sono regole JSON a livello di storage account che automatizzano tiering ed eliminazione dei block blob in base a condizioni come daysAfterModificationGreaterThan, daysAfterLastAccessTimeGreaterThan (richiede last access time tracking attivo) o daysAfterCreationGreaterThan per gli snapshot/versioni.

Le azioni tipiche in una regola sono:

  • tierToCool / tierToCold / tierToArchive — sposta i blob su tier progressivamente più freddi.
  • delete — elimina automaticamente blob, versioni precedenti o snapshot obsoleti.

Le regole supportano filtri per prefisso (prefixMatch) e per blob index tag, così da applicare politiche diverse a dataset diversi nello stesso container. Esempio concettuale: Hot per 30 giorni → Cool → Archive dopo 180 giorni → delete dopo 7 anni.

"actions": {
  "baseBlob": {
    "tierToCool": { "daysAfterModificationGreaterThan": 30 },
    "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
    "delete": { "daysAfterModificationGreaterThan": 2555 }
  }
}

Data protection: versioning e soft delete

Tiering e retention riguardano il costo; la protezione del dato è un asse separato ma spesso combinato:

  • Blob versioning — mantiene automaticamente una versione precedente a ogni sovrascrittura o cancellazione, consentendo il ripristino a uno stato passato. Va gestito con lifecycle rule dedicate, altrimenti le versioni accumulate fanno lievitare i costi.
  • Soft delete for blobs / containers — trattiene i dati eliminati per un periodo di retention configurabile, rendendo recuperabile una cancellazione accidentale prima della rimozione definitiva.
  • Per un ripristino a un istante preciso serve point-in-time restore, che a sua volta richiede versioning, soft delete e change feed attivi.

Trappole tipiche d’esame

  • Serve accesso immediato a dati archiviati per compliance → NON Archive. Se il requisito è “leggibile subito ma raramente”, scegli Cool o Cold (online), non Archive che richiede ore di rehydration.
  • Blob spostato in Archive/Cool/Cold ed eliminato o ri-tierizzato subito → early deletion penalty. L’addebito minimo copre 30 giorni (Cool), 90 (Cold), 180 (Archive) anche se il dato viene rimosso prima.
  • “Ridurre i costi automaticamente dopo N giorni di inattività” → lifecycle management policy, non scripting manuale né cambio di tier a mano.
  • Recupero da sovrascrittura accidentale → blob versioning; recupero da cancellazione accidentale entro la retention → soft delete. Non confondere i due meccanismi.
  • Tier di default a livello di account applicabile solo a Hot/Cool: Archive si imposta solo a livello di singolo blob o tramite lifecycle policy, mai come default dell’account.