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

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Planificación de RTO y RPO: cuantificar la tolerancia y diseñar la arquitectura

El RTO (Objetivo de tiempo de recuperación) y el RPO (Objetivo de punto de recuperación) impulsan cada decisión de resiliencia, desde el dimensionamiento de la computación hasta la topología de replicación. Comience por clasificar las cargas de trabajo según el impacto en el negocio y el costo del tiempo de inactividad, y luego traduzca esas prioridades en objetivos medibles: los RPO de milisegundos impulsan la replicación síncrona o bases de datos globales diseñadas específicamente, mientras que los RPO de minutos a horas permiten la replicación asíncrona, la programación de instantáneas o el envío de registros por lotes. Utilice servicios de AWS que se alineen con los objetivos: Amazon Aurora Multi‑AZ y Aurora Global Database para RTO/RPO bajos a escala, RDS Multi‑AZ para alta disponibilidad síncrona en una sola región, réplicas de lectura entre regiones para recuperación y generación de informes, y AWS Elastic Disaster Recovery (DRS) para la replicación casi en tiempo real de servidores on-premise con cambios mínimos en la aplicación. Una trampa común es diseñar solo para soportar la carga promedio en lugar de las operaciones de recuperación en el peor de los casos; otra es suponer que las instantáneas (snapshots) por sí solas cumplen el RPO para sistemas transaccionales, ya que pueden tener minutos de diferencia entre sí y carecer de consistencia de la aplicación. Las compensaciones en las decisiones son sencillas: la replicación síncrona aumenta el costo y la latencia de escritura, pero reduce el RPO; la replicación asíncrona reduce la latencia y el costo, pero aumenta la pérdida potencial de datos. Pruebe el plan con pruebas de caos (chaos testing), failovers programados y simulacros de restauración para validar el RTO/RPO real e identificar dependencias ocultas como la autenticación externa, el DNS o las listas blancas de IP (IP whitelists).

Arquitecturas Multi‑AZ y Multi‑Región y estrategias de failover

Las arquitecturas Multi‑AZ protegen contra fallas de AZ al distribuir recursos redundantes de computación, redes y almacenamiento a través de Zonas de Disponibilidad (Availability Zones); las arquitecturas Multi‑Región amplían la tolerancia a fallas a nivel de región, desastres naturales o particiones de red a gran escala. Elija un patrón de arquitectura (pilot light, warm standby, activo-pasivo o activo-activo) según el costo y las necesidades de recuperación. El patrón Pilot light utiliza recursos mínimos en una región secundaria para minimizar el costo y escala durante un failover; warm standby mantiene servicios con escalado reducido en ejecución para una recuperación más rápida; activo-activo atiende el tráfico en múltiples regiones para obtener el RTO más bajo, pero exige una replicación de datos sólida y resolución de conflictos. Utilice Route 53 con comprobaciones de estado (health checks) y enrutamiento de failover, Amazon CloudFront o Global Accelerator para la gestión del tráfico global, y servicios de datos como DynamoDB Global Tables o Aurora Global Database para la replicación entre regiones. Los errores comunes incluyen depender de TTL de DNS que son demasiado largos, no validar el failover de servicios con estado (stateful), como los almacenes de sesiones o las cachés, y descuidar los costos de transferencia de datos entre regiones y las restricciones de cumplimiento normativo (compliance). Equilibre la complejidad y el costo de una implementación multirregional con el tiempo de inactividad y la pérdida de datos aceptables; en caso de duda, instrumente y modele los tiempos de failover para fundamentar el caso de negocio.

Patrones de resiliencia de aplicaciones: diseño sin estado, desacoplamiento y gestión de estado

Diseñe para el fallo minimizando el estado anclado a nodos de computación individuales y desacoplando componentes para que las fallas parciales no se propaguen en cascada. Los nodos de aplicación sin estado (stateless) detrás de un Application Load Balancer o un Network Load Balancer permiten el escalado horizontal y el reemplazo rápido. Para el estado de la sesión, prefiera almacenes externos como Amazon DynamoDB o Amazon ElastiCache en lugar de sesiones persistentes (sticky sessions); para recursos compartidos de archivos, utilice Amazon S3, Amazon EFS o FSx según el protocolo y las necesidades de rendimiento. Los patrones asíncronos que utilizan Amazon SQS, SNS o Kinesis amortiguan los picos de carga, permiten reintentos, suavizan la contrapresión (backpressure) y reducen las dependencias síncronas durante un failover. Implemente patrones como circuit breakers, bulkheads y exponential backoff en los clientes para aislar los subsistemas que fallan. Una trampa frecuente para los arquitectos es subestimar los tiempos de arranque en frío (cold-start) o de escalado: los límites de concurrencia de Lambda, los periodos de enfriamiento (cooldowns) de Auto Scaling y las estrategias de calentamiento (warm-up) afectan el RTO. Otra es tratar el almacenamiento en caché como si fuera durabilidad; las cachés deben poder reconstruirse. Las decisiones de costo frente a resiliencia se manifiestan en el dimensionamiento de los búferes y la replicación: una mayor resiliencia a menudo requiere más capacidad reservada o replicación entre regiones, lo que aumenta el costo; elija la redundancia mínima viable que satisfaga el RTO/RPO, al tiempo que garantiza la observabilidad y la automatización para detectar y remediar fallas.

