Las decisiones de diseño de almacenamiento en AZ-305: qué redundancia cumple los requisitos de durabilidad y DR, qué access tier minimiza costo según el patrón de acceso, y qué mecanismo de autorización es el más seguro.
Contenido
| Opción | Copias | Sobrevive a... | Durabilidad |
|---|---|---|---|
| LRS | 3 en un datacenter | Fallo de disco/rack | 11 nueves |
| ZRS | 3 en 3 availability zones | Caída de un datacenter/zona entero | 12 nueves |
| GRS | LRS + 3 asíncronas en región emparejada | Desastre regional (failover) | 16 nueves |
| GZRS | ZRS + 3 asíncronas en región emparejada | Zona caída Y desastre regional | 16 nueves |
| RA-GRS / RA-GZRS | Igual + lectura en la secundaria | Permite LEER de la secundaria sin failover | 16 nueves |
Claves de diseño
Cómo elegir
| Tier | Costo storage / acceso | Mínimo de permanencia | Uso |
|---|---|---|---|
| Hot | Storage caro / acceso barato | — | Datos de uso frecuente |
| Cool | Más barato / acceso más caro | 30 días | Acceso infrecuente: backups recientes, datos de 30-90 días |
| Cold | Aún más barato / acceso caro | 90 días | Raramente accedido pero disponible online al instante |
| Archive | Mínimo / rehidratación necesaria (horas) | 180 días | Cumplimiento, retención de años. OFFLINE: rehidratar a Hot/Cool para leer (1-15h, o High Priority <1h) |
Lifecycle management policies
Reglas automáticas por antigüedad/último acceso: mover a Cool tras 30 días sin acceso → Archive tras 180 → eliminar tras 7 años. Si el escenario pide "optimizar costos de blobs automáticamente según su uso", la respuesta es lifecycle management — no scripts ni Azure Functions.
Tipos de cuenta
Data Lake Storage Gen2
| Servicio | Protocolo | Cuándo |
|---|---|---|
| Azure Files Standard/Premium | SMB, NFS (premium), REST | File shares administrados: lift-and-shift de apps con shares, perfiles FSLogix de AVD. Auth Kerberos con Entra DS/AD DS |
| Azure File Sync | SMB (agente en Windows Server) | Cache local en servidores on-prem con cloud tiering — sucursales con acceso rápido y nube como verdad |
| Azure NetApp Files | NFSv3/v4.1, SMB, dual | Workloads enterprise exigentes: SAP HANA, HPC, bases de datos sobre NFS — latencia <1ms y throughput extremo |
| Blob NFS 3.0 | NFS sobre blob | Analítica/HPC que lee objetos vía NFS, más barato que NetApp |
| Mecanismo | Riesgo | Cuándo |
|---|---|---|
| Entra ID + RBAC (DataActions) | Mínimo — sin secretos, con CA y auditoría | PRIMERA opción siempre: managed identity + Storage Blob Data Contributor/Reader |
| User delegation SAS | Bajo — firmada con credenciales Entra, no con account key | Acceso temporal delegado a clientes externos (la mejor SAS) |
| Service/Account SAS | Medio — firmada con account key; revocar = rotar la clave | Acceso granular temporal cuando no hay identidad Entra. Limitar con stored access policies |
| Account keys | Alto — acceso total a la cuenta | Evitar en apps. Deshabilitar shared key si la policy lo permite |
| Anonymous public access | Crítico | Solo contenido deliberadamente público (CDN origin). Deshabilitado por defecto |
Red
Private Endpoints para tráfico solo-VNet (recuerda la zona DNS privatelink), firewall de cuenta con IPs/VNets permitidas, y "Allow trusted Microsoft services" para que Backup/Defender accedan pese al firewall.
| Requisito | Diseño |
|---|---|
| Datos críticos que deben sobrevivir caída de zona Y de región | GZRS (o RA-GZRS si necesitan leer en DR) |
| Reportes leen de la secundaria sin hacer failover | RA-GRS / RA-GZRS (endpoint -secondary) |
| Retención de 10 años al menor costo, acceso casi nunca | Archive tier + lifecycle policy |
| Mover blobs automáticamente a tiers fríos según último acceso | Lifecycle management policy |
| Data lake con permisos por directorio para Synapse | ADLS Gen2 (hierarchical namespace + ACLs) |
| Latencia de blob baja y consistente para workload interactivo | Premium block blob (LRS/ZRS) |
| Compartir archivos SMB con cache en sucursales | Azure Files + Azure File Sync (cloud tiering) |
| SAP HANA sobre NFS con latencia <1ms | Azure NetApp Files |
| Una app accede a blobs sin secretos | Managed identity + RBAC data plane |
| Partner externo sube archivos durante 48h | User delegation SAS con expiración |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aseguradora almacena expedientes digitalizados: se consultan con frecuencia los primeros 60 días, casi nunca después, y la regulación exige conservarlos 10 años y poder recuperarlos en menos de 24 horas. Quieren el menor costo posible con mínima administración. ¿Qué diseñas?
Inicia sesión para llevar tu progreso.