La lliçó anterior va deixar una regla clara: una aplicació que escala horitzontalment no pot desar res al seu disc local. I Contoso Airlines genera un fitxer per cada venda: la targeta d'embarcament en PDF. Aquest fitxer ha de viure en algun lloc on arribin totes les instàncies, que aguanti milions d'objectes, que sigui barat i que permeti donar al client un enllaç de descàrrega sense obrir el magatzem sencer a internet.

Aquest lloc és Azure Storage. Al mòdul 1 ja vas crear el compte sttarjetascontosodev amb el seu contenidor tarjetas-embarque, HTTPS obligatori i accés anònim desactivat, però vas deixar ajornada una decisió important: quina redundància fer servir en desenvolupament i quina en producció. Aquesta lliçó recull aquest cap solt i el tanca.

Aprendràs què són els quatre serveis que caben en un compte d'emmagatzematge, com funciona Blob Storage en detall (tipus de blob, nivells d'accés i regles de cicle de vida), per a què serveixen Azure Files, Queue Storage i Table Storage, com es protegeix l'accés amb signatures d'accés compartit i identitats, i quines eines fer servir en cada cas. Al final muntaràs el flux real de Contoso: pujar una targeta d'embarcament, generar un enllaç temporal per al passatger i programar que el fitxer s'abarateixi sol amb el temps.

Avís de cost: l'emmagatzematge es factura per GB al mes, per operacions i per sortida de dades. Els exemples d'aquesta lliçó mouen kilobytes i costen cèntims, però els comptes d'emmagatzematge oblidats s'acumulen. Al final tens la neteja.

1. El compte d'emmagatzematge: un recurs, quatre serveis
2. Blob Storage: contenidors i tipus de blob
3. Nivells d'accés: Hot, Cool, Cold i Archive
4. Regles de cicle de vida: les targetes d'embarcament de Contoso
5. Azure Files: el recurs compartit de l'oficina
6. Queue Storage: desacoblar l'emissió de targetes
7. Table Storage i la seva relació amb Cosmos DB
8. Redundància: LRS, ZRS, GRS, GZRS i RA-GRS
9. Seguretat d'accés: claus, SAS i identitats
10. Xifratge, versionatge, instantànies i eliminació temporal
11. Eines: az storage, AzCopy i Storage Explorer
12. Exemple complet: la targeta d'embarcament de principi a fi
13. Neteja
14. Errors Comuns i Consells
15. Exercicis
16. Conclusió

Un compte d'emmagatzematge és el contenidor de facturació, seguretat i configuració de fins a quatre serveis de dades diferents, cadascun amb el seu propi punt de connexió:

En crear el compte tries dues coses que condicionen tota la resta:

I una restricció que sorprèn tothom: el nom del compte és globalment únic, entre 3 i 24 caràcters, només minúscules i números. Res de guions. Per això els comptes de Contoso es diuen sttarjetascontosodev i sttarjetascontosopro i no segueixen el patró amb guions de la resta de recursos.

Recordatori del que es va crear al mòdul 1, amb l'ordre completa per si l'has de refer:

--allow-blob-public-access false és la línia que impedeix que ningú pugui obrir un contenidor al públic per error. Amb ella activada a nivell de compte, cap configuració de contenidor no pot exposar els fitxers anònimament.

La jerarquia de Blob Storage té tres nivells i prou:

No hi ha carpetes reals: el que sembla una jerarquia són noms de blob amb barres. Les eines la mostren com si fos un arbre, però per al servei és un nom pla. Això té una conseqüència pràctica útil: pots llistar «una carpeta» amb un prefix, i és una operació eficient.

Per a les targetes d'embarcament de Contoso: blobs en blocs, sens dubte.

Fixa't en --content-type "application/pdf": sense ell, el navegador pot descarregar el fitxer en lloc de mostrar-lo. És un detall petit que genera moltes incidències de suport.

Consell de disseny del nom: 2026/08/IB3241-20260814-A7K2.pdf inclou any, mes, vol, data i localitzador. Aquest esquema permet llistar per període amb prefixos i aplicar regles de cicle de vida per carpeta. Un nom pla tipus tarjeta12345.pdf funciona igual de bé per llegir, però et deixa sense eines per gestionar el cicle de vida.

