DIGITAL RESILIENCE
Verwoeste datacenters AWS, OVH en NorthC vragen om digitale weerbaarheid
Verwoeste datacenters AWS, OVH en NorthC vragen om digitale weerbaarheid
De cloud is niet onverwoestbaar
De cloud heeft een merkwaardige eigenschap gekregen in het denken over continuïteit: hoe groter de aanbieder, hoe gemakkelijker organisaties aannemen dat uitval eigenlijk niet meer hun probleem is. De infrastructuur staat immers ergens anders, wordt professioneel beheerd en beschikt over meerdere datacenters, availability zones en noodvoorzieningen.
TEKST: Sander Hulsman & Rashid Niamat BEELD: WONDERWORKS
De gebeurtenissen bij AWS in de Verenigde Arabische Emiraten maken duidelijk waar die redenering tekortschiet. In maart 2026 werden twee AWS-locaties in de regio Abu Dhabi getroffen door Iraanse droneaanvallen. De fysieke schade was zo groot dat stroomvoorziening en infrastructuur langdurig uitvielen. In september bevestigde AWS bovendien dat gegevens die uitsluitend in één van de getroffen availability zones waren opgeslagen, niet meer konden worden hersteld.
Dat is een fundamenteel ander soort incident dan de traditionele cloudstoring. Het gaat niet om een softwarefout, een verkeerd uitgerolde update of een tijdelijke stroomonderbreking. De fysieke infrastructuur zelf werd vernietigd. Daarmee komt een ongemakkelijke vraag op tafel, want hoe resilient is een cloud wanneer de fysieke werkelijkheid onder die cloud verandert?
Redundantie ≠ resilience
Voor bestuurders is dat onderscheid belangrijk. Availability zones, clusters, dubbele voedingen en geografisch verspreide systemen zijn allemaal vormen van redundantie. Maar redundantie werkt alleen zolang de aannames achter het ontwerp kloppen.
Een cloudregio is dus geen back-upstrategie op zichzelf
Bij AWS is zichtbaar geworden dat meerdere availability zones binnen één regio niet automatisch betekenen dat een organisatie bestand is tegen een grootschalige fysieke calamiteit. AWS stelt dat de meeste klanten hun activiteiten inmiddels konden hervatten doordat zij back-ups hadden, gegevens konden kopiëren of workloads naar andere regio’s konden verplaatsen. Maar precies daar zit de crux, want die laatste stap moet vooraf architectonisch, organisatorisch en contractueel zijn geregeld. Een cloudregio is dus geen back-upstrategie op zichzelf.
Dat inzicht is niet nieuw. Het verschil is dat het in het verleden vooral werd gekoppeld aan brand, stroomuitval, overstroming of menselijke fouten. De gebeurtenissen in de Golfregio voegen een andere categorie toe, namelijk die van fysieke vernietiging als gevolg van een geopolitiek conflict.
Reuters berichtte dat nieuwe plannen voor grootschalige AI-datacenters in de regio inmiddels worden aangepast. In plaats van één omvangrijke campus wordt gekeken naar meer spreiding, grotere fysieke afstanden tussen gebouwen en het ondergronds brengen van delen van de infrastructuur. Daarmee verandert ook de betekenis van redundantie. Niet alleen componenten moeten dubbel zijn; ook de blast radius van een incident moet worden beperkt.
Straatsburg: zelfde probleem, kleinere schaal
Vijf jaar eerder liet de brand bij OVHcloud in Straatsburg al zien hoe snel digitale afhankelijkheid kan botsen met fysieke realiteit. In de nacht van 9 op 10 maart 2021 ging een datacenter op de locatie in vlammen op. Een tweede gebouw raakte eveneens buiten gebruik. Duizenden klanten werden getroffen en een deel van de data ging verloren. Een belangrijk element was daarbij dat niet alle klanten een back-upstrategie hadden die onafhankelijk was van de getroffen infrastructuur.
Wie alleen naar de beschikbaarheid van een platform kijkt, kan een vals gevoel van continuïteit krijgen
Het incident leidde uiteindelijk tot een opvallende reactie van OVHcloud: het bedrijf besloot back-ups voortaan standaard en kosteloos aan te bieden. Daarmee werd impliciet een belangrijk onderscheid zichtbaar. Een dienst kan technisch beschikbaar worden geleverd zonder dat daarmee automatisch wordt gegarandeerd dat de onderliggende data bij een calamiteit herstelbaar zijn. Wie alleen naar de beschikbaarheid van een platform kijkt, kan daardoor een vals gevoel van continuïteit krijgen.
Ook certificeringen bieden daarbij geen volledige zekerheid. De discussie rond OVH liet zien dat bijvoorbeeld ISO 27001 niets zegt over de vraag of een gebouw een grote brand kan weerstaan. Een certificering heeft altijd een scope. Voor bestuur en toezicht is daarom niet alleen de vraag of een leverancier gecertificeerd is relevant, maar vooral waarop die certificering betrekking heeft en welke risico’s buiten de scope vallen.
Almere: risico buiten datavloer
Het incident bij NorthC in Almere in mei 2026 voegt daar nog een derde dimensie aan toe. De brand ontstond niet in de datavloer met de systemen van klanten, maar in het technische deel van het gebouw. Juist daardoor werd zichtbaar hoe afhankelijk de digitale dienstverlening is van alles wat buiten de eigenlijke serverruimte gebeurt.
De brand bleef uiteindelijk buiten de datavloeren en de brandscheiding beperkte de rookverspreiding. Toch raakte de stroomvoorziening ernstig verstoord. NorthC moest generatoren, UPS-systemen, verdelers en meer dan een kilometer bekabeling inzetten om de infrastructuur gefaseerd weer beschikbaar te maken.
Fysieke gebeurtenis in technische infrastructuur kan alsnog meerdere afhankelijkheden tegelijk raken
Dat is een relevante les voor organisaties die hun continuïteitsanalyse vooral op applicaties en servers richten. Een applicatie kan volledig redundant zijn uitgevoerd, terwijl een fysieke gebeurtenis in de technische infrastructuur alsnog meerdere afhankelijkheden tegelijk raakt.
Dit incident is een herinnering aan het vaak onderschatte aspect van resilience dat werkzaamheden en onderhoud zelf een risicocategorie vormen. Dat geldt voor datacenters, maar net zo goed voor de infrastructuur van organisaties die ervan afhankelijk zijn. De meeste aandacht gaat vanzelfsprekend naar de productieomgeving. De vraag is of dezelfde discipline ook wordt toegepast op werkzaamheden aan elektriciteit, koeling, bekabeling en andere ondersteunende systemen.
Van uptime naar impact
Voor bestuurders verandert daarmee de relevante vraag. Het gaat niet langer alleen om de vraag hoeveel negens er achter de beschikbaarheid in een SLA staan. Een beschikbaarheid van 99,9 of 99,99 procent zegt immers weinig over wat er gebeurt wanneer een specifieke locatie daadwerkelijk verdwijnt. De belangrijkere vraag is dan hoe snel de organisatie haar kritieke dienstverlening kan hervatten, en hoeveel data en bedrijfsfunctionaliteit zij bereid is te verliezen.
Dat vraagt om een andere manier van kijken naar cloud en datacenter resilience. Organisaties moeten precies weten welke data uitsluitend op één fysieke locatie of binnen één cloudregio staat en hoe afhankelijk bedrijfskritische workloads zijn van die specifieke infrastructuur. Ook moet duidelijk zijn hoeveel tijd het in werkelijkheid kost om een workload naar een andere regio of omgeving te verplaatsen. Op papier kan zo’n mogelijkheid bestaan, terwijl de praktijk aanzienlijk weerbarstiger is. Denk bijvoorbeeld aan afhankelijkheden van identity and access management, DNS, netwerkconnectiviteit, certificaten, encryptiesleutels en andere diensten die nodig zijn om een applicatie daadwerkelijk weer operationeel te krijgen.
Als zowel productie als back-up via dezelfde leverancier worden geleverd, kan één incident beide voorzieningen tegelijk raken
Hetzelfde geldt voor back-ups. Een back-up is pas een echte continuïteitsmaatregel wanneer die voldoende onafhankelijk is van de productieomgeving. Een kopie die zich fysiek in dezelfde omgeving bevindt, of afhankelijk is van dezelfde infrastructuur die tijdens een incident uitvalt, biedt bij een grootschalige calamiteit mogelijk veel minder bescherming dan op papier wordt aangenomen. Daarbij gaat het niet alleen om technische onafhankelijkheid, maar ook om organisatorische en contractuele onafhankelijkheid. Als zowel productie als back-up bij dezelfde leverancier, in dezelfde regio of via dezelfde onderliggende infrastructuur worden geleverd, kan één incident beide voorzieningen tegelijk raken.
RPO en RTO
Daarom moeten ook de eigen recovery objectives scherp zijn gedefinieerd. Twee begrippen zijn daarbij essentieel: RPO (Recovery Point Objective) en RTO (Recovery Time Objective). De RPO geeft aan hoeveel gegevensverlies een organisatie maximaal kan accepteren, uitgedrukt in tijd. Een RPO van vijftien minuten betekent bijvoorbeeld dat de organisatie ervan uitgaat dat zij bij een ernstig incident maximaal vijftien minuten aan transacties of andere gegevens mag kwijtraken. De RTO gaat over iets anders, namelijk hoelang het maximaal mag duren voordat een systeem of bedrijfsproces na een incident weer beschikbaar is. Bij een RTO van vier uur moet de organisatie dus in staat zijn om de betreffende dienstverlening binnen vier uur te herstellen.
Een recovery objective is een operationele capaciteit die aantoonbaar moet kunnen worden waargemaakt
Die twee doelstellingen moeten niet alleen op papier bestaan, maar aansluiten op de daadwerkelijke bedrijfsvoering en technische mogelijkheden. Een RPO van enkele minuten heeft weinig betekenis wanneer het herstelproces in de praktijk dagen duurt. En een RTO van vier uur is evenmin veel waard wanneer een organisatie nog nooit heeft aangetoond dat zij een volledige workload naar een andere regio kan verplaatsen en daar daadwerkelijk kan laten functioneren. Een recovery objective is uiteindelijk geen technische belofte, maar een operationele capaciteit die aantoonbaar moet kunnen worden waargemaakt.
Verborgen afhankelijkheden zichtbaar maken
Dat betekent ook dat testen een wezenlijk onderdeel van resilience wordt. Een failover-procedure die alleen in een architectuurdocument bestaat, is nog geen bewezen continuïteitsmaatregel. Pas wanneer organisaties daadwerkelijk oefenen met het wegvallen van een datacenter, cloudregio of essentiële leverancier, worden verborgen afhankelijkheden zichtbaar. Juist dan blijkt vaak dat niet de primaire applicatie het grootste probleem vormt, maar de systemen en diensten die eromheen zijn gebouwd.
Resilience ontstaat daarmee uiteindelijk niet door simpelweg meer redundante infrastructuur aan te schaffen. Het gaat erom dat een organisatie vooraf bepaalt welke uitval zij moet kunnen verdragen, welke bedrijfsfuncties daarbij overeind moeten blijven en hoeveel data en tijd zij maximaal kan verliezen. Vervolgens moet zij aantoonbaar kunnen maken dat de gekozen technische architectuur, leveranciers, contracten en herstelprocedures die doelstellingen ook daadwerkelijk ondersteunen. De echte maatstaf voor digitale weerbaarheid is daarom niet hoeveel infrastructuur dubbel is uitgevoerd, maar wat er overblijft wanneer een belangrijk deel daarvan daadwerkelijk wegvalt.
Nieuwe kwetsbaarheid: concentratie
Daarmee komt ook een bredere beleidsvraag naar voren. De groei van cloud en AI leidt wereldwijd tot steeds grotere datacenterclusters. Economisch is concentratie aantrekkelijk, want energievoorziening, glasvezel, netwerkconnectiviteit, grond en gespecialiseerde kennis kunnen efficiënt worden gecombineerd. Maar wat efficiënt is, is niet automatisch resilient.
Als fysieke dreigingen veranderen, moeten ook ontwerpcriteria veranderen
Een cluster van datacenters kan technisch redundant zijn en tegelijkertijd geografisch kwetsbaar. Als meerdere locaties dezelfde elektriciteitsinfrastructuur, glasvezelroutes, watervoorziening, toeleveranciers of fysieke omgeving delen, kan één incident een veel grotere impact hebben dan de afzonderlijke beschikbaarheidsmodellen suggereren.
De gebeurtenissen rond AWS maken die discussie urgent. Als fysieke dreigingen veranderen, moeten ook ontwerpcriteria veranderen. Dat geldt voor hyperscalers, maar uiteindelijk ook voor de klanten die hun bedrijfsvoering daarop bouwen.
Resilience wordt bestuursvraagstuk
De belangrijkste les uit AWS, OVH en NorthC is daarom niet dat datacenters kwetsbaar zijn. Dat wisten we al. De les is dat digitale weerbaarheid steeds minder kan worden teruggebracht tot de betrouwbaarheid van afzonderlijke componenten. Een datacenter kan redundant zijn. Een cloudplatform kan redundant zijn. Een applicatie kan redundant zijn. En toch kan de dienstverlening verdwijnen.
De echte toets is de afstand tussen het incident en het bedrijfsproces. Hoeveel fysieke, technische, geografische en organisatorische afhankelijkheden zitten daar nog tussen? Voor de boardroom betekent dit dat cloud resilience onderdeel moet worden van business continuity en enterprise risk management. Niet als technische exercitie van de IT-afdeling, maar als expliciete bedrijfskeuze. Want welke verstoring kan de organisatie accepteren, voor hoe lang en tegen welke kosten?
De AWS-incidenten in de VAE geven die discussie een nieuwe urgentie. OVH liet zien wat brand kan doen. NorthC laat zien dat zelfs een brand buiten de datavloer grote gevolgen kan hebben. De gemeenschappelijke factor is niet het type incident, maar de afhankelijkheid. De cloud heeft veel risico’s verplaatst. Hij heeft ze niet laten verdwijnen. En misschien is dat wel de belangrijkste definitie van digital resilience: niet de belofte dat systemen nooit uitvallen, maar de zekerheid dat een organisatie haar kritieke functies kan blijven uitvoeren wanneer dat wel gebeurt. 