En el examen AWS DOP-C02, los dominios de "Diseno de alta disponibilidad y resiliencia", "Soluciones de escalabilidad" y "Recuperacion automatica y ante desastres" representan aproximadamente el 35% del total de preguntas. El examen evalua principalmente el juicio arquitectonico, no la memorizacion, por lo que es necesario comprender tanto el funcionamiento interno de cada servicio como los escenarios exactos donde cada uno se aplica.
Patrones de diseno para alta disponibilidad
Health checks profundos en ALB — Aislamiento automatico de SPOF
El health check predeterminado de ALB unicamente verifica si un puerto TCP esta abierto. Esto significa que el balanceador de carga continuara enviando trafico a una instancia que esta activa pero que no puede atender solicitudes porque su conexion a la base de datos o una dependencia externa ha fallado. Los usuarios reciben errores 500 o 503 como resultado.
La solucion es configurar ALB para usar un health check HTTP contra un endpoint dedicado (tipicamente ) que verifique activamente las dependencias internas.
Cuando ALB recibe un 503 del health check, elimina automaticamente la instancia del grupo de destino. Esto requiere solo un cambio en el codigo de la aplicacion, sin modificaciones de infraestructura, lo que lo convierte en la respuesta correcta cuando el enunciado especifica "minimizar cambios en la infraestructura existente."
Route 53 Failover opera a nivel DNS y no puede controlar el trafico de instancias individuales con la misma granularidad. CloudWatch Alarm combinado con Auto Scaling funciona reemplazando instancias no saludables, lo que introduce latencia comparado con bloquear el trafico inmediatamente en el balanceador de carga.
Aurora Global Database — Lecturas globales con soberania de datos regional
Aurora Global Database consiste en una region primaria (lectura y escritura) y hasta cinco regiones secundarias (solo lectura). Utiliza una infraestructura de replicacion dedicada a nivel de almacenamiento que logra una latencia de replicacion de menos de un segundo desde la region primaria a las secundarias.
| Atributo | Aurora Global Database | DynamoDB Global Tables | |----------|------------------------|------------------------| | Modelo de datos | Relacional (MySQL/PostgreSQL) | NoSQL (clave-valor/documento) | | Regiones de escritura | Solo una region primaria | Todas las regiones simultaneamente | | Mecanismo de replicacion | Capa de replicacion fisica dedicada | Basado en DynamoDB Streams | | Recuperacion ante desastres | Promocion de region secundaria en menos de 1 minuto | Conmutacion activa-activa automatica |
La funcion Write Forwarding permite que las escrituras realizadas contra una region secundaria sean reenviadas automaticamente a la region primaria para su procesamiento. Si bien es conveniente, los datos se almacenan realmente en la region primaria, no en la secundaria. En entornos con requisitos de soberania de datos regional, Write Forwarding viola el cumplimiento normativo y no debe usarse.
DynamoDB Global Tables — Activo-activo multirregion
Cuando todas las regiones de un servicio global deben manejar tanto lecturas como escrituras simultaneamente, DynamoDB Global Tables es la eleccion correcta.
Caracteristicas clave: Todas las replicas de cada region aceptan tanto lecturas como escrituras Replicacion asincrona basada en DynamoDB Streams, tipicamente propagandose en menos de un segundo Los conflictos de escritura concurrente se resuelven automaticamente mediante Last Writer Wins (LWW) No se requiere un pipeline de replicacion personalizado
La distincion respecto a Aurora Global Database es un tema frecuente en el examen. La frase "escrituras desde todas las regiones" apunta a DynamoDB Global Tables. La frase "mantener la estructura de base de datos relacional" apunta a Aurora Global Database.
Route 53 Latency Routing + Health Check
Para lograr simultaneamente optimizacion de latencia y conmutacion automatica por error, asocie Health Checks a registros de politica de enrutamiento por latencia — no use el tipo de registro Failover.
Enrutamiento por latencia: dirige a cada usuario a la region con el tiempo de respuesta mas rapido Asociacion de health check: excluye automaticamente las regiones fallidas de las respuestas DNS
El tipo de registro Failover es una construccion binaria Primario/Secundario. Durante el funcionamiento normal no puede distribuir el trafico entre multiples regiones. El enrutamiento por geolocalizacion sirve a los usuarios segun su ubicacion geografica, lo que es adecuado para cumplimiento normativo y localizacion de contenido. Para optimizacion del rendimiento, el enrutamiento por latencia es la eleccion correcta.
ARC Zonal Shift — Aislamiento inmediato de zonas de disponibilidad
Cuando la infraestructura falla en una AZ especifica, el trafico puede continuar fluyendo hacia esa AZ mientras Auto Scaling aun esta en proceso de reemplazar instancias no saludables. Zonal Shift de AWS Application Recovery Controller mueve todo el trafico de ALB o NLB desde la AZ afectada hacia AZs saludables con una sola llamada a la API.
Cambio de trafico inmediato sin demoras por DNS TTL Se integra con ALB y NLB a nivel del grupo de destino Puede activarse automaticamente basandose en alarmas de CloudWatch Puede permanecer activo hasta 72 horas
La conmutacion de Route 53 requiere esperar a que expire el TTL de DNS antes de que se complete la propagacion. Zonal Shift es la respuesta correcta cuando el escenario exige aislamiento inmediato de trafico por AZ.
Soluciones de escalabilidad — Patrones principales
ASG Lifecycle Hooks + Warm Pool — Resolucion de retrasos de inicializacion
Cuando las instancias requieren varios minutos despues del arranque para completar la inicializacion, registrarlas con el balanceador de carga antes de que finalice la inicializacion provoca fallos en las solicitudes de los usuarios.
Como funcionan los Lifecycle Hooks:
El tiempo de espera predeterminado es de una hora, ampliable hasta 48 horas. Enviar una senal ABANDON termina la instancia si la inicializacion falla.
Warm Pool mantiene instancias pre-inicializadas en estado detenido o en ejecucion. Cuando ocurre un evento de scale-out, las instancias de Warm Pool hacen la transicion a InService inmediatamente, eliminando los retrasos de arranque en frio. Las instancias en estado detenido generan solo costos de almacenamiento EBS, sin cargos por instancias EC2, lo que hace que este enfoque sea eficiente en costos.
Estrategia de combinacion de politicas de Auto Scaling
| Politica | Comportamiento | Mejor caso de uso | |----------|---------------|-------------------| | Target Tracking | Mantiene un valor objetivo de metrica, AWS gestiona alarmas automaticamente | Cargas de trabajo generales | | Step Scaling | Pasos de escalado inmediatos en umbrales de alarma de CloudWatch | Picos de trafico imprevisibles | | Scheduled Scaling | Pre-escala en momentos definidos | Patrones de trafico predecibles | | Predictive Scaling | Basado en ML, requiere 7-14 dias de datos historicos | Patrones ciclicos recurrentes |
Los escenarios del examen que piden manejar "picos de trafico imprevisibles" mientras "reducen costos durante noches y fines de semana" — sin agregar Lambda o EventBridge — requieren la combinacion Target Tracking + Step Scaling. Predictive Scaling tiene dificultades con picos de eventos puntuales. Scheduled Scaling solo ayuda cuando el patron es consistente.
Pipeline serverless Kinesis Data Streams + Lambda + DynamoDB
Este es el diseno estandar de pipeline serverless para procesar eventos de alta frecuencia de miles de sensores IoT o fuentes similares en tiempo real.
Kinesis Data Streams escala mediante shards. Cada shard maneja 1 MB/s de escrituras y 2 MB/s de lecturas. El mapeo de fuente de eventos de Lambda activa automaticamente la ejecucion de Lambda, con concurrencia proporcional al numero de shards.
Kinesis Data Firehose vs Kinesis Data Streams: Kinesis Data Streams: procesamiento en tiempo real, requiere aplicacion consumidora personalizada, latencia en milisegundos Kinesis Data Firehose: completamente gestionado, entrega directamente a S3/Redshift/OpenSearch, puede almacenar en buffer durante minutos
Si se necesita almacenamiento clave-valor y consultas de dashboard en tiempo real, use Kinesis Data Streams + Lambda + DynamoDB. Si el objetivo es archivo a largo plazo y analitica por lotes, use Kinesis Data Firehose + S3.
ECS + Fargate — Contenedores serverless
Para eliminar la carga operativa de parcheo del sistema operativo, actualizaciones de seguridad y gestion de capacidad en un entorno de contenedores basado en EC2, use AWS Fargate.
Fargate: AWS gestiona completamente el host del contenedor ECS + Fargate: adecuado para cargas de trabajo de contenedores sencillas y equipos pequenos EKS + Fargate: adecuado cuando se requieren funciones de Kubernetes
Las integraciones del servicio ECS con ALB soportan mapeo dinamico de puertos, permitiendo que multiples tareas de contenedor se registren en un grupo de destino de ALB simultaneamente.
Cuando ECS Fargate desplegado en una subred privada falla al extraer imagenes de ECR, y los permisos IAM se confirman correctos, la causa raiz casi siempre son VPC endpoints faltantes. Endpoints requeridos:
— llamadas a la API de ECR — protocolo de registro Docker (gateway) — las capas de imagen de ECR se almacenan en S3 — CloudWatch Logs (recomendado)
Permisos IAM correctos combinados con fallo en la extraccion de imagenes es una senal clara de VPC endpoints faltantes.
Comparacion de estrategias de recuperacion ante desastres
Las cuatro estrategias DR
| Estrategia | RTO | RPO | Costo | Descripcion | |------------|-----|-----|-------|-------------| | Backup & Restore | Horas | Horas | Mas bajo | Restauracion completa desde backup | | Pilot Light | 30-60 min | Minutos-segundos | Bajo | Solo servicios principales a escala minima | | Warm Standby | 5-15 min |