Amazon DOP-C02: Alta Disponibilidad, Resiliencia y Recuperación ante Desastres — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Forma parte de la AWS DevOps Engineer Professional DOP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Información general

La alta disponibilidad y la recuperación ante desastres en AWS se centran en reducir el tiempo de inactividad (RTO) y la pérdida de datos (RPO) ante fallos de componentes, de Zonas de Disponibilidad (AZ) o de Regiones. Los diseños Multi-AZ absorben los fallos de AZ sin pérdida de datos y con un impacto mínimo en el servicio; los diseños multirregión abordan las interrupciones regionales y los eventos a gran escala. La selección entre estrategias activo/activo, activo/pasivo (espera en caliente o warm standby) y de luz piloto (pilot light) se basa en los objetivos de RTO/RPO del negocio, los requisitos de consistencia y el costo. Alcanzar estos objetivos requiere un diseño coherente que abarque el enrutamiento DNS, la elasticidad de la computación, el balanceo de carga, la replicación/conmutación por error de bases de datos, el almacenamiento de objetos duradero con replicación/versionado, el respaldo centralizado y la verificación continua de la resiliencia mediante la inyección de fallos.

Arquitecturas para RTO/RPO y enrutamiento inteligente

Multi-AZ y multirregión:

• Multi-AZ: Coloque instancias redundantes en al menos dos subredes en diferentes AZ detrás de un balanceador de carga. Utilice bases de datos gestionadas con replicación síncrona (RDS Multi-AZ, clúster Aurora Multi-AZ). El RPO suele ser cero para el almacenamiento síncrono; los objetivos de RTO van desde menos de un minuto (Aurora) hasta unos pocos minutos (conmutación por error de RDS Single-Instance Multi-AZ).
• Multirregión: Elija activo/activo para el RTO más bajo con aislamiento regional y baja latencia, o warm standby/pilot light para una recuperación ante desastres optimizada en costos. La replicación de datos debe cumplir con el RPO: réplicas de base de datos asíncronas, Aurora Global Database (RPO típico <1 s), tablas globales de DynamoDB (multirregión, multiactivo) y S3 Cross-Region Replication (CRR) con Replication Time Control (RTC) opcional para una replicación respaldada por SLA.

Políticas de enrutamiento y comprobaciones de estado de Route 53:

• Enrutamiento por conmutación por error (Failover): Cree dos registros para el mismo nombre: Primario y Secundario. Asocie una comprobación de estado (health check) con el Primario (o use “Evaluate Target Health” para alias a un ALB/NLB). En caso de fallo, el tráfico se desvía al Secundario. Mantenga un TTL bajo (p. ej., 60 s) para reducir el retraso de la caché de DNS y supervise el estado de la comprobación de estado con alarmas de CloudWatch.
• Enrutamiento basado en latencia: Dirija a los usuarios a la Región con la latencia medida más baja. Asocie comprobaciones de estado a cada registro para garantizar que solo los endpoints saludables reciban tráfico. Combínelo con pilas multirregión y almacenes de datos regionales que soporten consistencia eventual/fuerte según sea necesario.
• Enrutamiento ponderado: Divida el tráfico por porcentaje para soportar lanzamientos canary, pruebas A/B o preparación para DR “por goteo” (por ejemplo, 1% al secundario de forma continua). Combínelo con comprobaciones de estado para que los pesos no saludables sean excluidos. Use pesos que cambien gradualmente para migrar el tráfico durante una evacuación regional.
• Comprobaciones de estado (Health checks): Sondee endpoints HTTP(S)/TCP o alarmas de CloudWatch. Para alias de ALB/NLB, habilite “Evaluate Target Health” para heredar el estado del grupo de destino. Diseñe los endpoints de estado para que reflejen la disponibilidad real (dependencias accesibles, migraciones aplicadas). Para aplicaciones con estado (stateful), incluya comprobaciones de dependencias (base de datos, caché) para evitar enrutar a instancias parcialmente saludables.

Elastic Load Balancing y Auto Scaling

Elastic Load Balancing:

• Application Load Balancer (ALB): Capa 7, enrutamiento por host/ruta, WebSocket/HTTP/2, WAF integrado, persistencia de sesión (stickiness) mediante cookies del grupo de destino y comprobaciones de estado basadas en solicitudes. Utiliza el balanceo de carga entre zonas (cross-zone load balancing) y el retraso de anulación de registro (drenaje de conexiones) para drenar gradualmente los destinos durante una reducción horizontal (scale-in) o despliegues. Configura el inicio lento (slow start) y la detección de valores atípicos (outlier detection) para un calentamiento desigual del backend.
• Network Load Balancer (NLB): Capa 4, latencia ultrabaja, IP estáticas/Elastic IPs, paso a través/terminación de TLS (pass-through/termination), conserva la IP de origen y admite conexiones de larga duración. Úsalo para protocolos TCP/UDP, cargas de trabajo de alto rendimiento o donde la visibilidad de la IP del cliente es obligatoria. Las comprobaciones de estado son TCP/HTTP/HTTPS en Capa 4/7 según se configure.
• Drenaje de conexiones (retraso de anulación de registro): Establece un retraso apropiado (por ejemplo, 60–300 s) para permitir que las solicitudes en curso se completen. Asegúrate de que los eventos de despliegue y de terminación de Auto Scaling respeten este retraso para evitar interrupciones para el usuario.

Grupos de Auto Scaling:

• Políticas de escalado:
  • Escalado de seguimiento de objetivo (Target tracking scaling): Mantiene una métrica (CPUUtilization, ALB RequestCountPerTarget) en un valor objetivo. Es la política más simple y adaptable para flotas de web/API.
  • Escalado por pasos (Step scaling): Escala en pasos definidos cuando las métricas cruzan umbrales. Útil para tráfico en ráfagas con patrones predecibles.
  • Escalado programado (Scheduled scaling): Preescala para eventos conocidos (rebajas, lanzamientos) para evitar capacidad en frío.
  • Escalado predictivo (Predictive scaling): Opcionalmente, pronostica la demanda usando ML para patrones diarios/semanales.
• Ganchos de ciclo de vida (Lifecycle hooks): Launching:Wait y Terminating:Wait te permiten controlar la preparación y el desmantelamiento (teardown) de la instancia. Usa los ganchos para:
  • Inicializar (bootstrap) instancias (SSM Automation, finalización de user data, hidratación de la AMI) antes de que entren en servicio.
  • Recopilar logs y artefactos antes de la terminación para el análisis de causa raíz.
  • Coordinar despliegues azul

Ingeniería del caos y AWS Fault Injection Simulator (FIS)

Los experimentos de caos validan que los mecanismos de alta disponibilidad (HA) y recuperación ante desastres (DR) se comportan según lo diseñado. AWS FIS orquesta fallos controlados con barreras de protección (guardrails):

• Las plantillas de experimento definen acciones (por ejemplo, detener o reiniciar un porcentaje de instancias EC2 en un ASG, inyectar estrés de CPU o memoria a través de SSM, añadir latencia de red/pérdida de paquetes en las instancias, terminar pods de EKS, detener tareas de ECS, activar una conmutación por error [failover] de RDS/Aurora) y destinos (etiquetas de recursos, ARN).
• Controles de seguridad: Especifique condiciones de detención con alarmas de CloudWatch, límites de tiempo, restricciones del radio de impacto (blast radius) mediante etiquetas/filtros y comprobaciones previas. Ejecutar primero en entornos de no producción y luego en producción con barreras de protección estrictas y la aprobación del negocio.
• Observabilidad: Instrumente los KPI (tasa de errores, latencia de cola larga, antigüedad de la cola, retraso de la réplica) y verifique las respuestas automatizadas, incluyendo las reacciones de Auto Scaling, la convergencia del estado de salud del balanceador de carga, la conmutación por error de Route 53, la promoción de la base de datos y el comportamiento del disyuntor (circuit breaker).
• Resiliencia continua: Integre los experimentos en las canalizaciones (pipelines)/gamedays para evitar que la deriva de la configuración (configuration drift) erosione la resiliencia. Use Parameter Store o AppConfig para los interruptores (toggles) y para coordinar despliegues seguros.

Escenario de un problema práctico

Expedia Group opera una API global de búsqueda de viajes que debe proporcionar un RTO inferior a 60 segundos y un RPO cercano a cero para los datos críticos de reservas, manteniendo al mismo tiempo una baja latencia para los usuarios de Norteamérica y Europa. El equipo experimenta caídas de servicio parciales (brownouts) regionales ocasionales e inestabilidad inducida por los despliegues, y los auditores exigen copias de seguridad inmutables entre cuentas y simulacros de DR documentados.

Enfoque paso a paso:

1. Establecer pilas (stacks) multirregionales activo/activo

• Desplegar pilas de API sin estado en us-east-1 y eu-west-1 en múltiples AZ detrás de ALBs. Usar el enrutamiento basado en latencia de Route 53 con comprobaciones de estado y la opción Evaluate Target Health en los registros de alias. Esto proporciona un enrutamiento de baja latencia y una evasión regional automática si un punto de conexión (endpoint) no está en buen estado.

