Cae una región y se paraliza media cadena de suministro
La caída de AWS de 2025 muestra cómo las dependencias regionales de la nube pueden poner en riesgo los procesos de las cadenas de suministro.
Un fallo de DNS en la región us-east-1 de AWS desencadenó una cadena de interrupciones de servicios el 20 de octubre de 2025. También se vieron afectadas funciones que dependían de esa región. Para las empresas cuyas cadenas de suministro se apoyan en la nube, es importante saber qué procesos y servicios comparten un punto único de fallo. Un plan de recuperación probado permite identificar estas dependencias.
Lo esencial en breve
- Un fallo de DNS afectó al punto de conexión regional de DynamoDB. La cadena de errores posterior perjudicó a otros servicios de AWS en Virginia del Norte.
- Las dependencias compartidas pueden poner en riesgo los procesos de suministro. Las empresas deben identificar qué aplicaciones y proveedores utilizan los mismos componentes de la nube para operaciones críticas.
- La recuperación debe ajustarse a los objetivos de negocio. Una segunda región puede ayudar si los datos, las dependencias y la conmutación por error se comprueban con regularidad.
Un fallo de DNS desencadenó una cascada de interrupciones
Según el informe del incidente de AWS, el origen fue una condición de carrera en la gestión de DNS de DynamoDB. Esta dejó una entrada DNS vacía para el punto de conexión regional. El sistema automático no pudo corregir el error por sí solo. Como consecuencia, fallaron las nuevas conexiones al punto de conexión afectado.
Tras corregirse el problema de DNS, los sistemas dependientes siguieron afectados. Entre otras cosas, se produjeron problemas al iniciar nuevas instancias EC2. Más tarde, las comprobaciones de estado incorrectas de Network Load Balancer causaron nuevos problemas de conexión. La interrupción inicial del DNS duró casi tres horas y la recuperación de otros servicios se prolongó durante el resto del día.
Las caídas regionales pueden afectar más allá de la región
También se vieron afectadas algunas funciones que dependían de us-east-1, entre ellas funciones de IAM y DynamoDB Global Tables. Por tanto, una aplicación alojada en otra región solo es independiente de la cadena concreta de fallos si los servicios y procedimientos operativos que necesita también están disponibles allí.
Para el análisis no basta con una lista de los servidores propios. También deben incluirse las bases de datos, los servicios de identidad, el DNS, las interfaces y los servicios de los proveedores. Para cada proceso crítico debe quedar claro cuáles de estos componentes se necesitan para su funcionamiento y cuáles para su recuperación.
Las cadenas de suministro necesitan objetivos claros de recuperación
Una caída puede interrumpir, por ejemplo, la recepción de pedidos o el acceso a los datos de inventario si las aplicaciones correspondientes dependen de un componente de nube afectado. El alcance de una interrupción depende del proceso concreto y de las alternativas disponibles.
El departamento de TI y el área de negocio deben definir para cada proceso crítico cuánto tiempo puede permanecer interrumpido y qué pérdida de datos es asumible. El AWS Well-Architected Framework denomina a estos objetivos Recovery Time Objective y Recovery Point Objective. Las pruebas periódicas de recuperación y conmutación por error muestran si la arquitectura elegida permite alcanzarlos.
Evaluar las opciones multirregión y multinube
Una segunda región del proveedor actual puede ser una medida adecuada. Para ello, los datos y la aplicación deben estar disponibles allí y la conmutación no debe depender de un componente que haya dejado de funcionar. Una prueba también debe comprobar si los permisos, las interfaces y las herramientas operativas funcionan en la región de destino.
Un segundo proveedor puede reducir las dependencias adicionales del primero. Al mismo tiempo, supone un esfuerzo de integración y gestión. La solución adecuada depende de los objetivos de recuperación, las dependencias compartidas reales y los recursos disponibles.
Para las entidades financieras incluidas en el ámbito de aplicación de DORA se añade una dimensión jurídica: al prever contratos de servicios de TIC que respalden funciones esenciales o importantes, deben evaluar, entre otros aspectos, los riesgos de concentración. El artículo 29 menciona a los proveedores difíciles de sustituir y la existencia de varios contratos de ese tipo con el mismo proveedor o con proveedores estrechamente vinculados.
Preguntas frecuentes
¿Qué es un riesgo de concentración en la nube?
Un riesgo de concentración surge, por ejemplo, cuando varios procesos críticos dependen del mismo proveedor o de un componente técnico compartido. Si este falla, puede afectar a varios procesos al mismo tiempo.
¿Protege una segunda región de nube frente a una caída?
Puede proteger frente a una caída regional si la aplicación, los datos y las dependencias necesarias están disponibles en la segunda región. Una prueba de conmutación por error comprueba si la recuperación se completa dentro de los objetivos establecidos.
¿Qué exige DORA en materia de riesgo de concentración?
Las entidades financieras incluidas en su ámbito de aplicación deben evaluar, al prever el uso de servicios de TIC para funciones esenciales o importantes, entre otros aspectos, si un proveedor es difícil de sustituir o si existen varios contratos de ese tipo con el mismo proveedor o con proveedores estrechamente vinculados.
Selección editorial
cloudmagazinCopias de seguridad en la nube con IaC: resiliencia frente al riesgo de restauracióncloudmagazinInfraestructuras críticas en la nube: cómo asegurar la migracióncloudmagazinAWS recurre a un agente de IA para investigar las incidenciasMás de la red MBF Media
Digital ChiefsLa apuesta multimillonaria de los hiperescaladores y su factura de la nubeSecurityTodayCuando una llamada detiene la producción de automóvilesFuente de la imagen: generada por IA (julio de 2026)
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
