La alta disponibilidad (HA) consiste en diseñar el servicio para que esté "casi siempre" encendido, mientras que la recuperación ante desastres (DR) se trata de restaurarlo rápidamente si alguna vez se cae. El examen AZ-305 evalúa con frecuencia tu capacidad para elegir la capa adecuada y el servicio correcto para cada objetivo. En esta guía repasaremos los servicios clave uno a uno y aclararemos los criterios de selección que más confunden a los candidatos.
---
RTO, RPO y diseño de continuidad de negocio
Todo diseño de recuperación ante desastres comienza con dos números: RTO y RPO.
RTO (Recovery Time Objective) es el tiempo máximo que tu servicio puede estar caído antes de que deba volver a estar en línea. Si tu RTO es de cuatro horas, debes restaurar el servicio en ese plazo desde que ocurre el incidente. Un RTO más corto exige una infraestructura de conmutación más rápida — y por tanto mayor costo.
RPO (Recovery Point Objective) es la pérdida de datos máxima tolerable, expresada como una ventana de tiempo. Un RPO de 24 horas significa que puedes permitirte perder hasta 24 horas de datos. Este valor determina directamente la frecuencia con la que debes hacer copias de seguridad o replicar datos. Con copias diarias, tu RPO es de 24 horas como máximo. Si cambias a copias horarias, el RPO se reduce a una hora.
Uno de los errores más comunes en el examen es confundir el período de retención con el RPO. El período de retención responde a la pregunta "¿hasta qué punto en el tiempo puedo restaurar?" — por ejemplo, 12 meses de copias mensuales significa que puedes restaurar una instantánea de hace 10 meses. El RPO responde una pregunta completamente distinta: "¿cuántos datos podría perder si ocurriera un fallo ahora mismo?" Con copias diarias, esa respuesta sigue siendo de hasta 24 horas, independientemente de cuánto tiempo conserves esas copias.
El principio central del diseño de continuidad de negocio es hacer coincidir tu estrategia de recuperación con tus objetivos de RTO y RPO. Objetivos holgados — digamos, RTO de 12 horas y RPO de 24 horas — suelen cubrirse con una buena estrategia de backup. Objetivos estrictos — RTO de minutos y RPO de segundos — exigen replicación continua y conmutación automática.
---
Availability Zones y Availability Sets
Azure ofrece dos formas fundamentales de proteger las cargas de trabajo ante fallos de un único centro de datos.
Un Availability Set distribuye las VMs en diferentes racks físicos dentro del mismo centro de datos. Las VMs se reparten entre dominios de error (rutas de alimentación y red independientes) y dominios de actualización (ventanas de mantenimiento escalonadas), de modo que un fallo de hardware o un ciclo de mantenimiento planificado nunca deje todas las VMs inactivas al mismo tiempo. El SLA es del 99,95 %.
Un Availability Zone va más allá. Dentro de una misma región de Azure, cada zona es un centro de datos físicamente separado con su propia alimentación eléctrica, refrigeración e infraestructura de red independientes. Aunque una zona completa sufra un corte de energía, las VMs de las otras zonas siguen funcionando. El SLA es del 99,99 %.
Las Availability Zones protegen contra fallos dentro de una región. Si la región completa queda fuera de servicio, las Availability Zones no son suficientes — necesitas una arquitectura multi-región.
Regla de referencia para el examen: fallo de rack o host en un único centro de datos → Availability Set; fallo a nivel de zona dentro de una región → Availability Zone; fallo de toda la región → diseño multi-región.
!Availability Zone vs Availability Set
Region Pairs y arquitectura multi-región
Azure agrupa ciertas regiones en pares geográficamente cercanos, conocidos como Region Pairs. Por ejemplo, Korea Central está emparejada con Korea South.
Los Region Pairs tienen tres propiedades importantes:
Las actualizaciones de la plataforma Azure nunca se despliegan en ambas regiones del par al mismo tiempo, lo que distribuye el riesgo de interrupciones relacionadas con las actualizaciones. Si configuras GRS (almacenamiento con redundancia geográfica) o restauración entre regiones (CRR), tus datos se replican automáticamente a la región emparejada. Azure Key Vault realiza failover automático a la región emparejada durante una interrupción regional y opera en modo de solo lectura. La recuperación de claves existentes, el cifrado y el descifrado siguen funcionando, pero crear o modificar claves no es posible durante el período de failover.
Para cargas de trabajo que deben sobrevivir a una interrupción regional completa, existen dos patrones multi-región principales:
El primero es Active-Active o Warm Standby — mantener infraestructura idéntica en la región secundaria en todo momento. Esto mantiene RTO y RPO extremadamente bajos, pero pagas por la infraestructura secundaria de forma continua.
El segundo es Cold Standby — conservar solo datos replicados en la región secundaria y aprovisionar la infraestructura bajo demanda cuando se produce un fallo. Es más rentable, pero resulta en un RTO algo mayor. El DR de VMs basado en Azure Site Recovery es el ejemplo clásico de este patrón.
Para back-ends web basados en VMSS, el patrón recomendado es desplegar un VMSS idéntico en la región secundaria y configurar el failover global usando Front Door. Front Door sondea el estado del backend cada 30 segundos y desvía el tráfico automáticamente a la región secundaria si la principal no está disponible.
---
Estrategia de Azure Site Recovery y Backup
Azure Backup y Azure Site Recovery suenan parecido, pero sirven propósitos muy distintos.
Azure Backup almacena instantáneas de tus datos en un momento específico dentro de un Recovery Services Vault. Puedes configurar niveles de retención diarios, semanales, mensuales y anuales, con retención de hasta 99 años. Para hacer copias de archivos y carpetas de un Windows Server local directamente en Azure sin un servidor de backup independiente, instalas el MARS Agent (Microsoft Azure Recovery Services Agent). El MARS Agent envía archivos, carpetas y estado del sistema al Recovery Services Vault de forma autónoma — puede ejecutarse junto al Windows Server Backup existente sin conflictos.
Azure Site Recovery (ASR) replica de forma continua los discos de las VMs a una región secundaria, alcanzando un RPO de unos pocos minutos a aproximadamente 15 minutos. En condiciones normales, ninguna VM está en ejecución en la región secundaria — solo se mantienen los datos de replicación — lo que minimiza los costos. Cuando se produce un fallo, las VMs se aprovisionan automáticamente en la región secundaria, lo que permite la recuperación con un RTO inferior a una hora. ASR admite escenarios de local a local, local a Azure y Azure a Azure. Los Recovery Plans te permiten definir el orden de failover y gestionar las dependencias automáticamente. La función Test Failover te permite validar tu plan de DR en una red aislada sin ningún impacto en producción.
El Recovery Services Vault es el almacén central tanto para Azure Backup como para Azure Site Recovery. Activar el Immutability Lock impide que los datos de backup sean eliminados o modificados, lo cual es tu principal defensa contra los ataques de ransomware. Con GRS y la restauración entre regiones (CRR), puedes restaurar desde la región secundaria incluso durante una interrupción regional. Dado que un Vault está vinculado a la región donde se creó, los entornos multi-región requieren un Vault separado por región. Para monitorear múltiples Vaults desde un único panel, usa Backup Center.
Para aplicar una política de backup estandarizada a cientos de VMs de forma masiva, vincula una Azure Policy a la política de backup de tu Recovery Services Vault. Las nuevas VMs que entren dentro del ámbito de la política se inscriben automáticamente, manteniendo el estado de cumplimiento sin intervención manual.
---
Tabla comparativa de servicios
La siguiente tabla compara los principales componentes de Azure para alta disponibilidad y recuperación ante desastres según alcance de protección, SLA y RTO/RPO.
| Componente | Alcance de protección | SLA | RPO | RTO | Características clave | |------------|-----------------------|-----|-----|-----|-----------------------| | Availability Set | Racks y hosts dentro de un centro de datos | 99,95 % | N/A | N/A | Distribución por dominios de error, sin costo adicional | | Availability Zone | Centros de datos independientes dentro de una región | 99,99 % | N/A | N/A | Alimentación y refrigeración físicas separadas | | Region Pair + GRS | Replicación de almacenamiento entre regiones | 99,99 %+ | Minutos a 1 hora | Horas | Redundancia geográfica en capa de almacenamiento | | Azure Backup | Retención de datos en un momento dado | - | Horas a 24 horas | Horas a 12 horas | Retención a largo plazo, PITR | | Azure Site Recovery | Replicación de VMs entre regiones | - | Minutos a 15 minutos | Menos de 1 hora | Failover automático, rentable | | SQL Auto-Failover Group | Azure SQL DB entre regiones | 99,99 % | Menos de 5 segundos | Menos de 1 hora | Endpoint único, conmutación automática | | Always On AG + ILB | SQL Server en VMs | 99,99 %+ | 0 segundos (síncrono) | Segundos | Entorno IaaS, basado en WSFC |
---
Criterios de selección que confunden más en el examen
Aquí tienes un resumen de los escenarios y reglas de decisión que aparecen con más frecuencia en el examen real.
Escenario 1: RTO de 12 horas, RPO de 24 horas, la infraestructura secundaria no puede ejecutarse de forma continua, la eficiencia en costos es prioritaria. Elige Azure Backup con PITR. No necesitas mantener VMs en ejecución en la región secundaria, y los backups diarios entregan el RPO requerido de 24 horas. Active Geo-Replication es demasiado costoso para este requisito.
Escenario 2: Failover automático ante una interrupción regional, el servicio debe reanudarse sin cambiar la cadena de conexión de la aplicación (Azur