Twee beschikbaarheidszones, zes uur uit elkaar

Om 12:51 UTC op 2 maart 2026 stopte de beschikbaarheidszone die AWS aanduidt als mec1-az2, in zijn regio Midden-Oosten Emiraten, met normaal functioneren. Om 18:46 UTC diezelfde dag was ook mec1-az3 getroffen. AWS bevestigde dat beide rechtstreeks door drones waren geraakt tijdens het bredere conflict in het gebied. Een derde locatie, mes1-az2 in de afzonderlijke regio Bahrein, was rond 06:56 UTC die maandag verstoord, wat AWS toeschreef aan een droneaanval in de directe nabijheid die fysieke gevolgen had voor zijn infrastructuur.

De inslagen veroorzaakten branden. De branden activeerden de sprinklerinstallaties van de datacenters, en het water beschadigde apparatuur. AWS meldde dat klanten hoge foutpercentages zagen bij het inlezen en uitleveren van gegevens bij diensten zoals S3, dat minstens één gezonde zone per regio nodig heeft om te werken. Het bedrijf schatte dat het herstellen van de locaties en hun koelsystemen minstens een dag zou vergen.

Houd die schatting vast voor de rest van dit stuk. Zij werd te goeder trouw gegeven, door een exploitant met betere informatie dan welke klant ook, en zij beschreef de reparatie accuraat.

De zin in het advies die er werkelijk toe deed

Naast de statusberichten zei AWS iets met grotere gevolgen. Het raadde klanten aan hun gegevens veilig te stellen en hun werklasten mogelijk naar andere AWS-regio's te verplaatsen, op grond dat het aanhoudende conflict in het gebied de bedrijfsomgeving onvoorspelbaar maakte. Cloudaanbieders vragen een betalende klant niet lichtvaardig een regio te verlaten die zij zelf verkopen.

Dat advies is het bruikbare overblijfsel van de hele episode, want het is de enige instructie die de werkelijke faalwijze aanpakt. Sprinklerschade is een reparatie. Een onvoorspelbare bedrijfsomgeving is geen reparatie, het is een eigenschap van de locatie, en geen enkele techniek binnen het gebouw verandert daar iets aan. AWS zei klanten in wezen dat het juiste antwoord op deze klasse van gebeurtenissen vertrek is en geen geduld.

Het ongemakkelijke deel: de meeste herstelhandboeken hebben een pagina voor wachten en geen enkele voor vertrekken.

Minstens een dag, afgezet tegen de kalender

Op 30 april vermeldde de eigen dienstenstatus van AWS dat de regio Midden-Oosten Emiraten schade had geleden als gevolg van het conflict in het Midden-Oosten en op dat moment klantapplicaties niet betrouwbaar kon dragen. Let op wat er in die zin veranderde. In maart had de regio een storing en een schatting. Eind april had zij een toestand en helemaal geen schatting.

Op 28 juli publiceerde Cloudflare zijn kwartaaloverzicht van verstoringen van het internet, gebaseerd op de netwerkgegevens van Radar. Daarin staat dat het HTTP-verkeer naar me-central-1 laag is gebleven, en de aanhoudende daling wordt beschreven als de stroomafwaartse signatuur van fysieke schade aan de onderliggende datacenterinfrastructuur. Dat is een onafhankelijke meting in plaats van een uitspraak van de leverancier, en zij wijst ongeveer vijf maanden na de inslagen dezelfde kant op.

De rekensom voor uw volgende continuïteitsevaluatie: de gepubliceerde schatting was minstens een dag, en het waarneembare antwoord wordt nog steeds in maanden gemeten.

Regionale weerbaarheid is op de verkeerde storing ontworpen

Een architectuur over meerdere beschikbaarheidszones is een oprecht goed antwoord op de storing waarvoor zij is ontworpen. Zones worden gescheiden zodat een brand, een overstroming, een stroomincident of een netwerkfout in de ene niet de andere meeneemt. Die ontwerpaanname houdt prachtig stand zolang het gevaar lokaal is aan een gebouw en onafhankelijk tussen gebouwen. Zij houdt niet meer stand wanneer het gevaar regionaal en gecorreleerd is, want dan wordt de afstand tussen zones in kilometers gemeten en datgene wat de schade veroorzaakt niet.

Twee van de drie zones in de Emiraten werden op dezelfde dag geraakt. Een locatie in een andere regio, in een ander land, werd diezelfde week getroffen. Zone-onafhankelijkheid is een fysieke bewering over een specifieke lijst gevaren, en gewapend conflict staat niet op die lijst. Dit is het waard om helder te zeggen, omdat het het deel is dat achteraf vanzelfsprekend klinkt en vooraf vrijwel nooit in een ontwerpevaluatie opduikt.

Voor Europese bedrijven bestaat de verplichting al: financiële entiteiten onder DORA zijn hun toezichthouder een gedocumenteerd exit- en continuïteitsplan verschuldigd voor kritieke ICT-dienstverleners, en dat plan moet bestand zijn tegen het onbeschikbaar worden van een leveranciersregio en niet alleen tegen traagheid.

Vier wijzigingen in uw handboek deze week

Ten eerste, schrijf uw werkelijke hersteltijddoelstelling op voor het verlies van een hele regio en niet van een zone, en wees eerlijk over de vraag of u die ooit hebt getest. Is het eerlijke antwoord dat regioverlies buiten scope valt, dan is dat een besluit, en het hoort met een benoemde eigenaar te worden vastgelegd in plaats van als weglating te blijven staan. Ten tweede, scheid uw reparatiescenario's van uw vertrekscenario's. Een reparatiescenario wacht. Een vertrekscenario beweegt, en het heeft zijn gegevens, zijn identiteitsconfiguratie en zijn netwerkroutes al elders klaarstaan nodig.

Ten derde, bepaal vooraf welk bewijs een verhuizing zou activeren. De bruikbare trigger was hier niet de storing van 2 maart, het was het advies dat klanten opriep migratie te overwegen. Leveranciers zeggen dat zelden, en wanneer zij het doen hoort het als het signaal te worden behandeld en niet als achtergrondruis. Ten vierde, controleer waar uw back-ups zich fysiek bevinden. Een back-up binnen de regio die u probeert te verlaten is geen back-up, en het moment waarop u hem nodig hebt is het moment waarop de regio het probleem is.