La lección anterior dejó una regla clara: una aplicación que escala horizontalmente no puede guardar nada en su disco local. Y Contoso Airlines genera un fichero por cada venta: la tarjeta de embarque en PDF. Ese fichero tiene que vivir en algún sitio al que lleguen todas las instancias, que aguante millones de objetos, que sea barato y que permita dar al cliente un enlace de descarga sin abrir el almacén entero a internet.

Ese sitio es Azure Storage. En el módulo 1 ya creaste la cuenta sttarjetascontosodev con su contenedor tarjetas-embarque, HTTPS obligatorio y acceso anónimo desactivado, pero dejaste aplazada una decisión importante: qué redundancia usar en desarrollo y cuál en producción. Esta lección recoge ese cabo suelto y lo cierra.

Aprenderás qué son los cuatro servicios que caben en una cuenta de almacenamiento, cómo funciona Blob Storage en detalle (tipos de blob, niveles de acceso y reglas de ciclo de vida), para qué sirven Azure Files, Queue Storage y Table Storage, cómo se protege el acceso con firmas de acceso compartido e identidades, y qué herramientas usar en cada caso. Al final montarás el flujo real de Contoso: subir una tarjeta de embarque, generar un enlace temporal para el pasajero y programar que el fichero se abarate solo con el tiempo.

Aviso de coste: el almacenamiento se factura por GB al mes, por operaciones y por salida de datos. Los ejemplos de esta lección mueven kilobytes y cuestan céntimos, pero las cuentas de almacenamiento olvidadas se acumulan. Al final tienes la limpieza.

1. La cuenta de almacenamiento: un recurso, cuatro servicios
2. Blob Storage: contenedores y tipos de blob
3. Niveles de acceso: Hot, Cool, Cold y Archive
4. Reglas de ciclo de vida: las tarjetas de embarque de Contoso
5. Azure Files: el recurso compartido de la oficina
6. Queue Storage: desacoplar la emisión de tarjetas
7. Table Storage y su relación con Cosmos DB
8. Redundancia: LRS, ZRS, GRS, GZRS y RA-GRS
9. Seguridad de acceso: claves, SAS e identidades
10. Cifrado, versionado, instantáneas y eliminación temporal
11. Herramientas: az storage, AzCopy y Storage Explorer
12. Ejemplo completo: la tarjeta de embarque de principio a fin
13. Limpieza
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

Una cuenta de almacenamiento es el contenedor de facturación, seguridad y configuración de hasta cuatro servicios de datos distintos, cada uno con su propio punto de conexión:

Al crear la cuenta eliges dos cosas que condicionan todo lo demás:

Y una restricción que sorprende a todos: el nombre de la cuenta es globalmente único, entre 3 y 24 caracteres, solo minúsculas y números. Nada de guiones. Por eso las cuentas de Contoso se llaman sttarjetascontosodev y sttarjetascontosopro y no siguen el patrón con guiones del resto de recursos.

Recordatorio de lo creado en el módulo 1, con el comando completo por si necesitas rehacerlo:

--allow-blob-public-access false es la línea que impide que nadie pueda abrir un contenedor al público por error. Con ella activada a nivel de cuenta, ninguna configuración de contenedor puede exponer los ficheros anónimamente.

La jerarquía de Blob Storage tiene tres niveles y no más:

No existen carpetas reales: lo que parece una jerarquía son nombres de blob con barras. Las herramientas la muestran como si fuera un árbol, pero para el servicio es un nombre plano. Esto tiene una consecuencia práctica útil: puedes listar «una carpeta» con un prefijo, y es una operación eficiente.

Para las tarjetas de embarque de Contoso: blobs en bloques, sin duda.

Fíjate en --content-type "application/pdf": sin él, el navegador puede descargar el fichero en lugar de mostrarlo. Es un detalle pequeño que genera muchas incidencias de soporte.

Consejo de diseño del nombre: 2026/08/IB3241-20260814-A7K2.pdf incluye año, mes, vuelo, fecha y localizador. Ese esquema permite listar por periodo con prefijos y aplicar reglas de ciclo de vida por carpeta. Un nombre plano tipo tarjeta12345.pdf funciona igual de bien para leer, pero te deja sin herramientas para gestionar el ciclo de vida.

