Alquiler récord en España y hosting cada vez más caro: mismo guion, mismos caseros. Por…
Se fue la luz en Londres y Revolut dejó de pagar el café: la factura de depender de cuatro nubes
Fuentes principales: The Journal y Euronews sobre la caída de Revolut; los informes post-incidente de AWS, Cloudflare y Microsoft; el postmortem de Coinbase; y las cuotas de mercado de Synergy Research.
El martes 20 de octubre, poco después de las seis de la mañana, se fue la luz en un centro de datos de Google al lado de Londres. A las nueve, millones de personas en Reino Unido, Irlanda, Francia, España o Japón descubrieron que su tarjeta de Revolut no pagaba el café. Al mediodía Google daba el incidente por “mitigado para la mayoría de clientes”; por la tarde, la página de estado de Revolut seguía listando 31 servicios caídos, de los pagos con tarjeta a las transferencias y los cajeros. Un banco con más de 80 millones de clientes, regulado y supervisado, estuvo medio día sin funcionar porque un edificio en Inglaterra se quedó sin corriente. No es una anécdota. Es la arquitectura de internet en 2026, y esta semana solo ha vuelto a enseñar la factura.
La nube no es un lugar. Son cuatro empresas.
Amazon, Microsoft y Google controlan dos tercios de la infraestructura mundial. Cloudflare está delante de una quinta parte de las webs. Nueve caídas graves en dos años.
El mapa del poder: tres dueños y un portero
Según Synergy Research, el gasto mundial en infraestructura en la nube superó los 143.000 millones de dólares solo en el segundo trimestre de 2026, un 43% más que un año antes. De ese dinero, Amazon Web Services se lleva en torno al 30%, Microsoft Azure alrededor del 20% y Google Cloud entre el 12% y el 15%, un récord para Google. Tres compañías, dos tercios del mercado. Y delante de todas ellas, un cuarto actor que no vende servidores sino la puerta: Cloudflare, que según W3Techs sirve, protege o acelera alrededor de una quinta parte de todas las webs del mundo, incluidas muchas que viven en las otras tres nubes.
Esa concentración no es un accidente ni, en sí misma, una irresponsabilidad. Es la consecuencia lógica de quince años de “no reinventes la rueda”: nadie monta su propio centro de datos porque AWS lo hace mejor, nadie monta su propio CDN porque Cloudflare lo hace mejor, y nadie monta su propia red de pagos porque es más fácil apoyarse en un banco digital que, a su vez, se apoya en Google. El resultado es una pirámide invertida donde una cantidad enorme de servicios distintos descansa sobre un vértice muy pequeño. Y los vértices, como se ve en la tabla, fallan con una regularidad que ya es estadística.
Nueve caídas en dos años: el calendario de la dependencia
| Fecha | Proveedor | Causa | Duración | Quién lo sufrió |
|---|---|---|---|---|
| 19 jul 2024 | CrowdStrike sobre Windows (la antesala) | Una actualización de contenido defectuosa | Días de recuperación | 8,5 millones de equipos; aerolíneas, hospitales y bancos en tierra |
| 12 jun 2025 | Google Cloud | Un puntero nulo en Service Control, sin gestión de errores ni interruptor | De 3 a 7 horas según el servicio | Todas las regiones a la vez; arrastró a Cloudflare, Spotify, Discord y OpenAI |
| 19-20 oct 2025 | AWS, región de Virginia (us-east-1) | Condición de carrera en la automatización DNS de DynamoDB | 14 horas y media | Slack, Atlassian, bancos británicos y buena parte del propio AWS |
| 29 oct 2025 | Microsoft Azure Front Door | Un cambio de configuración de un inquilino procesado por versiones incompatibles del plano de control | 8 horas y media | Microsoft 365, Xbox, portales de Azure y miles de webs detrás del servicio |
| 18 nov 2025 | Cloudflare | Un fichero de Bot Management que dobló su tamaño por un cambio de permisos en base de datos | 5 horas y 46 minutos | “La mayoría del tráfico” de su red: X, ChatGPT y medio internet con error 500 |
| 20 feb 2026 | Cloudflare | Retirada por BGP de unos 1.100 prefijos de clientes con IP propia | 6 horas y 7 minutos | Clientes que creían tener su propia red |
| 7-8 may 2026 | AWS, región de Virginia | Fallo simultáneo de varias enfriadoras en una sala; apagado térmico de los racks | Unas 20 horas | Coinbase detuvo casi todo su trading durante siete horas |
| 7-14 ago 2026 | Cloudflare | Trece incidentes en ocho días, con el almacenamiento R2 como protagonista | Una semana de intermitencia | Clientes con datos de R2 sin recuperar días después |
| 20 oct 2026 | Google Cloud, región de Londres | “Un evento de energía” en europe-west2 | Unas 6 horas, con cola hasta la tarde | Revolut, 31 servicios caídos; otros bancos británicos |
No es el hardware: es el plano de control
Hay un patrón que la tabla deja a la vista. Dos de las nueve caídas fueron físicas: la luz en Londres y las enfriadoras en Virginia. Las otras siete las provocó el propio proveedor desde dentro: un cambio de configuración, un fichero que creció de más, una automatización que se pisó a sí misma, un puntero nulo sin interruptor de emergencia. Son fallos del plano de control, la capa de software que gobierna la nube, y tienen una característica que el hardware no tiene: se propagan a todas las regiones a la vez, en segundos, porque para eso se diseñó la replicación global. La redundancia que te venden contra incendios e inundaciones no sirve de nada contra un despliegue erróneo que llega a todos los centros de datos en el mismo minuto.
El caso de Google en junio de 2025 es el manual completo. Un código nuevo sin gestión de errores, una política con campos en blanco replicada globalmente en segundos, y todos los binarios de Service Control del planeta entrando en bucle a la vez. Cloudflare, que dependía de Google para su almacén de claves Workers KV, vio fallar el 90% de las peticiones durante dos horas y media. Es decir: la caída de una nube tumbó al portero de otra, y detrás del portero, a Spotify, Discord y OpenAI. Las dependencias no son un árbol; son una red, y nadie tiene el mapa entero.
La multinube existe en las presentaciones. En producción, casi todo el mundo tiene una nube y una esperanza.
Hipertensión mental, tras nueve post-incidentes leídos del tirón
Por qué un banco cae con un centro de datos
Lo de Revolut merece una lectura más fina, porque es el caso más incómodo de la lista. Un banco digital no es una startup de newsletters: está regulado, tiene planes de continuidad auditados y, desde enero de 2025, está sujeto a DORA, el reglamento europeo de resiliencia operativa digital que obliga a las entidades financieras a gestionar el riesgo de sus proveedores tecnológicos críticos. Y aun así, una sola región de Google, la de Londres, bastó para dejar sin tarjetas a clientes en Japón. Google ofrece zonas múltiples y regiones múltiples precisamente para esto. Que un banco global no sobreviviera a la pérdida de una región dice menos de Google que de lo caro, lento y difícil que es de verdad diseñar para que una región entera desaparezca.
El problema es económico antes que técnico. Replicar activamente en dos regiones duplica la factura y multiplica la complejidad; replicar en dos proveedores distintos la triplica y obliga a renunciar a los servicios gestionados que hacían atractiva la nube. Así que la mayoría de las empresas, bancos incluidos, hace lo que hizo Revolut: elige una región principal, confía en que el proveedor cumpla su promesa de disponibilidad y guarda el plan de contingencia en un cajón. Funciona 364 días al año. El día 365 sale en Euronews.
Lo que dicen los contratos
- Disponibilidad del 99,99%: menos de una hora de caída al año.
- Zonas de disponibilidad “independientes” dentro de cada región.
- Créditos de servicio si se incumple: AWS ofreció un 10% de la factura tras Virginia.
- Un dashboard de estado que, en casi todos los casos, también se cae.
Lo que dice el calendario
- Virginia ha caído tres veces desde octubre de 2025; la última, veinte horas.
- Las zonas son independientes hasta que falla lo que las une: el plano de control.
- Un 10% de crédito no cubre siete horas sin trading ni medio día sin tarjeta.
- Lo que se apaga no es tu web: es la confianza de tus clientes, y eso no tiene SLA.
El efecto Cloudflare: el portero que vigila a todas las puertas
Cloudflare es el caso aparte de la lista porque no compite con las otras tres: se coloca delante. Una web en AWS, otra en Azure y otra en Google pueden creer que han diversificado y estar las tres detrás del mismo proxy. El 18 de noviembre de 2025 lo demostró: un fichero de configuración que creció al doble de su tamaño por un cambio de permisos en una base de datos interna, y “la mayoría del tráfico principal” de la red dejó de fluir durante casi seis horas. X, ChatGPT y una fracción enorme de la web devolvieron el mismo error 500 a la vez, sin que ninguna de ellas hubiera tocado nada. Cloudflare publicó un post-incidente ejemplar, como siempre. El problema no es la transparencia; es que la transparencia llega después.
Qué puede hacer quien no es un banco
- Saber de qué dependes de verdad. No es solo tu hosting: es tu CDN, tu DNS, tu proveedor de identidad, tu pasarela de pago y la nube en la que viven todos ellos. La mayoría de empresas descubre el mapa completo el día de la caída. Dibújalo antes.
- Elegir qué debe sobrevivir. Replicar todo en dos regiones es carísimo; replicar la página de “estamos trabajando en ello” con el teléfono de atención y una versión estática de lo esencial cuesta casi nada. La resiliencia empieza por decidir qué no puede caerse.
- Sacar el DNS de la ecuación. Si tu DNS vive en el mismo proveedor que tu web, una caída te deja sin forma de redirigir a nadie a ningún sitio. Es la dependencia más barata de romper.
- Leer los post-incidentes. Los nueve de la tabla son públicos y detallados. Cada uno es una lección gratuita sobre cómo falla la infraestructura que pagas. Quien los lee diseña distinto.
- Desconfiar de la multinube de folleto. Tener cuentas en tres proveedores no es resiliencia; es tres facturas. Resiliencia es haber apagado una región a propósito un martes por la mañana y haber comprobado que el negocio seguía.
Durante quince años, mover la infraestructura a la nube fue la decisión segura: nadie te despedía por elegir AWS. Sigue siéndolo, en el sentido de que las alternativas son peores. Pero “seguro” ha pasado a significar otra cosa: no que no vaya a caer, sino que, el día que caiga, caerás junto a medio mundo y nadie te podrá reprochar nada. Revolut tendrá que explicar a sus reguladores por qué una región de Google bastó para dejar sin dinero a sus clientes. La respuesta honesta, la que nadie dará en público, es la misma que daría casi cualquier empresa del planeta: porque diseñar para que no pase costaba más que esperar que no pasara. Hasta que pasa.
Para profundizar: los informes post-incidente que conviene leer
AWS publicó un resumen minucioso de la caída de Virginia de octubre de 2025, con la condición de carrera en el DNS de DynamoDB y la cronología hora a hora. Cloudflare documentó la de noviembre de 2025 (el fichero de Bot Management) y la de febrero de 2026 (la retirada de prefijos BGP) en su blog, con la honestidad habitual de la casa. Microsoft publicó una revisión preliminar y luego una entrada sobre las lecciones aprendidas en Azure Front Door, incluido el aumento del tiempo de propagación de configuraciones a unos 45 minutos. Coinbase explicó con detalle su parada de siete horas en mayo de 2026. Google, por ahora, ha explicado la caída de Londres con tres palabras: “un evento de energía”. Es la única de la lista sin informe público detallado a fecha de hoy.
