Två tillgänglighetszoner, sex timmar isär
Klockan 12:51 UTC den 2 mars 2026 slutade tillgänglighetszonen som AWS betecknar mec1-az2, i regionen Mellanöstern Emiraten, att fungera normalt. Klockan 18:46 UTC samma dag var även mec1-az3 drabbad. AWS bekräftade att båda hade träffats direkt av drönare under den bredare konflikten i området. En tredje anläggning, mes1-az2 i den separata regionen Bahrain, hade störts omkring 06:56 UTC den måndagen, vilket AWS tillskrev ett drönarangrepp i omedelbar närhet med fysiska följder för bolagets infrastruktur.
Träffarna orsakade bränder. Bränderna utlöste datacentrens sprinklersystem, och vattnet skadade utrustning. AWS uppgav att kunderna såg höga felfrekvenser vid inläsning och utleverans av data på tjänster som S3, som behöver minst en frisk zon per region för att fungera. Bolaget uppskattade att återställandet av anläggningarna och deras kylsystem skulle ta minst ett dygn.
Håll kvar den uppskattningen genom resten av texten. Den gavs i god tro, av en operatör med bättre information än någon kund hade, och den beskrev reparationen korrekt.
Meningen i meddelandet som faktiskt spelade roll
Vid sidan av statusuppdateringarna sade AWS något mer följdriktigt till kunderna. Bolaget rådde dem att säkra sina data och eventuellt flytta sina arbetslaster till andra AWS-regioner, på grunden att den pågående konflikten i området gjorde driftsmiljön oförutsägbar. Molnleverantörer ber inte lättvindigt en betalande kund att lämna en region som de själva säljer.
Det meddelandet är den användbara kvarlevan från hela händelsen, eftersom det är den enda instruktion som träffar det verkliga felsättet. Sprinklerskada är en reparation. En oförutsägbar driftsmiljö är ingen reparation, det är en egenskap hos platsen, och ingen teknik inne i byggnaden ändrar den. AWS sade i praktiken till kunderna att det rätta svaret på den här klassen av händelser är utträde och inte tålamod.
Den obekväma delen: de flesta återställningshandböcker har en sida om att vänta och ingen om att ge sig av.
Minst ett dygn, mätt mot kalendern
Den 30 april angav AWS egen tjänstestatus att regionen Mellanöstern Emiraten hade lidit skada till följd av konflikten i Mellanöstern och för närvarande inte tillförlitligt kunde bära kundernas program. Notera vad som ändrades i den meningen. I mars hade regionen ett avbrott och en uppskattning. I slutet av april hade den ett tillstånd och ingen uppskattning alls.
Den 28 juli publicerade Cloudflare sin kvartalsgenomgång av störningshändelser på internet, hämtad från nätverksdata i Radar. Där står att HTTP-trafiken till me-central-1 har förblivit låg, och den ihållande minskningen beskrivs som den nedströms signaturen av fysisk skada på den underliggande datacenterinfrastrukturen. Det är en oberoende mätning snarare än ett leverantörsuttalande, och den pekar åt samma håll ungefär fem månader efter träffarna.
Räkneövningen till nästa kontinuitetsgenomgång: den publicerade uppskattningen löd på minst ett dygn, och det observerbara svaret mäts fortfarande i månader.
Regional motståndskraft är ritad mot fel avbrott
En arkitektur över flera tillgänglighetszoner är ett genuint bra svar på det fel den ritades mot. Zoner separeras så att en brand, en översvämning, en elhändelse eller ett nätfel i en inte tar med sig de andra. Det designantagandet håller utmärkt så länge faran är lokal för en byggnad och oberoende mellan byggnader. Det slutar hålla när faran är regional och korrelerad, för då mäts avståndet mellan zoner i kilometer och det som orsakar skadan gör det inte.
Två av de tre zonerna i Emiraten träffades samma dag. En anläggning i en annan region, i ett annat land, drabbades samma vecka. Zonoberoende är ett fysiskt påstående om en bestämd lista av faror, och väpnad konflikt står inte på den listan. Det är värt att säga rakt ut, eftersom det är den del som i efterhand låter självklar och i förväg nästan aldrig dyker upp i en designgenomgång.
För europeiska företag finns skyldigheten redan: finansiella enheter som omfattas av DORA är skyldiga sin tillsynsmyndighet en dokumenterad utträdes- och kontinuitetsplan för kritiska it-leverantörer, och den planen ska bära att en leverantörsregion blir otillgänglig och inte bara långsam.
Fyra ändringar i din handbok den här veckan
För det första, skriv ned ditt faktiska mål för återställningstid vid förlust av en hel region och inte en zon, och var ärlig om huruvida du någonsin har testat det. Är det ärliga svaret att regionförlust ligger utanför omfattningen är det ett beslut, och det bör antecknas med en namngiven ansvarig i stället för att lämnas som en utelämning. För det andra, skilj dina reparationsscenarier från dina utträdesscenarier. Ett reparationsscenario väntar. Ett utträdesscenario flyttar sig, och det behöver sina data, sin identitetskonfiguration och sina nätverksvägar redan förberedda någon annanstans.
För det tredje, bestäm i förväg vilket underlag som skulle utlösa en flytt. Den användbara utlösaren var här inte avbrottet den 2 mars, utan meddelandet som bad kunderna överväga migrering. Leverantörer säger det sällan, och när de gör det bör det behandlas som signalen och inte som bakgrundsbrus. För det fjärde, kontrollera var dina säkerhetskopior fysiskt finns. En säkerhetskopia inne i den region du försöker lämna är ingen säkerhetskopia, och stunden då du behöver den är stunden då regionen är problemet.
Läs vidare: OpenAI betalade tillbaka i det som gick sönder | En fjärde molnjätte blir mer trolig