Aquí hi ha el mecanisme amb què Azure Storage s'abarateix de debò. Cada blob té un nivell d'accés que intercanvia cost d'emmagatzematge per cost i temps de recuperació.

Quatre regles que eviten ensurts:

1. La permanència mínima es factura encara que esborris abans. Si puges un blob a Cool i l'esborres al cap de 3 dies, en pagues 30. Canviar de nivell massa aviat també compta com a esborrat anticipat.
2. Archive no es llegeix. Un blob a Archive és fora de línia: cal rehidratar-lo (az storage blob set-tier --rehydrate-priority High) i esperar hores. No serveix per a res que un client pugui demanar en calent.
3. El nivell s'aplica per blob, encara que el compte tingui un nivell predeterminat per als blobs nous.
4. Baixar de nivell estalvia en emmagatzematge però encareix cada lectura. Si un fitxer es llegeix cada setmana, Cool pot sortir més car que Hot.

El patró d'ús de les targetes d'embarcament de Contoso, mesurat per en Diego Salas:

Aquest patró es tradueix directament en una regla de cicle de vida.

Una regla de cicle de vida (lifecycle management) és una política que Azure executa cada dia sobre els blobs del compte, movent-los de nivell o esborrant-los segons la seva antiguitat. És automàtica i gratuïta: només pagues les operacions que genera.

Lectura del document, apartat per apartat:

• filters.blobTypes: només afecta els blobs en blocs (els de pàgines d'un disc no s'han de moure mai a Cool).
• filters.prefixMatch: el prefix comença pel nom del contenidor, no pel nom del blob. És l'error de sintaxi més freqüent d'aquestes regles.
• tierToCool als 30 dies, tierToArchive als 90, delete als 1825 (5 anys): exactament la política de retenció de Contoso.
• snapshot.delete: les instantànies antigues també ocupen i es facturen.

Aplicació de la regla:

Dues advertències operatives: la política triga fins a 24 hores a executar-se per primera vegada (no esperis veure el canvi en cinc minuts), i daysAfterModificationGreaterThan compta des de l'última modificació, no des de la creació. Si un procés reescriu els fitxers, el rellotge es reinicia i mai res no baixa de nivell.

Azure Files ofereix recursos compartits de xarxa accessibles per SMB (el protocol de Windows, també admès a Linux i macOS) i per NFS (només en comptes premium). A diferència dels blobs, aquí sí que hi ha un sistema de fitxers real amb carpetes, permisos i bloqueig de fitxers.

Contoso té un cas clar: a les oficines de Barcelona i Palma hi ha un recurs compartit \\servidor-oficina\operaciones amb parts d'incidències, plantilles i fulls de càlcul que el personal de terra obre cada dia des de Windows. Aquest recurs es pot moure tal qual a Azure Files sense canviar la forma de treballar de ningú.

A Windows seria un net use Z: \\stoperacionescontosopro.file.core.windows.net\compartido-operaciones. Dues consideracions importants:

• El port 445 (SMB) està bloquejat per molts proveïdors d'internet domèstics i corporatius. Per això el muntatge des d'una oficina exigeix, a la pràctica, connectivitat privada: VPN o ExpressRoute. És just el que veurem a la lliçó 02-06.
• Existeix Azure File Sync, que manté sincronitzat un servidor de fitxers local amb el recurs d'Azure i deixa en local només els fitxers utilitzats recentment. És la via habitual per migrar un servidor de fitxers d'oficina sense canviar res per a l'usuari.

Queue Storage és un servei de cues de missatges senzill: un productor deixa un missatge, un consumidor el recull i el processa. Missatges de fins a 64 KB, fins a milions en una cua, amb una semàntica d'«almenys un cop».

El cas de Contoso: quan un passatger compra un bitllet, generar el PDF de la targeta d'embarcament triga un parell de segons. Fer-ho dins de la petició web vol dir que el client espera; si el generador falla, la compra falla. Amb una cua, la web deixa un missatge i respon immediatament; un procés a part genera el PDF i el puja al contenidor.

