Je Azure-omgeving lijkt op papier weerbaar. Je hebt back-ups, Availability Zones, SLA’s en misschien een tweede regio. Maar wat doet je workload als er echt iets uitvalt?
Je klanten willen geen uitleg over een storing in Azure PostgreSQL. Ze willen een bestelling kunnen plaatsen. Als dat niet lukt, kost het je omzet.
Leestijd 9 minuten Gepubliceerd: 30 oktober 2026
IN HET KORT:
Azure resiliency is het vermogen van je workload en cloudinfrastructuur om verstoringen op te vangen en te blijven werken zonder merkbare gevolgen voor klanten.
Dat kan gaan om een infrastructuurprobleem of plotselinge piekbelasting, maar ook om de uitval van een Availability Zone, een regionale verstoring of een cyberaanval.
“De meeste organisaties weten niet of hun infrastructuur weerbaar is. Ze weten alleen hoe die is ontworpen. Maar is bij dat ontwerp ook rekening gehouden met weerbaarheid?”
Wesley Haakman, Principal Azure Architect
Azure resiliency omvat drie samenhangende onderdelen:
Een hoog beschikbare applicatie helpt weinig als je na een aanval geen betrouwbare data kunt herstellen. Back-ups garanderen evenmin dat klanten tijdens een regionale storing kunnen doorwerken. Bekijk daarom de volledige workload.
Microsoft levert de basis:
Jij bent verantwoordelijk voor je applicatie, afhankelijkheden, hersteldoelstellingen, back-ups en disaster recovery.
Bij wettelijke vereisten of eisen rond soevereiniteit bepaal je ook waar data mag staan en hoe verplaatsing en herstel binnen die grenzen blijven.
Regionale verstoringen beginnen niet altijd binnen Azure. Cloudapplicaties zijn afhankelijk van telecomnetwerken en onderzeese kabels. Schade aan kabels, aanlandingsstations of telecominfrastructuur kan communicatieroutes verstoren.
Zo raakten de onderzeese kabelverstoringen in de Rode Zee in 2025 internetverbindingen in delen van het Midden-Oosten en Azië. Microsoft meldde verhoogde latency in de regio, waarna de Azure-services werden hersteld.
Je Azure-resources kunnen dus draaien terwijl klanten toch hinder ondervinden.
Regionale weerbaarheid vraagt daarom ook aandacht voor connectiviteit, latency, capaciteit, data residency en de mogelijkheid om elders te draaien.
Infrastructuur in twee regio’s helpt niet als je applicatie niet kan overschakelen. Een gedeelde afhankelijkheid kan uitvallen, data kan verkeerd synchroniseren of je deployment vereist functionaliteit die in de tweede regio ontbreekt.
Meerdere regio’s kunnen bijdragen aan een weerbare architectuur. Ze bewijzen niet dat je workload blijft werken.
Een workload werkt niet gegarandeerd ongewijzigd in een andere Azure-regio. Regio’s kunnen verschillen in:
Ook je deploymentconfiguratie telt mee. Een hardgecodeerde regio in je Infrastructure as Code (IaC) of deploymentscript kan deployment elders blokkeren.
Gebruikt de beschikbare capaciteit in je herstelregio ARM-processors? Dan moeten je container images ook ARM ondersteunen.
Een tweede regio is pas nuttig als je workload daar daadwerkelijk draait.
Een Azure Well-Architected assessment brengt risico’s en verbeterpunten rondom reliability, security en andere belangrijke onderdelen van je cloudomgeving in kaart.
Laat je Azure-omgeving beoordelenDe technisch meest logische failoverlocatie is niet altijd toegestaan voor je data. Geopolitieke weerbaarheid raakt daarmee ook aan soevereiniteit.
Sommige Azure-regio’s vormen region pairs, andere niet. Geografie, regelgeving en soevereiniteit beïnvloeden je herstelkeuzes. Gevoelige data over een landsgrens verplaatsen kan bijvoorbeeld uitgesloten zijn.
Mogelijke benaderingen zijn:
Je disaster recovery-strategie moet bij je workload passen, niet andersom.
Hoog beschikbare Azure-infrastructuur kan nog steeds een kwetsbare applicatie draaien. Je code moet uitval correct afhandelen om Azure’s mogelijkheden te benutten.
Veelvoorkomende applicatierisico’s zijn:
Softwarearchitectuur kan zo de beperkende factor worden voor Azure resiliency.
Dat speelt vooral bij lift-and-shift-migraties. Je verplaatst een bestaand probleem naar Azure, maar lost het daarmee niet op. Ook developmentpraktijken moeten rekening houden met uitval.
De SLA’s van PostgreSQL, Azure DNS en je VM Scale Set kunnen afzonderlijk goed zijn. Maar wat gebeurt er als één afhankelijkheid uitvalt en je hele applicatie stopt?
Losse beschikbaarheidspercentages geven geen volledig beeld. Je klant merkt dat je dienst niet werkt, ongeacht welke resource uitvalt.
SLA’s blijven relevant voor contracten en compliance. Operationeel zijn dit betere vragen:
Meet weerbaarheid vanuit je workload en klant, niet resource voor resource.
Met Cloud Control houd je grip op je Azure-omgeving en ontdek je continu waar je weerbaarheid, security en performance kunt verbeteren.
Ontdek Cloud ControlAzure resiliency vraagt om samenhang tussen infrastructuur, applicatiearchitectuur, databescherming, regionaal herstel en tests.
Geen enkele architectuur past bij elke workload. Breng herstelsnelheid, kosten, complexiteit, wettelijke vereisten en operationele inspanning in balans.
Een workload die bestand is tegen zone-uitval moet blijven werken wanneer een Availability Zone wegvalt.
Een VM offline halen simuleert niet het verlies van een volledige zone. Je workload heeft ook afhankelijkheden in data, netwerken en andere services. Test daarom hoe de applicatie reageert als die samen wegvallen.
Je keuze hangt af van de workload, hersteldoelstellingen, geografische risico’s en wettelijke beperkingen. Meer redundantie is niet automatisch beter.
Veelgebruikte benaderingen zijn:
Meer weerbaarheid brengt ook kosten en complexiteit mee. Active/active kan passen bij grote financiële gevolgen van downtime. Voor andere workloads biedt active/passive een betere balans.
Hoeveel verstoring kan je workload verdragen en wat wil je uitgeven om dat risico te verkleinen?
Ga ervan uit dat infrastructuur en afhankelijkheden kunnen uitvallen. De afhandeling hoort in je applicatiearchitectuur, niet alleen in je infrastructuur.
Houd rekening met:
Let vooral op verborgen afhankelijkheden. Ook een multi-region applicatie kan door één gedeeld onderdeel volledig uitvallen. Breng die relaties in kaart om single points of failure te herkennen.
Is een tweede regio onderdeel van je herstelplan? Toon dan aan dat je daar kunt deployen.
Controleer je IaC op regioafhankelijke aannames. Valideer services, SKU’s, Availability Zones, processorarchitecturen, capaciteit en subscriptionquota in de doelregio.
“We kunnen elders opnieuw deployen” is pas een herstelstrategie als het aantoonbaar werkt.
Een ongeteste architectuur blijft gebaseerd op aannames. Uitvaltests laten zien hoe je volledige workload reageert wanneer resources, afhankelijkheden of zones wegvallen.
Test bijvoorbeeld een uitgevallen VM, verbroken netwerkverbinding, DNS-storing of onbeschikbare Availability Zone.
Met Azure Chaos Studio kun je via fault injection hypotheses toetsen en game days uitvoeren. Simuleer bijvoorbeeld VM-uitval, netwerkproblemen of DNS-storingen.
Dit is chaos engineering: storingen nabootsen om systeemgedrag te onderzoeken en zwakke plekken te vinden. Regelmatige tests tonen aan of je herstelmechanismen ook tijdens verstoringen werken.
Azure Infrastructure Resiliency Manager, geïntroduceerd tijdens Microsoft Build 2026 en beschikbaar in public preview, beoordeelt weerbaarheid op applicatie- en resourceniveau.
Het combineert mogelijkheden van Azure Advisor, Azure Chaos Studio en Azure Monitor. Met service groups beoordeel je resources uit meerdere resource groups en subscriptions als één workload.
De aanpak kent drie fasen:
De waarde zit in het meten op workloadniveau en het opnemen van continue validatie in je dagelijkse operatie.
De Azure Resiliency Agent beoordeelt workloads op risico’s, configuratiefouten en afwegingen rond weerbaarheid. De agent kan kosten, beschikbaarheid en compliance meenemen en IaC-templates voor verbeteringen genereren.
Zo wordt weerbaarheid onderdeel van DevOps-workflows, in plaats van een afzonderlijke architectuurreview.
De Azure Backup MCP Server maakt ook back-upvalidatie, controles op herstelgereedheid en beleidsgestuurde herstelacties programmeerbaar.
Azure resiliency gaat om blijven werken, belangrijke data beschermen en veilig herstellen als er iets misgaat.
Applicaties en afhankelijkheden veranderen. Je huidige omgeving kan daardoor afwijken van de architectuur die je oorspronkelijk ontwierp.
Geen enkel patroon neemt elk risico weg. Het doel is om risico’s te verkleinen, relevante scenario’s te testen en te weten hoe je workload reageert.
Uiteindelijk telt één vraag: blijft je dienst werken als er iets misgaat?
Wat is resiliency in Azure?
Maken meerdere Azure-regio’s je automatisch weerbaar?
Hoe vaak moet je Azure resiliency testen?
Moet elke Azure-workload active/active-regio’s gebruiken?
Wat controleer je voordat je een tweede Azure-regio kiest?
Wat test je tijdens een Azure resilience drill?
Wanneer beoordeel je je Azure-architectuur opnieuw?