AWS kan de toegang tot zijn regio in Bahrein en één beschikbaarheidszone in de VAE niet herstellen, blijkt uit een statusupdate die Reuters op 15 september inzag na maandenlange schade door droneaanvallen.
Voor een Nederlandse organisatie met workloads in één cloudregio verandert daarmee de status van back-up van technische voorzorg in een bestuursbeslissing: data en herstelmiddelen moeten buiten de getroffen regio bestaan. Een tweede zone binnen dezelfde regio is niet hetzelfde als uitwijk naar een andere regio.
Bahrein wordt geen tijdelijk incident
In Bahrein, AWS-regio ME-SOUTH-1, gaat AWS verder dan melden dat herstel langer duurt. Het bedrijf zegt dat de schade meerdere Availability Zones besloeg en groter was dan zijn regionale en multi-AZ-diensten aankunnen. AWS kan data en resources die uitsluitend in de Bahrein-regio stonden niet herstellen, en zegt dat het alle opties voor niet-gemigreerde data en resources heeft onderzocht en uitgeput. Een volgende openbare update over Bahrein volgt begin 2027.
De eerste zone raakte in maart beschadigd. AWS adviseerde toen migratie; de regio werd na verstoring van een tweede zone in april onbeschikbaar. Volgens AWS hadden de meeste klanten hun bedrijfsvoering al naar andere regio's verplaatst met back-ups of oplossingen voor ontoegankelijke data. Dat is operationele continuïteit, niet herstel van de oorspronkelijke regio.
In de VAE blijft één zone onbereikbaar
In de VAE ligt de grens anders. In ME-CENTRAL-1 kan AWS resources en data die uitsluitend in mec1-az2 staan niet herstellen. Het werkt nog aan regionale resources en aan resources in mec1-az1 en mec1-az3, en vervangt de getroffen infrastructuur. Een datum voor volledige restauratie noemt AWS niet; de volgende update komt in de komende maanden.
De huidige AWS-statuspagina noemt 136 verstoorde diensten, één gedegradeerde dienst en drie geraakte diensten. Daaronder staan EC2, S3, DynamoDB, Lambda, RDS, CloudWatch, IAM, VPC en de Management Console. Dat maakt de storing relevant voor meer dan compute alleen: opslag, databases, beheer, beveiliging en netwerkfuncties kunnen tegelijk beperkt zijn.
Waarom multi-AZ niet genoeg is

Availability Zones zijn afzonderlijke fysieke locaties binnen één cloudregio. AWS maakt in zijn eigen herstelrichtlijn onderscheid tussen hoge beschikbaarheid binnen één regio en herstel na verlies van een hele regio. Voor dat tweede scenario noemt het document back-ups van data en configuratie in een andere regio; bij S3 en DynamoDB ligt de verantwoordelijkheid voor back-up, versiebeheer en replicatie bij de klant.
Ook de onafhankelijke verslaggeving beschrijft multi-zone redundantie als bescherming tegen één falende locatie, niet tegen schade aan meerdere delen van dezelfde regio.
De grens ligt bij de herstelkopie
Voor een Nederlandse organisatie verschuift de relevante vraag daarmee van welke regio de laagste latency heeft naar welke foutgrens de architectuur kan dragen. Dat raakt dataresidentie, latency, kosten en exitmogelijkheden tegelijk. Wie alle kopieën, infrastructuurdefinities en toegangsmechanismen binnen dezelfde regio houdt, heeft bij regionaal verlies geen volwaardige uitwijk, ook als de applicatie over meerdere zones is verdeeld.
Dat is vooral relevant voor organisaties die een regio kiezen vanwege dataresidentie. Een juridisch toegestane locatie blijft niet vanzelf beschikbaar; een kopie naar een andere regio kan bovendien een aparte toets op contracten, privacy en latency vragen. De AWS-status maakt die spanning zichtbaar zonder dat de primaire applicatie zelf fout hoeft te zijn.
Die grens sluit aan op het uitgangspunt dat de plek van je data en de zeggenschap van je leverancier een bedrijfsrisico vormen. De cloud maakt infrastructuur eenvoudiger te gebruiken, niet geografisch onkwetsbaar. Bahrein en de VAE laten zien dat een regio met meerdere zones geen garantie is tegen een gebeurtenis die meerdere zones tegelijk raakt.
Voor organisaties die op beschikbaarheid bouwen, begint continuïteit daarom bij de grens waar data en herstelkopieën uit elkaar staan.
Veelgestelde vragen
Bouw een uitweg in
Ik ontwerp en bouw systemen die data en processen over meerdere diensten en locaties kunnen verdelen, van meedenken en ontwerp tot realiseren en automatiseren. Waar het kan houd ik de infrastructuur self-hosted en de overstap beheersbaar.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
