Una región cae, la mitad de la cadena de suministro se detiene
Un riesgo de concentración en la nube es un riesgo de cadena de suministro. Lo que enseña la caída de us-east-1 y por qué un entorno de varias regiones…
El 20 de octubre de 2025, parte de internet se paralizó. Slack, Snapchat y Atlassian estuvieron inaccesibles durante horas, las tiendas online perdieron pedidos y los servicios de logística no pudieron procesar envíos. El origen del problema se encontraba en una única región de AWS en la costa este de EE.UU. El fallo deja al descubierto una verdad incómoda: la concentración en la nube no es solo un tema de TI, sino un riesgo para la cadena de suministro.
Lo más importante en resumen
- Basta con una región. El fallo de AWS de octubre de 2025 comenzó con un registro DNS vacío en us-east-1 y dejó fuera de servicio durante más de 15 horas a Slack, Snapchat y miles de tiendas online.
- La concentración es un riesgo para la cadena de suministro. La gestión de inventarios, el seguimiento de envíos y el procesamiento de pagos dependen de la nube. Si la nube falla, la cadena de suministro física también se detiene.
- La multi-nube rara vez es la solución. Un segundo proveedor duplica la complejidad y los costes, no la seguridad. Para la mayoría de las pymes, un sistema probado con múltiples regiones es el primer paso más adecuado.
Relacionado:Separar NIS2 y DORA de forma limpia: clústeres de cumplimiento en Kubernetes / Copias de seguridad en la nube con IaC: resiliencia en lugar de riesgos de restauración
Qué ocurrió en us-east-1
El fallo comenzó con un error mínimo en la gestión DNS del servicio de bases de datos DynamoDB. Una condición de carrera generó un registro DNS vacío para el punto de conexión regional. El sistema automático no lo reparó. DNS es la guía telefónica de internet. Si el registro estaba vacío, las aplicaciones simplemente ya no encontraban la base de datos.
Lo que empezó como un problema en DynamoDB se convirtió en una cascada. No se podían iniciar instancias de EC2, las funciones Lambda y las tareas de Fargate fallaban, y los equilibradores de carga y los servicios de contenedores también caían. Lo que comenzó como una interrupción de tres horas en la base de datos se prolongó más de 15 horas hasta que todos los servicios dependientes volvieron a funcionar.
Por qué una región paraliza a medio mundo
us-east-1 no es una región cualquiera. Es la más antigua y grande de AWS y alberga funciones de control de las que dependen otras regiones. Ciertos servicios globales, como las actualizaciones de IAM o las tablas globales de DynamoDB, se gestionan de forma centralizada desde us-east-1. Si esta región falla, los clientes que creen alojarse en otro lugar también lo notan.
Aquí reside el error de concepto de muchos planes de contingencia. Una empresa puede distribuir su aplicación correctamente en varias regiones, pero seguir dependiendo de una capa de control concentrada en una sola región. La tolerancia a fallos en el papel no es lo mismo que la tolerancia a fallos en una situación real.
El problema de la cadena de suministro tras el fallo informático
Para la logística y el comercio, un fallo así no es un problema técnico abstracto. La gestión de inventarios, el seguimiento de envíos, la recepción de pedidos y el procesamiento de pagos dependen cada vez más de servicios en la nube. Si la nube falla, la cadena de suministro física también se detiene. Una hora de inactividad puede costarle a un minorista mediano cinco cifras en euros, y mucho más a empresas más grandes.
Los reguladores ya lo han reconocido. Con DORA para el sector financiero y NIS2 en un ámbito más amplio, el riesgo de concentración está ganando protagonismo. Las empresas deberán demostrar en el futuro que conocen y gestionan su dependencia de proveedores y regiones individuales. Una mera referencia genérica a la nube ya no será suficiente.
Por qué la multi-nube a menudo no es una protección real
El reflejo tras una caída así suele ser la multi-nube. Sin embargo, operar con dos proveedores en paralelo no duplica automáticamente la seguridad, sino que primero incrementa la complejidad y los costes. Si la dependencia real reside en un nivel de control compartido o en un servicio centralizado, un segundo proveedor aporta poco.
Más sensato es plantearse con honestidad qué servicios son realmente críticos y qué dependencias reales tienen. Para la mayoría de las pymes, configurar correctamente un entorno multi-región con el proveedor actual es un primer paso mejor que un costoso proyecto de segunda nube que nadie ha probado en un escenario real.
Qué debería revisar ahora la TI logística
Tres preguntas deben ponerse sobre la mesa. En primer lugar: ¿qué procesos nuestros se paralizarían si falla una sola región de la nube? En segundo lugar: ¿tenemos dependencias ocultas de servicios centrales como IAM o DNS, concentrados en una región? Y en tercer lugar: ¿hemos probado alguna vez el failover en condiciones reales, y no solo en una presentación?
Quien no pueda responder a estas preguntas no tiene un concepto de resiliencia, sino una esperanza. La caída de octubre de 2025 fue un recordatorio caro de que la nube no exime de la responsabilidad en cuanto a la disponibilidad, sino que solo la traslada.
Preguntas frecuentes
¿Qué es un riesgo de concentración en la nube?
Un riesgo de concentración se produce cuando demasiados procesos críticos dependen de un único proveedor, una región o un servicio centralizado. Si ese punto falla, se produce un colapso desproporcionado. La caída de AWS en octubre de 2025 es un ejemplo paradigmático de ello.
¿Por qué la región us-east-1 fue tan crítica?
us-east-1 es la región más antigua y grande de AWS, y alberga funciones de control global de las que dependen otras regiones, como actualizaciones de IAM y tablas globales de DynamoDB. Por eso, un fallo allí tiene un impacto que trasciende la propia región.
¿Protege la multi-nube frente a este tipo de fallos?
No automáticamente. La multi-nube duplica la complejidad y los costes, pero no elimina las dependencias que residen en un servicio centralizado compartido. Para muchas empresas, configurar correctamente un entorno multi-región con el proveedor actual es un primer paso mejor.
¿Qué exige la regulación al respecto?
DORA en el sector financiero y NIS2 en un ámbito más amplio exigen que las empresas conozcan y gestionen sus dependencias de proveedores y regiones individuales. Ya no basta con una mención genérica a la nube; el riesgo de concentración debe documentarse y controlarse.
¿Cómo pruebo correctamente la resiliencia de mi nube?
Solo un failover que se haya practicado en condiciones reales es un verdadero failover. Simule la caída de una región completa y compruebe qué procesos siguen funcionando y qué dependencias ocultas aparecen. Una documentación de failover sin prueba es solo una lista de deseos.
Recomendaciones de lectura de la redacción
- KRITIS en la nube: qué garantiza la migración
- AWS y Azure bajo supervisión de la UE: el bloqueo se tambalea
- Broker en la nube: un 30 % menos de costes en entornos multi-nube
Más del grupo MBF Media
Más de la red MBF Media
MyBusinessFutureEstancamiento inversor: cómo la IA desbloquea presupuestos ocultosDigital ChiefsLa apuesta millonaria de los hyperscalers y tu factura en la nubeSecurityTodayCuando una llamada detiene la producción de cochesFuente de la imagen de portada: Generada por IA (julio 2026)
