Cuando la nube nos falla: lo que dejaron las caídas de AWS y Azure —y cómo blindar el negocio

Luis Gorgona

Socio de Consultoría y Auditoría de TI en RSM Costa Rica

Desde la salida del concepto llamado computación en la nube, hace ya unos 15 años, más y más empresas y profesionales, han decidido trasladar sus archivos, servidores y sistemas a la nube, por una serie de razones, tales como: menor costo de operación, flexibilidad, mayor resiliencia, cumplimiento normativo, entre otros.

En el teatro clásico, un deus ex machina es un “dios” que baja al escenario para resolver el final de la obra. En la nube, a veces esperamos algo parecido: que el proveedor “arregle todo” de forma casi mágica. En el contexto de resiliencia en la nube, podemos reinterpretar el concepto como la capacidad de los sistemas en la nube para intervenir casi “divinamente” ante fallas catastróficas, restaurando operaciones de forma automática, invisible y en tiempo real. Ese “deus ex nube”, en mi opinión, es un error de concepto: no podemos delegar toda la continuidad del negocio en un tercero.

En la madrugada del 20 de octubre, Nuestra fe en la resiliencia de la nube recibió un golpe de realidad. El internet “entró en crisis”. AWS presentó problemas de acceso que paralizaron empresas alrededor de todo el planeta. La semana siguiente, volvió a ocurrir: Microsoft diagnosticó problemas globales en Azure por un cambio de configuración en Azure Front Door. No hubo ciberataques; sí fallas lógicas en el control‑plane que dejaron ver lo obvio: la resiliencia es, hoy, un activo de negocio tanto como una tecnología.

Descripción de los incidentes

• 20 de octubre – AWS. Un problema en el sistema de nombres de internet (DNS) afectó un servicio clave y cortó nuevas conexiones por horas. Muchas empresas notaron fallas al usar aplicaciones que dependen de esa infraestructura.

• 29–30 de octubre – Azure. Un cambio de configuración en Azure Front Door (la “puerta de entrada” que enruta el tráfico hacia apps en Azure) causó demoras y errores a escala global hasta que Microsoft volvió a la última configuración válida.

Más allá de la información técnica, las noticias de distintos medios corroboraron el alcance: plataformas de consumo y empresas en múltiples industrias sufrieron interrupciones y degradaciones, un recordatorio de la concentración de dependencia en pocos operadores (hyperscalers)

El patrón que se repite: automatización, cambios… y radios de impacto

En ambos incidentes, se determinó que esto no fue obra de malware o intrusiones. Ambos incidentes están relacionados con errores de orquestación en capas críticas (DNS y edge), que bastaron para forzar modos de fallo en servicios que millones de usuarios asumen invisibles. El informe de AWS detalla la condición de carrera entre componentes de su gestor de DNS; el de Azure, un cambio de configuración que se propagó y obligó a bloquear cambios y a volver a la “última configuración buena conocida (Las known Good Configuration)”. Son lecciones duras de ingeniería de confiabilidad —y, sobre todo, de gestión del riesgo empresarial.

La mirada del negocio: por qué la resiliencia no es un proyecto de TI

El Middle Market Business Index – Cybersecurity 2025 de RSM muestra una foto útil: casi 1 de cada 5 compañías del middle market reportó una brecha el último año (18%). El dato es positivo frente al pico anterior, pero el propio informe pide no caer en la complacencia: el entorno es volátil y la pregunta no es “si” habrá incidentes, sino cómo absorberlos y recuperarse.

En esa línea, RSM propone una estrategia bifocal para la ciber resiliencia: reducir superficie de ataque y preparar la recuperación (plan, gente, procesos y arquitectura). Y lleva el tema a la sala del directorio: metas medibles (por ejemplo, zero trust completo en 3–5 años) y tableros de riesgo en tiempo real.

Como mitigar los riesgos de resiliencia de la nube

A continuación, brindamos algunas medidas que contribuyan a reducir el impacto de este tipo de incidentes:

•  
• 1-Planificar la contingencia, aunque nuestra infraestructura esté en la nube.

Al final de cuentas, la nube no existe, existe el servidor de alguien más. Y bajo tal concepto, no podemos depositar toda nuestra confianza, nuestro negocio y nuestra resiliencia en un tercero si nosotros mismos no tenemos definida una estrategia de resiliencia en nuestras empresas. Esto debe de tener al menos un plan de contingencia, que en RSM recomendamos institucionalizar estas prácticas mediante ejercicios y e informes con indicadores de performance (KPIs) ante el nivel ejecutivo.

•  
• 2- Arquitectura multi‑región y “celular”.

Separar regiones (y, dentro de ellas, células funcionales) reduce el radio de impacto de un bug de control‑plane. En AWS, Route 53 Application Recovery Controller (ARC) permite orquestar failovers con rutas seguras que evitan conmutaciones peligrosas; en Azure, Traffic Manager funciona como plano de DNS global complementario a Front Door para escenarios de conmutación entre regiones.

•  
• 3) Plan B para el Edge.

Si Front Door falla o se degrada, el bypass controlado con Traffic Manager y sondas de salud de aplicación (no sólo ping) permite rutar hacia una ruta alterna hasta estabilizar. Microsoft lo recoge en sus guías de arquitectura y confiabilidad. Esto debe de ser acompañado de métricas de salud (latencia, errores, saturación que permitan conocer el estado de nuestros sistemas y las medidas que se deben de tomar como contingencia.

Dos puntos para revisar hoy con su equipo

Gerentes y líderes empresariales: este es un buen momento para sentarse con su equipo de TI y plantear dos preguntas simples, pero decisivas:

• ¿Nuestra operación depende de un único punto de entrada? Y si ese punto falla, ¿tenemos una ruta alterna comprobada?

• ¿Hemos ensayado realmente nuestro plan de recuperación, o solo existe en papel?

Las respuestas a estas dos preguntas pueden marcar la diferencia entre una pausa controlada y una crisis total. La resiliencia no se improvisa: se construye, se mide y se practica.

En conclusión, la nube no sólo es frágil; es compleja. Esa complejidad —automatizada, hiper escalada, global— exige que las empresas diseñen su resiliencia bajo el concepto de que tarde o temprano van a fallar, este es el primer paso. A continuación, analice documentación al respecto, como los informes de los incidentes de ambos proveedores (PIR) y las guías de RSM relacionadas con la resiliencia. Finalmente discutan la situación, planifiquen y ejecuten, hasta convertirlo en una disciplina empresarial. Lo ocurrido el 20 de octubre y el 29 de octubre no fueron dos “accidentes aislados”: fueron ensayos generales de lo que distingue a quienes sostienen la operación en medio del ruido

Fuentes principales

• AWS — Summary of the Amazon DynamoDB Service Disruption in US‑EAST‑1 (Oct 19–20, 2025).

• Microsoft Azure — Preliminary PIR (Oct 29–30, 2025) – Azure Front Door: Connectivity issues across multiple regions.

• RSM — MMBI Cybersecurity 2025; Creating a blueprint for cybersecurity resilience; The board’s role in establishing effective digital resilience.

• Cobertura periodística — Selección de Reuters, AP y otros sobre el alcance de los incidentes.