El 16 de julio, CloudFront —el CDN de AWS— estuvo unas ocho horas sirviendo errores 5xx en lugar de páginas web a los clientes que usan VPC Origins. Cayeron desde Hugging Face hasta la lotería nacional británica. No fue un ataque: fue una "restricción interna" en la flota que gestiona las conexiones a orígenes privados, según la propia AWS. Y es la tercera caída seria de AWS en nueve meses.
Cada vez que pasa esto se repite el mismo ciclo: memes con el logo en llamas, hilos sobre multi-cloud, y a la semana siguiente todo el mundo sigue exactamente igual. Nosotros llevamos años operando infraestructura —propia y de clientes— y creemos que la lección de estas caídas es otra, menos espectacular y más útil: el incidente de tu proveedor no tiene por qué ser tu incidente del mismo tamaño. Eso no se consigue con más nube. Se consigue con un plan de recuperación que exista de verdad.
Cuatro caídas grandes en nueve meses. Ningún hacker.
Pongamos los casos sobre la mesa, porque el patrón importa más que cada caída por separado:
- →Octubre de 2025, AWS us-east-1. Una race condition latente en la automatización DNS de DynamoDB dejó vacío el registro del endpoint regional. Unas 15 horas de caída con efecto cascada sobre Lambda, API Gateway y medio Internet.
- →Noviembre de 2025, Cloudflare. Un cambio de permisos en una base de datos hizo que el fichero de configuración de Bot Management se llenara de filas duplicadas, superara un límite interno y tumbara el software que enruta el tráfico. Unas seis horas de errores; la propia Cloudflare lo llamó su peor caída desde 2019.
- →Mayo de 2026, AWS us-east-1 (otra vez). Un evento térmico dejó sin alimentación racks de la zona us1-az4: instancias EC2 y volúmenes EBS afectados, con una recuperación de unas 17 horas.
- →Julio de 2026, CloudFront. La de la semana pasada: unas ocho horas de errores 5xx para los clientes con VPC Origins, porque el sistema que distribuye la configuración de enrutado no cargó bien los datos al alcanzar una restricción interna.
Fíjate en lo que NO hay en esa lista: ataques. Son automatizaciones que fallan, ficheros de configuración que crecen más de la cuenta, racks que se calientan. Es decir: el funcionamiento normal de sistemas enormes operados por humanos. Ninguna certificación, ninguna región extra y ningún contrato eliminan esa clase de fallo. Va a volver a pasar.
El SLA no es un plan de recuperación
Hay una confusión que nos encontramos constantemente: creer que contratar un servicio con un buen SLA equivale a tener disaster recovery. Un SLA te da, como mucho, un descuento en la factura del mes siguiente. No te devuelve las ventas de las ocho horas que estuviste caído, ni te explica ante tus clientes, ni decide qué haces mientras tanto. El SLA es el problema de tu proveedor; el plan de recuperación es el tuyo. Y externalizar la infraestructura no externaliza esa responsabilidad — eso es exactamente de lo que hablamos cuando hablamos de disaster recovery.
Primero: entérate de cuánto AWS (y Cloudflare) llevas dentro
La caída de octubre arrastró a Lambda, API Gateway y a un sinfín de servicios SaaS construidos encima. Consecuencia directa: puedes no tener nada contratado con AWS y aun así pararte, porque tu ERP en SaaS, tu pasarela de pago o tu herramienta de soporte sí corren en us-east-1. Esa es la parte del mapa de dependencias que casi nadie dibuja: no basta con saber dónde corren tus sistemas; hay que saber dónde corren los sistemas de los que dependes. El ejercicio es aburrido y no requiere comprar nada: lista tus procesos críticos (cobrar, servir, facturar, atender), y para cada uno apunta de qué servicios depende y quién está detrás de cada servicio. La primera vez siempre aparece alguna sorpresa incómoda. Mejor encontrarla un martes tranquilo que un día de caída global.
Un modo degradado vale más que un failover perfecto
El plan de recuperación de manual dibuja un failover automático que conmuta todo a otro sitio sin que nadie lo note. En la práctica, para la mayoría de empresas medianas, ese failover nunca llega a existir: es caro, es complejo y no se prueba. Lo que sí se puede tener —y salva el día— es un modo degradado decidido de antemano: qué versión mínima de tu negocio tiene que seguir en pie si tu proveedor principal desaparece unas horas. A veces es una página estática con un teléfono y un "estamos operativos, escríbenos". A veces es poder cobrar a mano y registrar pedidos en una hoja compartida que vive en otro proveedor. No es elegante. Funciona. Y lo que separa un susto de un pánico un día como el 16 de julio casi nunca es el presupuesto: es haber decidido esto antes o estar improvisándolo en caliente.
Backups fuera del radio de la explosión (y monitorización que no se cae con el proveedor)
Dos reglas que aplicamos a todo lo que operamos, y que estas caídas vuelven a validar:
- ✓Al menos una copia fuera del ecosistema del proveedor. La regla 3-2-1 no es nostalgia de la era de las cintas: si tus datos Y tus backups viven en la misma nube, comparten el mismo radio de explosión — el mismo proveedor, la misma cuenta, a veces la misma automatización que puede fallar. Nosotros lo montamos con copias fuera del proveedor de origen e inmutables, y con restauraciones probadas: un backup que nunca has restaurado es una hipótesis, no un backup.
- ✓La monitorización vive en otra parte. Si tu sistema de alertas corre en el mismo proveedor que tus servicios, el día de la caída te quedas ciego y mudo a la vez. Nuestra monitorización (Zabbix y SmokePing) corre sobre infraestructura propia, repartida en varios datacenters, precisamente para poder ver un incidente de un proveedor desde fuera del incidente.
La contra: no, no te estamos diciendo que montes multi-cloud
Después de cada caída global se venden muchos proyectos de multi-cloud activo-activo. Seamos honestos: para la mayoría de empresas medianas es una mala compra. Duplica costes, duplica superficie de fallo, exige un equipo que sepa operar dos nubes igual de bien, y la complejidad añadida provoca sus propias caídas — la de Cloudflare de noviembre la causó precisamente la maquinaria interna de un sistema sofisticado, no la falta de redundancia. Lo que defendemos es menos épico: aceptar el riesgo residual con los ojos abiertos, cubrir con dinero real solo los procesos que de verdad matan el negocio, y tener el modo degradado, los backups y la visibilidad del punto anterior. Con eso, una caída de ocho horas de tu proveedor pasa de crisis existencial a mala tarde.
Nuestro sesgo, dicho claramente: operamos infraestructura propia —Proxmox y Ceph repartidos en varios datacenters, red propia con BGP, tránsito y peering— y también desplegamos y gestionamos cargas en nube pública. No estamos en el bando "la nube es mala" ni en el de "todo a la nube": estamos en el de que cada pieza crítica tenga un plan B proporcional a lo que cuesta perderla.
En corto
AWS va a volver a caerse. Cloudflare también. No es una crítica: es la estadística de nueve meses hablando. La pregunta útil no es "¿cuándo se caerá mi proveedor?", sino "¿cuánto de mi negocio se cae con él, y durante cuánto tiempo?". Esa respuesta cabe en una hoja: el mapa de dependencias, el modo degradado, la copia fuera del radio de explosión y alguien que pueda verlo todo desde fuera. Si esa hoja no existe en tu empresa, esta semana es un buen momento para escribirla — mientras el recuerdo del 16 de julio todavía escuece.
Fuentes (verificadas): caída de CloudFront del 16-jul-2026 (inicio 09:45 UTC, resuelta ~17:39 UTC, VPC Origins, afectados Hugging Face, UK National Lottery, Fallout 76) — The Register; evento térmico us-east-1 (us1-az4) del 7/8-may-2026 — The Register; caída us-east-1 del 19/20-oct-2025 (race condition en DNS de DynamoDB, ~15 h) — InfoQ y ThousandEyes; caída de Cloudflare del 18-nov-2025 (fichero de Bot Management, 11:20–17:06 UTC) — postmortem oficial de Cloudflare.
¿Sabes cuánto de tu negocio se cae cuando se cae tu proveedor?
En everyWAN diseñamos planes de disaster recovery con RTO y RPO honestos: mapa de dependencias, modo degradado, backups fuera del radio de explosión y pruebas de restauración de verdad. Sin humo y sin venderte una segunda nube que no necesitas.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN