Tu nube aguanta perder una zona. AWS acaba de perder una región

El martes 15 de septiembre AWS actualizó su panel de estado del servicio. No fue una nota de prensa ni un análisis posterior: fue una línea de texto administrativo. Decía que, tras una evaluación a fondo, no puede restaurar el acceso a los recursos y datos alojados exclusivamente en esa región. Esa palabra —exclusivamente— es la que separa a los clientes que han perdido datos de forma permanente de los que se han llevado un susto largo.

Hasta donde alcanza la cobertura pública, es la primera vez que un hiperescalar da por perdida una región entera a causa de un ataque militar. Conviene leer despacio qué dijo exactamente, porque casi todo lo que hace falta saber para revisar tu propia casa ya estaba publicado antes de que pasara nada.

Lo que pasó, en seco

En marzo de 2026, durante la guerra con Irán, hubo ataques con drones que alcanzaron instalaciones de AWS en Emiratos Árabes Unidos y dañaron físicamente infraestructura en Baréin. En abril cayó una segunda zona en Baréin. Seis meses después, el 15 de septiembre, AWS publicó el resultado: la región de Baréin (me-south-1) no se recupera, y en Emiratos tampoco se recupera una de las tres zonas de disponibilidad, la identificada como mec1-az2.

La frase técnica de AWS, la que explica el porqué, es esta: «The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand.» El daño abarcó varias zonas de disponibilidad y superó lo que los servicios regionales y multi-AZ están diseñados para soportar.

Una guerra no se cuenta en zonas de disponibilidad, y lo primero que deja detrás no son datos. No vamos a opinar aquí sobre el conflicto, ni sobre quién disparó: no es nuestro tema y no nos corresponde. Lo que sí nos corresponde es lo que viene justo después de esa frase técnica, porque es literalmente nuestro oficio: mirar una infraestructura y decir qué pasa si desaparece un trozo. Y ahí hay una lección que aplica igual a una empresa de Sabadell con dos servidores que a un banco del Golfo.

Porque AWS también dijo esto: la mayoría de clientes reanudaron operaciones en otro sitio, restaurando desde copias o accediendo a los datos que seguían siendo accesibles. Los que no han perdido nada no tuvieron más suerte. Tenían algo fuera.

El perímetro estaba publicado desde el principio

Todo el mundo del sector se sabe el número de la durabilidad de S3: once nueves, 99,999999999%. Se cita en reuniones como si fuera una propiedad del dato, igual que su tamaño o su formato. Casi nadie abre la página de donde sale, y ahí está el problema: las dos frases que lo acompañan son las que definen de qué está hablando ese número.

La primera: las clases de almacenamiento estándar «redundantly store objects on multiple devices across a minimum of three Availability Zones in an AWS Region». Un mínimo de tres zonas de disponibilidad dentro de una región de AWS. La segunda, el objetivo de diseño, en singular: están «designed to sustain data in the event of the loss of an entire Amazon S3 Availability Zone». La pérdida de una zona entera. Una.

Y hay un tercer dato en el mismo párrafo que casi nadie cita, y es el más revelador de los tres. Las zonas «are physically separated by a meaningful distance, many kilometers, from any other Availability Zone, although all are within 100 km (60 miles) of each other». Están separadas por una distancia significativa, varios kilómetros, pero todas a menos de 100 kilómetros unas de otras.

Cien kilómetros es una distancia excelente contra un incendio, una inundación, un corte de suministro o un albañil con una radial. Es una distancia razonable contra un terremoto local. Y es una distancia que, contra ciertos tipos de suceso, no significa nada, porque el suceso es más grande que el radio. Eso no es un fallo de AWS: es exactamente lo que AWS escribió que hacía. La frase del panel de estado cierra el círculo con una precisión casi incómoda: el daño superó lo que los servicios regionales y multi-AZ están diseñados para soportar. El diseño no falló. Se salió del perímetro que el propio diseño publica.

