Perché Blob Storage nell’esame AZ-204

Azure Blob Storage è il servizio di object storage per dati non strutturati: immagini, video, backup, log, artefatti di build. Come sviluppatore devi scegliere il tipo di blob giusto, l’access tier corretto per il ciclo di vita del dato e il modello di autenticazione più sicuro. Sono esattamente le decisioni che l’esame verifica.

Tipi di blob

  • Block blob — l’opzione predefinita per file e streaming. Composto da blocchi caricati singolarmente e poi “committati”. È la scelta per upload di documenti, media e la maggior parte dei contenuti applicativi. Dimensione massima molto elevata (fino a circa 190 TiB).
  • Append blob — ottimizzato per operazioni di sola aggiunta in coda. Ideale per logging e telemetria dove scrivi eventi in sequenza ma non modifichi i dati esistenti.
  • Page blob — collezione di pagine da 512 byte ottimizzate per scritture e letture casuali (random access). Sono il backing store dei dischi gestiti delle VM (VHD). Se lo scenario parla di dischi o I/O casuale frequente, è page blob.

Access tier e trade-off di costo

Gli access tier bilanciano costo di storage contro costo di accesso e latenza:

  • Hot — storage più costoso, accesso più economico. Per dati usati di frequente.
  • Cool — storage più economico di Hot, costi di accesso più alti. Minimo di permanenza consigliato circa 30 giorni.
  • Cold — ancora più economico in storage, accesso più caro. Minimo circa 90 giorni. Dati raramente acceduti ma ancora online (leggibili immediatamente).
  • Archive — costo di storage minimo, ma è un tier offline. I dati non sono leggibili finché non li riporti online. Minimo circa 180 giorni.

Hot, Cool e Cold sono online: puoi impostare il tier a livello di account (default) o per singolo blob. Archive è impostabile solo per blob. Puoi automatizzare i passaggi con le lifecycle management policy.

Rehydration dall’Archive

Per leggere un blob in Archive devi prima farne la rehydration verso Hot o Cool, in due modi:

  • Change tier (Set Blob Tier) sul blob stesso.
  • Copy blob verso una destinazione online (l’originale resta in Archive).

La rehydration ha priorità Standard (fino a circa 15 ore) o High (tipicamente entro 1 ora, più costosa). In entrambi i casi non è istantanea.

Modello a oggetti dell’SDK (.NET)

Il pacchetto Azure.Storage.Blobs espone una gerarchia di client:

  • BlobServiceClient — punto d’ingresso a livello di account; gestisce e itera i container.
  • BlobContainerClient — un container; crea/elimina e lista i blob.
  • BlobClient — il singolo blob; upload, download, gestione di metadata e proprietà.
var service = new BlobServiceClient(new Uri("https://acct.blob.core.windows.net"),
                                    new DefaultAzureCredential());
var container = service.GetBlobContainerClient("media");
var blob = container.GetBlobClient("logo.png");
await blob.UploadAsync(stream, overwrite: true);

Metadata vs proprietà: i metadata sono coppie chiave-valore personalizzate (SetMetadataAsync); le proprietà sono attributi di sistema come ContentType, ETag, dimensione (GetProperties). Non confonderli: il Content-Type è una proprietà HTTP, non un metadato.

Autenticazione: DefaultAzureCredential vs account key

Le account key danno accesso pieno all’intero account e sono difficili da ruotare: evitale nel codice. La best practice è Microsoft Entra ID tramite DefaultAzureCredential, che prova in sequenza environment variables, managed identity, credenziali di Azure CLI/Visual Studio, ecc. Lo stesso codice funziona in locale (identità sviluppatore) e in produzione (managed identity), senza segreti.

L’autorizzazione richiede un ruolo RBAC dati sull’identità, ad esempio Storage Blob Data Contributor o Reader. Attenzione: i ruoli “Owner”/“Contributor” di gestione non concedono accesso al piano dati dei blob.

Trappole tipiche d’esame

  • Leggere un blob in Archive → devi prima fare rehydration (Set Blob Tier o Copy) verso Hot/Cool; l’accesso non è immediato e può richiedere ore.
  • Log applicativi in sola aggiunta → append blob, non block blob; dischi VM / random I/O → page blob.
  • Assegnato “Contributor” ma HTTP 403 sui blob → serve un ruolo dati come Storage Blob Data Contributor; il ruolo di gestione non basta.
  • Eliminare account key hardcoded → sostituisci con DefaultAzureCredential + managed identity, non con una SAS incollata nel codice.
  • Ridurre costi su dati raramente letti ma che servono subito → Cool/Cold (online), non Archive (offline).