El 16 de juliol, CloudFront —el CDN d'AWS— va estar unes vuit hores servint errors 5xx en lloc de pàgines web als clients que fan servir VPC Origins. Van caure des de Hugging Face fins a la loteria nacional britànica. No va ser un atac: va ser una "restricció interna" a la flota que gestiona les connexions a orígens privats, segons la mateixa AWS. I és la tercera caiguda seriosa d'AWS en nou mesos.
Cada vegada que passa això es repeteix el mateix cicle: mems amb el logo cremant, fils sobre multi-cloud, i la setmana següent tothom continua exactament igual. Nosaltres portem anys operant infraestructura —pròpia i de clients— i creiem que la lliçó d'aquestes caigudes és una altra, menys espectacular i més útil: l'incident del teu proveïdor no ha de ser el teu incident de la mateixa mida. Això no s'aconsegueix amb més núvol. S'aconsegueix amb un pla de recuperació que existeixi de debò.
Quatre caigudes grans en nou mesos. Cap hacker.
Posem els casos sobre la taula, perquè el patró importa més que cada caiguda per separat:
- →Octubre de 2025, AWS us-east-1. Una race condition latent a l'automatització DNS de DynamoDB va deixar buit el registre de l'endpoint regional. Unes 15 hores de caiguda amb efecte cascada sobre Lambda, API Gateway i mig Internet.
- →Novembre de 2025, Cloudflare. Un canvi de permisos en una base de dades va fer que el fitxer de configuració de Bot Management s'omplís de files duplicades, superés un límit intern i tombés el programari que enruta el trànsit. Unes sis hores d'errors; la mateixa Cloudflare en va dir la seva pitjor caiguda des del 2019.
- →Maig de 2026, AWS us-east-1 (una altra vegada). Un esdeveniment tèrmic va deixar sense alimentació racks de la zona us1-az4: instàncies EC2 i volums EBS afectats, amb una recuperació d'unes 17 hores.
- →Juliol de 2026, CloudFront. La de la setmana passada: unes vuit hores d'errors 5xx per als clients amb VPC Origins, perquè el sistema que distribueix la configuració d'enrutament no va carregar bé les dades en assolir una restricció interna.
Fixa't en el que NO hi ha en aquesta llista: atacs. Són automatitzacions que fallen, fitxers de configuració que creixen més del compte, racks que s'escalfen. És a dir: el funcionament normal de sistemes enormes operats per humans. Cap certificació, cap regió extra i cap contracte eliminen aquesta mena de fallada. Tornarà a passar.
L'SLA no és un pla de recuperació
Hi ha una confusió que ens trobem constantment: creure que contractar un servei amb un bon SLA equival a tenir disaster recovery. Un SLA et dona, com a molt, un descompte a la factura del mes següent. No et torna les vendes de les vuit hores que vas estar caigut, ni t'explica davant dels teus clients, ni decideix què fas mentrestant. L'SLA és el problema del teu proveïdor; el pla de recuperació és el teu. I externalitzar la infraestructura no externalitza aquesta responsabilitat — això és exactament del que parlem quan parlem de disaster recovery.
Primer: assabenta't de quant AWS (i Cloudflare) portes a dins
La caiguda d'octubre va arrossegar Lambda, API Gateway i un munt de serveis SaaS construïts a sobre. Conseqüència directa: pots no tenir res contractat amb AWS i tot i així aturar-te, perquè el teu ERP en SaaS, la teva passarel·la de pagament o la teva eina de suport sí que corren a us-east-1. Aquesta és la part del mapa de dependències que gairebé ningú dibuixa: no n'hi ha prou de saber on corren els teus sistemes; cal saber on corren els sistemes dels quals depens. L'exercici és avorrit i no requereix comprar res: llista els teus processos crítics (cobrar, servir, facturar, atendre), i per a cadascun apunta de quins serveis depèn i qui hi ha darrere de cada servei. La primera vegada sempre apareix alguna sorpresa incòmoda. Millor trobar-la un dimarts tranquil que un dia de caiguda global.
Un mode degradat val més que un failover perfecte
El pla de recuperació de manual dibuixa un failover automàtic que ho commuta tot a un altre lloc sense que ningú ho noti. A la pràctica, per a la majoria d'empreses mitjanes, aquest failover mai no arriba a existir: és car, és complex i no es prova. El que sí que es pot tenir —i salva el dia— és un mode degradat decidit per endavant: quina versió mínima del teu negoci ha de continuar dempeus si el teu proveïdor principal desapareix unes hores. De vegades és una pàgina estàtica amb un telèfon i un "estem operatius, escriu-nos". De vegades és poder cobrar a mà i registrar comandes en un full compartit que viu en un altre proveïdor. No és elegant. Funciona. I el que separa un ensurt d'un pànic un dia com el 16 de juliol gairebé mai no és el pressupost: és haver decidit això abans o estar improvisant-ho en calent.
Backups fora del radi de l'explosió (i monitoratge que no cau amb el proveïdor)
Dues regles que apliquem a tot el que operem, i que aquestes caigudes tornen a validar:
- ✓Almenys una còpia fora de l'ecosistema del proveïdor. La regla 3-2-1 no és nostàlgia de l'era de les cintes: si les teves dades I els teus backups viuen al mateix núvol, comparteixen el mateix radi d'explosió — el mateix proveïdor, el mateix compte, de vegades la mateixa automatització que pot fallar. Nosaltres ho muntem amb còpies fora del proveïdor d'origen i immutables, i amb restauracions provades: un backup que mai no has restaurat és una hipòtesi, no un backup.
- ✓El monitoratge viu en una altra banda. Si el teu sistema d'alertes corre al mateix proveïdor que els teus serveis, el dia de la caiguda et quedes cec i mut alhora. El nostre monitoratge (Zabbix i SmokePing) corre sobre infraestructura pròpia, repartida en diversos datacenters, precisament per poder veure un incident d'un proveïdor des de fora de l'incident.
La contra: no, no t'estem dient que muntis multi-cloud
Després de cada caiguda global es venen molts projectes de multi-cloud actiu-actiu. Siguem honestos: per a la majoria d'empreses mitjanes és una mala compra. Duplica costos, duplica superfície de fallada, exigeix un equip que sàpiga operar dos núvols igual de bé, i la complexitat afegida provoca les seves pròpies caigudes — la de Cloudflare de novembre la va causar precisament la maquinària interna d'un sistema sofisticat, no la falta de redundància. El que defensem és menys èpic: acceptar el risc residual amb els ulls oberts, cobrir amb diners reals només els processos que de debò maten el negoci, i tenir el mode degradat, els backups i la visibilitat del punt anterior. Amb això, una caiguda de vuit hores del teu proveïdor passa de crisi existencial a mala tarda.
El nostre biaix, dit clarament: operem infraestructura pròpia —Proxmox i Ceph repartits en diversos datacenters, xarxa pròpia amb BGP, trànsit i peering— i també despleguem i gestionem càrregues en núvol públic. No som al bàndol "el núvol és dolent" ni al de "tot al núvol": som al de que cada peça crítica tingui un pla B proporcional al que costa perdre-la.
En clar
AWS tornarà a caure. Cloudflare també. No és una crítica: és l'estadística de nou mesos parlant. La pregunta útil no és "quan caurà el meu proveïdor?", sinó "quant del meu negoci cau amb ell, i durant quant de temps?". Aquesta resposta cap en un full: el mapa de dependències, el mode degradat, la còpia fora del radi d'explosió i algú que ho pugui veure tot des de fora. Si aquest full no existeix a la teva empresa, aquesta setmana és un bon moment per escriure'l — mentre el record del 16 de juliol encara cou.
Fonts (verificades): caiguda de CloudFront del 16-jul-2026 (inici 09:45 UTC, resolta ~17:39 UTC, VPC Origins, afectats Hugging Face, UK National Lottery, Fallout 76) — The Register; esdeveniment tèrmic us-east-1 (us1-az4) del 7/8-maig-2026 — The Register; caiguda us-east-1 del 19/20-oct-2025 (race condition al DNS de DynamoDB, ~15 h) — InfoQ i ThousandEyes; caiguda de Cloudflare del 18-nov-2025 (fitxer de Bot Management, 11:20–17:06 UTC) — postmortem oficial de Cloudflare.
Saps quant del teu negoci cau quan cau el teu proveïdor?
A everyWAN dissenyem plans de disaster recovery amb RTO i RPO honestos: mapa de dependències, mode degradat, backups fora del radi d'explosió i proves de restauració de debò. Sense fum i sense vendre't un segon núvol que no necessites.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN