AZ-900
Deep Dive
Cómo Azure construye sus datacenters, el diseño real de las AZs, Availability Sets, Dedicated Hosts y cómo diseñar para SLAs de 99.99%+. El D2 va más allá de los conceptos — aquí está la arquitectura real.
Contenido
Antes de entender AZs y SLAs, hay que entender qué protege físicamente Azure.
Infraestructura física de un datacenter Azure
Fuentes de energía redundantes
Alimentación eléctrica de múltiples subestaciones independientes. UPS (Uninterruptible Power Supply) para cada rack. Generadores diésel con combustible para 72h de operación autónoma.
Cooling independiente
Sistemas de climatización separados. Si falla cooling de un módulo, los otros siguen. Eficiencia PUE de ~1.12 (vs 1.5 típico empresarial).
Red de fibra redundante
Múltiples rutas de fibra óptica entrando al datacenter por distintos conductos físicos. Sin single point of failure en conectividad.
Seguridad física multi-capa
Perímetro físico, biometría (iris, huella), acceso con escolta obligatoria, cámaras 24/7, guardias de seguridad. Solo personal certificado con necesidad específica entra.
Azure vs Datacenter empresarial típico
Qué separa físicamente a las AZs
Distancia física
AZs están a mínimo varios kilómetros entre sí dentro de la misma región metropolitana. Suficiente para que un incidente local (inundación, incendio) no afecte a todas.
Red independiente
Cada AZ tiene sus propios puntos de entrada de fibra, switches de borde y routers. No comparten ningún componente de red física con las otras AZs.
Latencia garantizada
Microsoft garantiza < 2ms de latencia de ida entre cualquier par de AZs en la misma región. Esto permite arquitecturas active-active sincrónicamente.
Servicios con soporte de AZs
No todos los servicios de Azure soportan AZs. Tres categorías:
Despliegas en una AZ específica (Zone 1, 2 o 3). Tú controlas la zona.
Ejemplos: VMs, Managed Disks, Standard IPs
Azure despliega automáticamente en múltiples AZs. Sin configuración de zona.
Ejemplos: Azure SQL DB, Zone-redundant Storage, App Gateway v2
Servicios globales sin AZ. Siempre disponibles sin asociación a zona.
Ejemplos: Entra ID, Azure DNS, Azure Front Door
SLA por arquitectura de despliegue
Downtime máximo: ~8.7h/año
Downtime máximo: ~4.4h/año
Downtime máximo: ~52min/año
Downtime máximo: ~5min/año
Ambos mejoran la disponibilidad de VMs, pero protegen contra distintos tipos de fallos. Es una de las confusiones más comunes en el AZ-900.
Availability Sets (AS)
Distribuye VMs en Fault Domains (racks físicos distintos) y Update Domains (grupos para mantenimiento planificado) dentro del mismo datacenter.
Fault Domains (FD)
Máx. 3 FDs por región. Cada FD = rack físico separado con su propia energía y red. Si cae un rack (corte eléctrico) → solo VMs en ese FD se afectan.
Update Domains (UD)
Máx. 20 UDs. Cuando Azure hace mantenimiento del host físico, solo reinicia un UD a la vez. Con 2 UDs: mientras reinicia UD1, UD2 sigue sirviendo.
SLA con AS
99.95% para VMs con Premium SSD en Availability Set
Availability Zones (AZ)
Distribuye VMs en datacenters físicamente separados (distintos edificios, distinta energía, distinta red) dentro de la misma región metropolitana.
Protege contra
Fallo completo de un datacenter: incendio, inundación, corte eléctrico total, fallo masivo de hardware. La otra AZ sigue funcionando.
Latencia entre AZs
< 2ms garantizado. Permite replicación síncrona (datos en dos AZs = siempre consistentes). App se puede ejecutar en AZ1 con DB en AZ1 y AZ2.
SLA con AZs
99.99% para VMs desplegadas en múltiples AZs
| Característica | Availability Sets | Availability Zones |
|---|---|---|
| Scope de protección | Dentro del mismo datacenter | Entre datacenters distintos |
| Protege contra fallo de rack | ✓ (Fault Domains) | ✓ (cada AZ = datacenter distinto) |
| Protege contra fallo de datacenter | ✗ | ✓ |
| SLA VM | 99.95% | 99.99% |
| Granularidad | Rack / grupo de mantenimiento | Datacenter completo |
| Costo adicional | Ninguno (misma región) | Mínimo egress entre AZs |
| Disponibilidad | Todas las regiones | Solo en regiones con AZs (~40+) |
| Cuándo usar | Apps legacy, regiones sin AZs, granularidad de rack | Recomendado por defecto cuando disponible |
¿Se pueden combinar AS y AZs?
NO. Una VM pertenece a un Availability Set O a una Availability Zone — no a ambos. Si tu región tiene AZs, usa AZs (mejor protección). Si no tiene AZs o por compatibilidad de app legacy, usa Availability Sets. Microsoft recomienda AZs sobre AS para nuevas implementaciones.
Azure Dedicated Hosts
Servidor físico completo dedicado exclusivamente a tu organización. Solo tus VMs corren en ese hardware.
¿Cuándo usarlo?
Limitaciones
Proximity Placement Groups (PPG)
Agrupa VMs lo más cerca físicamente posible (mismo datacenter, mismo rack si es posible) para minimizar la latencia entre ellas.
¿Por qué importa la latencia intra-cluster?
Un cluster de HPC (High Performance Computing) o un cluster de base de datos necesita comunicación entre nodos en microsegundos, no milisegundos. Sin PPG, dos VMs pueden estar en racks distintos del mismo AZ → latencia de 0.5–2ms. Con PPG → <0.1ms.
Casos de uso
Cuando tu arquitectura tiene múltiples componentes, el SLA total es el producto de los SLAs individuales. Esto es fundamental para diseñar y es pregunta frecuente del AZ-900.
Fórmula: SLA compuesto = SLA₁ × SLA₂ × SLA₃
Para componentes en serie (si uno falla, el servicio falla), los SLAs se multiplican.
App web clásica 3-tier (en serie)
Azure Load Balancer
99.99%
Azure App Service (Standard)
99.95%
Azure SQL Database (General Purpose)
99.99%
99.93%
0.9999 × 0.9995 × 0.9999 = 0.9993 ≈ 99.93%
Aunque cada componente tiene SLA alto, el SLA compuesto BAJA. Este es el efecto acumulativo.
App web con redundancia en App Service
Azure Load Balancer
99.99%
App Service × 2 AZs (paralelo)
99.9999%*
Azure SQL Database (Zone Redundant)
99.995%
99.985%
0.9999 × 0.999999 × 0.99995 ≈ 99.985%
*SLA de App Service con Zone Redundancy. Para paralelo: 1 - (1-SLA)^n
El efecto acumulativo — regla para el examen
Más componentes en serie = SLA compuesto SIEMPRE menor que el SLA más bajo individual. Si alguien dice "nuestra arquitectura tiene SLA de 100% porque todos los componentes tienen 99.99%", está equivocado. No existe SLA de 100%.
Active-Passive (Activo-Pasivo)
Una instancia activa maneja todo el tráfico. Una instancia pasiva en standby, lista para tomar el relevo si la activa falla.
Ventajas
Desventajas
En Azure
Azure Site Recovery, SQL Server AlwaysOn en modo asíncrono, Azure SQL Database Business Critical con geo-replica
Active-Active (Activo-Activo)
Múltiples instancias activas manejando tráfico simultáneamente. Si una falla, las demás absorben su carga.
Ventajas
Desventajas
En Azure
VM Scale Sets con Load Balancer, App Service con múltiples instancias, Cosmos DB multi-region write
N+1 Redundancy
Tienes N instancias necesarias para manejar la carga + 1 instancia extra. Si una falla, las N restantes siguen manejando toda la carga.
Ventajas
Desventajas
En Azure
VM Scale Sets con min 2 instancias, AKS con 3 nodos mínimo, App Service con 2 instancias en Standard+
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
¿Cuál es el propósito principal de los pares de regiones (region pairs) en Azure?