To tilgængelighedszoner med seks timers mellemrum

Klokken 12:51 UTC den 2. marts 2026 holdt tilgængelighedszonen, som AWS betegner mec1-az2, i regionen Mellemøsten Emiraterne op med at fungere normalt. Klokken 18:46 UTC samme dag var mec1-az3 også ramt. AWS bekræftede, at begge var blevet direkte ramt af droner under den bredere konflikt i området. En tredje facilitet, mes1-az2 i den særskilte region Bahrain, var blevet forstyrret omkring 06:56 UTC den mandag, hvilket AWS tilskrev et droneangreb i umiddelbar nærhed med fysiske følger for selskabets infrastruktur.

Nedslagene udløste brande. Brandene aktiverede datacentrenes sprinkleranlæg, og vandet beskadigede udstyr. AWS oplyste, at kunderne så høje fejlrater ved indlæsning og udlevering af data på tjenester som S3, der kræver mindst én sund zone per region for at fungere. Selskabet anslog, at genopretning af faciliteterne og deres kølesystemer ville tage mindst et døgn.

Hold fast i det skøn resten af artiklen. Det blev givet i god tro af en operatør med bedre oplysninger end nogen kunde havde, og det beskrev reparationen præcist.

Sætningen i meddelelsen, der faktisk betød noget

Ved siden af statusopdateringerne sagde AWS noget mere vidtrækkende til kunderne. Selskabet rådede dem til at sikre deres data og eventuelt flytte arbejdslaster til andre AWS-regioner, fordi den igangværende konflikt i området gjorde driftsmiljøet uforudsigeligt. Skyleverandører beder ikke let en betalende kunde om at forlade en region, de selv sælger.

Den meddelelse er det brugbare levn fra hele forløbet, for den er den eneste anvisning, der rammer den faktiske fejlform. Sprinklerskade er en reparation. Et uforudsigeligt driftsmiljø er ingen reparation, det er en egenskab ved stedet, og ingen teknik inde i bygningen ændrer det. AWS sagde reelt til kunderne, at det rigtige svar på denne slags hændelser er exit og ikke tålmodighed.

Den ubehagelige del: de fleste beredskabshåndbøger har en side om at vente og ingen om at rejse.

Mindst et døgn, målt mod kalenderen

Den 30. april oplyste AWS' egen driftsstatus, at regionen Mellemøsten Emiraterne havde lidt skade som følge af konflikten i Mellemøsten og på det tidspunkt ikke pålideligt kunne bære kundernes programmer. Læg mærke til, hvad der ændrede sig i den sætning. I marts havde regionen et nedbrud og et skøn. Ved udgangen af april havde den en tilstand og slet intet skøn.

Den 28. juli offentliggjorde Cloudflare sin kvartalsgennemgang af forstyrrelseshændelser på internettet, baseret på netværksdata fra Radar. Heri står, at HTTP-trafikken til me-central-1 er forblevet lav, og den vedvarende nedgang beskrives som den nedstrøms signatur af fysisk skade på den underliggende datacenterinfrastruktur. Det er en uafhængig måling frem for en leverandørudtalelse, og den peger samme vej omkring fem måneder efter nedslagene.

Regnestykket til din næste kontinuitetsgennemgang: det offentliggjorte skøn lød på mindst et døgn, og det observerbare svar måles stadig i måneder.

Regional robusthed er tegnet mod den forkerte fejl

En arkitektur over flere tilgængelighedszoner er et ægte godt svar på den fejl, den blev tegnet mod. Zoner adskilles, så en brand, en oversvømmelse, en strømhændelse eller en netfejl i én ikke tager de andre med. Den designantagelse holder fremragende, så længe faren er lokal for en bygning og uafhængig mellem bygninger. Den holder ikke længere, når faren er regional og korreleret, for så måles afstanden mellem zoner i kilometer, og det, der forvolder skaden, gør ikke.

To af de tre zoner i Emiraterne blev ramt samme dag. En facilitet i en anden region, i et andet land, blev ramt samme uge. Zoneuafhængighed er en fysisk påstand om en bestemt liste af farer, og væbnet konflikt står ikke på den liste. Det er værd at sige klart, fordi det er den del, der bagefter lyder indlysende og forinden næsten aldrig dukker op i en designgennemgang.

For europæiske virksomheder findes pligten allerede: finansielle enheder omfattet af DORA skylder deres tilsyn en dokumenteret exit- og kontinuitetsplan for kritiske it-leverandører, og den plan skal kunne bære, at en leverandørregion bliver utilgængelig og ikke blot langsom.

Fire ændringer i din håndbog i denne uge

For det første: skriv dit reelle mål for genopretningstid ved tab af en hel region og ikke en zone, og vær ærlig om, hvorvidt du nogensinde har afprøvet det. Er det ærlige svar, at tab af region ligger uden for rammen, så er det en beslutning, og den bør noteres med en navngiven ansvarlig frem for at stå som en udeladelse. For det andet: adskil dine reparationsscenarier fra dine exitscenarier. Et reparationsscenarie venter. Et exitscenarie flytter sig og har brug for sine data, sin identitetsopsætning og sine netværksruter klargjort et andet sted i forvejen.

For det tredje: afgør på forhånd, hvilket bevis der ville udløse en flytning. Den brugbare udløser var her ikke nedbruddet den 2. marts, men meddelelsen, der bad kunderne overveje at migrere. Leverandører siger sjældent det, og når de gør, bør det behandles som signalet og ikke som baggrundsstøj. For det fjerde: undersøg, hvor dine sikkerhedskopier fysisk ligger. En sikkerhedskopi inde i den region, du forsøger at forlade, er ingen sikkerhedskopi, og det øjeblik, du får brug for den, er det øjeblik, hvor regionen er problemet.

Læs videre: OpenAI betalte tilbage i det, der brød ned  |  En fjerde skygigant bliver mere plausibel