HA en AWS y estrategias

Alta Disponibilidad en AWS: RTO, RPO y Estrategias de Recuperación (Pilot Light, Warm Standby, Active-Active)

Introducción

En arquitecturas de Alta Disponibilidad (High Availability) y Recuperación ante Desastres (Disaster Recovery, DR) en AWS, es fundamental comprender algunos conceptos clave y estrategias. En esta clase profundizaremos en: RTO, RPO, y tres estrategias de DR (Pilot Light, Warm Standby y Active-Active). Para cada tema daremos una definición técnica, ejemplos de implementación en AWS, comparativas de tiempo de recuperación, costo y complejidad, y su relevancia para el examen AWS Solutions Architect Associate (SAA).

Recovery Time Objective (RTO) – Objetivo de Tiempo de Recuperación

Definición: El RTO es el tiempo máximo aceptable que un servicio puede permanecer caído después de un desastre antes de ser restaurado. En otras palabras, marca cuánto tiempo de inactividad puede tolerar el negocio. Por ejemplo, un RTO de 1 hora significa que debemos recuperar la funcionalidad del sistema en menos de 60 minutos tras una falla.

Implementación en AWS: Las arquitecturas en AWS deben diseñarse según los RTO requeridos. Algunas técnicas para reducir el RTO incluyen:

• Multizona (Multi-AZ): Usar instancias Amazon RDS Multi-AZ o despliegues multi-AZ para servidores de aplicaciones. Esto permite failover automático a una zona sana en 1-2 minutos, reduciendo drásticamente el RTO frente a fallos zonales. Por ejemplo, RDS Multi-AZ logra recuperación automática rápida (minutos) comparado con restaurar desde backup (horas).
• Auto Scaling y Balanceo: Utilizar Amazon EC2 Auto Scaling y Elastic Load Balancing (ELB) distribuye carga y reemplaza instancias defectuosas automáticamente, disminuyendo el tiempo de restauración de la capacidad.
• Infraestructura como código: Tener plantillas CloudFormation preparadas para desplegar recursos en otra región acelera la recuperación en caso de desastre regional. Esto evita configuraciones manuales que alargarían la interrupción.

Comparativa: Un RTO bajo exige más inversión en redundancia. Por ejemplo, un RTO cercano a cero requiere soluciones activas (ver Active-Active), mientras que un RTO de varias horas podría lograrse con simples copias de seguridad y restauración. Garantizar RTO cortos suele incrementar costos y complejidad. Es importante definir un RTO realista: no siempre es factible “cero” minutos, y objetivos demasiado estrictos pueden ser inviables o muy costosos. En resumen: a menor RTO, mayor inversión en HA/DR.

En el examen (SAA): El examen suele esperar que el candidato distinga RTO de RPO y sepa aplicar ambos. Podrían plantear un escenario donde se menciona un RTO específico (p. ej., “la empresa requiere que la aplicación vuelva a estar operativa en menos de 15 minutos”) y hay que elegir la arquitectura apropiada (multi-AZ, warm standby, etc.). Es esencial reconocer que RTO se refiere al tiempo de recuperación y seleccionar la estrategia AWS que lo satisfaga (por ejemplo, Multi-AZ o warm standby para RTO de minutos, vs. backup & restore para RTO de horas). Preguntas típicas pueden ser de tipo ¿Qué configuración garantiza un RTO máximo de X? o ¿Cómo reducir el RTO de una solución existente?. Saber que servicios como RDS Multi-AZ, Auto Scaling, o Route 53 health checks ayudan a disminuir RTO es útil para el examen.

Recovery Point Objective (RPO) – Objetivo de Punto de Recuperación

Definición: El RPO es la cantidad máxima de tiempo aceptable que puede pasar desde el último punto de respaldo de datos hasta un desastre. En términos simples, marca cuánto datos podemos perder (medido en tiempo). Por ejemplo, un RPO de 4 horas implica que podemos perder hasta 4 horas de datos como máximo; en la práctica, deberíamos tener respaldos o replicación de datos al menos cada 4 horas.

Implementación en AWS: Para cumplir un RPO determinado, debemos elegir la estrategia de respaldo o replicación de datos adecuada:

