AZ-104
Deep Dive
El servicio de almacenamiento de objetos, archivos, colas y tablas de Azure. El AZ-104 evalúa tipos de cuenta, redundancia, tiers de acceso, seguridad y herramientas de transferencia.
Contenido
Una Storage Account es el contenedor de nivel superior para todos los servicios de almacenamiento de Azure. Dentro de una cuenta puedes tener Blob Storage, Azure Files, Queue Storage y Table Storage, cada uno con un endpoint único.
El nombre de la cuenta debe ser globalmente único en Azure (3-24 caracteres, solo letras minúsculas y números). El endpoint toma la forma: https://<cuenta>.blob.core.windows.net
Namespace único
Cada objeto tiene una URL única basada en el nombre de la cuenta. Permite acceso HTTP/HTTPS directo a cualquier objeto.
El nombre de cuenta forma parte de la URL pública — elige uno descriptivo y sin datos sensibles.
Durabilidad
Mínimo 3 copias de cada dato en la región primaria. Con GRS/GZRS hay 3 copias adicionales en la región secundaria.
Azure garantiza 11 nueves (99.999999999%) de durabilidad con LRS. Con GRS: 16 nueves.
Escalabilidad
Hasta 5 PiB de capacidad por cuenta. Hasta 20.000 IOPS. Ancho de banda de hasta 60 Gbps de entrada / 60 Gbps de salida.
Si necesitas más rendimiento: usa múltiples cuentas o Storage v2 con particionado por prefijos.
| Tipo | Rendimiento | Servicios incluidos | Uso recomendado |
|---|---|---|---|
| Standard (GPv2) | Standard (HDD) | Blob, File, Queue, Table, Data Lake | Caso general. El tipo por defecto y recomendado para la mayoría de escenarios. |
| Premium Block Blob | Premium (SSD) | Solo Block Blobs y Append Blobs | Workloads de alto rendimiento: IoT, analytics en tiempo real, baja latencia. |
| Premium File Share | Premium (SSD) | Solo Azure Files | Aplicaciones empresariales que necesitan latencia <1ms para shares SMB. |
| Premium Page Blob | Premium (SSD) | Solo Page Blobs | Discos no administrados de VMs (legacy). Hoy se prefieren Managed Disks. |
| Standard GPv1 (legacy) | Standard (HDD) | Blob, File, Queue, Table | No crear nuevas. Migrar a GPv2 para acceder a tiers de acceso y otras features. |
Regla de oro para el examen
GPv2 Standard es el tipo correcto para casi todo. Si la pregunta menciona "alta IOPS", "baja latencia", "SSD" → Premium Block Blob. Si menciona "Azure Files empresarial" → Premium File Share. Si ves GPv1 → siempre migrar a GPv2.
Blob Storage
Almacenamiento de objetos no estructurados. Tres tipos de blob: Block Blob (archivos hasta 190.7 TiB), Append Blob (logs), Page Blob (discos, acceso aleatorio).
Casos de uso
Imágenes, videos, backups, logs, datos de ML, static website hosting.
.blob.core.windows.net
Azure Files
Shares de archivos SMB (v2.1, 3.0) y NFS montables desde Windows, Linux o macOS. Compatible con apps que usan APIs de sistema de archivos estándar.
Casos de uso
Lift-and-shift de aplicaciones que usan file shares, home directories, config compartida.
.file.core.windows.net
Queue Storage
Mensajes hasta 64 KB, retención máxima 7 días. Un mensaje puede ser leído por un consumidor a la vez (visibilidad temporal). Hasta 500 TiB por cola.
Casos de uso
Desacoplamiento de componentes, procesamiento asíncrono, backlog de tareas.
.queue.core.windows.net
Table Storage
NoSQL key-value store schemaless. Cada entidad tiene PartitionKey + RowKey (PK compuesta) + atributos dinámicos. Hasta 252 propiedades por entidad.
Casos de uso
Datos de configuración, datos históricos de series de tiempo, catálogos sin relaciones complejas.
.table.core.windows.net
Tipos de Blob — comparación
| Tipo | Tamaño máx | Operaciones | Caso típico |
|---|---|---|---|
| Block Blob | 190.7 TiB | Put Block + Put Block List (subida por bloques) | Archivos generales, video, imágenes, backups |
| Append Blob | 195 GiB | Solo Append Block (no actualizar existentes) | Logs, auditoría — escritura solo al final |
| Page Blob | 8 TiB | Escritura/lectura aleatoria en páginas de 512 bytes | VHD de VMs (legacy), disco de BD |
La configuración de redundancia determina cuántas copias del dato existen y dónde. Es una de las preguntas más frecuentes del AZ-104 sobre Storage.
| Tipo | Copias | Ubicación | Protege contra | Read de secundaria |
|---|---|---|---|---|
| LRS | 3 | Mismo datacenter (1 AZ) | Fallo de disco/rack | ✗ |
| ZRS | 3 | 3 Availability Zones (misma región) | Fallo de datacenter/AZ | ✗ |
| GRS | 6 | 3 en región primaria (LRS) + 3 en región secundaria (LRS) | Fallo de región completa | ✗ |
| RA-GRS | 6 | Igual que GRS | Fallo de región + lectura desde secundaria siempre | ✗ |
| GZRS | 6 | 3 en 3 AZs primaria + 3 en región secundaria (LRS) | AZ + región | ✗ |
| RA-GZRS | 6 | Igual que GZRS | AZ + región + lectura desde secundaria | ✗ |
Datos de replicación geo
• La región secundaria es fija por Azure (no la eliges) — ej: East US → West US
• La replicación a secundaria es asíncrona — puede haber lag (RPO no garantizado)
• Con GRS/GZRS la secundaria es read-only SOLO durante failover (a menos que sea RA-*)
• Failover se inicia manualmente desde Azure Portal o PowerShell (o automático en desastres)
Árbol de decisión rápido
→ Datos no críticos, menor costo: LRS
→ Alta disponibilidad en región, protección AZ: ZRS
→ DR geográfico, no necesitas leer desde secundaria: GRS
→ DR + lectura desde secundaria (ej: analytics): RA-GRS
→ Máxima resiliencia (AZ + geo): GZRS o RA-GZRS
Los access tiers permiten optimizar costos según la frecuencia de acceso. Solo disponibles en cuentas GPv2 y Premium Block Blob.
| Tier | Almacenamiento | Acceso/transferencia | Latencia | Mín. almacenamiento | Uso ideal |
|---|---|---|---|---|---|
| Hot | Alto | Bajo | Milisegundos | Ninguno | Datos accedidos frecuentemente: apps activas, sitios web |
| Cool | Bajo | Medio | Milisegundos | 30 días | Datos accedidos ocasionalmente: backups a corto plazo, datos de 30-90 días |
| Cold | Muy bajo | Alto | Milisegundos | 90 días | Datos raramente accedidos que necesitan disponibilidad online: archivos inactivos |
| Archive | Mínimo | Muy alto | Horas (rehydration) | 180 días | Retención a largo plazo, compliance, datos históricos inaccesibles |
Archive — comportamiento especial
• Blobs en Archive no son accesibles directamente — primero hay que "rehidratarlos"
• Rehydration Priority Standard: hasta 15 horas | High Priority: <1 hora (costo extra)
• Puedes copiar el blob a un tier Hot/Cool/Cold en otro contenedor sin modificar el original
• Si eliminas un blob en Archive antes de 180 días: cargo proporcional por early deletion
Métodos de autenticación y autorización
Entra ID (RBAC)
RecomendadoEl método recomendado. Asigna roles de Storage (Storage Blob Data Reader, Contributor, etc.) a usuarios, grupos o Managed Identities. No necesita gestionar claves.
Account Keys
Evitar en producciónDos claves de 512-bit que dan acceso total a la cuenta. Rotar periódicamente. Guardar en Azure Key Vault, nunca en código. Cualquiera con la clave tiene acceso ilimitado.
Shared Access Signature (SAS)
Para acceso temporalToken de acceso delegado con permisos, recurso y tiempo limitados. Tres tipos: Account SAS, Service SAS, User Delegation SAS (firmada con credenciales Entra ID — más segura).
Anonymous Access (Public)
Solo para contenido público explícitoPermite leer blobs sin autenticación. Configurable a nivel de contenedor (container: lista + lee, blob: solo lee). Desactivado por defecto en cuentas nuevas.
Roles RBAC de Storage — clave para examen
Trampa del examen
Storage Account Contributor es un rol de plano de control: puede cambiar configuración, ver claves, pero NO puede leer/escribir datos de blobs directamente via Entra ID. Para datos necesitas los roles "Data" específicos.
Cifrado
• Encryption at rest: AES-256 automático para todos los datos. No se puede desactivar.
• Microsoft-managed keys (MMK): por defecto, sin configuración.
• Customer-managed keys (CMK): tú controlas la clave en Azure Key Vault. Permite rotación y revocación.
• Encryption in transit: HTTPS obligatorio (configurable "Secure transfer required" — activado por defecto).
• Infrastructure encryption: doble cifrado a nivel de infraestructura (para requisitos de compliance máximos).
Public endpoint (default)
Accesible desde internet. Puedes restringir via Storage Firewall: permitir solo IPs específicas o subredes VNet (Service Endpoints).
Storage Account → Networking → Firewalls and virtual networks
Service Endpoints
Extiende la identidad de la VNet al servicio de Storage. El tráfico sigue por la red de Azure pero el acceso se restringe solo a la subred configurada.
VNet → Subnets → Service endpoints → Microsoft.Storage
Private Endpoints
Crea una IP privada dentro de tu VNet para la Storage Account. El tráfico nunca sale a internet. Se usa Private DNS Zone para resolución. Más seguro que Service Endpoints.
Storage → Networking → Private endpoint connections → New
Azure DNS zones para Storage
Con Private Endpoints hay que crear Private DNS Zones (ej: privatelink.blob.core.windows.net) para que la resolución DNS devuelva la IP privada en lugar de la pública.
Normalmente creadas automáticamente al crear el Private Endpoint.
Automatiza la transición de blobs entre tiers y la eliminación basada en antigüedad. Reduce costos sin intervención manual.
Estructura de una regla de lifecycle
Filter (filtro)
Define qué blobs aplica la regla. Opciones: prefijo del nombre (ej: logs/2023/), tipo de blob (blockBlob, appendBlob), tamaño.
Action (acción)
Qué hacer con los blobs que cumplen el filtro: transición a Cool/Cold/Archive, eliminar el blob, eliminar versiones anteriores, eliminar snapshots.
Condición temporal
La acción se ejecuta cuando el blob cumple N días desde: creación, última modificación, último acceso (si tracking habilitado), o último acceso a versión base.
Ejemplo: política de archivado progresivo
→ 0-30 días: Hot (acceso frecuente)
→ 30-90 días: transición a Cool (modificación > 30 días)
→ 90-365 días: transición a Cold (modificación > 90 días)
→ 365+ días: transición a Archive (modificación > 365 días)
→ 7+ años: eliminar (modificación > 2555 días)
Una SAS es un URI firmado que delega acceso limitado a recursos de Storage sin exponer las account keys.
| Tipo | Firmada con | Scope | Revocación |
|---|---|---|---|
| Account SAS | Account Key | Múltiples servicios y operaciones de la cuenta | Rotando la account key (afecta TODAS las SAS) |
| Service SAS | Account Key | Un servicio específico (Blob, File, Queue, Table) | Rotando la account key o usando Stored Access Policy |
| User Delegation SAS | Credenciales Entra ID (OAuth) | Solo Blob Storage y Data Lake | Revocando las credenciales Entra ID del usuario. La más segura. |
Parámetros de una SAS URI
Stored Access Policies
Una Stored Access Policy (SAP) permite revocar una SAS sin rotar las account keys. Se define en el contenedor/cola/share y la SAS hace referencia a ella.
→ Crear SAP: Portal → contenedor → Access policy → Add policy
→ SAS de servicio puede referenciar la SAP con el parámetro si=nombrePolicy
→ Para revocar: eliminar o modificar la SAP → todas las SAS que la referencian quedan inválidas
→ Máximo 5 SAPs por contenedor/recurso
AzCopy
CLI de alto rendimiento para copiar datos hacia/desde/entre Storage Accounts. Soporta Blob, File, ADLS Gen2. Autenticación con SAS o Entra ID (azcopy login).
azcopy copy "ruta_local" "https://cuenta.blob.core.windows.net/contenedor?SAS" --recursive
azcopy sync "origen/" "destino/" --delete-destination=true
azcopy copy "blob_origen?SAS" "blob_destino?SAS" (server-side copy — no pasa por cliente)
Storage Explorer
GUI multiplataforma para gestionar Storage Accounts. Soporta Blob, File, Queue, Table, CosmosDB, ADLS. Ideal para operaciones ocasionales y exploración.
Drag & drop de archivos desde/hacia contenedores
Manage access policies y SAS
Editar entidades de Table Storage directamente
Azure Data Box — transferencia offline masiva
Data Box Disk
Hasta 35 TB (5 discos SSD de 8 TB)
Migraciones pequeñas, datos iniciales
Data Box
80 TB
Migración de datacenter a Azure, envío físico de dispositivo
Data Box Heavy
770 TB
Migraciones masivas, lagos de datos iniciales
Usar Data Box cuando la transferencia por red tomaría más de 7 días. Azure envía el dispositivo físico, cargas los datos, lo devuelves y Azure importa.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa necesita que su Storage Account sea accesible solo desde una VNet específica, sin que el tráfico pase por internet. ¿Qué configuración deben usar?