Queue Storage és l'opció bàsica i barata. Quan calen temes de publicació i subscripció, sessions, transaccions, ordre garantit o missatges de més de 64 KB, la resposta és Azure Service Bus; i per a esdeveniments a gran escala, Event Grid i Event Hubs. Els tres es comparen a la lliçó 06-05; aquí n'hi ha prou que sàpigues que la cua existeix dins del compte d'emmagatzematge i per a què serveix.

Table Storage és un magatzem NoSQL de clau-valor amb esquema flexible. Cada entitat té:

• PartitionKey: agrupa entitats; determina el repartiment i el rendiment.
• RowKey: identifica l'entitat dins de la partició.
• Fins a 252 propietats més, sense esquema fix.

La seva virtut és el preu: emmagatzemar milions de files simples costa una fracció del que costaria una base relacional. El seu límit és la consulta: només és ràpida buscant per PartitionKey + RowKey. Qualsevol altra consulta recorre la taula.

Relació amb Cosmos DB: Azure Cosmos DB for Table ofereix la mateixa API amb distribució global, latència garantida per SLA, índexs sobre totes les propietats i rendiment aprovisionat. És l'evolució natural quan Table Storage es queda curt. La comparació completa i quan fer el salt són a la lliçó 03-03.

Criteri ràpid: si la teva dada és una taula d'auditoria barata amb accés per clau, Table Storage. Si necessites consultes variades, latència garantida o presència global, Cosmos DB.

Aquest és el cap solt que va deixar el mòdul 1. Azure Storage sempre guarda diverses còpies de les teves dades; el que tries és on són aquestes còpies, i això determina de quina fallada et protegeix.

Detalls que cal conèixer abans de decidir:

• La regió parella de West Europe és North Europe (fixat a la lliçó 01-02). La replicació geogràfica és asíncrona: en un desastre pots perdre les últimes escriptures de minuts (l'anomenat punt de recuperació, RPO, d'uns 15 minuts).
• La commutació per error a la regió parella és una operació que s'inicia (az storage account failover), no una cosa instantània i automàtica.
• Amb RA-GRS pots llegir sempre de la secundària a https://<compte>-secondary.blob.core.windows.net, però aquestes dades poden anar endarrerides. Serveix per a informes o lectures tolerants, no per donar una targeta d'embarcament acabada d'emetre.
• La redundància es pot canviar després (az storage account update --sku), encara que alguns salts (per exemple, a ZRS) poden requerir una migració sol·licitada.

I una advertència que cal dir en veu alta: la redundància no és una còpia de seguretat. GZRS replica fidelment els esborrats i les sobreescriptures. Si un procés esborra les targetes d'agost, s'esborren a les sis còpies alhora. Contra això protegeixen el versionatge i l'eliminació temporal de l'apartat 10, i Azure Backup a la lliçó 07-05.

Hi ha tres formes d'autoritzar l'accés a les dades, i estan ordenades de pitjor a millor.

Cada compte té dues claus de 512 bits que donen control total sobre tot el contingut, sense caducitat i sense identitat associada.

Que hi hagi dues claus és precisament per poder rotar sense talls: configures les aplicacions amb la secundària, renoves la primària, canvies les aplicacions i renoves la secundària. Tot i així, la recomanació és no fer-les servir: si una clau es filtra en un repositori, qualsevol llegeix i esborra tot. Les pots deshabilitar del tot:

Una SAS és una URL amb permisos limitats i caducitat. És la forma de donar a un passatger accés a la seva targeta d'embarcament i a res més.

La de delegació d'usuari és la recomanada: no requereix que l'aplicació conegui la clau del compte, queda associada a una identitat i es pot revocar sense trencar tota la resta.

Desglossament de les opcions, perquè cadascuna és una decisió de seguretat:

Bones pràctiques de SAS que Contoso aplica: caducitat de 15 minuts per a descàrregues de passatger, permisos mínims, generació al servidor (mai al navegador), i directives d'accés emmagatzemades a nivell de contenidor quan cal poder revocar en massa.

L'opció correcta perquè una aplicació accedeixi a les dades: sense claus, sense SAS, amb permisos RBAC concrets i auditoria.

