Amazon SOA-C02: Alta Disponibilidad, Tolerancia a Fallos y Recuperación ante Desastres — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Forma parte de la AWS SysOps Administrator Associate SOA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Este dominio abarca el diseño de sistemas que se mantienen disponibles y recuperables cuando fallan componentes, servicios o regiones enteras. Cubre estrategias de respaldo y snapshots, patrones de replicación y conmutación por error (failover), y las pruebas operativas necesarias para cumplir con los objetivos de negocio de RTO (Recovery Time Objective) y RPO (Recovery Point Objective). La importancia operativa es alta: las interrupciones y la pérdida de datos impactan directamente en los SLAs, los ingresos y el cumplimiento normativo. Los diseños eficaces equilibran el costo, la complejidad y el riesgo aceptable de pérdida de datos y tiempo de inactividad.

Estrategias de respaldo, snapshots y retención

Los respaldos deben ser automatizados, consistentes con el estado de la aplicación y retenidos según las políticas establecidas. Utilice AWS Backup para centralizar planes, retención y reglas de ciclo de vida (crear un plan de respaldo con un vault, asignar ARNs de ID de recurso o etiquetas). Para volúmenes de EBS, use Data Lifecycle Manager (DLM) para programar snapshots (consola o aws dlm create-lifecycle-policy); ejemplo de creación de snapshot por CLI: aws ec2 create-snapshot –volume-id vol-0123456789abcdef0 –description “pre-upgrade”. Para RDS, utilice snapshots automatizados o snapshots de base de datos manuales (aws rds create-db-snapshot –db-instance-identifier mydb –db-snapshot-identifier mydb-snap-YYYYMMDD). Habilite los respaldos automatizados de RDS para la recuperación a un punto en el tiempo (point-in-time recovery); habilite el monitoreo mejorado (enhanced monitoring) y la retención de snapshots para cumplir con los SLAs de retención.

La retención, la inmutabilidad y las copias entre regiones son decisiones críticas:

Un RPO/RTO bajo requiere snapshots frecuentes y ventanas de eliminación de retención cortas; esto aumenta el costo.
Para la inmutabilidad por motivos regulatorios, utilice AWS Backup Vault Lock o S3 Object Lock para la retención legal (legal hold).
Para la durabilidad entre regiones, copie los snapshots (aws ec2 copy-snapshot –source-region us-east-1 –source-snapshot-id snap-abc –destination-region us-west-2) y habilite el versionado de S3 antes de la replicación entre regiones.

Capture siempre un estado consistente con la aplicación: para EC2, utilice AWS Systems Manager Run Command o scripts para vaciar/bloquear los sistemas de archivos antes de crear snapshots; para bases de datos, prefiera los snapshots nativos del motor (RDS/Aurora) o respaldos lógicos (mysqldump, pg_dump) para la validación a un punto en el tiempo.

Replicación entre regiones y patrones de recuperación ante desastres