Aquí está el mecanismo con el que Azure Storage se abarata de verdad. Cada blob tiene un nivel de acceso que intercambia coste de almacenamiento por coste y tiempo de recuperación.

Cuatro reglas que evitan sustos:

1. La permanencia mínima se factura aunque borres antes. Si subes un blob a Cool y lo borras a los 3 días, pagas los 30. Cambiar de nivel demasiado pronto también cuenta como borrado anticipado.
2. Archive no se lee. Un blob en Archive está fuera de línea: hay que rehidratarlo (az storage blob set-tier --rehydrate-priority High) y esperar horas. No sirve para nada que un cliente pueda pedir en caliente.
3. El nivel se aplica por blob, aunque la cuenta tenga un nivel predeterminado para los blobs nuevos.
4. Bajar de nivel ahorra en almacenamiento pero encarece cada lectura. Si un fichero se lee cada semana, Cool puede salir más caro que Hot.

El patrón de uso de las tarjetas de embarque de Contoso, medido por Diego Salas:

Ese patrón se traduce directamente en una regla de ciclo de vida.

Una regla de ciclo de vida (lifecycle management) es una política que Azure ejecuta a diario sobre los blobs de la cuenta, moviéndolos de nivel o borrándolos según su antigüedad. Es automática y gratuita: solo pagas las operaciones que genera.

Lectura del documento, apartado por apartado:

• filters.blobTypes: solo afecta a blobs en bloques (los de páginas de un disco no deben moverse jamás a Cool).
• filters.prefixMatch: el prefijo empieza por el nombre del contenedor, no por el nombre del blob. Es el error de sintaxis más frecuente de estas reglas.
• tierToCool a los 30 días, tierToArchive a los 90, delete a los 1825 (5 años): exactamente la política de retención de Contoso.
• snapshot.delete: las instantáneas antiguas también ocupan y se facturan.

Aplicación de la regla:

Dos advertencias operativas: la política tarda hasta 24 horas en ejecutarse por primera vez (no esperes ver el cambio en cinco minutos), y daysAfterModificationGreaterThan cuenta desde la última modificación, no desde la creación. Si un proceso reescribe los ficheros, el reloj se reinicia y nada baja de nivel nunca.

Azure Files ofrece recursos compartidos de red accesibles por SMB (el protocolo de Windows, también soportado en Linux y macOS) y por NFS (solo en cuentas premium). A diferencia de los blobs, aquí sí hay un sistema de ficheros real con carpetas, permisos y bloqueo de ficheros.

Contoso tiene un caso claro: en las oficinas de Barcelona y Palma hay un recurso compartido \\servidor-oficina\operaciones con partes de incidencias, plantillas y hojas de cálculo que el personal de tierra abre a diario desde Windows. Ese recurso puede moverse tal cual a Azure Files sin cambiar la forma de trabajar de nadie.

En Windows sería un net use Z: \\stoperacionescontosopro.file.core.windows.net\compartido-operaciones. Dos consideraciones importantes:

• El puerto 445 (SMB) está bloqueado por muchos proveedores de internet domésticos y corporativos. Por eso el montaje desde una oficina exige, en la práctica, conectividad privada: VPN o ExpressRoute. Es justo lo que veremos en la lección 02-06.
• Existe Azure File Sync, que mantiene sincronizado un servidor de ficheros local con el recurso de Azure y deja en local solo los ficheros usados recientemente. Es la vía habitual para migrar un servidor de ficheros de oficina sin cambiar nada para el usuario.

Queue Storage es un servicio de colas de mensajes sencillo: un productor deja un mensaje, un consumidor lo recoge y lo procesa. Mensajes de hasta 64 KB, hasta millones en una cola, con una semántica de «al menos una vez».

El caso de Contoso: cuando un pasajero compra un billete, generar el PDF de la tarjeta de embarque tarda un par de segundos. Hacerlo dentro de la petición web significa que el cliente espera; si el generador falla, la compra falla. Con una cola, la web deja un mensaje y responde de inmediato; un proceso aparte genera el PDF y lo sube al contenedor.