• Respaldo periódico: Si el RPO permitido es alto (por ejemplo ≥ 24 horas), bastarían respaldos diarios usando AWS Backup o snapshots (EBS, RDS, etc.). Un Amazon RDS Snapshot nocturno, por ejemplo, da un RPO ~24 horas.
• Replicación continua: Para RPO bajos (minutos o segundos), se usan réplicas o replicación multi-región. Ejemplos: Amazon S3 Cross-Region Replication copia objetos continuamente a otro bucket/región (RPO cercano a cero en términos de respaldo de objetos). RDS Read Replicas o Amazon Aurora Global Database mantienen datos casi sincronizados entre regiones con retraso típico de <1s, logrando RPO de segundos. DynamoDB Global Tables permiten replicación multi-región activa con RPO cercano a cero.
• Versionado y backups incrementales: Activar el versionado en S3 o backups incrementales frecuentes en bases de datos permite reducir la pérdida de datos en caso de corrupción o borrado accidental.

Comparativa: Al igual que con RTO, un RPO más estricto (menos pérdida de datos) implica más costo y complejidad. Replicación síncrona o casi en tiempo real (RPO ≈ 0) requiere tecnologías avanzadas (como Aurora Global, DynamoDB Global Tables) y múltiples copias de datos, incrementando costos. Si el negocio tolera más pérdida de datos (RPO en horas), se puede optar por respaldos menos frecuentes y arquitectura más simple. RPO y RTO están relacionados pero independientes: un sistema puede tener RPO=0 (ninguna pérdida de datos mediante replicación continua) pero un RTO alto si, por ejemplo, la restauración es lenta; o viceversa. AWS Resilience Hub recomienda definir claramente ambos objetivos para cada carga de trabajo.

En el examen (SAA): Espere preguntas donde debe identificarse la mejor solución para lograr cierto RPO. Un escenario típico: “La empresa XYZ puede tolerar solo 5 minutos de pérdida de datos” – esto apunta a replicación continua (e.g. Aurora Global DB, multi-AZ, o DynamoDB Global Tables) en lugar de backups diarios. El candidato debe reconocer palabras clave: RPO se relaciona con puntos de recuperación de datos. También pueden preguntar la diferencia entre RPO y RTO; hay que recordar: RPO = datos que se pueden perder, RTO = tiempo offline permitido. Saber elegir servicios de replicación vs. backup según el RPO requerido es fundamental.

Estrategia Pilot Light (Luz piloto)

Definición: Pilot Light es una estrategia de DR activo/pasivo en la que se mantiene una versión mínima de la infraestructura en una región secundaria, con los datos replicados constantemente, mientras que la mayor parte de los servidores de aplicación permanecen apagados hasta que ocurre un desastre. En otras palabras, tenemos siempre encendidos los componentes críticos (por ejemplo, base de datos, almacenamiento esencial) en la región de DR, y los componentes de cómputo (servidores web/app) están preparados pero inactivos. Esta “llama piloto” asegura que la infraestructura núcleo esté lista, aunque en estado reducido, permitiendo arrancar rápidamente una copia completa de producción cuando sea necesario.

Ejemplo en AWS: En AWS, una implementación típica de Pilot Light podría ser:

• Base de datos replicada: Mantener una réplica en la región de respaldo. Por ejemplo, un Amazon RDS Read Replica o una Aurora Global Database en la región de DR, continuamente actualizada desde la región primaria. Así, los datos están casi al día (RPO bajo) y la base de datos de respaldo se puede promover a principal en caso de falla (aunque toma unos minutos promover una réplica de RDS estándar).
• Storage replicado: Si la aplicación usa archivos, habilitar S3 Cross-Region Replication para que el bucket de respaldo tenga todos los objetos recientes.
• Servidores “apagados” pero listos: Preparar AMIs de Amazon EC2 con la aplicación instalada y actualizada en la región secundaria, pero no lanzar instancias EC2 hasta el momento del desastre. Alternativamente, mantener instancias EC2 creadas pero detenidas (“stopped”). Por ejemplo, tener grupos de Auto Scaling con tamaño deseado 0 o instancias EC2 apagadas con el último código desplegado. Esto coincide con la recomendación de AWS de no tener servidores activos innecesariamente; usar AMIs y CloudFormation para desplegarlos al momento de “encender” la luz piloto.
• DNS de failover: Configurar Amazon Route 53 con un registro failover o de salud. Todo el tráfico apunta normalmente a la región primaria; si se declara un desastre, Route 53 conmutará el DNS al endpoint de la región secundaria (una vez que se “encienda” la infraestructura allí). Esto puede ser manual (requiere acción humana para evitar conmutaciones en falso) o automático con health checks, según lo crítico que sea el tiempo.

Tiempo de recuperación, costo y complejidad: Pilot Light ofrece RTO y RPO moderados (orden de decenas de minutos) a un costo moderado. Dado que solo la base de datos y unos pocos recursos están continuamente activos, el gasto es menor que en estrategias más agresivas. Sin embargo, tras un desastre se requiere tiempo para arrancar y escalar los servidores de aplicaciones (por eso el RTO no es instantáneo). Comparado con Warm Standby, Pilot Light suele implicar un RTO/RPO más alto (más lento) pero con menos costo, ya que Warm Standby tiene más componentes corriendo todo el tiempo. Aun así, Pilot Light es mucho más rápido que simplemente backup/restore tradicional, porque la infraestructura principal ya está preaprovisionada. En términos de complejidad, Pilot Light requiere mantener IaC y automatizaciones para desplegar en dos regiones, lo cual agrega complejidad operativa, pero es menos complejo que una arquitectura Active-Active.

En el examen (SAA): Debe reconocerse la descripción de Pilot Light. Un escenario de examen podría ser: “Una empresa quiere minimizar costos de DR pero no puede permitirse perder más de ~15 minutos de datos y puede aceptar ~30 minutos de inactividad en caso de desastre”. La solución adecuada sería Pilot Light (datos replicados continuamente + servidores apagados listos para encender). Si la pregunta menciona "mantener una copia mínima de la infraestructura en la región de DR, con base de datos replicada y servidores apagados", claramente se refiere a Pilot Light. También podrían preguntar por la diferencia entre Pilot Light y Warm Standby – recuerde: Pilot Light no atiende tráfico hasta que se encienden/escalan los recursos. Saber que servicios como RDS read replicas, S3 CRR, AMIs y Route 53 Failover son componentes típicos de Pilot Light le ayudará a seleccionar la opción correcta en el examen.

Estrategia Warm Standby (Espera semiactiva)

Definición: Warm Standby es una estrategia de DR activo/pasivo donde se mantiene una copia reducida pero completamente funcional de la infraestructura de producción en otra región, siempre encendida y lista para asumir carga en cualquier momento. A diferencia de Pilot Light, en Warm Standby ya hay servidores de aplicación ejecutándose continuamente en la región de DR – aunque en menor escala – capaces de manejar tráfico de prueba o bajas tasas de usuarios. Esto reduce significativamente el tiempo de recuperación, ya que en caso de desastre no hay que desplegar nuevos recursos desde cero, solo escalar los existentes a nivel de producción. En resumen, Warm Standby extiende el concepto de luz piloto: todo está desplegado y funcionando a pequeña escala, de modo que se puede atender tráfico inmediatamente en la región de respaldo (a capacidad reducida).

Ejemplo en AWS: Una arquitectura Warm Standby en AWS suele incluir:

• Infraestructura duplicada en menor escala: Por ejemplo, si producción en la región primaria usa 4 servidores EC2 en un Auto Scaling Group, la región de DR podría tener 1 servidor EC2 corriendo por capa (web/app) en su ASG. Este servidor está sirviendo un mínimo de tráfico o simplemente en espera. Se pueden incluir también instancias más pequeñas o menos nodos en clústeres (por ejemplo, un Amazon ECS cluster con 1 tarea en DR vs. 4 en producción).
• Base de datos sincronizada: Igual que Pilot Light, los datos están replicados continuamente (RDS read replica, Aurora Global, DynamoDB Global Table, etc.) para asegurar RPO bajo. La diferencia es que aquí la base de datos secundaria podría estar recibiendo algunas lecturas o pequeños workloads. Por ejemplo, en Warm Standby podríamos tener un Aurora Global Database cuyo secundario atiende consultas read-only de baja prioridad regularmente, lo que confirma su funcionamiento continuo.
• Balanceadores y endpoints activos: Se puede configurar Route 53 en modo active-passive, donde el site secundario está “ágil” para tomar tráfico. Incluso es posible enviar una pequeña fracción del tráfico real a la región de respaldo (p. ej., 1%) para validar que esté operativa (esto a veces se llama “pilot light extended”). AWS Global Accelerator o Route 53 con políticas de peso pueden dirigir un porcentaje mínimo de usuarios al sitio standby para mantenerlo probado.
• Escalamiento Rápido: En caso de failover, simplemente se aumenta la capacidad. Por ejemplo, usando EC2 Auto Scaling, se incrementa el Desired Capacity de 1 a 4 instancias en cada grupo para igualar producción. Este escalado puede hacerse manualmente, via script/CLI, o automatizado con métricas. Es crucial asegurarse de que las quotas de servicio en la región DR soporten escalar a los niveles requeridos. También, como nota AWS, depender de Auto Scaling (plano de control) introduce un riesgo: algunos clientes optan por tener “hot standby” con toda la capacidad ya aprovisionada para eliminar incluso ese tiempo de escalado.

Tiempo de recuperación, costo y complejidad: Warm Standby logra RTO y RPO bajos (minutos) a costo más alto que Pilot Light. Puesto que varios componentes están corriendo permanentemente, se incurre en gastos continuos mayores (ej.: instancias EC2, bases de datos activas de menor tamaño, etc.). A cambio, ante un desastre la recuperación es rápida: como todo está pre-desplegado y funcionando, solo se redirige el tráfico y se escala verticalmente u horizontalmente la capacidad. Comparado con Pilot Light, Warm Standby es más caro pero más rápido – Pilot Light requiere encender instancias primero, Warm Standby ya las tiene encendidas recibiendo tráfico ligero. En complejidad operativa, Warm Standby implica mantener dos entornos siempre activos (aunque uno a menor escala), lo que conlleva monitoreo, actualizaciones y pruebas en ambos. Sigue siendo menos complejo y costoso que Active-Active, ya que solo una región maneja usuarios normalmente. Muchas organizaciones ven Warm Standby como un equilibrio: tiempos de recuperación cercanos a producción sin duplicar totalmente los costos de tener todo activo en múltiples regiones.

En el examen (SAA): Deberá identificar Warm Standby en descripciones. Un ejemplo: “Un sistema corre parcialmente en una segunda región a pequeña escala (por ejemplo, un servidor por capa y base de datos replicada) de modo que en un desastre puede escalar rápidamente y asumir la carga”. Esa es la definición de Warm Standby. Preguntas de comparación son comunes: Pilot Light vs Warm Standby (la respuesta: Warm Standby tiene algunos servicios ya funcionando y puede aceptar algo de tráfico inmediatamente, por eso menor RTO, pero cuesta más). También pueden presentar un requerimiento de RTO muy bajo (pocos minutos) pero con presupuesto limitado para no tener un sitio completo activo; Warm Standby sería la estrategia apropiada. El candidato SAA debe reconocer las implicaciones de tener recursos en espera corriendo (por ejemplo, saber que un DNS failover más Auto Scaling rápido encaja con Warm Standby). Recordar la palabra “standby caliente” o “copia reducida activa” puede ayudar a relacionar con esta estrategia en preguntas teóricas.

Estrategia Active-Active (Multi-Active)

Definición: Active-Active Multi-Site es la estrategia de DR más robusta, en la que dos o más regiones operan activamente al mismo tiempo sirviendo tráfico de producción. No existe propiamente un sitio “pasivo”: todas las regiones son primarias. Si una cae, el tráfico simplemente se redistribuye a las restantes sin necesidad de un proceso de failover prolongado. Esta estrategia proporciona RTO ~0 (tiempo de recuperación casi inmediato) y RPO ~0 (pérdida de datos mínima) en la mayoría de escenarios, a costa de ser la más compleja y costosa de implementar. Es esencial implementar sincronización de datos en tiempo real entre regiones y mecanismos avanzados de balanceo geográfico para lograr que la experiencia de usuarios sea uniforme. Active-Active es lo más cercano a “no downtime”, aunque todavía se depende de respaldos para recuperar de corrupciones de datos u otros desastres lógicos (donde el RPO no puede ser cero).

Ejemplo en AWS: Un despliegue Active-Active en AWS podría lucir así:

• Balanceo de tráfico global: Se usaría Amazon Route 53 con routing geográfico, de latencia o peso, o AWS Global Accelerator, para distribuir clientes entre las distintas regiones activas. Por ejemplo, Route 53 puede dirigir a los usuarios de Europa a la región EU (Frankfurt) y a usuarios de América a la región US (Virginia). Si una región falla, Route 53 automáticamente deja de enviarle tráfico (health checks fallidos) y todo se atiende desde la región sobreviviente. AWS Global Accelerator ofrece también un failover casi instantáneo mediante la red global de AWS.
• Datos replicados y consistencia: Aquí está el mayor reto. Se necesita replicación bidireccional o simultánea de datos. Algunas opciones: Amazon DynamoDB Global Tables permite que cada región acepte escrituras en la tabla y las propaga a las demás con consistencia eventual en ~1 segundo. Para bases de datos relacionales, Aurora Global Database soporta lecturas locales en cada región y escrituras “principal en una región” con réplica casi en tiempo real; en Active-Active a veces se usa un patrón “write forwarding” (Aurora puede reenviar escrituras de secundarios al primario). Otros patrones para escrituras globales incluyen particionar por región (cada región maneja cierto subconjunto de datos y replica a las demás) o implementar capas de sincronización custom. En cualquier caso, lograr consistencia de datos multi-región añade complejidad: hay que manejar posibles conflictos de escritura (p. ej., DynamoDB usa “last writer wins” en conflictos).
• Infraestructura duplicada completa: Todos los componentes (EC2, balanceadores, VPC, microservicios, colas, etc.) están desplegados en todas las regiones activas con la misma capacidad que producción. Por ejemplo, si normalmente usamos 10 servidores web, cada región Active-Active podría tener 10 servidores corriendo. Esto asegura que cada región por sí sola podría llevar el 100% de la carga si las otras fallan. Es común usar AWS CloudFormation StackSets o herramientas como AWS CDK para desplegar idéntica infraestructura en múltiples regiones de forma consistente. La arquitectura debe diseñarse para tolerar la pérdida de N-1 regiones.

Tiempo de recuperación, costo y complejidad: Active-Active ofrece el menor RTO posible (casi cero) porque no hay que “recuperar” nada – otra región ya está sirviendo. El RPO también puede ser prácticamente cero si la replicación de datos es síncrona o casi en tiempo real. El costo es el más alto, ya que se efectivamente duplica (o triplica, etc.) todo el entorno en regiones adicionales, y todos esos recursos están activos 24/7. También es la opción más compleja: manejar sincronización de bases de datos distribuidas, enrutamiento inteligente de usuarios, mayor superficie de monitoreo y garantizar coherencia requiere experiencia avanzada. AWS la recomienda solo para cargas críticas que justifican la inversión, o por requisitos estrictos regulatorios o de latencia geográfica. Muchas empresas optan por Active-Active solo tras evaluar que Warm Standby no es suficiente. Si mantener dos regiones activas a pleno rendimiento no aporta valor salvo para DR, a veces se prefiere Warm Standby por menor coste. En resumen: Active-Active = máxima disponibilidad a cambio de máxima inversión.

En el examen (SAA): Es importante identificar cuándo la estrategia Active-Active es la respuesta. Un ítem de examen puede describir una aplicación global que no puede tener tiempo de inactividad ni pérdida de datos perceptible ante la caída de una región – la solución sería despliegue multi-región activo/activo. Debe recordar palabras clave como “múltiples regiones activas sirviendo tráfico” o “usuarios dirigidos a distintas regiones simultáneamente”. También, entender las herramientas: si una opción de examen habla de Route 53 latency-based routing con instancias en 2 regiones o DynamoDB Global Tables multi-región, eso apunta a Active-Active. Preguntas de trade-off también son comunes: ¿Qué estrategia de DR tiene el mayor costo pero el menor downtime? – la respuesta es Active-Active Multi-site. A nivel de SAA, no se espera que diseñe la replicación de datos a detalle, pero sí que sepa que Active-Active implica duplicación completa y sincronización casi instantánea. Reconocer servicios globales (como DynamoDB global, Aurora Global, Route 53, Global Accelerator) asociados a Active-Active le ayudará a identificar esta estrategia en el examen.

Comparativa de estrategias de DR (Pilot Light vs Warm Standby vs Active-Active)

A modo de resumen, comparemos las tres estrategias de recuperación ante desastres mencionadas en términos de tiempo de recuperación, pérdida de datos, costo y complejidad:

