Logística y cadena de suministro

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…

Por Andreas Knols 12 julio 2026 5 min de lectura

Una región cae, la mitad de la cadena de suministro se detiene

El 20 de octubre de 2025, una parte de Internet se detuvo. Slack, Snapchat y Atlassian no fueron accesibles durante horas; las tiendas en línea perdieron pedidos y los servicios logísticos no pudieron procesar envíos. El detonante estaba en una única región de AWS en la costa este de EE. UU. La interrupción revela una verdad incómoda: la concentración en la nube no es solo un tema de TI, sino un riesgo en la cadena de suministro.

Qué ocurrió en us-east-1

La interrupción comenzó con un pequeño error en la gestión de DNS del servicio de base de datos DynamoDB. Una condición de carrera generó un registro DNS vacío para el punto final regional. El sistema automático no lo reparó. DNS es el libro de teléfonos de Internet. Si el registro estaba vacío, las aplicaciones simplemente ya no podían encontrar la base de datos.

Del problema inicial con DynamoDB se derivó una cascada de fallos. Las instancias EC2 ya no pod iniciarse, las funciones Lambda y las tareas de Fargate fallaron, y los balanceadores de carga y los servicios de contenedores cayeron junto con ellos. Lo que comenzó como una interrupción de base de datos de tres horas se prolongó durante más de 15 horas hasta que todos los servicios dependientes volvieron a funcionar.

Por qué una región paraliza medio mundo

us-east-1 no es cualquier región. Es la región de AWS más antigua y grande, 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 ejecutan centralmente a través de us-east-1. Si esta región falla, también lo notan los clientes que creen estar alojados en otro lugar.

Aquí radica el error de pensamiento de muchos planes de contingencia. Una empresa puede distribuir su aplicación limpiamente entre varias regiones y aun así verse afectada porque el nivel de control está concentrado en una sola región. La disponibilidad en papel no es lo mismo que la disponibilidad en situaciones reales.

El problema de la cadena de suministro detrás de la caída de TI

Para la logística y el comercio, una interrupción de este tipo no es un problema técnico abstracto. La gestión de almacenes, el seguimiento de envíos, la recepción de pedidos y el procesamiento de pagos se ejecutan cada vez más a través de servicios en la nube. Si la nube cae, la cadena de suministro física también se detiene. Una hora de inactividad puede costar a un comerciante de tamaño medio una cantidad de cinco dígitos en euros, y mucho más a empresas mayores.

Los reguladores han tomado conciencia de ello. Con DORA para el sector financiero y NIS2 de forma más amplia, el riesgo de concentración está adquiriendo protagonismo. En el futuro, las empresas deberán demostrar que conocen y controlan su dependencia de proveedores y regiones individuales. Una referencia genérica a la nube ya no es suficiente.

Por qué la multi-nube a menudo no es una protección real

El reflejo tras un fallo de este tipo es la multi-nube. Sin embargo, operar con dos proveedores en paralelo duplica inicialmente la complejidad y los costes, no la seguridad automáticamente. Si la dependencia real reside en un nivel de control compartido o en un servicio centralizado, tener un segundo proveedor ayuda poco.

Es más sensato plantearse la pregunta honesta sobre qué servicios son realmente críticos y qué dependencias reales tienen. Para la mayoría de las pymes, una configuración limpia de multi-región con el proveedor actual es el primer paso mejor que un costoso proyecto de segunda nube, en el que nadie ha practicado en caso de emergencia.

Qué debería revisar ahora la TI logística

Tres preguntas deben estar sobre la mesa. Primero: ¿Cuáles de nuestros procesos se detienen si falla una única región de la nube? Segundo: ¿Tenemos dependencias ocultas de servicios centrales como IAM o DNS, que están concentrados regionalmente? Tercero: ¿Hemos probado alguna vez el failover en condiciones reales, no solo en la presentación?

Quien no pueda responder a estas preguntas, no tiene un concepto de resiliencia, sino una esperanza. El fallo de octubre de 2025 fue un recordatorio caro de que la nube no asume la responsabilidad por la disponibilidad, sino que solo la desplaza.

Preguntas frecuentes

¿Qué es un riesgo de concentración en la nube?

Un riesgo de concentración surge cuando demasiados procesos críticos dependen de un único proveedor, una región o un servicio central. Si ese punto falla, colapsa desproporcionadamente mucho. El fallo de AWS de octubre de 2025 es un ejemplo didáctico de ello.

¿Por qué us-east-1 tuvo consecuencias tan graves?

us-east-1 es la región de AWS más antigua y grande y alberga funciones de control global de las que dependen otras regiones, como actualizaciones de IAM y tablas globales de DynamoDB. Un fallo allí repercute mucho más allá de la propia región.

¿Protege la multi-nube contra estos fallos?

No automáticamente. La multi-nube duplica la complejidad y los costes, pero no elimina una dependencia que reside en un servicio central compartido. Para muchas empresas, una configuración de multi-región probada con el proveedor actual es el primer paso mejor.

¿Qué exige la regulación al respecto?

DORA en el sector financiero y NIS2 de forma más amplia exigen que las empresas conozcan y gestionen sus dependencias de proveedores y regiones individuales. Una referencia genérica a la nube ya no basta; el riesgo de concentración debe documentarse y controlarse.

¿Cómo pruebo correctamente mi resiliencia en la nube?

Solo un failover practicado en condiciones reales es un verdadero failover. Simule el fallo de toda una región y compruebe qué procesos se detienen y qué dependencias ocultas aparecen. Una documentación de failover sin pruebas es solo una lista de deseos.