Recuperación ante desastres en AWS con IaC multi-región

En los últimos años, la resiliencia ha pasado de ser un “nice to have” a un requisito crítico para cualquier plataforma digital. Los fallos regionales, aunque poco frecuentes, existen, al igual que los problemas derivados de errores humanos, y cuando ocurren, el impacto en el negocio puede ser enorme si no se está preparado.

En este artículo quiero compartir un proyecto reciente y exitoso en el que, desde Unikal Tech Partners, automatizamos la recuperación completa de un entorno AWS desplegado en una región primaria (Región A) hacia una región secundaria (Región B), utilizando Infraestructura como Código (IaC) y servicios nativos de AWS.

Recuperación ante desastres en AWS: objetivos, retos y entorno real 

El principal objetivo marcado era claro: recuperar la plataforma de forma rápida, repetible y sin intervención manual. Incluso ante un fallo grave de toda una región.

El reto principal era el siguiente: recuperación regional sin improvisación.

El entorno original en la Región A incluía, principalmente, los siguientes elementos:

• Aplicaciones desplegadas sobre EC2 detrás de Application Load Balancers
• Bases de datos gestionadas en Amazon RDS
• Almacenamiento de objetos en Amazon S3
• Servicios de colas (Amazon SQS) y notificaciones (Amazon SNS)
• Configuración de red con VPC, subredes, gateways y reglas de seguridad
• Servicios de seguridad y cumplimiento debido a que se trata de un entorno certificado ENS (Esquema Nacional de Seguridad) Alto

Lógicamente, al ser un entorno crítico productivo, se tuvieron en cuenta las dependencias críticas entre servicios. Una de las premisas principales marcadas por el cliente era la siguiente:

“Si la región deja de estar disponible, no queremos reconstruir el entorno a mano.”

Principales desafíos en la recuperación ante desastres multi-región

Los principales desafíos a los que se enfrentaba el CIO de la compañía eran los siguientes:

• Reducir el RTO (Recovery Time Objective) real, ya que no era posible cumplir con el RTO requerido si se continuaba trabajando con la metodología actual de trabajo seguida en la recuperación de desastres
• Minimizar errores humanos en un escenario de crisis, bien sea por no tener disponibilidad de los recursos con el conocimiento necesario para volver a levantar el entorno o por cometer errores ante una situación de crisis en la que el negocio presiona por una solución inmediata.
• Garantizar que la infraestructura en la Región B fuese idéntica y consistente, ya que los SLA comprometidos con sus clientes no permitían que el ecosistema sufriese una degradación de servicio. EN caso de producirse, se aplicarían penalizaciones económicas.
• Poder probar el plan de recuperación sin afectar a la producción, de manera periódica y con garantías de que los resultados son realistas.
• Poder realizar la adaptación del plan de recuperación ante los cambios que pudiese sufrir el ecosistema productivo, de una manera fácil y controlada, garantizando que el entorno desplegado en la Región B siempre será idéntico al entorno en la Región A

Estrategia de recuperación ante desastres automatizada con IaC en AWS

Dentro de las diferentes opciones que tenemos a la hora de realizar un Disaster Recovery, optamos por una estrategia multi‑región activa/pasiva, donde la Región B permanece preparada para levantar el entorno completo bajo demanda. A pesar de la criticidad del entorno, teniendo en cuenta el compromiso entre RTO, RPO y costes recurrentes, se descartaron las modalidades activo-activo.

Los pilares de la solución fueron:

Resultados reales de la recuperación ante desastres automatizada

Gracias a este enfoque, el cliente consiguió:

• Recuperar el entorno completo en la Región B en minutos
• Reducir drásticamente el RTO frente a un despliegue manual
• Eliminar errores humanos en momentos críticos
• Probar el plan de DR de forma periódica y segura
• Tener documentación viva: el propio código es la documentación

Además, el uso de IaC permitió optimizar costes, ya que la Región B solo consume recursos mínimos (almacenamiento y backup) hasta que se activa el plan de recuperación.

5 Lecciones clave en proyectos de recuperación ante desastres en AWS 

Algunas conclusiones clave del proyecto:

1. Si no está automatizado, no es un DR real
2. Infraestructura como Código no es solo para despliegues, es una herramienta de resiliencia.
3. Probar el DR es tan importante como diseñarlo
4. Un DR desactualizado no es un DR útil
5. AWS proporciona todos los servicios necesarios, pero el valor está en cómo se integran

Conclusión

La recuperación ante desastres no debe ser un documento olvidado en un cajón. Debe ser un proceso vivo, probado y automatizado. AWS, combinado con Infraestructura como Código, permite construir soluciones de alta disponibilidad y recuperación regional de forma elegante, segura y eficiente.

Si tu plataforma todavía depende de pasos manuales para recuperarse de un fallo grave, probablemente no esté tan preparada como crees. Te invitamos a que, desde Unikal Tech Partners, revisemos tu Plan de Recuperación de Desastres en AWS y podamos analizar si realmente cumple con los SLA marcados por negocio.