Las estrategias multirregión reducen el radio de impacto de una falla regional. La replicación entre regiones de S3 (Cross-Region Replication o CRR) requiere versionado, un rol de IAM para la replicación y una configuración de replicación (consola o aws s3api put-bucket-replication –bucket src –replication-configuration file://replication.json). RDS admite réplicas de lectura entre regiones (aws rds create-db-instance-read-replica) y Aurora Global Database para arquitecturas de lectura/escritura multirregión de baja latencia con conmutación por error (failover) controlada. Las tablas globales de DynamoDB (DynamoDB Global Tables) replican datos de forma asíncrona entre regiones y son adecuadas para lecturas multirregión con consideraciones de consistencia eventual.

Elija un patrón de DR basado en el RTO/RPO y el costo:

Pilot Light (Luz piloto): replicar datos críticos a una región secundaria (S3, snapshots, réplicas de BD) pero con una infraestructura en ejecución mínima; escalado rápido mediante plantillas de IaC.
Warm Standby (En espera semiactiva): una huella activa más pequeña en la región secundaria con datos replicados continuamente y servicios reducidos que se pueden escalar automáticamente.
Multi-Region Active-Active (Multirregión activo-activo): ejecutar pilas completas en múltiples regiones con enrutamiento de tráfico y resolución de conflictos; requiere replicación global (DynamoDB global tables, Aurora Global DB, manejo de conflictos a nivel de aplicación).

Considere la consistencia de la replicación: la replicación síncrona minimiza el RPO pero aumenta la latencia y puede no ser compatible entre regiones; la mayoría de las opciones multirregión son asíncronas e introducen un retraso en la replicación (replication lag) que define el RPO realista.

Opciones de arquitectura Multi-AZ y Multi-Region

Multi-AZ es la opción predeterminada para alta disponibilidad dentro de una región; proporciona conmutación por error (failover) automática para muchos servicios administrados con un RTO mínimo. RDS Multi-AZ y Aurora replican el almacenamiento entre Zonas de Disponibilidad (AZs); la conmutación por error suele ser automática y utiliza un cambio de DNS (DNS switch-over). Para EC2, coloque instancias en múltiples AZs detrás de un Application Load Balancer y grupos de Auto Scaling; utilice verificaciones de estado (health checks) entre AZs para detectar y reemplazar los destinos en mal estado.

Multi-Region añade resiliencia contra fallas a nivel de región, pero aumenta la complejidad (replicación de datos, enrutamiento global, cumplimiento normativo). Criterios de decisión:

Utilice Multi-AZ cuando necesite alta disponibilidad con baja latencia dentro de una región y desee una conmutación por error automática y administrada a un costo menor.
Utilice Multi-Region para la recuperación ante desastres (disaster recovery) contra la pérdida de una región o para la reducción de latencia en una arquitectura global activo-activo.

Consideraciones de diseño:

TTLs de DNS: se necesitan TTLs bajos (p. ej., 60 s) para una conmutación por error rápida basada en DNS, pero aumentan la carga de consultas de DNS.
Localidad de los datos y cumplimiento normativo: algunos datos deben permanecer en una región; diseñe la replicación y el cifrado en consecuencia.
Costo vs. RTO/RPO: una arquitectura multirregión activo-activo aumenta el costo pero minimiza el RTO.

Mecanismos de conmutación por error (chequeos de salud de Route53, automatizados)

La conmutación por error automatizada utiliza chequeos de salud, políticas de enrutamiento y orquestación. Route53 admite chequeos de salud y enrutamiento de conmutación por error (failover), ponderado (weighted) y por latencia (latency). Configure los chequeos de salud de Route53 para sondear los endpoints (HTTP, TCP o alarmas de CloudWatch) y un conjunto de registros de conmutación por error que cambie a un recurso secundario cuando el primario falle. Ejemplo de actualización por CLI: aws route53 change-resource-record-sets –hosted-zone-id Z123456 –change-batch file://changes.json. Utilice alarmas de CloudWatch (las acciones de alarma activan AWS Lambda) para orquestar la conmutación por error para acciones que no son de DNS.

Integre Load Balancers y Auto Scaling: los chequeos de salud de los grupos de destino (target groups) de ALB/NLB eliminan las instancias en mal estado, mientras que Auto Scaling las reemplaza automáticamente. Para la conmutación por error de bases de datos, confíe en los mecanismos a nivel de servicio: RDS Multi-AZ o la conmutación por error automatizada de Aurora, y para la promoción entre regiones, utilice réplicas de lectura (read replicas) o la promoción controlada de Aurora Global DB.

Dos patrones operativos:

Conmutación por error de DNS (Route53): rápido de implementar, pero dependiente del TTL del DNS y del almacenamiento en caché del cliente.
Conmutación por error del plano de control (Lambda/Step Functions + llamadas a la API): orquesta la promoción, la reasignación de IP/EIP y las actualizaciones de Route53 en una secuencia predecible para aplicaciones complejas.

Planificación, pruebas y validación de RTO/RPO

El RTO es el tiempo de inactividad máximo aceptable; el RPO es la pérdida de datos máxima aceptable. Defina objetivos medibles para cada carga de trabajo y alinee las decisiones de arquitectura: la replicación síncrona reduce el RPO pero puede aumentar la latencia; la replicación asíncrona reduce el costo pero aumenta la ventana potencial de pérdida de datos. Traduzca los SLA de negocio en frecuencia de retención y replicación: RPO = retraso de replicación + intervalo de copia de seguridad; RTO = tiempo de detección + tiempo de orquestación de la conmutación por error + tiempo de validación de la recuperación.

Las pruebas son esenciales: ejecute simulacros de DR programados que validen los procedimientos de restauración, la conmutación por error de DNS y la integridad de la aplicación. Valide las copias de seguridad restaurándolas en una cuenta o VPC aislada (utilice CloudFormation/CloudFormation StackSets o Terraform para automatizar las reconstrucciones). Capture métricas durante las pruebas (tiempo de propagación del DNS, punto de recuperación, verificaciones a nivel de aplicación) e itere sobre la automatización para reducir el RTO.

Errores Comunes y Criterios de Decisión

Asumir que los snapshots equivalen a la recuperabilidad: realice siempre restauraciones en un entorno separado y valide la consistencia de la aplicación; utilice snapshots nativos del motor o ponga en reposo (quiesce) las aplicaciones antes de tomar el snapshot.
Diseñar sistemas de una sola región para cargas de trabajo críticas globales: elija patrones Multi-Region o warm standby cuando un fallo regional afecte a los clientes; considere la soberanía de los datos.
Ignorar el RTO/RPO en el diseño: capture el RTO/RPO por carga de trabajo y seleccione la replicación/copias de seguridad en consecuencia; asigne el RPO a la frecuencia de replicación y el RTO a la automatización de la orquestación.
TTLs de DNS largos que bloquean una conmutación por error rápida: establezca TTLs bajos para los registros de conmutación por error críticos y utilice la aceleración global solo cuando se requiera un enrutamiento estable.
Omitir los permisos de IAM para la replicación entre regiones: la CRR, la copia de snapshots y el acceso al backup vault requieren roles y políticas de recursos correctos; pruebe las rutas de IAM para la replicación.
No monitorear el retraso de la replicación y su estado: instrumente las métricas de CloudWatch (ReplicaLag, CPU, red) y alerte cuando los umbrales se acerquen a los límites del RPO.

Problema Práctico: Escenario de Caso de Uso

AcmePayments ejecuta una API de transacciones bajo el ámbito de PCI en us-east-1 y necesita un RTO <5 minutos y un RPO casi nulo para los datos de transacciones principales durante una interrupción regional.

Definir RTO=5 min y RPO≈0 seleccionando Aurora Global Database con una base de datos primaria de escritura en us-east-1 y una secundaria en eu-west-1 para una replicación rápida entre regiones.
Habilitar Multi-AZ síncrono/por región para la alta disponibilidad (HA) dentro de la región (réplicas de Aurora + Multi-AZ), y publicar el DNS a través de Route53 con chequeos de salud y un TTL bajo (60s) para el enrutamiento de conmutación por error.
Usar snapshots automatizados entre regiones y copias en vaults de AWS Backup como una copia inmutable adicional con retención y vault lock.
Automatizar el playbook de conmutación por error con Step Functions y Lambda para validar la promoción de la réplica, actualizar los registros de Route53 (aws route53 change-resource-record-sets), ejecutar pruebas de humo (smoke tests) y revertir los cambios si se detectan fallos.
Programar simulacros de DR trimestrales restaurando copias de seguridad en una VPC aislada y medir el RTO y RPO reales, para luego refinar la automatización y las políticas de escalado.

Justificación: la combinación de un producto de base de datos global de baja latencia (Aurora Global) con enrutamiento basado en DNS y orquestación automatizada cumple con los estrictos RTO/RPO, al tiempo que mantiene los pasos operativos repetibles y comprobables. La validación regular garantiza que las copias de seguridad y las réplicas sean realmente recuperables.

← Monitoreo · Todos los dominios · Implementación →

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