Es la misma trampa que ya hemos contado con otra ropa: dos cosas duplicadas solo son dos si no comparten el punto que puede fallar. La redundancia no es un número de copias: es una lista de cosas que pueden pasar sin que te enteres.

El reparto del trabajo está en el contrato, con título propio

La documentación de Amazon EBS abre el capítulo de snapshots con un recuadro marcado como Important que no admite interpretación: «AWS does not automatically back up the data stored on your EBS volumes. For data resiliency and disaster recovery, it is your responsibility to create EBS snapshots on a regular basis, or to set up automatic snapshot creation by using Amazon Data Lifecycle Manager or AWS Backup.» AWS pone las herramientas para automatizarlo; poner la copia en marcha es tuyo.

Y cuando explica dónde vive ese snapshot, repite el perímetro: «Snapshot data is automatically replicated across all Availability Zones in the Region.» Por todas las zonas de la región. El snapshot que haces cada noche, el que te da tranquilidad, está por defecto dentro del mismo perímetro que el dato original. Te protege del error humano, del borrado, del ransomware y de perder una zona. No te protege de perder la región, salvo que lo copies a otra a propósito.

El contrato dice lo mismo con lenguaje de abogado. El AWS Customer Agreement tiene una sección entera, la 2.3, titulada «Your Security and Backup»: «You are responsible for properly configuring and using the Services and otherwise taking appropriate action to secure, protect and backup your accounts and Your Content in a manner that will provide appropriate security and protection, which might include use of encryption to protect Your Content from unauthorized access and routinely archiving Your Content.»

Y la sección 11.3, Force Majeure, lista qué eventos eximen de responsabilidad. Entre acts of God, terremotos, cortes eléctricos y disturbios, al final de la enumeración, con todas sus letras: «acts of terrorism, or war». La palabra estaba escrita en el contrato años antes de que hiciera falta.

Por si quedaba duda de qué se cobra cuando algo va mal, el SLA de cómputo lo cierra por los dos lados. Por un lado, el remedio: «Unless otherwise provided in the Agreement, this SLA sets forth your sole and exclusive remedies, and AWS' sole and exclusive obligations, for any unavailability, non-performance, or other failure by us to provide Amazon EC2.» Créditos de servicio, y nada más. Por otro, la exclusión, que en el original enumera los dos SLA y sus supuestos: los SLA «…do not apply to any unavailability, suspension or termination of Amazon EC2… caused by factors outside of our reasonable control, including any force majeure event…» En un caso de fuerza mayor, el SLA directamente no aplica.

AWS ha sido generoso al margen de todo eso: condonó la facturación de uso de marzo en las regiones afectadas y suspendió el cobro mientras duró la situación, un gesto que Forbes estimó en abril en unos 150 millones de dólares —es una estimación periodística, no una cifra que AWS haya publicado—. No lo contamos como reproche, sino por el contraste: un crédito compensa una factura. No compensa un dato. Y nadie ha pretendido nunca que lo hiciera; está escrito que no lo hace.

Esto no va de AWS

La lectura fácil de esta noticia es «ves, el cloud». Es una lectura mala y además cómoda, porque le ahorra al que la hace tener que mirar lo suyo. Un hiperescalar publica su perímetro de diseño con nombre, kilómetros y objetivo de durabilidad. Tu sala de servidores no publica nada de eso, y eso no significa que no tenga perímetro: significa que no lo has escrito.

Los perímetros que más nos encontramos en visitas reales: el NAS de copias en el mismo armario que el servidor que copia. El segundo nodo del clúster en el rack de al lado, conectado al mismo cuadro eléctrico. La copia externa que sale, sí, pero a un disco que vive en el mismo edificio dentro de un cajón. Y el caso más común de todos, que ni siquiera se percibe como una decisión: el correo y los ficheros en Microsoft 365, sin ninguna copia fuera de Microsoft, porque «ya está en la nube».

Lo repetimos a menudo porque es el eje de todo lo que hacemos: el fallo es inevitable, la avería es una decisión de diseño. Un disco que se muere es un fallo. Que por eso tu almacén no saque pedidos es una avería, y la diferencia entre las dos cosas la decidió alguien hace años, cuando eligió dónde poner la segunda copia. La redundancia se construye por capas —disco, máquina, sala— y cada capa cubre lo de abajo. Lo que ha hecho AWS esta semana es enseñar la capa de encima, la que casi nadie dibuja porque parecía teórica: la región.

Las cuatro preguntas que escribimos en una hoja

No es una lista de buenas prácticas. Es literalmente lo que apuntamos, en este orden, cuando entramos en una empresa a revisar continuidad. Cuatro preguntas, y las cuatro se contestan con un nombre propio o con un número, nunca con un adjetivo.

1. Si desaparece la SALA entera, ¿qué se queda sin volver? No el disco, no el servidor, no el nodo: la sala, el edificio, el sitio. Es la pregunta que casi nadie se hace en voz alta porque suena catastrofista, y es la única que ordena todas las demás. La respuesta es una lista de sistemas, no un «bueno, tendríamos las copias».
2. ¿Dónde está la copia que NO comparte esa sala? Nombre del sitio, a cuántos kilómetros, en qué proveedor, quién tiene las credenciales para leerla. Si la respuesta es «está en la nube», la pregunta sigue en pie: en qué región, y si esa región es la misma donde corre el sistema. Si ambas respuestas coinciden, tienes una copia, no dos sitios.
3. ¿Cuánto se tarda en estar operativo desde ahí? Cronometrado, no estimado. Y con fecha: cuándo fue la última vez que alguien puso el cronómetro. Una restauración que nadie ha hecho no tiene RTO, tiene una esperanza. Un plan de continuidad que nadie ha ensayado es un documento, y los documentos no arrancan servidores.
4. Si el perímetro se rompe, ¿quién responde? Esta es de contrato, no de arquitectura, y es la que suele estar sin contestar. Abre el acuerdo de tu proveedor —el que sea— y busca dos palabras: backup y fuerza mayor. Vas a encontrar, casi seguro, que la primera te señala a ti y que la segunda le exime a él. Eso no es una estafa: es el reparto del trabajo, y conviene conocerlo el día que firmas y no el día que falla algo.

Lo que AWS le recomienda a sus propios clientes

Conviene decirlo porque desmonta la caricatura: nada de esto es un descubrimiento nuestro ni una crítica al proveedor. Está en el documento técnico de recuperación ante desastres que publica el propio AWS, y la frase es explícita: «If your definition of a disaster goes beyond the disruption or loss of a physical data center to that of a Region or if you are subject to regulatory requirements that require it, then you should consider Pilot Light, Warm Standby, or Multi-Site Active/Active.»

Es decir: si para ti un desastre puede ser perder una región entera, copia y restauración dentro de la región no es tu estrategia. Y el mismo documento avisa de que la más ambiciosa de las cuatro, multi-site activo/activo, «is the most complex and costly approach to disaster recovery». Ese matiz es tan importante como el anterior: la mayoría de las empresas con las que trabajamos no necesita activo/activo, y venderlo sería vender humo. Lo que sí necesita todo el mundo es saber en qué casilla está y haberlo decidido, en lugar de acabar en una casilla por acumulación de decisiones pequeñas.

Y una nota del mismo documento, en un recuadro, que podríamos haber firmado nosotros: «Your backup strategy must include testing your backups.»

Lo que hacemos nosotros, y lo que no vamos a prometerte

En los sistemas que operamos, la recuperación se cronometra. El último simulacro de recuperación completa que hicimos se resolvió en 14 minutos. Es un dato interno de una prueba nuestra, sobre una infraestructura concreta y con un procedimiento concreto: es una prueba, no una promesa, y no significa que tu caso vaya a tardar eso. Significa que el número existe y tiene fecha, que es exactamente lo que le falta a la mayoría de planes de continuidad que nos encontramos.