2. Almacén de datos global con bajo RPO

• Migrar los datos de reservas y de sesión a Amazon Aurora Global Database (compatible con MySQL) con us-east-1 como principal y eu-west-1 como secundaria. Un RPO típico <1 s y un RTO <1 min cumplen el objetivo de interrupción. Usar los puntos de conexión del clúster y de lectura en la configuración de la aplicación con reintentos/retroceso exponencial (backoff) para tolerar las conmutaciones por error.

3. Escalado resiliente y transiciones suaves

• Configurar el seguimiento de objetivos de Auto Scaling sobre ALB RequestCountPerTarget con una capacidad mínima en ambas regiones. Añadir grupos de instancias precalentadas (warm pools) dimensionados para absorber el aumento de tráfico de 10x durante eventos importantes y ganchos de ciclo de vida (lifecycle hooks) Launching:Wait para retrasar el registro hasta que las comprobaciones de preparación de la aplicación se superen. Habilitar un retardo de anulación de registro (deregistration delay) del ALB de 120 segundos para preservar las solicitudes en curso durante el escalado hacia adentro y los despliegues.

4. DR para objetos duraderos

• Habilitar el versionado de S3 y la CRR con RTC para los documentos de itinerarios desde us-east-1 a eu-west-1. Usar un rol de IAM de replicación dedicado y claves KMS en ambas regiones, otorgando kms:Decrypt en el origen y kms:Encrypt en el destino. Las métricas y alertas de RTC proporcionan confianza en los SLA de replicación.

5. Controles de DNS para canary y conmutación por error

• Añadir registros ponderados de Route 53 (flujo constante del 1 % a eu-west-1) para ejercitar la ruta secundaria continuamente. Combinado con las comprobaciones de estado, esto asegura que el sistema en espera (standby) esté listo para producción y detecta la deriva antes de una crisis.

6. Copias de seguridad centralizadas e inmutables

• En una cuenta de respaldo propiedad del equipo de seguridad, crear almacenes (vaults) de AWS Backup con Vault Lock y CMK de KMS. Definir políticas de copia de seguridad a nivel de organización para programar copias de seguridad diarias y copias entre cuentas para RDS, DynamoDB, EFS y EBS. Asignar recursos mediante la etiqueta Backup_Frequency. Esto logra resistencia al ransomware y separación de funciones.

7. Orquestación de la conmutación por error automatizada

• Implementar una regla de EventBridge para detectar señales de fallo del primario de Aurora e invocar una función Lambda que promueve la región secundaria y actualiza un punto de conexión de la aplicación almacenado en Parameter Store. Las aplicaciones cargan el punto de conexión al iniciarse y lo actualizan en caso de errores de conexión, minimizando los pasos manuales.

8. Validación del caos con AWS FIS

• Crear plantillas de experimento de FIS para: terminar el 10 % de las instancias del ASG, inyectar 150 ms de latencia y 1 % de pérdida de paquetes en EC2 a través de SSM, y activar una conmutación por error de Aurora. Proteger con condiciones de detención de alarmas de CloudWatch sobre la latencia p95 y la tasa de errores. Ejecutar gamedays mensuales para validar la velocidad de la conmutación por error de Route 53, la recuperación del ASG, la convergencia del estado de salud del ALB y el RTO de la promoción de Aurora.

Por qué estos servicios:

• El enrutamiento basado en latencia y ponderado de Route 53 proporciona tanto una latencia óptima para el usuario como una modelación controlada del tráfico para la preparación ante desastres (DR).
• ALB más ASG con grupos de instancias precalentadas (warm pools) y ganchos de ciclo de vida garantizan un escalado rápido y suave sin penalizaciones por arranque en frío ni interrupciones para el usuario.
• Aurora Global Database cumple de forma única con un RPO cercano a cero y un RTO inferior al minuto entre regiones con cambios mínimos en la aplicación.
• El versionado de S3 y la CRR con RTC ofrecen una replicación auditable y respaldada por SLA para artefactos críticos.
• AWS Backup con almacenes (vaults) entre cuentas y Vault Lock crea copias de seguridad inmutables y gobernadas centralmente, alineadas con las necesidades de cumplimiento.
• AWS FIS proporciona una inyección de fallos segura y automatizada para probar continuamente la postura de resiliencia y evitar que la deriva de la configuración socave el plan de DR.

← Contenedores y Operaciones sin Servidor · Todos los dominios · Arquitecturas Orientadas a Eventos y Automatización →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →