RTO, RPO y niveles de recuperación ante desastres

El Recovery Time Objective (RTO) es el tiempo máximo aceptable desde que ocurre un desastre hasta que el sistema vuelve a estar operativo. Si su RTO es de 4 horas, su empresa puede tolerar 4 horas de inactividad. El Recovery Point Objective (RPO) es la cantidad máxima aceptable de pérdida de datos, medida en tiempo; si su RPO es de 1 hora, debe poder recuperarse hasta un punto que no sea anterior al desastre en más de 1 hora. Ambas métricas se definen según los requisitos empresariales, no según preferencias técnicas.

AWS define cuatro estrategias principales de recuperación ante desastres, ordenadas desde el menor coste y el RTO más alto hasta el mayor coste y el RTO más bajo: 1) Backup and Restore — la opción más económica, con un RTO de horas. 2) Pilot Light — el núcleo mínimo está siempre en ejecución, con un RTO de minutos a horas. 3) Warm Standby — una versión reducida pero funcional, con un RTO de minutos. 4) Multi-Site Active-Active — la opción más costosa, con un RTO cercano a cero. Su elección depende del coste empresarial de la inactividad frente al coste de la infraestructura de recuperación ante desastres.

Con Backup and Restore, se realizan periódicamente snapshots de los datos y se almacenan en otra ubicación (por ejemplo, en S3 con replicación entre regiones). En caso de desastre, se restaura el backup más reciente. Esta es la estrategia más económica porque no requiere ejecutar una infraestructura en espera. La desventaja es el RTO más largo (horas para restaurar bases de datos grandes a partir de snapshots) y el RPO más alto (se pierden los datos generados desde el último backup). AWS Backup automatiza las programaciones de snapshots en EC2, RDS, EFS, DynamoDB y otros servicios.

La estrategia Pilot Light mantiene los componentes principales del sistema en ejecución en una región de recuperación ante desastres, con una capacidad mínima, como una llama piloto que puede avivar rápidamente una llama completa. Normalmente, esto implica replicar continuamente la base de datos en la región de recuperación ante desastres y mantener una infraestructura de red básica (VPC, subredes y grupos de seguridad). Los servidores de aplicaciones NO están en ejecución, pero se pueden iniciar rápidamente a partir de AMI o plantillas de lanzamiento previamente creadas. El RTO suele ser de 30 minutos a varias horas, según la cantidad de trabajo manual necesaria.

La estrategia Warm Standby ejecuta una copia completamente funcional y reducida del entorno de producción en la región de recuperación ante desastres. A diferencia de Pilot Light, la capa de aplicación está en ejecución (quizás con 1 o 2 instancias en lugar de 20) y la base de datos es una instancia secundaria de Aurora Global Database o una réplica de lectura de RDS. Durante la conmutación por error, se escala el entorno de recuperación ante desastres hasta igualar la capacidad de producción. El RTO suele ser inferior a 15 minutos. Esta es la estrategia de recuperación ante desastres más habitual para cargas de trabajo de criticidad media o alta.

Multi-Site Active-Active ejecuta simultáneamente la capacidad total de producción en dos o más regiones. Todas las regiones atienden tráfico real y los datos se replican casi en tiempo real (o mediante un esquema multimaestro). No existe retraso de conmutación por error: cuando una región falla, Route 53 o Global Accelerator dirige inmediatamente todo el tráfico a las regiones saludables restantes. Esto proporciona el RTO y el RPO más bajos, pero también el coste más alto, ya que se paga la capacidad total de producción en todas las regiones en todo momento.

Su RPO determina directamente qué tecnología de replicación necesita. RPO = 0 requiere replicación síncrona: no se pierde nada. Un RPO de segundos requiere replicación asíncrona casi en tiempo real, como Aurora Global Database (<1s de retraso). Un RPO de minutos permite la replicación asíncrona con un retraso pequeño (DynamoDB Streams, réplicas de lectura de RDS). Un RPO de horas se puede lograr mediante snapshots periódicos (programación horaria de AWS Backup). Establezca claramente el requisito de RPO de su empresa antes de elegir una tecnología.

Las arquitecturas sin servidor (Lambda, DynamoDB y API Gateway) son naturalmente más resistentes, pero aun así requieren una planificación de recuperación ante desastres. DynamoDB Global Tables proporciona una configuración activa-activa entre varias regiones para la capa de base de datos. Lambda se puede implementar en una segunda región desde el mismo pipeline de CI/CD. API Gateway debe aprovisionarse en la región de recuperación ante desastres. El principal riesgo es la desviación de configuración entre regiones; utilice AWS CDK o Terraform para implementar una infraestructura idéntica en ambas regiones a partir de la misma base de código.

Considere una empresa con ingresos anuales de 10 millones de dólares. Si la inactividad cuesta 1.000 dólares por minuto, una interrupción de 8 horas (RTO=8h) cuesta 480.000 dólares. Un entorno Warm Standby activo-pasivo con un RTO de 15 minutos reduce la pérdida potencial a 15.000 dólares por incidente. Si el entorno en espera cuesta 5.000 dólares al mes (60.000 dólares al año), solo resulta económicamente conveniente si se produce más de una interrupción significativa al año. Este análisis de justificación de costes es exactamente lo que el examen SAA-C03 le pide realizar al seleccionar estrategias de recuperación ante desastres.

Un plan de recuperación ante desastres que nunca se ha probado no es más que un documento. AWS recomienda encarecidamente realizar simulacros de recuperación ante desastres con regularidad: practique los procedimientos de conmutación por error, mida el RTO y el RPO reales e identifique las deficiencias. Utilice AWS Fault Injection Simulator (FIS) para simular una degradación regional de forma controlada. Documente runbooks con los pasos de conmutación por error para que, bajo la presión de un incidente real, el equipo de guardia siga un procedimiento claro y probado en lugar de improvisar.

Muchos sectores tienen requisitos normativos de recuperación ante desastres. PCI DSS exige planes de recuperación ante desastres documentados y sometidos a pruebas. HIPAA exige procedimientos de backup de datos y recuperación ante desastres. SOC 2 evalúa los controles de disponibilidad, incluida la recuperación ante desastres. Utilice AWS Config y AWS Audit Manager para evaluar y documentar continuamente que sus recursos de recuperación ante desastres (backups, réplicas y comprobaciones de estado) estén configurados correctamente. Esto proporciona evidencias para las auditorías de cumplimiento sin necesidad de recopilarlas manualmente.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que: el RTO es el tiempo de inactividad máximo aceptable y el RPO es la pérdida de datos máxima aceptable, los cuatro niveles de recuperación ante desastres equilibran el coste y la velocidad de recuperación y el requisito de RPO determina qué tecnología de replicación debe utilizar. Pruebe siempre su plan de recuperación ante desastres para validar el RTO y el RPO reales. A continuación, analizaremos en detalle la estrategia de copia de seguridad y restauración.