Queue Storage es la opción básica y barata. Cuando hacen falta temas de publicación y suscripción, sesiones, transacciones, orden garantizado o mensajes de más de 64 KB, la respuesta es Azure Service Bus; y para eventos a gran escala, Event Grid y Event Hubs. Los tres se comparan en la lección 06-05; aquí basta con que sepas que la cola existe dentro de la cuenta de almacenamiento y para qué sirve.

Table Storage es un almacén NoSQL de clave-valor con esquema flexible. Cada entidad tiene:

• PartitionKey: agrupa entidades; determina el reparto y el rendimiento.
• RowKey: identifica la entidad dentro de la partición.
• Hasta 252 propiedades más, sin esquema fijo.

Su virtud es el precio: almacenar millones de filas simples cuesta una fracción de lo que costaría una base relacional. Su límite es la consulta: solo es rápida buscando por PartitionKey + RowKey. Cualquier otra consulta recorre la tabla.

Relación con Cosmos DB: Azure Cosmos DB for Table ofrece la misma API con distribución global, latencia garantizada por SLA, índices sobre todas las propiedades y rendimiento aprovisionado. Es la evolución natural cuando Table Storage se queda corto. La comparación completa y cuándo dar el salto están en la lección 03-03.

Criterio rápido: si tu dato es una tabla de auditoría barata con acceso por clave, Table Storage. Si necesitas consultas variadas, latencia garantizada o presencia global, Cosmos DB.

Este es el cabo suelto que dejó el módulo 1. Azure Storage siempre guarda varias copias de tus datos; lo que eliges es dónde están esas copias, y eso determina de qué fallo te protege.

Detalles que hay que conocer antes de decidir:

• La región pareja de West Europe es North Europe (fijado en la lección 01-02). La replicación geográfica es asíncrona: en un desastre puedes perder los últimos minutos de escrituras (el llamado punto de recuperación, RPO, de unos 15 minutos).
• La conmutación por error a la región pareja es una operación que se inicia (az storage account failover), no algo instantáneo y automático.
• Con RA-GRS puedes leer siempre de la secundaria en https://<cuenta>-secondary.blob.core.windows.net, pero esos datos pueden ir retrasados. Sirve para informes o lecturas tolerantes, no para dar una tarjeta de embarque recién emitida.
• La redundancia se puede cambiar después (az storage account update --sku), aunque algunos saltos (por ejemplo, a ZRS) pueden requerir una migración solicitada.

Y una advertencia que hay que decir en voz alta: la redundancia no es una copia de seguridad. GZRS replica fielmente los borrados y las sobrescrituras. Si un proceso borra las tarjetas de agosto, se borran en las seis copias a la vez. Contra eso protegen el versionado y la eliminación temporal del apartado 10, y Azure Backup en la lección 07-05.

Hay tres formas de autorizar el acceso a los datos, y están ordenadas de peor a mejor.

Cada cuenta tiene dos claves de 512 bits que dan control total sobre todo el contenido, sin caducidad y sin identidad asociada.

Que haya dos claves es precisamente para poder rotar sin cortes: configuras las aplicaciones con la secundaria, renuevas la primaria, cambias las aplicaciones y renuevas la secundaria. Aun así, la recomendación es no usarlas: si una clave se filtra en un repositorio, cualquiera lee y borra todo. Puedes deshabilitarlas por completo:

Una SAS es una URL con permisos limitados y caducidad. Es la forma de dar a un pasajero acceso a su tarjeta de embarque y a nada más.

La de delegación de usuario es la recomendada: no requiere que la aplicación conozca la clave de la cuenta, queda asociada a una identidad y se puede revocar sin romper todo lo demás.

Desglose de las opciones, porque cada una es una decisión de seguridad:

Buenas prácticas de SAS que Contoso aplica: caducidad de 15 minutos para descargas de pasajero, permisos mínimos, generación en el servidor (nunca en el navegador), y directivas de acceso almacenadas a nivel de contenedor cuando se necesita poder revocar en masa.

