La nube no es infalible: prepárate para más caídas en 2026

Madrugada del lunes 20 de octubre de 2025. En Virginia, un registro DNS de DynamoDB queda vacío por una condición de carrera. En Panamá, nadie tocó un servidor. Y aun así, para el mediodía, hay empresas que no pueden facturar, apps que no cargan y un gerente preguntando por qué «lo que está en la nube» no responde.

Durante años, migrar a la nube se vendió como la forma de dejar de preocuparse por la disponibilidad. En muchos casos sigue siendo cierto. Pero hay una realidad que las organizaciones están empezando a enfrentar con más seriedad: estar en la nube no significa estar protegido contra las interrupciones.

¿Qué pasó con la nube en 2025?

Los grandes incidentes de 2025 dejaron una señal difícil de ignorar. AWS, Microsoft Azure, Google Cloud y Cloudflare tuvieron interrupciones que afectaron directa o indirectamente a miles de organizaciones. La más grande fue la de AWS en octubre.

TechTarget publicó en enero de 2026 un análisis con una conclusión incómoda: estos incidentes podrían dejar de ser eventos excepcionales y convertirse en un riesgo operativo que hay que incorporar a la estrategia de continuidad. No como escenario remoto. Como línea del plan.

¿Por qué una caída de AWS afecta a una empresa que no usa AWS?

Porque las dependencias no están donde crees. Una empresa mediana puede tener el ERP en un SaaS, la colaboración en Microsoft 365, la app de clientes en Azure, la autenticación en otro servicio y los respaldos en un tercero. Sobre el papel, todo está distribuido. En la práctica, detrás de esos cinco proveedores puede haber dos hyperscalers y una región.

Ese SaaS de facturación que usas probablemente corre en us-east-1. Su proveedor de correo transaccional también. La pasarela de pago, quizás. Ninguno te lo dijo, y no tenías por qué preguntarlo, hasta que los tres se cayeron a la misma hora.

La infraestructura puede estar distribuida físicamente. Las dependencias pueden seguir centralizadas. El riesgo no desaparece cuando migras a la nube: cambia de lugar.

¿Por qué Forrester espera más caídas en 2026?

Lee Sustar, analista principal de Forrester, lo escribió sin rodeos en las predicciones 2026 de la firma: «creemos que esta estrategia tendrá consecuencias en la forma de al menos dos caídas mayores de varios días en 2026».

La estrategia a la que se refiere es la de los hyperscalers: están invirtiendo cantidades enormes en centros de datos orientados a GPU para cargas de inteligencia artificial, mientras la infraestructura x86 y ARM heredada, que sostiene la mayoría de los servicios que tu empresa usa hoy, envejece y gana complejidad. Más carga, más piezas, menos atención sobre lo viejo.

Eso plantea una pregunta para cualquier responsable de tecnología: ¿estás diseñando tu operación para funcionar solo cuando todo lo demás funciona? Si la respuesta es sí, no tienes un problema de nube. Tienes un problema de resiliencia.

¿Cuánto cuesta de verdad una interrupción?

El informe «The Hidden Costs of Downtime» de Splunk, con encuesta de Oxford Economics, estima que las empresas Global 2000 pierden unos 400,000 millones de dólares al año por downtime. En promedio, 9,000 dólares por minuto, 540,000 por hora. Y la recuperación de ingresos tarda unos 75 días después del incidente.

Tu empresa no es Global 2000 y no pierde 9,000 dólares por minuto. Pero haz la cuenta con tu número: facturación anual entre las horas del año en que operas, por las horas que estuviste sin sistema. Para una pyme que factura 2 millones al año y opera 2,500 horas, una tarde de cinco horas sin facturar son 4,000 dólares de ingreso detenido, sin contar lo que se dejó de vender ni el cliente que no volvió. La proporción sobre el negocio suele ser peor que la de la empresa grande.

Y el impacto no termina cuando el servicio vuelve. La recuperación técnica no es la recuperación del negocio: quedan los pedidos que se perdieron, los acuerdos de servicio incumplidos, la reputación. Es el mismo patrón que separa tener backup de tener recuperación.

¿Entonces hay que salir de la nube?

No. Sería la conclusión equivocada. La nube sigue siendo una pieza central de cualquier infraestructura moderna y ofrece capacidades que serían caras y difíciles de replicar por tu cuenta.

El problema no es usar la nube. Es depender de ella sin diseñar para su fallo. La conversación tiene que pasar de «¿qué proveedor usamos?» a «¿qué pasa con el negocio si ese proveedor deja de estar disponible durante dos días?».

Esa segunda pregunta tiene respuestas de distinto tamaño, y no todas las empresas necesitan la más cara.

¿Cómo sabes que tu infraestructura está fallando?

Hay un elemento que casi siempre queda fuera de estas conversaciones. Si todo tu monitoreo, tus alertas, tus dashboards y hasta el chat del equipo dependen del mismo proveedor que está caído, no solo tienes una falla. Perdiste la visibilidad sobre la falla.

Una arquitectura resiliente contempla mecanismos de monitoreo y comunicación independientes para los servicios críticos. No hace falta que sean sofisticados: un chequeo externo desde otro proveedor y un canal de respaldo acordado (sí, puede ser un grupo de WhatsApp con reglas) resuelven el 80% del problema. Lo que importa es haberlo decidido antes.

Qué revisar esta semana

1. Lista tus servicios críticos y pregúntale a cada proveedor dónde corre. Región y hyperscaler. Si tres de tus cinco sistemas viven en la misma región, ya sabes qué caída te deja fuera.
2. Confirma que existe una copia fuera de ese proveedor y de su identidad. Y que alguien la restauró este trimestre. Si nunca se restauró, es una expectativa, no un respaldo.
3. Mueve al menos un chequeo de monitoreo y un canal de aviso fuera del proveedor principal. Un monitor externo gratuito y un canal de respaldo acordado bastan para empezar.
4. Escribe qué hace cada persona en las primeras dos horas sin el sistema principal. Quién atiende clientes, quién factura a mano, quién decide cuándo activar el plan B. Una página. Impresa.

Cuándo esto no te aplica

Si tu operación puede detenerse dos días sin perder clientes ni ingresos (hay negocios así, y no tiene nada de malo), el nivel de respaldos independientes es suficiente y lo demás es gasto. La resiliencia se compra en proporción a lo que cuesta no tenerla, no por moda.

Si mañana a las 9 a.m. tu proveedor principal de nube deja de responder y no vuelve hasta el miércoles, ¿qué hace tu equipo a las 9:15?

Si la respuesta es «llamar a IT», ese es el hallazgo. La resiliencia no se compra; se diseña, y se ensaya antes de necesitarla.