AWS confirma la pérdida permanente de datos de clientes en Emiratos y Bahréin
La compañía admite que los ataques a sus centros de datos en Oriente Medio superaron lo que su arquitectura multi-AZ estaba diseñada para resistir, y que parte de la información no se puede recuperar.
AWS ha confirmado que parte de los datos de sus clientes en Oriente Medio no se pueden recuperar. Los ataques militares contra sus centros de datos de Emiratos Árabes Unidos y Bahréin provocaron daños que, según la propia compañía, exceden lo que sus servicios regionales y su arquitectura multi-AZ estaban diseñados para soportar. La actualización llegó el 15 de septiembre en su panel de estado, la primera comunicación pública desde abril.
En Emiratos (me-central-1) se da por perdida una de las tres zonas de disponibilidad, mec1-az2; las otras dos siguen en proceso de recuperación. Bahréin (me-south-1) está peor: ninguna de sus tres zonas se puede recuperar. AWS sostiene que evaluó toda la infraestructura afectada y usó las alternativas disponibles para salvar datos y recursos antes de que la región dejara de funcionar. Dicho de otro modo: no es que sigan intentándolo, es que ya no hay nada que sacar de ahí.
Tres ataques, no uno
El calendario explica por qué el desenlace era previsible. El 1 de marzo, drones iraníes alcanzaron dos edificios en Emiratos y dañaron estructuras en Bahréin. En abril, un segundo impacto se llevó por delante otra zona de disponibilidad y tumbó la región entera. El 24 de julio, el IRGC lanzó misiles contra el edificio que seguía en pie, algo confirmado con imágenes por satélite.
AWS venía recomendando a sus clientes que movieran las cargas a otras regiones desde abril, y asegura que la mayoría lo hizo antes de que la región dejara de estar disponible. Los datos perdidos son los de quien no migró: clientes sin copia de seguridad ni réplica en otra región.
El agua, no solo los misiles
El daño estructural cortó la alimentación eléctrica y obligó a tareas de extinción, que a su vez provocaron daños por agua. Un informe surcoreano citado en la cobertura lo dice sin rodeos: parte del daño físico vino del agua usada para apagar el fuego. Los sistemas de respaldo energético, de protección contra inundaciones y de extinción están pensados para accidentes, no para un edificio alcanzado por fuego y luego encharcado.
La hipótesis de multi-AZ se rompe
El diseño habitual (zonas de disponibilidad repartidas y la aplicación sigue viva si una cae) asume fallos escalonados, no una misma acción militar que arrasa las tres a la vez. Eso es justo lo que AWS reconoce que ocurrió.
Lo que sí ha funcionado: tener los datos en otra región. La compañía ayudó a clientes a reconstruir operaciones en regiones alternativas a partir de sus copias. De ahí salen tres deberes. Uno, el backup tiene que estar en otra región, no en otra zona: las tres zonas comparten emplazamiento físico. Dos, hay que probar la restauración real, no solo que la copia se genere. Tres, conviene saber qué datos viven en un único sitio, porque eso es lo que estaba en riesgo.
Queda por ver cuándo vuelven las dos regiones. AWS habla de "los próximos meses" para Emiratos y de principios de 2027 para Bahréin, sin fecha cerrada. Mientras, los Emiratos revisan sus planes de centros de datos de IA: repartir emplazamientos, construir parte bajo tierra, hormigón resistente a explosiones y sistemas de intercepción de drones y misiles. Hay más contexto en la cobertura de Ars Technica. Tras el primer ataque, AWS otorgó 150 millones de dólares en créditos a clientes y condonó la factura de marzo en la región de Emiratos.
La pregunta que deja el caso no es de proveedor, sino de diseño: qué nivel de riesgo se le supone a la infraestructura donde guardas tus datos. Entre el 1 de marzo y el 15 de septiembre pasaron seis meses y medio para averiguar que una parte no volvía. Si tu organización tardara lo mismo en descubrirlo, ¿cuánto aguantaría el negocio?
