Wat er gebeurt als een cloudregio uitvalt

De meeste teams bouwen hun systemen op kleine storingen.

Een container crasht. Een node verdwijnt. Misschien heeft een availability zone een tijdje last. Dat zijn de scenario's waar architectuurplaten je op voorbereiden, en de meeste platformen vangen ze goed genoeg op dat je het nauwelijks merkt.

Een regiostoring is van een heel andere orde. Hij komt zelden voor, en juist daarom schuif je hem makkelijk weg. Maar als het gebeurt, is de klap er meteen en laat hij zich moeilijk indammen. In plaats van één onderdeel dat raar doet, vallen hele lagen tegelijk weg.

Het eerste wat je merkt is niet altijd een duidelijke storing. Dingen houden gewoon op te werken, op vreemde manieren. Requests blijven hangen. Sommige endpoints geven fouten, andere lopen in een timeout. Achtergrondjobs verwerken niets meer, zonder dat er een alarm afgaat. Systemen die van elkaar afhankelijk zijn, vallen na elkaar om, en het is niet altijd duidelijk waar het begon.

Moderne cloudsystemen zijn diep met elkaar verweven, ook als het op papier niet zo lijkt.

Een API hangt aan een database, die hangt aan een managed storagelaag, die weer leunt op interne netwerk- en identityservices. Valt een regio weg, dan begeven die afhankelijkheden het niet netjes één voor één. Ze verdwijnen tegelijk, en alles wat erbovenop is gebouwd volgt.

Wat het lastig maakt: sommige delen van je systeem lijken misschien nog te draaien. Een service staat nog overeind, maar kan zijn database niet bereiken. Een andere serveert nog cachede antwoorden, waardoor het lijkt alsof het deels goed gaat. Van buitenaf oogt het als een gedeeltelijke storing. Van binnenuit staat vrijwel alles stil.

Je workloads over availability zones verdelen geldt vaak als hét antwoord op veerkracht, en tegen lokale storingen helpt het ook echt.

Het probleem is dat een regiostoring zich niet gedraagt als een zone-storing. Regio's zijn ontworpen om zones van elkaar te isoleren, maar ze delen nog altijd onderliggende systemen. Gaat het op dát niveau mis, dan kunnen meerdere zones tegelijk geraakt worden — soms op manieren die je niet meteen doorziet.

Er zijn incidenten geweest waarbij storage- of netwerkproblemen zich over zones heen verspreidden, terwijl de architectuur precies dat had moeten voorkomen. Van buitenaf zag alles er keurig verdeeld uit. In de praktijk sneed de storing dwars door die grenzen heen.

Multi-AZ verkleint het risico dus wel, maar neemt het niet weg. Het lost een andere klasse problemen op.

Valt een grote regio uit, dan blijven de gevolgen zelden binnen één systeem of zelfs één bedrijf.

Grote delen van het internet leunen op dezelfde providers en vaak op dezelfde regio's. Gaat er één om, dan duiken de naschokken op plekken op die je er niet meteen mee in verband brengt. Interne tools doen het niet meer. Koppelingen met derden vallen weg. Diensten die niets met elkaar te maken leken te hebben, blijken dezelfde onderliggende afhankelijkheid te delen.

Wat teams meestal verrast, is niet zozeer dat hun eigen applicatie plat ligt, maar dat de tools waarmee ze het probleem normaal zouden onderzoeken of oplossen óók onbereikbaar zijn.

Ook nadat de provider de regio hersteld heeft, springt niet alles meteen terug in de plooi.

Er heeft zich tegen die tijd van alles opgestapeld. Requests die niet verwerkt konden worden, staan ergens te wachten. Queues zijn volgelopen. Geplande jobs zijn overgeslagen. Caches zijn leeg en moeten opnieuw opgebouwd. Systemen die verse data nodig hebben, lopen uit de pas.

Op de statuspagina staat de storing misschien al als opgelost. Operationeel valt er nog een boel te ontwarren. De prestaties blijven een tijdje wisselvallig, en juist in die fase duiken vervolgproblemen op.

Het is verleidelijk om te denken dat je failover wel uitvogelt tijdens een incident.

In werkelijkheid improviseren systemen niet. Ze gedragen zich naar de beslissingen die al genomen zijn. Is er geen duidelijk pad om verkeer elders heen te sturen, dan gebeurt dat niet. Is data buiten de regio niet beschikbaar, dan blijft die onbeschikbaar. Zijn er geen prioriteiten bepaald, dan vecht alles tegelijk om aandacht.

Teams die storingen goed doorstaan, hebben meestal vooraf besloten hoe ver ze willen gaan om beschikbaar te blijven en welke afwegingen ze acceptabel vinden. De rest neemt die beslissingen onder druk — zelden het moment waarop je consistentie tegen beschikbaarheid wilt afwegen, of kosten tegen hersteltijd.

Over meerdere regio's draaien wordt vaak gepresenteerd als de logische volgende stap.

Het verkleint inderdaad de kans dat één regio je hele boel meesleurt, maar het verandert ook de vorm van je systeem. Data moet gerepliceerd worden, en dat roept vragen op over consistentie en latency. Deployments worden ingewikkelder. Observability wordt lastiger, want je hebt nu meerdere omgevingen die zich niet per se identiek gedragen.

En er speelt iets praktisch mee: niet elk systeem hoeft tijdens een regiostoring volledig door te draaien. Voor sommige producten volstaat een goed uitgevoerd herstel. Voor andere, zeker met strenge uptime-eisen, is de investering in multi-region wél logisch.

Eén detail wordt vaak over het hoofd gezien: waar staat je control plane?

Zitten je CI/CD-pipelines, je infrastructuurstate of je deploytools in dezelfde regio als je applicatie, dan kan een storing je het vermogen ontnemen om überhaupt nog iets te wijzigen. Op dat moment worden zelfs simpele fixes lastig door te voeren.

Een ongemakkelijke situatie: het systeem ligt plat, en juist het gereedschap waarmee je het overeind zou helpen, is onbereikbaar.

Het komt zelden voor, en precies daarom wordt het bij het ontwerp makkelijk vergeten.

Een regiostoring aankunnen betekent niet dat je vanaf dag één een wereldwijd verdeeld systeem moet bouwen.

Wat meer telt, is dat je scherp hebt wat er zou gebeuren als je primaire regio een tijd wegvalt. Waar staat je data? Kun je die elders terugzetten? Hoe zou je verkeer omleiden, en wie besluit wanneer dat gebeurt?

Zelfs een eenvoudige, goed opgeschreven aanpak is beter dan aannemen dat je het ter plekke wel bedenkt. Systemen gedragen zich onder stress juist heel voorspelbaar — het venijn zit erin dat de uitkomst allang vastlag voordat het incident begon.

Cloudplatformen zijn ontworpen op hoge beschikbaarheid, maar ze zijn niet immuun voor grootschalige storingen.

Elk systeem loopt vroeg of laat tegen omstandigheden aan waar het niet volledig op voorbereid was. Een regiostoring is daar een van de duidelijkste voorbeelden van. Hij legt aannames bloot die verborgen blijven zolang alles werkt zoals verwacht.

De vraag is niet óf er ergens ooit een regio omvalt. De vraag is wat jouw systeem dan doet — en of dat gedrag overeenkomt met wat je voor ogen had toen je het ontwierp.