• Pilot Light: RTO y RPO de decenas de minutos (debe lanzarse infraestructura adicional al fallar). Costo relativamente bajo (mínimos recursos corriendo: típicamente solo DB y almacenamiento replicados). Complejidad moderada: requiere automatizar despliegues en DR y replicación de datos, pero entorno reducido. Ideal cuando se busca ahorro y se puede tolerar algo de tiempo de inactividad.
• Warm Standby: RTO y RPO del orden de minutos (infraestructura ya corriendo, solo escalar tráfico/capacidad). Costo alto: se mantienen recursos continuamente en dos regiones (aunque a menor escala en la de DR). Complejidad alta pero manejable: dos entornos activos parcialmente, sincronizados, requieren monitoreo y actualización continua. Es un balance entre costo y tiempo de recuperación, adecuado para muchos sistemas que necesitan alta disponibilidad sin llegar al extremo de Active-Active.
• Active-Active: RTO y RPO cercanos a cero (con diseño adecuado, la conmutación es casi instantánea). Costo muy alto, duplicando todo en múltiples regiones activas. Complejidad muy alta: implica arquitecturas globales distribuidas, replicación bidireccional y testing riguroso. Se justifica para aplicaciones críticas donde incluso minutos de caída o datos perdidos son inaceptables.

Estas diferencias suelen aparecer en la documentación oficial de AWS y son fundamentales para decidir la estrategia adecuada. Comprenderlas no solo ayuda en la práctica, sino que también permite responder preguntas de examen donde se plantean escenarios con distintas necesidades de RTO/RPO y restricciones de presupuesto.

Relevancia para el examen AWS Solutions Architect Associate

En el examen SAA, AWS pone especial foco en la resiliencia y alta disponibilidad. Algunos puntos a tener en cuenta para la prueba:

• Conocer definiciones: Espere que le pregunten directamente por qué es RTO y RPO o cuál es la diferencia. Es un conocimiento básico que debe tener preciso. Por ejemplo, una pregunta de opción múltiple podría darle cuatro definiciones y pedir cuál corresponde a RPO.
• Escenarios de DR: Es común que planteen escenarios donde debe elegir la estrategia de DR apropiada. Piense en palabras clave:
  • “Tiempo de recuperación máximo X” y “pérdida de datos máxima Y” → identificar RTO/RPO y mapear a backup/restore, pilot, warm o multi-site según los valores.
  • “Costo es una preocupación principal” + “puede tolerar varias horas de downtime” → probablemente Backup & Restore (no cubierto aquí, pero es la opción más básica). Si dice “downtime moderado aceptable” pero quiere mantener datos recientes, podría ser Pilot Light.
  • “Necesita recuperación casi instantánea, sin prácticamente interrupción” → claramente Active-Active.
  • “Región secundaria con capacidad reducida corriendo” → Warm Standby.
• Servicios y características AWS: El examen puede no mencionar “Pilot Light” o “Warm Standby” por nombre, sino describir configuraciones. Debe asociar:

  • RDS Read Replica cross-region + servidores apagados = Pilot Light.

  • ASG con instancias mínimas en 2ª región + Route 53 Failover = Warm Standby.

  • Route 53 latency routing + Multi-region active DB (DynamoDB Global/Aurora) = Active-Active.

    Saber qué servicios habilitan multi-región y alta disponibilidad (Route 53, RDS Multi-AZ vs Multi-Región, S3 CRR, CloudFront/Global Accelerator, etc.) es clave para eliminar opciones incorrectas en el examen.

• Trade-offs: AWS examina si comprende los compromisos. Por ejemplo, una pregunta teórica: “¿Cuál estrategia de recuperación ante desastres ofrece el menor RTO pero conlleva el mayor costo y complejidad?”. La respuesta será Active-Active. O “¿Qué enfoque permite mantener bajos costos de DR a cambio de un RTO más alto?” → Pilot Light. Este tipo de preguntas evalúa la comprensión de las diferencias.

En resumen, dominar RTO, RPO y las estrategias de DR en AWS no solo le permitirá diseñar arquitecturas resilientes, sino que también es esencial para aprobar el AWS Solutions Architect Associate. Asegúrese de repasar la documentación oficial de AWS sobre Disaster Recovery y prácticas de alta disponibilidad, ya que muchos de estos conceptos provienen directamente de las guías de arquitectura de AWS y son considerados “tema caliente” en el examen. ¡Con estos conocimientos, estará mejor preparado para cualquier pregunta de resiliencia que AWS le presente!