El SAP-C02 evalúa la capacidad de diseñar arquitecturas de DR con RPO/RTO específicos usando los servicios correctos. Las preguntas siempre incluyen restricciones de costo vs tiempo de recuperación que debes balancear.
Contenido
RPO — Recovery Point Objective
Máxima cantidad de datos que se puede perder, medida en tiempo desde el último backup/snapshot hasta el momento del desastre.
RPO = 1 hora → máximo 1 hora de datos perdidos
RPO = 0 → zero data loss (replicación síncrona)
Determina: frecuencia de backups, replicación síncrona vs asíncrona
RTO — Recovery Time Objective
Máximo tiempo aceptable para restaurar el servicio después de un desastre. El negocio puede operar hasta X horas sin el sistema.
RTO = 4 horas → el sistema debe estar online en 4h
RTO = minutos → requiere failover automático pre-desplegado
Determina: infraestructura DR pre-calentada o cold start
Multi-Site Active-Active
Dos o más regiones procesan tráfico de producción simultáneamente. Si una región falla, Route 53 o Global Accelerator enruta automáticamente todo el tráfico a la región disponible.
Cómo implementar en AWS:
DynamoDB Global Tables (escrituras en todas las regiones), Aurora Global DB (escrituras solo en primaria), Route 53 latency routing + health checks, ALB en cada región.
Usar cuando:
RTO/RPO < 1 minuto, aplicaciones críticas de misión, gaming, finanzas en tiempo real.
Warm Standby
Versión mínima de producción corriendo en la región DR con instancias de tamaño reducido. Los datos se replican continuamente. En caso de desastre, se escala verticalmente/horizontalmente.
Cómo implementar en AWS:
RDS Read Replica cross-region (promover a primaria), instancias EC2 mínimas siempre encendidas en DR, ASG configurado para escalar rápido, Route 53 failover routing.
Usar cuando:
RTO de 15-60 minutos es aceptable. Mayor disponibilidad que Pilot Light con menor costo que Active-Active.
Pilot Light
Solo los componentes más críticos (base de datos, datos) están replicados en la región DR. Las capas de aplicación y cómputo están apagadas o en mínimo. Se arrancan en caso de desastre.
Cómo implementar en AWS:
RDS con cross-region snapshot o Read Replica, AMIs pre-configuradas para arranque rápido, CloudFormation templates listos, Route 53 con failover hacia la región DR.
Usar cuando:
RTO de 1-4 horas. Balance entre costo y velocidad de recuperación para sistemas importantes pero no críticos.
Backup & Restore
Backup periódico de datos a S3 en otra región. No hay infraestructura pre-desplegada en DR. En caso de desastre, se restaura desde los backups y se recrea la infraestructura.
Cómo implementar en AWS:
S3 Cross-Region Replication para backups, AWS Backup para automatizar, CloudFormation para recrear infraestructura, RDS snapshot copy a región DR.
Usar cuando:
Sistemas no críticos donde downtime de horas/días es aceptable. Mínimo costo.
| Política | Cómo funciona | Health Checks | Caso de uso DR/HA |
|---|---|---|---|
| Failover | Primary recibe todo el tráfico. Si falla el health check, Route 53 enruta al Secondary. | Obligatorios en Primary | Active-passive DR entre dos regiones |
| Latency | Enruta al endpoint con menor latencia para el usuario. Con health checks, evita regiones degradadas. | Opcionales (recomendados) | Active-active multi-región con enrutamiento por latencia |
| Weighted | Distribuye el tráfico según pesos configurados (ej: 90/10 para canary releases). | Opcionales | Canary deployments, blue/green entre regiones |
| Geolocation | Enruta según la ubicación geográfica del usuario (país, continente, default). | Opcionales | Compliance de datos (GDPR: usuarios EU → región EU) |
| Geoproximity | Enruta según la proximidad física al endpoint, con bias ajustable. | Opcionales | Ajustar distribución de tráfico entre regiones cercanas |
| Multivalue Answer | Devuelve hasta 8 IPs saludables al cliente. Cada record tiene health check. | Obligatorios por record | Balanceo de carga simple a nivel DNS con health checks |
Route 53 Health Checks — crítico para DR
Endpoint checks
Verifica HTTP/S o TCP a un endpoint. Puede evaluar el string de respuesta. Recomendado: verificar un endpoint de /health de la app, no solo el TCP.
Calculated health checks
Combina el resultado de múltiples health checks (AND/OR). Para marcar "saludable" solo si todos los componentes críticos responden.
CloudWatch alarm checks
El health check se basa en el estado de una alarma CloudWatch. Para recursos que no tienen endpoint HTTP (bases de datos, colas).
| Característica | Global Accelerator | CloudFront |
|---|---|---|
| Función principal | Acelera el routing de tráfico a nivel red (anycast IPs estáticas) | CDN — cachea contenido en edge locations |
| Tipo de tráfico | TCP y UDP (cualquier protocolo, no solo HTTP) | HTTP/S principalmente |
| Caching | NO cachea — es solo routing optimizado | SÍ cachea contenido estático y dinámico configurable |
| IPs estáticas | SÍ — 2 anycast IPs fijas (no cambian) | NO — IPs de edge locations varían |
| Protocolos | TCP, UDP, HTTP, HTTPS | HTTP, HTTPS, WebSocket |
| Failover | Failover automático en < 1 minuto a endpoint secundario | Failover via Origin Groups con health checks |
| Casos de uso | Gaming (UDP), IoT, VoIP, failover de API, IPs fijas para whitelisting | Sitios web, APIs HTTP, streaming de video, contenido estático |
| Shield Advanced | Incluido con Shield Advanced | Incluido con Shield Advanced |
AWS Backup es el servicio centralizado para gestionar backups de múltiples servicios AWS desde un solo lugar. Para entornos multi-cuenta, AWS Backup se gestiona centralmente via Organizations.
Servicios soportados
Características clave para el examen
Backup Vault Lock — el "escudo anti-ransomware" del examen
Backup Vault Lock aplica WORM (Write Once Read Many) a la vault. Una vez activado, nadie (incluyendo el root user y AWS) puede eliminar los backups antes de que expiren. Es la respuesta cuando el escenario dice "proteger backups contra eliminación maliciosa, incluso por admins con privilegios elevados".
Resilience Hub analiza aplicaciones AWS (via CloudFormation, Terraform, AppRegistry) y evalúa si cumplen con las políticas de resiliencia (RTO/RPO targets) definidas. Genera un Resiliency Score y recomendaciones de mejora.
Resiliency Policy
Define los targets de RTO/RPO para diferentes tipos de disrupciones (AZ, región, hardware).
Application Assessment
Analiza la arquitectura e identifica Single Points of Failure (SPoF) y brechas de resiliencia.
Recommended Actions
Sugiere cambios concretos: añadir Multi-AZ, configurar backups, añadir health checks.
Resiliency Score
Puntuación de 0-100 basada en cuántas recomendaciones se han implementado.
Trampa: "RPO es el tiempo de recuperación y RTO es la pérdida de datos"
Realidad: Invertido. RPO = máxima pérdida de datos (Recovery Point). RTO = máximo tiempo de recuperación (Recovery Time). RPO determina la frecuencia de backups; RTO determina cuánta infraestructura pre-calienta.
Trampa: "Warm Standby y Pilot Light son la misma estrategia"
Realidad: Diferentes. Pilot Light solo mantiene encendido el "núcleo" (DB replicada, datos críticos). Warm Standby mantiene una versión mínima pero completa de la app corriendo — lista para escalar. Warm Standby tiene RTO menor pero mayor costo.
Trampa: "Global Accelerator cachea contenido como CloudFront"
Realidad: FALSO. Global Accelerator NO cachea nada — solo optimiza el routing de red usando la backbone de AWS. El caching es exclusivo de CloudFront.
Trampa: "Route 53 Failover policy hace failover instantáneo"
Realidad: Route 53 detecta el fallo via health checks (verificaciones cada 30s por defecto). El TTL del registro DNS también afecta el tiempo de failover. El RTO no es 0 — puede ser de 1-5 minutos.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa de servicios financieros tiene su aplicación principal en us-east-1. Los requisitos de DR son: RPO máximo de 1 minuto y RTO máximo de 5 minutos. El presupuesto no permite una arquitectura active-active completa. ¿Cuál es la estrategia de DR más adecuada?
Inicia sesión para llevar tu progreso.