RPO y RTO en AWS: cómo definirlos sin adivinar
Cuando se pregunta cuánta pérdida de datos tolera un negocio, la primera respuesta es casi siempre «ninguna». Cuando se muestra lo que cuesta esa respuesta, aparece una segunda mucho más matizada. Este artículo explica cómo llegar directo a la segunda: qué significan RPO y RTO, cómo derivarlos de tu operación en lugar de inventarlos, y qué arquitectura de AWS exige cada nivel.
Las dos preguntas que hay detrás de las siglas
Son dos medidas distintas y se confunden todo el tiempo. Una habla de datos, la otra de tiempo.
RPO — Recovery Point Objective
¿Cuántos datos podés permitirte perder? Se mide hacia atrás desde el incidente. Un RPO de 4 horas significa que, en el peor caso, se pierde el trabajo de las últimas 4 horas.
RTO — Recovery Time Objective
¿Cuánto puede estar caído el servicio? Se mide hacia adelante. Un RTO de 2 horas significa que debés volver a operar dentro de las 2 horas siguientes al incidente.
Se pueden combinar de formas que parecen contradictorias y no lo son. Un sistema contable puede tolerar estar caído toda una tarde (RTO alto) pero no perder ni un asiento (RPO cercano a cero). Una plataforma de contenidos puede ser lo opuesto: tiene que estar arriba siempre, pero perder los últimos comentarios no es grave.
El error más caro: confundir backup con recuperación
Tener backups configurados y tener capacidad de recuperación no son lo mismo, y la diferencia solo se descubre el día del incidente.
Un backup responde a «¿existe una copia?». La recuperación responde a «¿en cuánto tiempo vuelvo a operar con esa copia?». Entre una y otra hay una cadena entera de cosas que pueden fallar:
- El snapshot existe, pero nadie documentó en qué orden se levantan los servicios que dependen de él.
- La base de datos restaura bien, pero la aplicación apunta a un endpoint que ya no existe.
- La copia está en la misma región que se cayó.
- Quien conocía el procedimiento ya no trabaja en la empresa.
- La restauración funciona, pero tarda seis horas y el RTO comprometido era de una.
Por eso un RPO y un RTO solo son reales si se probaron. Un objetivo que nunca se ejecutó de punta a punta es una intención, no un compromiso.
Cómo derivar tus números del negocio
No se eligen en una reunión técnica. Se calculan preguntando cuatro cosas a quien conoce la operación, sistema por sistema — porque no todos merecen el mismo nivel.
1. ¿Qué se deja de poder hacer si este sistema no está?
Facturar, despachar, atender pacientes, dar clase. Si la respuesta es «nada urgente», ya sabés que no necesita el nivel más caro.
2. ¿Cuánto cuesta cada hora sin ese sistema?
Sumá ingreso no facturado, personal detenido, penalizaciones contractuales y costo de rehacer el trabajo manualmente. Ese número es el techo de lo que tiene sentido invertir en evitarlo.
3. ¿Se puede reconstruir lo perdido desde otra fuente?
Si las transacciones también quedan en el correo del cliente o en un sistema del banco, tu RPO real es más laxo de lo que parece. Si el dato solo vive ahí, no hay margen.
4. ¿Hay algo que te obligue por fuera?
Un contrato con SLA, un requisito sectorial o una exigencia de tu propio cliente pueden fijarte el número sin que sea negociable.
Los cuatro patrones de recuperación en AWS
AWS organiza las estrategias de recuperación en cuatro patrones. Cada uno consigue un rango distinto de RPO y RTO, y cuesta en proporción. La elección no es cuál es mejor, sino cuál corresponde a los números que sacaste arriba.
| Patrón | RPO | RTO | Costo |
|---|---|---|---|
| Backup y restauración | Horas | Horas a días | El más bajo |
| Pilot light | Minutos | Decenas de minutos | Bajo |
| Warm standby | Segundos | Minutos | Medio a alto |
| Multi-sitio activo-activo | Cerca de cero | Cerca de cero | El más alto |
Backup y restauración
Copias periódicas con AWS Backup hacia S3, y restauración manual cuando hace falta. No hay nada corriendo en el sitio de respaldo.
Cuándo corresponde: Sistemas internos, entornos de desarrollo, o cargas donde perder medio día de trabajo es molesto pero no crítico.
Pilot light
Los datos se replican de forma continua, pero el cómputo está apagado. Ante un incidente se encienden las instancias y se escala.
Cuándo corresponde: La operación puede parar un rato, pero perder transacciones no es aceptable.
Warm standby
Una copia reducida del entorno corre permanentemente y atiende una fracción del tráfico. Ante un fallo se escala y toma todo.
Cuándo corresponde: Comercio electrónico, plataformas con usuarios concurrentes, sistemas que facturan mientras están arriba.
Multi-sitio activo-activo
Dos regiones atienden tráfico al mismo tiempo. Si una cae, la otra absorbe sin intervención.
Cuándo corresponde: Servicios financieros, salud crítica, o cuando el costo de un minuto caído supera con claridad el de la infraestructura duplicada.
Qué te da AWS de fábrica, y qué hay que construir
Buena parte del trabajo ya está resuelto por servicios administrados. Vale la pena saber qué RPO alcanza cada uno antes de diseñar algo a mano.
- RDS con recuperación a un punto en el tiempo: permite volver a cualquier segundo dentro del periodo de retención configurado. Es de lo más económico para bajar el RPO.
- RDS Multi-AZ: réplica sincrónica en otra zona de disponibilidad con conmutación automática. Cubre la caída de una zona, no la de una región completa.
- S3 con replicación entre regiones: copia los objetos a otra región de forma asíncrona. Es la base para que un plan multi-región sea viable.
- AWS Backup: centraliza las políticas de copia y retención de varios servicios en un solo lugar, en vez de tener reglas sueltas por recurso.
- Infraestructura como código: lo que más suele alargar el RTO no es restaurar los datos, sino reconstruir el entorno. Tener la infraestructura descrita en código convierte horas de trabajo manual en una ejecución.
Probarlo, que es la parte que casi nadie hace
Un plan de recuperación sin ensayo es una hipótesis. La prueba no tiene que ser dramática: se elige un sistema, se define el escenario, y se ejecuta el procedimiento midiendo el reloj.
Medí el tiempo real, no el estimado
Desde que se declara el incidente hasta que el servicio atiende usuarios. Incluí el tiempo de decidir, de encontrar el documento y de que alguien conteste el teléfono — en un incidente real también cuentan.
Que lo ejecute quien no lo diseñó
Si el procedimiento solo funciona con la persona que lo escribió, no es un procedimiento: es conocimiento en una sola cabeza, y esa es exactamente la dependencia que un plan de recuperación debería eliminar.
Anotá la diferencia y ajustá
Si el RTO comprometido era de 2 horas y la prueba tomó 5, hay dos caminos honestos: invertir para bajarlo, o corregir el compromiso. Dejarlo escrito como si nada es la única opción mala.
Por dónde empezar si hoy no tenés nada
No hace falta resolver todo de una vez. El orden que menos fricción genera es este:
- Listá tus sistemas y ordenálos por lo que cuesta cada hora sin ellos.
- Asigná RPO y RTO solo a los tres primeros. El resto puede esperar.
- Comprobá qué patrón cubre hoy tu configuración actual — muchas veces ya estás en «backup y restauración» sin haberlo decidido.
- Hacé una prueba real del sistema más crítico y medí el tiempo.
- Recién ahí decidí si hay que subir de patrón, con un número medido y no una intuición.
Si querés saber qué RPO y RTO permite hoy tu configuración actual en AWS —antes de comprometerte con un número frente a un cliente— podemos revisarlo.
Solicitar una revisión de resiliencia