Lessen uit de Cloudflare-storing: veerkrachtige cloudarchitectuur bouwen

Op 18 november 2025 kreeg Cloudflare — een grote leverancier van content delivery en internetinfrastructuur die ruwweg 1 op de 5 webverzoeken wereldwijd afhandelt — te maken met een omvangrijke netwerkstoring[1]. Het gevolg: tientallen bekende diensten zoals ChatGPT, X (voorheen Twitter) en andere applicaties waren urenlang geheel of gedeeltelijk onbereikbaar[2].

De storing bleek uiteindelijk voort te komen uit een configuratiefout in een intern bestand voor botbeheer — geen aanval dus — maar liet wel zien hoe kwetsbaar zelfs de meest robuuste infrastructuur is[3].

Voor organisaties die bezig zijn met cloudtransformatie, softwarelevering en landing zone-architectuur (zoals wij bij ZEN) is dit een wekker. Hoe bouw je systemen die overeind blijven wanneer je provider — of een cruciaal onderdeel daarvan — het begeeft?

In dit artikel delen we de lessen die we uit het incident hebben getrokken, en hoe je die toepast bij het ontwerpen of herzien van je cloudarchitectuur.

Rond 11:20 UTC zag Cloudflare een piek in “ongebruikelijk verkeer” op het netwerk. De oorzaak bleek een onverwachte groei van een bestand dat hoort bij hun Bot Management-dienst. Het bestand werd te groot, waardoor proxysystemen crashten en er een lawine van 5xx-fouten door het netwerk rolde.

De storing raakte kerndiensten, waaronder Workers KV, Access en het dashboard. Het geheel duurde enkele uren — het meeste verkeer liep rond 14:30 UTC weer, en volledig herstel was er rond 17:06 UTC.

Wat je hieruit meeneemt: dit was geen DDoS-aanval, maar een interne configuratiewijziging die zich wereldwijd verspreidde en grote infrastructuur platlegde — een illustratie van hoe storingen bij je provider door je hele stack rimpelen.

Storingen van deze omvang onderstrepen iets simpels: zelfs breed verdeelde edge- en CDN-providers kunnen op onvoorziene manieren omvallen. Gaat jouw architectuur uit van “Cloudflare (of provider X) staat altijd aan”, dan loop je risico.

Wat dat betekent voor je veerkracht:

• Ontwerp op provideruitval: neem aan dat je edge-provider omvalt en bedenk hoe je verkeer dan omgeleid wordt of netjes terugvalt.

• Vermijd afhankelijkheid van één provider: je edge of CDN is misschien hoog beschikbaar — maar hoe zit het met de control-plane-diensten (WAF, access, bots, proxy's)?

• Terugvalopties tellen: zit je stack strak vast aan de functies van één provider, dan heb je een stevige terugval- of afgeschaalde modus nodig.

Het rapport van Cloudflare laat zien hoe lastig het is om cascadestoringen te diagnosticeren wanneer de oorzaak diep in configuratielogica verstopt zit.

Voor jouw systemen:

• Bewaak je providerafhankelijkheden: weet welke diensten je gebruikt (botbeheer, edge proxy, KV, authenticatie) en hoe storingen zich voortplanten.

• Leg heldere herstelroutes vast: wat neemt het over als component X van je provider uitvalt? In het geval van Cloudflare beperkte het omzeilen van de proxy voor Workers KV de schade.

• Oefen je failover: het nabootsen van een storing bij een providerdienst maakt je weerbaarder — niet alleen voor uitvallende applicatieservers, maar ook voor verstoringen in infrastructuur, edge en CDN.

Veel systemen kennen maar twee standen: “helemaal in de lucht” of “plat”. De Cloudflare-storing laat zien dat diensten ook afgeschaald kunnen draaien (hogere latency, 500-fouten) en toch deels werken.

Zorg dat je systemen netjes terugvallen:

• Terugval naar een andere regio: valt één regio of providerzone weg, dan stroomt het verkeer naar een andere.

• Feature toggles en gecontroleerd afschalen: gaan je geavanceerde edge-functies (bots, WAF) onderuit, laat gebruikers dan door met beperkte functionaliteit in plaats van helemaal op zwart.

• Communiceer met je gebruikers: meld bij een SaaS of app open en eerlijk dat je in een afgeschaalde modus draait, in plaats van mensen tegen een plotselinge zwarte pagina te laten aanlopen.

Bouw je aan je cloud landing zone of applicatiearchitectuur, denk dan aan veerkracht in lagen, verdeeld over providers en diensten:

• gebruik meer dan één CDN- of edge-provider (of op zijn minst meerdere POP's of zones)

• scheid je control plane van je data plane — bijvoorbeeld met onafhankelijke authenticatie- of WAF-diensten

• versioneer je providerspecifieke logica (zoals botbeheerregels of feature files) en test die onder productieachtige omstandigheden

Dat sluit aan op het “Cloud Landing Zone”-principe van ZEN: bouw een goed doordacht fundament waarin afhankelijkheden helder zijn, veerkracht is ingebakken en je operatie uitgaat van uitval.

We beschouwen het uitrollen van applicaties vaak als het riskante moment — terwijl juist configuratiewijzigingen bij je provider, aangepaste rechten of uitgerolde functies (zoals bij Cloudflare) de oorzaak kunnen zijn van grote storingen.

Je proces hoort te bevatten:

• gecontroleerde uitrol van providerconfiguraties (canary, ring deployment, gefaseerd)

• geautomatiseerde validatie van wijzigingen (bestandslimieten, grootte van feature files, schommelingen in responstijden)

• zicht op de configuratiestand bij je provider en de bijbehorende wijzigingshistorie

Een lijstje dat je deze week kunt doorlopen:

• breng al je externe infrastructuurafhankelijkheden in kaart (CDN, WAF, botbeheer, edge proxy's)

• vraag je bij elke afhankelijkheid af: “als dit uitvalt, hoe schaalt mijn verkeer dan af?”

• voer buiten werktijd een storingsoefening uit op één afhankelijkheid (zet bijvoorbeeld de botmodule uit) en beoordeel de impact

• bouw of test een terugvalroute of alternatieve provider

• richt changemanagement in voor providerconfiguraties, zeker voor edge- en securityfuncties

• neem de gevolgen van edge- en providerstoringen op in de documentatie en verantwoordelijkheden van je landing zone

De Cloudflare-storing is meer dan een nieuwsbericht — het is een duidelijke herinnering dat zelfs “wereldwijde” providers op diepe en ingewikkelde manieren kunnen falen. Voor organisaties die naar cloud-native bewegen, microservices omarmen of hoogbeschikbare SaaS bouwen, moet veerkracht ook de lagen omvatten die je meestal niet ziet: edge-infrastructuur, CDN, botbeheer en de control planes van je provider.

Onze kijk bij ZEN is simpel: hoge beschikbaarheid betekent niet “altijd in de lucht” — het betekent “altijd voorbereid op uitval”. Bouw vanuit de aanname dat je edge-provider het begeeft, toets je alternatieven regelmatig, en zorg dat je landing zone de klap kan opvangen.

Want in architectuur bepaalt de manier waarop je met falen omgaat vaak hoe succesvol je bent.