Lo que no vamos a decirte es «con nosotros estás a salvo». Nuestro datacenter también es un sitio. Es una sala con una dirección postal, un cuadro eléctrico y un tejado, igual que el tuyo y que el de AWS. Un colocation no deja de ser un punto en un mapa por el hecho de que lo operemos nosotros. Por eso, en los diseños que firmamos, la segunda copia también sale de nuestro perímetro: otra ubicación, y cuando el caso lo pide, otro proveedor y otra tecnología. No vendemos la desaparición del riesgo, que no existe. Vendemos que el riesgo esté escrito, repartido y ensayado.

Hay una frase que decimos mucho: un backup sin probar no es un backup, es un amuleto. Los clientes de AWS que han vuelto son los que tenían algo fuera y sabían cómo leerlo. Y hay otra lección incómoda que ya vimos con el caso de la empresa a la que desconectar le costó 101 minutos y reconectarse nueve días: romper es rápido; volver, no. Por eso la pregunta útil no es cuánto tardas en perder algo, sino cuánto tardas en tenerlo otra vez.

Lo que no afirmamos

No decimos que AWS haya incumplido nada, ni que sus servicios sean poco fiables: decimos que el perímetro de su diseño está publicado y que el suceso lo superó, que es lo que la propia AWS escribió. No sabemos qué clientes concretos perdieron datos, ni cuántos, ni de qué tipo; AWS no lo ha publicado y nosotros no lo vamos a suponer. No sabemos si los afectados tenían o no copias fuera de la región, salvo por la afirmación general de AWS de que la mayoría de clientes reanudó operaciones en otro sitio. No hemos operado cargas en me-south-1 ni en la región de Emiratos, así que no contamos experiencia propia de esas regiones. Tampoco hemos leído el contrato concreto de ningún cliente afectado: las cláusulas que citamos son las públicas y generales, y un acuerdo empresarial negociado puede decir otra cosa. Y no somos parte interesada en la elección de proveedor: no revendemos AWS, ni Azure, ni Google Cloud, ni licencias de ninguno.

Nota de fuentes

Todo consultado el 19 de septiembre de 2026. Uno, el suceso: la actualización del panel de estado del servicio de AWS del 15 de septiembre de 2026, recogida por Reuters y por la prensa técnica internacional, de donde salen las dos citas literales —«The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand» y «we are unable to restore access to the resources and data hosted exclusively in…»—, la identificación de la región de Baréin (me-south-1) y de la zona mec1-az2 en Emiratos, las fechas de marzo y abril de 2026, y la afirmación de que la mayoría de clientes reanudó operaciones en otro sitio restaurando desde copias. La estimación de los 150 millones de dólares procede de Forbes, en abril de 2026, sobre la condonación de la facturación de marzo. Dos, el perímetro de diseño: la página Data protection in Amazon S3 de la documentación oficial (los once nueves, el mínimo de tres zonas dentro de una región, el objetivo de sostener la pérdida de una zona entera y la distancia de menos de 100 km entre zonas) y la página Amazon EBS snapshots (el aviso de que AWS no hace copia automática y de que la responsabilidad es del cliente, y la replicación del snapshot por todas las zonas de la región). Tres, el contrato: el AWS Customer Agreement, secciones 2.3 Your Security and Backup y 11.3 Force Majeure, y el Amazon Compute Service Level Agreement, apartados Credit Request and Payment Procedures y Amazon Compute SLA Exclusions. Cuatro, la recomendación del fabricante: el documento técnico Disaster Recovery of Workloads on AWS, capítulo Disaster recovery options in the cloud. Lo que es opinión nuestra, y va marcado como tal en el cuerpo: la lectura de que el problema no es el diseño sino que casi nadie lee el perímetro publicado; la lista de perímetros que nos encontramos en visitas; las cuatro preguntas; y la insistencia en que nuestro propio datacenter es también un punto en un mapa. Los datos de everyWAN —el simulacro de 14 minutos y la distinción entre fallo y avería— salen de nuestro material interno de resiliencia.

Imagen de portada: fotografía aérea del corredor de centros de datos de Ashburn (Virginia), de Wikimedia Commons, dominio público / CC0, recortada por nosotros. Los textos y la marca los añadimos encima.