La opción correcta para que una aplicación acceda a los datos: sin claves, sin SAS, con permisos RBAC concretos y auditoría.

Los roles de datos más usados: Storage Blob Data Reader (leer), Storage Blob Data Contributor (leer y escribir) y Storage Blob Data Owner (además, gestionar permisos POSIX). Ojo con una confusión clásica: el rol Colaborador de Azure permite gestionar la cuenta, pero no da acceso a los datos salvo a través de las claves. Identidades administradas y RBAC se desarrollan en la lección 04-02.

Cifrado en reposo: todo lo que hay en Azure Storage se cifra con AES de 256 bits, siempre y sin coste. Puedes usar claves gestionadas por Microsoft (por defecto) o claves propias en Key Vault (04-03) cuando el cumplimiento normativo lo exija.

Cifrado en tránsito: --https-only true y --min-tls-version TLS1_2, ya aplicados en la cuenta de Contoso desde el módulo 1.

Protección contra el borrado, que es lo que la redundancia no cubre:

Contoso activa eliminación temporal de 30 días y versionado en producción, y añade a la regla de ciclo de vida el borrado de versiones antiguas para que el versionado no dispare la factura.

Regla práctica: para mover más de unos cientos de megabytes o más de unos cientos de ficheros, AzCopy. az storage blob upload-batch funciona, pero es notablemente más lento.

Este script reúne todo lo anterior en el flujo real de Contoso: preparar la cuenta con la redundancia decidida, subir la tarjeta, entregar un enlace temporal al pasajero y programar el abaratamiento automático.

Prueba el enlace con curl -I "${ENLACE}": debe devolver HTTP/1.1 200 OK. Espera a que caduque y repítelo: obtendrás un 403 con el código AuthenticationFailed. Esa es exactamente la protección que buscamos: el enlace sirve para descargar la tarjeta ahora, no para siempre.

Recuerda: con la eliminación temporal activada, los blobs borrados siguen ocupando y facturando durante los días de retención. Es lo correcto para producción, pero tenlo en cuenta al limpiar un laboratorio.

• Repartir la clave de la cuenta para dar acceso a un fichero. Da control total sobre todo. Usa SAS de delegación de usuario con caducidad corta, o identidades administradas.
• Generar SAS con caducidad de meses o años. Una URL con un año de vida acaba en un correo, en un ticket y en un buscador. Minutos, no meses.
• Subir a Archive lo que un cliente puede pedir hoy. Archive está fuera de línea: rehidratar tarda horas. Nunca para tarjetas del vuelo de mañana.
• Olvidar la permanencia mínima. Mover a Cool y borrar a los tres días cuesta los 30 días completos. Ajusta la política a la realidad de tus datos.
• Confundir redundancia con copia de seguridad. GZRS replica los borrados fielmente. Activa eliminación temporal y versionado.
• Poner mal el prefixMatch de la regla de ciclo de vida. Empieza por el nombre del contenedor, no por el del blob. Es el fallo más habitual y silencioso: la regla no falla, simplemente no hace nada.
• Esperar que la regla actúe al instante. Se ejecuta a diario y la primera vez puede tardar 24 horas.
• No poner el content-type al subir. El PDF se descarga en vez de verse; luego llegan las incidencias de soporte.
• Usar Azure Files donde bastan blobs. Files cuesta más por GB y añade dependencia del puerto 445.
• Activar versionado sin ciclo de vida. Cada sobrescritura crea una versión que se factura para siempre. Combina siempre ambas cosas.
• Consejo: activa --allow-shared-key-access false en producción. Fuerza a que todo el acceso sea por Entra ID y elimina de golpe la clase entera de incidentes por clave filtrada.
• Consejo: diseña el nombre del blob con jerarquía por fecha (aaaa/mm/). Te da listados por prefijo y políticas de ciclo de vida por periodo prácticamente gratis.

Para cada dato de Contoso Airlines, indica qué servicio de la cuenta de almacenamiento usarías, qué nivel de acceso y qué redundancia, con su justificación:

