Porque las interrupciones no avisan.
RPO y RTO definidos como requisito de negocio, implementados en una de las cuatro estrategias de DR de AWS y probados periódicamente.
Casi toda empresa tiene backup. Pocas saben cuánto tiempo tardarían en volver a operar, y menos aún lo han probado. Esa es la diferencia entre backup y disaster recovery: el backup es una copia de los datos; el DR es la capacidad comprobada de retomar la operación dentro de un plazo que el negocio acepta. Sin prueba, no tienes DR: tienes una expectativa.
Todo empieza por dos números que son decisión de negocio, no de TI. El RPO (Recovery Point Objective) define cuántos datos aceptas perder, medido en tiempo. El RTO (Recovery Time Objective) define cuánto tiempo aceptas estar fuera de servicio. Esos dos números determinan la arquitectura y el coste. AWS recomienda definir un número pequeño de clases de RPO y RTO y encajar las aplicaciones en ellas, en lugar de negociar caso por caso.
AWS organiza el DR en cuatro estrategias, de menor a mayor coste y complejidad: backup y restauración; pilot light, con RPO en minutos y RTO en decenas de minutos; warm standby, con RPO en segundos y RTO en minutos; y multi-site activo/activo. Un detalle técnico que cambia el resultado: AWS divide sus servicios en data plane y control plane, y recomienda usar solo operaciones de data plane en el procedimiento de failover, porque el data plane tiene una meta de disponibilidad mayor que el control plane.
Si reconoces dos o más de estos escenarios, vale la pena conversar.
Diagnóstico inicial sin coste
La composición exacta depende de tu entorno y de los requisitos levantados en el diagnóstico. Esta es la base de lo que usamos en esta solución.
Punto central para configurar, programar y monitorear el backup de EBS, EC2, RDS, Aurora, DynamoDB, EFS, Storage Gateway y las familias FSx, con copia entre cuentas y entre regiones
Replicación continua con recuperación en una región secundaria, base de las estrategias pilot light y warm standby
Replicación asíncrona y continua de objetos hacia la región de DR
Protección contra eliminación y alteración indebida: mitigación directa para error humano y ransomware
Infraestructura como código, sin la cual reconstruir el entorno en la región de DR se vuelve lento y propenso a error
Redirección de tráfico en el failover con health checks y políticas de enrutamiento
Validación continua de si el entorno realmente cumple las metas de RTO y RPO declaradas
Automatización de restauraciones periódicas y de pruebas de recuperación
Retención inmutable, impidiendo que los backups sean borrados incluso por una credencial privilegiada
Mapeamos las aplicaciones y definimos clases de RPO y RTO junto con las áreas de negocio. No todo necesita warm standby, y pagar por eso en todo el portafolio es desperdicio.
Comparamos el RPO y RTO que el entorno actual entrega con lo que el negocio exige. La diferencia entre ambos es el alcance real del proyecto.
Asignamos a cada clase una de las cuatro estrategias de AWS, equilibrando coste y riesgo. Un sistema de facturación y un portal interno rara vez merecen la misma arquitectura.
Configuramos políticas de backup, replicación y el procedimiento de failover. Donde es posible, usamos solo operaciones de data plane en el camino crítico de la recuperación.
Ejecutamos el failover en un entorno controlado y medimos el RTO y RPO reales. Este es el paso que la mayoría de los proyectos se salta y es justamente lo que transforma un plan en una capacidad.
Establecemos un calendario de pruebas y documentamos el procedimiento de vuelta a la región primaria. Un entorno de DR sin prueba periódica acumula desvíos de configuración hasta dejar de funcionar.
Tiempo real de retomada verificado en prueba, no el número estimado en una hoja de cálculo
Pérdida de datos efectiva verificada en el ejercicio de recuperación
Porcentaje de recursos críticos bajo política activa y verificada
Restauraciones exitosas sobre el total intentado en las pruebas
Referencias de mercado documentadas por AWS en escenarios equivalentes. Cada tarjeta lleva a la historia original publicada en el sitio de AWS.
El proceso de failover manual de la solución legada de identificación, mantenida on-premises, dejaba a los empleados sin acceso a los sistemas por hasta 30 minutos. La empresa reconstruyó el mecanismo de failover con Amazon CloudWatch.
Resultado publicado
AWS publicó la reducción del tiempo de failover de 30 minutos a 3 minutos.
En el mismo programa de migración apoyado por AWS MAP, la empresa trató el disaster recovery como parte del alcance, y no como un proyecto posterior.
Resultado publicado
Según AWS, hubo mejora en las capacidades de seguridad y de disaster recovery.
Los cases anteriores son historias de clientes publicadas por Amazon Web Services. Los resultados citados pertenecen a las empresas mencionadas y sirven como referencia de lo que es técnicamente alcanzable en AWS. No representan resultados entregados por Núvoli ni garantía de desempeño equivalente, ya que cada entorno tiene su propio contexto.
Nuestro enfoque no es una opinión. Sigue lo prescrito y documentado por AWS, y puedes verificar la fuente.
El primer paso es un diagnóstico del escenario actual, sin coste y sin compromiso. Sales de él con los riesgos mapeados y las prioridades definidas, incluso si decides no seguir con Núvoli.
