AWS ha dicho, con todas las letras, que hay datos de clientes que no se van a recuperar. No es un corte de servicio largo ni una degradación: es que el dato ya no está.
Qué ha pasado
En una actualización de su panel de estado, AWS confirma que todo lo que estuviera alojado exclusivamente en su región de Baréin —me-south-1— sigue siendo inaccesible y que, después de evaluarlo, no puede restaurar el acceso. La explicación oficial es que los daños en la infraestructura afectaron a varias zonas de disponibilidad a la vez y superaron aquello para lo que están diseñados los servicios regionales y multi-AZ.
La secuencia, según cuenta The Register, importa más que el titular:
- Marzo: se daña la primera zona de disponibilidad de Baréin. AWS recomienda a los clientes mover sus cargas a otras regiones.
- Abril: nuevos ataques afectan a una segunda zona y la región entera queda no disponible.
- Septiembre: AWS da por irrecuperables los recursos que solo vivían allí.
En Emiratos la conclusión es parcial pero igual de dura: la zona mec1-az2, una de las tres de esa región, tampoco se recupera. Dos instalaciones del país fueron alcanzadas por drones en marzo. Sobre las otras dos zonas —mec1-az1 y mec1-az3— AWS dice que sigue trabajando. Y añade que «la mayoría de clientes» ha podido reanudar operaciones en otras regiones restaurando copias o copiando lo que aún era accesible. Preguntada por The Register, la empresa no quiso añadir nada a lo publicado en el panel.
Ojo a esa expresión: «la mayoría». Ahí dentro está la minoría que no ha podido.
Por qué importa
El radio de daño que asumías no era el real
AWS lo recomienda desde siempre y está en su documentación de infraestructura global: reparte la aplicación entre varias zonas de disponibilidad para sobrevivir a la pérdida de una ubicación. Eso funciona, y funciona bien, para lo que ocurre casi siempre: un incendio, un corte de alimentación, una inundación, una chapuza en el mantenimiento de un edificio. No funciona cuando el evento es regional.
Lo que he visto muchas veces en auditorías es la confusión entre las dos cosas. Una base de datos con réplica en otra AZ, un balanceador en tres zonas, y en el documento de continuidad pone «alta disponibilidad: sí». Eso no es un plan de recuperación ante desastres. Es tolerancia a fallo de un edificio. El plan empieza cuando la respuesta a «¿y si la región completa desaparece?» no es un silencio.
El aviso llegó, y duró semanas
Este es para mí el detalle más útil de toda la noticia. Entre el primer daño y la pérdida de la región pasó un mes. AWS avisó, y la mayoría se movió. Los que esperaron a ver si el servicio volvía se quedaron sin nada.
De ahí sale una tarea concreta, y no es técnica: escribe el disparador antes de necesitarlo. Quién decide evacuar una región, con qué señal, y cuánto tiempo se espera antes de dar el dato por perdido. Si esa decisión hay que improvisarla en caliente, con el cliente llamando, se retrasa. Siempre se retrasa.
Repasa dónde vive de verdad tu copia
En AWS casi todo es regional por defecto, y eso se olvida. Merece la pena comprobar, con la consola delante:
- Copias de seguridad. Un bucket de S3 vive en una región; una snapshot de EBS o RDS, también. Si no hay una copia explícita a otra región, tu copia se muere con el original.
- Claves de cifrado. Una clave de KMS no sale de su región. Una copia cifrada que llegue a un destino sin clave utilizable es un fichero bonito e inservible.
- Registro de imágenes. ECR es regional. Si tus contenedores solo están ahí, en el destino no tienes con qué arrancar.
- El estado de tu infraestructura como código. El clásico: el
tfstateen un bucket de la región caída. Sabes desplegar todo con un comando, pero el comando no sabe qué había. - Tu propio CI/CD y tus secretos. Si el pipeline que reconstruye vive dentro de lo que se ha perdido, no reconstruyes.
La residencia del dato y la resiliencia tiran en direcciones opuestas
Esta es la parte incómoda. Si tu regulador exige que los datos no salgan del país, tu copia de seguridad también está en el país, y el evento que te tumba la región te tumba la copia. No hay solución técnica limpia: hay que decidir, por escrito y con el cliente o el departamento legal delante, qué se cifra y se saca fuera, qué se queda dentro y qué se acepta perder. Que esa conversación esté documentada vale más que cualquier diagrama.
Qué NO cambia
Esto no es un argumento contra la nube. Un centro de datos propio en esa misma ciudad estaría igual de destruido, solo que sin nadie con quien restaurar en otro continente en horas. Quien use esta noticia para vender vuelta a hierro propio está contando otra historia.
Multi-AZ sigue mereciendo la pena. Cubre el fallo frecuente, que es el que te va a pasar de verdad. Lo que no se puede es llamarlo como no es.
No toda carga necesita multi-región activo-activo. Es caro y complica mucho. Para muchísimos sistemas, un plan del tipo «restauramos en otra región desde copias en dos días» es perfectamente válido —a condición de haberlo probado una vez, de verdad, con cronómetro. Un plan sin ensayo es una intención.
Y una precisión que en los resúmenes se pierde: AWS no ha dicho que la región de Emiratos esté perdida. Ha dado por irrecuperable una de sus tres zonas y sigue trabajando en las otras dos. La lectura catastrofista tampoco es exacta.
Si quieres, lo miramos con tu cuenta delante: en una tarde se ve si tus copias están donde crees. Cualquier duda me dices y lo vemos.
Un saludo, Vicente.