Recuperación entre regiones y lo que falta al llegar

La replicación continua entre regiones da un RPO muy bajo: lo que se escribe en una región aparece en la otra casi al instante. Esa misma virtud es su límite. Si un proceso defectuoso sobrescribe datos con basura, o alguien cifra los objetos, el origen cambia y la réplica recibe el cambio igual que cualquier otro. La réplica protege de perder la región, no de perder los datos por una orden válida pero equivocada.

Por eso la guía de AWS sobre recuperación ante desastres pide combinar la replicación con copias a un punto en el tiempo o con versionado: la réplica da el RPO bajo y la copia da el camino de vuelta a un estado anterior.

Las claves de cifrado de AWS KMS son por región: una clave normal existe en la región donde se creó. Existen las claves multirregión, que comparten identificador y material entre regiones, pero hay que crearlas así desde el principio y AWS no las replica nunca por su cuenta. Una copia cifrada con una clave de una sola región llega a la región de recuperación como datos que nadie puede descifrar allí.

En el escritorio, lee copia-db-pagos.txt para saber con qué clave está cifrada la copia de la base y paridad.txt para saber si esa clave existe en la región de recuperación.

Las cuotas de una cuenta son por región, y las de una región que nunca ha tenido cargas son las iniciales. El plan de una luz piloto o de una espera tibia da por hecho que, al subir la capacidad, la región de recuperación aceptará la carga; esa suposición se rompe con un error de cuota justo cuando hay prisa. El guion de recuperación debe incluir, por eso, que las cuotas de la región de recuperación estén ya subidas, y comprobarlo con regularidad.

Abre cuotas.txt. El plan pide la misma capacidad que usa hoy producción en la región de trabajo.

Conmutar cambia un registro DNS, y el cambio no llega a todos a la vez: cada cliente conserva la respuesta anterior hasta que vence su TTL. Un registro con TTL de una hora añade hasta una hora al RTO aunque todo lo demás sea instantáneo. La regla es sencilla: el TTL debe ser bastante menor que el RTO del servicio que el registro apunta, y se ajusta antes del desastre, no durante.

Abre dns.txt y pasa los TTL de segundos a minutos. Compara cada uno con el RTO del servicio que figura en la misma fila.

Una conmutación automática por alarma suena más segura que una decisión a mano, y no siempre lo es. Incluso con buenas prácticas, la recuperación tiene un RTO y un RPO mayores que cero, así que una conmutación por falsa alarma cuesta disponibilidad y datos sin necesidad. Por eso muchas organizaciones dejan la decisión en una persona y automatizan los pasos, de modo que decidir sea pulsar un botón. Además, los pasos que deben funcionar durante el desastre conviene que sean los de plano de datos —como un cambio de DNS con comprobaciones de salud—, más fiables que los de plano de control, como lanzar recursos nuevos.

Lee plan-de-conmutacion.txt: el plan de Calamar decide a mano, y deja los pasos 3 a 5 escritos como guion.