Els rols de dades més utilitzats: Storage Blob Data Reader (llegir), Storage Blob Data Contributor (llegir i escriure) i Storage Blob Data Owner (a més, gestionar permisos POSIX). Compte amb una confusió clàssica: el rol Col·laborador d'Azure permet gestionar el compte, però no dona accés a les dades llevat que sigui a través de les claus. Identitats administrades i RBAC es desenvolupen a la lliçó 04-02.

Xifratge en repòs: tot el que hi ha a Azure Storage es xifra amb AES de 256 bits, sempre i sense cost. Pots fer servir claus gestionades per Microsoft (per defecte) o claus pròpies a Key Vault (04-03) quan el compliment normatiu ho exigeixi.

Xifratge en trànsit: --https-only true i --min-tls-version TLS1_2, ja aplicats al compte de Contoso des del mòdul 1.

Protecció contra l'esborrat, que és el que la redundància no cobreix:

Contoso activa eliminació temporal de 30 dies i versionatge en producció, i afegeix a la regla de cicle de vida l'esborrat de versions antigues perquè el versionatge no dispari la factura.

Regla pràctica: per moure més d'uns quants centenars de megabytes o més d'uns quants centenars de fitxers, AzCopy. az storage blob upload-batch funciona, però és notablement més lent.

Aquest script reuneix tot l'anterior en el flux real de Contoso: preparar el compte amb la redundància decidida, pujar la targeta, lliurar un enllaç temporal al passatger i programar l'abaratiment automàtic.

Prova l'enllaç amb curl -I "${ENLLAC}": ha de retornar HTTP/1.1 200 OK. Espera que caduqui i repeteix-ho: obtindràs un 403 amb el codi AuthenticationFailed. Aquesta és exactament la protecció que busquem: l'enllaç serveix per descarregar la targeta ara, no per sempre.

Recorda: amb l'eliminació temporal activada, els blobs esborrats continuen ocupant i facturant durant els dies de retenció. És el correcte per a producció, però tingues-ho en compte en netejar un laboratori.

• Repartir la clau del compte per donar accés a un fitxer. Dona control total sobre tot. Fes servir SAS de delegació d'usuari amb caducitat curta, o identitats administrades.
• Generar SAS amb caducitat de mesos o anys. Una URL amb un any de vida acaba en un correu, en un tiquet i en un cercador. Minuts, no mesos.
• Pujar a Archive el que un client pot demanar avui. Archive és fora de línia: rehidratar triga hores. Mai per a targetes del vol de demà.
• Oblidar la permanència mínima. Moure a Cool i esborrar al cap de tres dies costa els 30 dies complets. Ajusta la política a la realitat de les teves dades.
• Confondre redundància amb còpia de seguretat. GZRS replica els esborrats fidelment. Activa eliminació temporal i versionatge.
• Posar malament el prefixMatch de la regla de cicle de vida. Comença pel nom del contenidor, no pel del blob. És l'errada més habitual i silenciosa: la regla no falla, simplement no fa res.
• Esperar que la regla actuï a l'instant. S'executa cada dia i el primer cop pot trigar 24 hores.
• No posar el content-type en pujar. El PDF es descarrega en lloc de veure's; després arriben les incidències de suport.
• Fer servir Azure Files on n'hi ha prou amb blobs. Files costa més per GB i afegeix dependència del port 445.
• Activar versionatge sense cicle de vida. Cada sobreescriptura crea una versió que es factura per sempre. Combina sempre totes dues coses.
• Consell: activa --allow-shared-key-access false en producció. Força que tot l'accés sigui per Entra ID i elimina de cop la classe sencera d'incidents per clau filtrada.
• Consell: dissenya el nom del blob amb jerarquia per data (aaaa/mm/). Et dona llistats per prefix i polítiques de cicle de vida per període pràcticament de franc.

Per a cada dada de Contoso Airlines, indica quin servei del compte d'emmagatzematge faries servir, quin nivell d'accés i quina redundància, amb la seva justificació:

1. Targetes d'embarcament en PDF de producció, retenció legal de 5 anys.
2. Plantilles i fulls de càlcul que el personal de terra de Palma obre des de l'explorador de Windows.
3. Sol·licituds d'emissió de targeta pendents de processar pel generador de PDF.
4. Registre d'auditoria de cada emissió: quin vol, quin localitzador, a quina hora, per consultar per vol.
5. Còpies dels fitxers de prova que en Diego regenera cada setmana.

1. Puja un fitxer de prova a tarjetas-embarque al compte de desenvolupament amb el tipus de contingut correcte.
2. Genera una SAS de delegació d'usuari, només de lectura, vàlida 10 minuts i només per HTTPS.
3. Verifica amb curl que funciona, i explica quina resposta esperes quan caduqui.
4. Escriu la política de cicle de vida que mogui a Cool als 30 dies, a Archive als 90 i esborri als 5 anys.

Escriu les ordres d'Azure CLI que responguin a aquestes preguntes sobre la subscripció:

1. Quins comptes d'emmagatzematge hi ha i amb quina redundància?
2. Algun permet accés públic a blobs o admet claus compartides?
3. Algun accepta TLS per sota d'1.2?
4. Quins comptes de producció no tenen política de cicle de vida?

Solució 1:

Solució 2:

3. Un cop passats els 10 minuts, la mateixa URL retorna HTTP/1.1 403 Forbidden amb el codi d'error AuthenticationFailed: la signatura inclou la caducitat i el servei la valida a cada petició. No cal esborrar ni revocar res.

4. Política:

Solució 3:

Al mòdul 4 veuràs com convertir aquestes comprovacions en Azure Policy perquè no depenguin que algú se'n recordi d'executar-les.

Has tancat el cap solt que va deixar el mòdul 1 i, de passada, has après el servei de dades més transversal d'Azure. Saps que un compte d'emmagatzematge allotja quatre serveis —Blob, File, Queue i Table— amb el seu propi punt de connexió i el seu nom globalment únic en minúscules. Coneixes Blob Storage en detall: contenidors, la jerarquia plana amb prefixos, els tres tipus de blob i els nivells d'accés Hot, Cool, Cold i Archive amb el seu compromís entre cost d'emmagatzematge i de recuperació, les permanències mínimes i la rehidratació d'Archive. Has traduït el patró real d'ús de les targetes d'embarcament de Contoso —molt la primera setmana, gairebé res després— en una regla de cicle de vida que les abarateix sola. Saps quan té sentit Azure Files per al recurs compartit de l'oficina, per a què serveix Queue Storage com a desacoblador i quina relació té Table Storage amb Cosmos DB. I has fixat la decisió de redundància de Contoso: LRS en desenvolupament, GZRS per a les targetes de producció i ZRS per als fitxers d'operacions, amb l'advertència essencial que la redundància no és una còpia de seguretat, per a la qual cosa has activat eliminació temporal i versionatge. En seguretat d'accés, has baixat per l'escala del dolent al bo: claus de compte (evitar i deshabilitar), SAS de servei, de compte i de delegació d'usuari amb caducitat curta, i accés per identitat de Microsoft Entra ID, que és la destinació final.

Fixa't en el que ja tens muntat: còmput elàstic, aplicacions publicades i emmagatzematge amb la seva política de cicle de vida. Però tot això, tal com està, parla per internet. La web arriba a l'API pel seu nom públic, l'aplicació arriba a l'emmagatzematge pel seu punt de connexió públic, i la base de dades que ve al mòdul 3 estaria igual d'exposada. Cap arquitectura seriosa no es queda així.

A la lliçó següent, Xarxes a Azure: xarxes virtuals, subxarxes i NSG, fem aquest pas: planificaràs l'espai d'adreces de vnet-contoso-pro amb l'aritmètica CIDR explicada des de zero, dissenyaràs les subxarxes snet-web, snet-app, snet-datos i snet-gestion, escriuràs regles de grups de seguretat de xarxa que obrin només l'imprescindible, entendràs l'aparellament de xarxes i el patró hub-and-spoke, i veuràs la diferència decisiva entre punts de connexió de servei i Azure Private Link —que és exactament el que farà que el compte sttarjetascontosopro i la base de dades de reserves deixin de ser accessibles des d'internet.