Cuando una empresa evalúa su plan de recuperación ante desastres, la conversación suele empezar por la tecnología. Es el orden equivocado. La decisión de disaster recovery empieza con dos números que define el negocio: cuánto tiempo puede estar caído cada sistema y cuántos datos puede perder. Todo lo demás — la arquitectura, la región de recuperación, el presupuesto — se deriva de esas dos respuestas.
AWS define cuatro estrategias oficiales de disaster recovery, ordenadas en un espectro de menor a mayor costo y de mayor a menor tiempo de recuperación. Esta guía las compara con criterios de decisión para gerentes de tecnología y de riesgo, no solo para arquitectos.
Los dos números que mandan: RTO y RPO
- RTO (Recovery Time Objective): el tiempo máximo aceptable entre la interrupción y la restauración del servicio. Es la pregunta “¿cuánto podemos estar caídos?”.
- RPO (Recovery Point Objective): la antigüedad máxima aceptable de los datos al recuperar. Es la pregunta “¿cuántas horas o minutos de transacciones podemos perder?”.
Estos números no los define TI: los define el costo de cada hora de indisponibilidad para el negocio. Un canal de ventas digital, un core transaccional y un sistema interno de reportes tienen RTO y RPO muy distintos — y por eso rara vez comparten la misma estrategia.
Las 4 estrategias oficiales de AWS
1. Backup & Restore
Los datos y las configuraciones se respaldan de forma periódica hacia la región de recuperación. Ante un desastre, la infraestructura se levanta desde cero y se restauran los respaldos. Es la estrategia de menor costo permanente — solo pagas almacenamiento de respaldos — y la de mayor tiempo de recuperación: típicamente horas, tanto de RTO como de RPO.
Funciona bien para cargas que toleran indisponibilidad prolongada: ambientes internos, sistemas de reporting, aplicaciones de baja criticidad.
2. Pilot Light
La “llama piloto” queda siempre encendida: los datos se replican de forma continua a la región de recuperación y los recursos centrales están aprovisionados, pero los servidores de aplicación permanecen apagados o sin desplegar. Ante un evento, se encienden y escalan los componentes que faltan.
El RTO y el RPO bajan a decenas de minutos, con un costo permanente moderado: replicación de datos más la infraestructura mínima. Es el punto de entrada más común para cargas de negocio importantes que no justifican un ambiente duplicado corriendo.
3. Warm Standby
En la región de recuperación corre una copia funcional completa del ambiente de producción, a escala reducida. Todo está desplegado y funcionando; ante un desastre solo hay que escalar y redirigir el tráfico.
El RTO y el RPO se miden en minutos. El costo permanente es mayor — hay un ambiente real corriendo todo el tiempo — pero la recuperación deja de depender de levantar infraestructura bajo presión.
4. Multi-sitio activo-activo
La carga corre simultáneamente en dos o más regiones, y todas atienden tráfico en condiciones normales. Ante la falla de una región, el tráfico se redirige a las demás sin proceso de “recuperación” propiamente dicho.
El RTO se acerca a cero y el RPO puede ser cercano a tiempo real. Es la estrategia de mayor costo y complejidad operativa, reservada para cargas donde cada minuto de indisponibilidad tiene un costo que la justifica: pagos, canales digitales de banca, comercio electrónico de alto volumen.
Comparación de un vistazo
| Estrategia | RTO / RPO típico | Qué está corriendo en la región de recuperación | Costo relativo |
|---|---|---|---|
| Backup & Restore | Horas | Nada: solo respaldos almacenados | $ |
| Pilot Light | Decenas de minutos | Datos replicados e infraestructura mínima; aplicación apagada | $$ |
| Warm Standby | Minutos | Copia funcional completa a escala reducida | $$$ |
| Multi-sitio activo-activo | Cercano a cero | Producción completa atendiendo tráfico | $$$$ |
Cómo elegir: el costo de la caída decide
La pregunta correcta no es “¿qué estrategia es mejor?” sino “¿cuánto le cuesta al negocio cada hora de este sistema caído?”. Con esa cifra, la decisión se vuelve financiera:
- Si la hora caída cuesta menos que mantener un ambiente duplicado, backup & restore o pilot light son racionales.
- Si la caída de un canal crítico se mide en clientes perdidos, incumplimientos o sanciones, warm standby o activo-activo se pagan solos.
- Clasifica las cargas en niveles y asigna a cada nivel su estrategia. Pagar activo-activo para todo es tan mala decisión como proteger el core con solo backups.
En sectores regulados de la región — banca y seguros bajo supervisión de la SBS en el Perú o de la CMF en Chile — la continuidad del negocio es además una expectativa del regulador: planes documentados, objetivos de recuperación definidos y evidencia de pruebas periódicas. La estrategia de disaster recovery deja de ser un tema interno de TI y pasa a ser parte del expediente de cumplimiento.
El plan que no se prueba no existe
Dos servicios de AWS elevan la madurez del plan más allá de la arquitectura:
- Amazon Application Recovery Controller (ARC) coordina el failover de forma controlada: verifica que la región de recuperación esté realmente lista y ejecuta el cambio de enrutamiento con controles explícitos, en lugar de depender de decisiones manuales bajo presión.
- AWS Fault Injection Service (FIS) permite practicar el desastre antes de que ocurra: inyecta fallas controladas — la base del chaos engineering — para validar que la recuperación funciona y que el equipo sabe ejecutarla.
La diferencia entre un plan en un documento y una capacidad real es el ensayo. Los reguladores lo saben, y los incidentes también.
Dónde ubicar la recuperación desde Perú y Chile
Para empresas de Perú y Chile, hoy la región de referencia es AWS Virginia: catálogo completo de servicios, escala y el enlace de fibra más directo desde la región. Y con la llegada de la región AWS Santiago — ya anunciada por AWS — el par natural será Santiago como región principal, por cercanía, latencia baja y residencia de datos, con Virginia como sitio de recuperación y separación geográfica real frente a un evento que afecte a Sudamérica. Diseñar ese par con paridad garantizada entre ambas regiones es el corazón de nuestra práctica de arquitectura multi-región — y esa paridad, en la práctica, se sostiene con infraestructura como código.
Empezar por el diagnóstico, no por la arquitectura
El primer paso no es elegir estrategia: es saber qué tan resiliente es hoy tu arquitectura y qué RTO y RPO puede cumplir realmente. Una revisión Well-Architected sobre el pilar de confiabilidad entrega exactamente eso: los riesgos priorizados y la distancia entre el plan que está escrito y la capacidad que existe.
Preguntas frecuentes
¿Qué estrategia necesita mi empresa? La que dicten el RTO y el RPO de cada carga — definidos por el costo de negocio de la caída, no por la tecnología disponible.
¿Pilot light o warm standby? Pilot light replica datos con la aplicación apagada (recupera en decenas de minutos); warm standby mantiene una copia funcional a escala reducida (recupera en minutos).
¿El backup ya es DR? Es la base, no el plan: falta dónde restaurar, en cuánto tiempo y con qué ensayo.
¿Tu plan de recuperación resistiría una prueba hoy?
Conversemos sobre tu continuidad de negocio y te decimos, con evidencia, qué RTO y RPO puede cumplir tu arquitectura actual.
