Detrás de cada caída de AWS o Cloudflare hay una decisión de arquitectura que no se tomó a tiempo

Buena parte de internet volvió a tropezar con el mismo problema: la infraestructura de la que depende casi todo —tiendas, apps de comida, redes sociales, sistemas de pago— falló varias veces en pocos días. AWS sumó su cuarto incidente serio en cuatro meses. Cloudflare, la red que enruta cerca de una cuarta parte del tráfico mundial, registró trece incidentes en solo ocho días.

Ninguna de las dos noticias tiene que ver con un lanzamiento nuevo ni con un modelo de IA sorprendente. Tiene que ver con algo mucho más básico: la solidez de los cimientos sobre los que casi todos construimos hoy nuestros productos digitales. Y como equipo que diseña arquitectura y despliega software real, esta semana nos pareció una buena excusa para hablar de algo que casi nunca se discute hasta que falla: qué tan resiliente es, de verdad, el producto que estás construyendo.

Cuatro fallas en cuatro meses: el patrón que AWS todavía no explica del todo

El historial de este año en AWS empieza a dibujar una curva preocupante. En mayo, una falla física en el sistema de refrigeración de un centro de datos en Virginia del Norte dejó servidores fuera de servicio. En junio, un proveedor de red externo provocó una interrupción de conectividad. El 24 de julio llegó el incidente más visible: 80 minutos de caída en la región US-West-2, en Oregon, que tumbaron Apple Pay, Reddit, Hulu, DoorDash y PlayStation Network al mismo tiempo (Tech Times). AWS solo habló de un "problema regional de conectividad a internet" en el límite entre su infraestructura y la red pública.

Lo que más nos llamó la atención de ese reporte fue una frase: "tres incidentes, tres capas distintas del stack". No fue el mismo bug repitiéndose. Fue refrigeración, después red de un tercero, después el borde de conectividad regional. Tres causas raíz completamente distintas, en menos de tres meses.

Agosto no rompió la racha. AWS registró un nuevo evento de enrutamiento vinculado a la misma ruta de red hacia el área metropolitana de Seattle que ya había fallado antes, sin confirmar públicamente si comparte causa con los incidentes previos (Tech Insider). Y por separado, el 15 de agosto, un problema de conectividad en el centro de datos Equinix FR5 de Frankfurt afectó a un conjunto amplio de servicios —cómputo, almacenamiento, bases de datos— con AWS reconociendo que la recuperación completa no sería inmediata (ServiceAlert.ai).

Cuatro incidentes, cuatro meses, capas distintas del stack. Ese es el patrón que nos parece relevante, más allá de cada incidente individual.

Cloudflare no se queda atrás: trece incidentes en ocho días

Si AWS tuvo un mes complicado, Cloudflare tuvo una semana todavía más agitada. Entre el 7 y el 14 de agosto, la compañía registró trece incidentes distintos en su plataforma. Doce fueron menores; solo uno, una disrupción en la entrega de correo vinculada a un listado de Spamhaus, se clasificó como mayor. La mayoría se concentró en dos días, con cuatro incidentes cada uno (Shattered.io).

Lo interesante no es la cantidad, sino la variedad de servicios tocados: fallas de escritura en su almacenamiento de objetos R2 en la región este de Norteamérica, caídas de disponibilidad en Durable Objects y Workflows, errores elevados en Workers KV, problemas puntuales en Workers AI, errores en Magic Transit y hasta fallas de autenticación en su portal de servidores MCP. No hubo una única causa raíz: fibra óptica cortada en Estambul, un problema en el dashboard de Magic Transit, el impacto de Spamhaus en el enrutamiento de correo. Incidentes independientes, ocurriendo en la misma ventana de tiempo.

El detalle que le da escala al problema es simple: Cloudflare enruta aproximadamente el 24% de todo el tráfico web mundial. Cuando falla, no falla una empresa. Fallan miles de checkouts, logins y llamadas a API de negocios que ni siquiera saben que dependen de Cloudflare hasta que dejan de poder cobrar.

¿Por qué esto se está convirtiendo en la norma?

Esta pregunta nos parece la más importante de las tres. Según un análisis de Forrester citado por TechTarget, los grandes proveedores de nube están desviando inversión de la infraestructura tradicional —los entornos x86 y ARM que sostienen la mayoría de las aplicaciones comunes— para priorizar centros de datos orientados a GPU, pensados para entrenar e inferir modelos de IA. El analista Lee Sustar proyecta al menos dos caídas mayores de varios días durante 2026, precisamente por esa tensión entre dónde se invierte y qué es lo que realmente sostiene la operación diaria de millones de empresas.

El costo de esa fragilidad no es abstracto. El mismo análisis estima que las empresas del Global 2000 pierden en conjunto cerca de 400 mil millones de dólares al año por tiempo de inactividad, a un ritmo aproximado de 9.000 dólares por minuto caído. La recuperación de ingresos después de un incidente toma en promedio 75 días, y suele venir acompañada de una caída bursátil cercana al 2,5%.

No compartimos estos números para generar alarma. Los compartimos porque cambian una pregunta que muchas empresas todavía no se hacen: no es "¿qué proveedor de nube deberíamos usar?", sino "¿qué pasa con nuestro producto el día que ese proveedor falle, aunque sea por veinte minutos?".

Lo que esto significa si tu producto no es Reddit ni Cloudflare

Es fácil leer estas noticias y pensar que son un problema de escala ajena: cosas que le pasan a compañías con millones de usuarios simultáneos. No es así. Cualquier producto que corra sobre AWS, Cloudflare, u otro proveedor grande hereda el mismo riesgo, sin importar su tamaño. La diferencia es que una empresa pequeña rara vez tiene el equipo dedicado a diseñar cómo responder cuando eso ocurre.

Esto no significa que la solución sea evitar la nube, ni construir infraestructura propia desde cero. La mayoría de las veces, esa sería una decisión peor que el problema que intenta resolver. Significa diseñar con la caída en mente desde el principio, en lugar de descubrir en producción que todo el sistema depende de un único punto de falla.

En la práctica, eso se traduce en decisiones concretas de arquitectura: separar qué partes del producto realmente necesitan alta disponibilidad y cuáles pueden degradarse con gracia si un servicio externo falla. Definir qué pasa si tu proveedor de almacenamiento no responde por unos minutos: ¿tu aplicación se cae por completo, o sigue funcionando en modo limitado? Tener procesos de despliegue y monitoreo que permitan detectar un problema en minutos, no quejas de usuarios en redes sociales. Y, cuando el negocio lo justifica, distribuir cargas críticas entre más de un proveedor, en lugar de depender de uno solo para todo.

Ninguna de estas decisiones se improvisa el día del incidente. Se toman antes, cuando se define la arquitectura del producto, y se revisan a medida que el negocio crece y lo que está en juego también crece.

Esto es, exactamente, el tipo de conversación que tenemos con los equipos que acompañamos en Rukma. No llegamos a un proyecto solo a escribir código: revisamos cómo está diseñada la arquitectura, qué tan dependiente es de un único proveedor o servicio, y qué tan preparado está el sistema para fallar de forma controlada en lugar de fallar por completo. Esa conversación técnica, hecha con tiempo, es mucho más barata que resolverla en medio de una caída con clientes reales esperando.

Si estás construyendo un producto que ya depende de servicios en la nube —y hoy casi todos lo hacen— vale la pena preguntarse qué tan preparado está para el día en que uno de esos servicios falle. Si todavía no tienes esa respuesta clara, conversemos: preferimos ayudarte a diseñar esa resiliencia antes de que la necesites, no después de un incidente.