1. Tarjetas de embarque en PDF de producción, retención legal de 5 años.
2. Plantillas y hojas de cálculo que el personal de tierra de Palma abre desde el explorador de Windows.
3. Solicitudes de emisión de tarjeta pendientes de procesar por el generador de PDF.
4. Registro de auditoría de cada emisión: qué vuelo, qué localizador, a qué hora, para consulta por vuelo.
5. Copias de los ficheros de prueba que Diego regenera cada semana.

1. Sube un fichero de prueba a tarjetas-embarque en la cuenta de desarrollo con el tipo de contenido correcto.
2. Genera una SAS de delegación de usuario, de solo lectura, válida 10 minutos y solo por HTTPS.
3. Verifica con curl que funciona, y explica qué respuesta esperas cuando caduque.
4. Escribe la política de ciclo de vida que mueva a Cool a los 30 días, a Archive a los 90 y borre a los 5 años.

Escribe los comandos de Azure CLI que respondan a estas preguntas sobre la suscripción:

1. ¿Qué cuentas de almacenamiento hay y con qué redundancia?
2. ¿Alguna permite acceso público a blobs o admite claves compartidas?
3. ¿Alguna acepta TLS por debajo de 1.2?
4. ¿Qué cuentas de producción no tienen política de ciclo de vida?

Solución 1:

Solución 2:

3. Una vez pasados los 10 minutos, la misma URL devuelve HTTP/1.1 403 Forbidden con el código de error AuthenticationFailed: la firma incluye la caducidad y el servicio la valida en cada petición. No hace falta borrar ni revocar nada.

4. Política:

Solución 3:

En el módulo 4 verás cómo convertir estas comprobaciones en Azure Policy para que no dependan de que alguien se acuerde de ejecutarlas.

Has cerrado el cabo suelto que dejó el módulo 1 y, de paso, has aprendido el servicio de datos más transversal de Azure. Sabes que una cuenta de almacenamiento aloja cuatro servicios —Blob, File, Queue y Table— con su propio punto de conexión y su nombre globalmente único en minúsculas. Conoces Blob Storage en detalle: contenedores, la jerarquía plana con prefijos, los tres tipos de blob y los niveles de acceso Hot, Cool, Cold y Archive con su compromiso entre coste de almacenamiento y de recuperación, las permanencias mínimas y la rehidratación de Archive. Has traducido el patrón real de uso de las tarjetas de embarque de Contoso —mucho la primera semana, casi nada después— en una regla de ciclo de vida que las abarata sola. Sabes cuándo tiene sentido Azure Files para el recurso compartido de la oficina, para qué sirve Queue Storage como desacoplador y qué relación tiene Table Storage con Cosmos DB. Y has fijado la decisión de redundancia de Contoso: LRS en desarrollo, GZRS para las tarjetas de producción y ZRS para los ficheros de operaciones, con la advertencia esencial de que la redundancia no es una copia de seguridad, para lo cual has activado eliminación temporal y versionado. En seguridad de acceso, has bajado por la escalera de lo malo a lo bueno: claves de cuenta (evitar y deshabilitar), SAS de servicio, de cuenta y de delegación de usuario con caducidad corta, y acceso por identidad de Microsoft Entra ID, que es el destino final.

Fíjate en lo que tienes ya montado: cómputo elástico, aplicaciones publicadas y almacenamiento con su política de ciclo de vida. Pero todo eso, tal como está, habla por internet. La web llega a la API por su nombre público, la aplicación llega al almacenamiento por su punto de conexión público, y la base de datos que viene en el módulo 3 estaría igual de expuesta. Ninguna arquitectura seria se queda así.

En la siguiente lección, Redes en Azure: redes virtuales, subredes y NSG, damos ese paso: planificarás el espacio de direcciones de vnet-contoso-pro con la aritmética CIDR explicada desde cero, diseñarás las subredes snet-web, snet-app, snet-datos y snet-gestion, escribirás reglas de grupos de seguridad de red que abran solo lo imprescindible, entenderás el emparejamiento de redes y el patrón hub-and-spoke, y verás la diferencia decisiva entre puntos de conexión de servicio y Azure Private Link —que es exactamente lo que hará que la cuenta sttarjetascontosopro y la base de datos de reservas dejen de ser accesibles desde internet.