Copias de seguridad, replicación, gobernanza y preparación operativa

Las copias de seguridad son un seguro; las partes cruciales son la consistencia, la seguridad, la retención y la recuperabilidad. Utilice AWS Backup para políticas de copia de seguridad centralizadas en EBS, RDS, DynamoDB, EFS y FSx y para forzar copias de seguridad entre cuentas y entre regiones para obtener resiliencia geográfica. Para datos de objetos, habilite el versionado de S3 con reglas de ciclo de vida (Lifecycle rules) y S3 Replication (CRR) para una durabilidad entre regiones. Asegure instantáneas consistentes con la aplicación para bases de datos y sistemas de archivos de Windows aprovechando las copias de seguridad nativas de la base de datos, las instantáneas automatizadas de RDS o AWS DRS con soporte para VSS. La replicación entre cuentas y el principio de privilegio mínimo (least‑privilege) de IAM son esenciales para prevenir eliminaciones accidentales. Los ejercicios de restauración regulares revelan problemas con roles de IAM faltantes, redes (superposiciones de CIDR de VPC) o integraciones externas. Automatice los runbooks con Systems Manager Automation y codifique los procedimientos de conmutación por error (failover) en CloudFormation o Terraform para reducir los errores manuales. Las trampas comunes incluyen depender únicamente de instantáneas de un momento específico (point‑in‑time) sin capacidad de exportación, no cifrar las copias de seguridad con claves administradas por el cliente y no monitorear el éxito de los trabajos de copia de seguridad. Equilibre los costos de retención y almacenamiento con los requisitos normativos; transfiera las copias de seguridad más antiguas a S3 Glacier para controlar los costos, mientras mantiene las copias de seguridad recientes rápidamente accesibles para restauraciones rápidas.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Events Inc., una empresa global de eventos en vivo, ejecuta una aplicación de venta de entradas en una única región de AWS utilizando grupos de EC2 Auto Scaling detrás de un ALB, con un clúster de PostgreSQL de 3 nodos en EC2 en una AZ e instantáneas nocturnas de EBS. La organización necesita reducir el RTO a menos de 10 minutos y el RPO a menos de 5 minutos, minimizando al mismo tiempo la sobrecarga operativa y el costo.

Desafío: Lograr una disponibilidad casi continua y una baja pérdida de datos para la base de datos entre AZ y regiones, con una conmutación por error (failover) predecible y cambios mínimos en la aplicación.

Enfoque recomendado:

Configure Amazon RDS for PostgreSQL con un despliegue Multi‑AZ o migre a Amazon Aurora PostgreSQL con Multi‑AZ y habilite copias de seguridad continuas automatizadas y exportaciones rápidas de instantáneas; habilite las copias de seguridad automatizadas con una ventana de retención adecuada.
Agregue replicación entre regiones utilizando Aurora Global Database (o replicación lógica/física de RDS a una réplica de lectura en una región secundaria) para cumplir con los objetivos de RPO geográficos, y configure el enrutamiento basado en latencia de Route 53 con chequeos de salud (health checks) para permitir una conmutación por error (failover) controlada entre regiones.
Reemplace la instancia de PostgreSQL en EC2 de una sola AZ con un servicio administrado para eliminar el mantenimiento del host, y refactorice la lógica de conexión de la aplicación para usar los endpoints del clúster o RDS Proxy para la agrupación de conexiones (connection pooling) y un manejo más rápido de la conmutación por error.
Implemente la verificación continua de la replicación y la automatización de runbooks: simulacros de conmutación por error programados utilizando Systems Manager Automation y plantillas de CloudFormation para la recreación rápida de recursos; instrumente métricas y ejecute alertas a través de CloudWatch y SNS.

Justificación: El uso de servicios de bases de datos administrados y Multi‑AZ junto con la replicación entre regiones reduce la complejidad operativa y cumple con los objetivos agresivos de RTO/RPO; la automatización y los simulacros periódicos aseguran que el plan funcione en la práctica, mientras que RDS/Aurora minimizan los pasos manuales y el tiempo de conmutación por error.

← Migración y Modernización · Todos los dominios · Optimización de Costos y Gobernanza →

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