BIO 17.01.01 ISO A.12.3

Multi-Region Architectuur Voor Hoge Beschikbaarheid In Azure

📅 2025-11-26
•
⏱️ 25 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Een multi-region architectuur in Azure verspreidt kritieke workloads en data over meerdere geografische regio's, waardoor organisaties beschermd zijn tegen regionale uitval, natuurrampen en grootschalige verstoringen. Voor Nederlandse overheidsorganisaties is dit essentieel om te voldoen aan BIO-eisen rond continuïteit van essentiële diensten en NIS2-verplichtingen voor risicobeheersing en incidentrespons.

Aanbeveling
IMPLEMENTEER EEN MULTI-REGION ARCHITECTUUR VOOR KRITIEKE AZURE-WORKLOADS
Risico zonder
High
Risk Score
9/10
Implementatie
180u (tech: 120u)
Van toepassing op:
✓ Azure Tenant
✓ Kritieke Workloads
✓ Overheidsorganisaties

Kritieke diensten die uitsluitend in één Azure-regio draaien, zijn kwetsbaar voor regionale uitval. Dit kan ontstaan door datacenterstoringen, netwerkproblemen, natuurrampen of grootschalige cyberaanvallen. Wanneer een primaire regio volledig uitvalt, betekent dit voor veel organisaties dat essentiële dienstverlening stilvalt, burgers geen toegang meer hebben tot digitale voorzieningen en bestuurlijke processen worden verstoord. Voor Nederlandse overheidsorganisaties, die verantwoordelijk zijn voor vitale processen zoals basisregistraties, belastingheffing, uitkeringen en veiligheidsdiensten, is dit onacceptabel. De Baseline Informatiebeveiliging Overheid (BIO) schrijft expliciet voor dat organisaties maatregelen moeten treffen om continuïteit van dienstverlening te waarborgen, zelfs bij grootschalige verstoringen. NIS2 versterkt dit door te eisen dat essentiële en belangrijke entiteiten aantoonbaar werkende processen hebben voor incidentrespons en business continuity. Zonder een doordachte multi-region architectuur blijven organisaties afhankelijk van de beschikbaarheid van één regio, wat een onacceptabel risico vormt voor de maatschappelijke verantwoordelijkheid van publieke organisaties.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Resources, Az.Compute, Az.Network, Az.Storage

Implementatie

Dit artikel beschrijft hoe Nederlandse overheidsorganisaties een robuuste multi-region architectuur inrichten voor Azure-workloads. We gaan in op architectuurprincipes zoals actief-passief en actief-actief patronen, de keuze van secundaire regio's binnen de EU Data Boundary, het ontwerpen van failover- en failback-processen, en het beheren van data-replicatie en synchronisatie tussen regio's. Daarnaast behandelen we praktische implementatieaspecten zoals het gebruik van Azure Traffic Manager of Azure Front Door voor geografische load balancing, het configureren van geo-redundante opslag, het inrichten van cross-region netwerkconnectiviteit en het testen van failover-scenario's. Het bijbehorende PowerShell-script helpt bij het monitoren van de multi-region configuratie en het valideren van replicatiestatus. Het resultaat is een architectuur die niet alleen technisch robuust is, maar ook aantoonbaar bijdraagt aan de continuïteitsdoelstellingen zoals vereist door BIO en NIS2.

Architectuurpatronen voor Multi-Region Implementaties

Bij het ontwerpen van een multi-region architectuur in Azure zijn er verschillende patronen beschikbaar, elk met eigen voor- en nadelen. Het actief-passief patroon is het meest eenvoudig: één regio draait als primaire omgeving waar alle verkeer naartoe gaat, terwijl een secundaire regio in stand-by staat met gerepliceerde data en voorbereide infrastructuren. Bij uitval van de primaire regio wordt verkeer omgeleid naar de secundaire regio, die vervolgens actief wordt. Dit patroon is kostenefficiënt omdat de secundaire regio alleen resources verbruikt voor replicatie en minimale testomgevingen, maar heeft als nadeel dat failover-tijd nodig is om de secundaire omgeving volledig operationeel te maken. Voor veel Nederlandse overheidsorganisaties is dit een goede start, vooral voor workloads met een Recovery Time Objective (RTO) van enkele uren. Het actief-actief patroon verdeelt verkeer en verwerking over meerdere regio's die beide volledig operationeel zijn. Dit kan betekenen dat gebruikers automatisch worden gerouteerd naar de dichtstbijzijnde regio voor optimale latency, of dat specifieke workloads of gebruikersgroepen aan specifieke regio's zijn toegewezen. Actief-actief biedt de beste beschikbaarheid en prestaties, maar is complexer om te beheren omdat data-synchronisatie, conflictresolutie en consistentie tussen regio's moeten worden geborgd. Dit patroon is geschikt voor kritieke workloads met zeer lage RTO-eisen, zoals real-time burgerportalen of landelijke registratiesystemen. Een hybride benadering combineert elementen van beide patronen: bepaalde componenten draaien actief-actief (bijvoorbeeld frontend-webapplicaties of API-gateways), terwijl andere componenten actief-passief zijn geconfigureerd (bijvoorbeeld databases of complexe verwerkingssystemen). Deze aanpak biedt flexibiliteit om per workload de juiste balans te vinden tussen beschikbaarheid, kosten en complexiteit. Voor Nederlandse overheidsorganisaties is het verstandig om te starten met een actief-passief patroon voor de meeste workloads en geleidelijk over te stappen naar actief-actief voor de meest kritieke systemen, zodra de organisatie ervaring heeft opgedaan met multi-region beheer. Ongeacht het gekozen patroon is het cruciaal om expliciet vast te leggen welke regio's worden gebruikt, wat de primaire en secundaire rollen zijn, en hoe failover wordt geactiveerd en beheerd. Deze informatie moet worden opgenomen in architectuurdocumentatie, runbooks en crisisprocedures, zodat bij een daadwerkelijke verstoring duidelijk is welke stappen moeten worden genomen en wie verantwoordelijk is voor welke acties.

De keuze van secundaire regio's is een belangrijke architectuurkeuze die zowel technische als compliance-overwegingen omvat. Voor Nederlandse overheidsorganisaties is het essentieel dat beide regio's binnen de EU Data Boundary vallen om te voldoen aan AVG- en BIO-eisen rond dataresidentie. Populaire combinaties zijn bijvoorbeeld West Europe (Nederland) als primaire regio met North Europe (Ierland) als secundaire regio, of vice versa. Andere opties binnen de EU zijn Germany West Central, France Central of Sweden Central, afhankelijk van de specifieke latency-eisen en beschikbaarheid van diensten. Het is belangrijk om te verifiëren dat alle benodigde Azure-services beschikbaar zijn in beide gekozen regio's, omdat niet alle services in alle regio's worden aangeboden. Naast geografische spreiding is het verstandig om rekening te houden met shared risk: regio's die fysiek dicht bij elkaar liggen of dezelfde onderliggende infrastructuur delen, kunnen kwetsbaar zijn voor gelijktijdige uitval. Daarom wordt vaak gekozen voor regio's die in verschillende geografische clusters vallen, bijvoorbeeld een combinatie van West Europe en North Europe, die elk hun eigen datacenterclusters hebben. Dit verkleint de kans dat beide regio's tegelijkertijd worden getroffen door dezelfde verstoring.

Data-Replicatie en Synchronisatie tussen Regio's

Een betrouwbare multi-region architectuur vereist dat data op een veilige en consistente manier wordt gerepliceerd tussen regio's. Azure biedt verschillende mechanismen voor data-replicatie, afhankelijk van het type data en de gewenste replicatiestrategie. Voor opslagaccounts kan geo-redundante opslag (GRS) of geo-zone-redundante opslag (GZRS) worden gebruikt, waarbij data automatisch wordt gerepliceerd naar een secundaire regio. Dit biedt bescherming tegen regionale uitval, maar het is belangrijk om te begrijpen dat GRS asynchroon is: wijzigingen in de primaire regio worden met enige vertraging gerepliceerd naar de secundaire regio. Dit betekent dat bij een failover recente wijzigingen mogelijk verloren gaan, wat de Recovery Point Objective (RPO) bepaalt. Voor databases zoals Azure SQL Database of Cosmos DB zijn er specifieke replicatie-opties beschikbaar. Azure SQL Database biedt actieve geo-replicatie waarbij tot vier leesbare secundaire databases kunnen worden gemaakt in verschillende regio's. Deze replicatie is asynchroon, maar biedt lage latency en kan worden gebruikt voor zowel failover als read-scaling. Cosmos DB heeft ingebouwde multi-region ondersteuning waarbij data automatisch wordt gerepliceerd naar alle geconfigureerde regio's met configurable consistency levels, van strong consistency tot eventual consistency. De keuze van consistency level heeft directe invloed op beschikbaarheid en prestaties: strong consistency biedt de hoogste garanties maar kan leiden tot hogere latency, terwijl eventual consistency betere prestaties biedt maar mogelijk stale reads toelaat. Voor stateful applicaties en virtuele machines kan Azure Site Recovery (ASR) worden gebruikt om volledige VM-replicatie tussen regio's in te richten. ASR repliceert continu de schijven van virtuele machines naar de secundaire regio, waardoor bij een failover de VM's kunnen worden gestart in de secundaire regio met minimale dataverlies. ASR ondersteunt zowel testfailovers (zonder impact op de productie) als geplande en ongeplande failovers. Voor container-workloads zoals Azure Kubernetes Service (AKS) kan geo-replicatie worden gerealiseerd door container images te repliceren naar container registries in meerdere regio's en door AKS-clusters in meerdere regio's te deployen met gedeelde configuratie via GitOps of Infrastructure as Code.

Ongeacht het gekozen replicatiemechanisme is het cruciaal om de replicatiestatus regelmatig te monitoren en te valideren. Replicatielag, fouten en inconsistenties moeten tijdig worden gedetecteerd en opgelost, omdat een niet-werkende replicatie betekent dat bij een failover data verloren gaat of dat de secundaire omgeving niet operationeel kan worden gemaakt. Het bijbehorende PowerShell-script in dit artikel helpt bij het monitoren van replicatiestatus voor verschillende Azure-services, zodat beheerders proactief kunnen ingrijpen wanneer problemen worden gedetecteerd.

Traffic Routing en Load Balancing tussen Regio's

Om verkeer intelligent te routeren tussen meerdere regio's biedt Azure verschillende services. Azure Traffic Manager is een DNS-based traffic load balancer die verkeer kan distribueren op basis van verschillende methoden: performance (routeert naar de regio met de laagste latency), priority (routeert naar primaire regio, failover naar secundaire bij uitval), weighted (verdeelt verkeer volgens gewichten), of geographic (routeert op basis van de geografische locatie van de gebruiker). Traffic Manager werkt op DNS-niveau, wat betekent dat het snel kan reageren op uitval zonder dat clients hun configuratie hoeven aan te passen. Voor Nederlandse overheidsorganisaties is de priority-methode vaak geschikt voor actief-passief patronen, terwijl performance of geographic routing beter past bij actief-actief scenario's. Azure Front Door is een moderne application delivery network (ADN) die naast geografische routing ook web application firewall (WAF), SSL-termination, caching en DDoS-bescherming biedt. Front Door werkt op layer 7 (HTTP/HTTPS) en kan intelligente routing uitvoeren op basis van URL-paden, HTTP-headers of client-locatie. Dit maakt het mogelijk om specifieke workloads naar specifieke regio's te routeren, bijvoorbeeld admin-interfaces naar een beveiligde regio en publieke content naar een regio met optimale latency. Front Door biedt ook health probes die automatisch regio's kunnen uitschakelen wanneer deze niet meer reageren, waardoor failover automatisch plaatsvindt. Voor interne Azure-services en API's kan Azure Application Gateway of Azure Load Balancer worden gebruikt in combinatie met Traffic Manager of Front Door. Application Gateway biedt layer 7 load balancing binnen een regio, terwijl Traffic Manager of Front Door de routing tussen regio's verzorgt. Deze gelaagde aanpak maakt het mogelijk om zowel binnen een regio als tussen regio's optimale prestaties en beschikbaarheid te realiseren.

Bij het configureren van traffic routing is het belangrijk om expliciet te definiëren hoe failover wordt geactiveerd. Automatische failover op basis van health probes is wenselijk voor snelle respons, maar moet worden getest om te verifiëren dat tijdelijke problemen niet leiden tot onnodige failovers. Daarnaast moet worden vastgelegd hoe en wanneer failback plaatsvindt: automatisch zodra de primaire regio weer beschikbaar is, of handmatig na verificatie dat alles stabiel is. Voor kritieke workloads is handmatige failback vaak verstandiger om te voorkomen dat gebruikers worden blootgesteld aan een instabiele primaire omgeving.

Implementatie van Multi-Region Architectuur

De implementatie van een multi-region architectuur begint met een grondige inventarisatie van bestaande workloads: welke applicaties en services zijn kritiek, wat zijn de RTO- en RPO-eisen per workload, en welke data moet worden gerepliceerd? Op basis hiervan wordt een prioritering gemaakt: welke workloads komen als eerste in aanmerking voor multi-region deployment. Kritieke systemen met hoge beschikbaarheidseisen en lage RTO-waarden hebben prioriteit, gevolgd door belangrijke maar minder kritieke workloads. Voor veel Nederlandse overheidsorganisaties betekent dit dat basisregistraties, belastingsystemen en uitkeringssystemen voorrang krijgen. Vervolgens wordt per workload een specifiek ontwerp gemaakt dat beschrijft welke regio's worden gebruikt, welk replicatiemechanisme wordt toegepast, hoe traffic routing is geconfigureerd en welke failover-procedures gelden. Dit ontwerp wordt vastgelegd in architectuurdocumentatie en gekoppeld aan runbooks voor operationele teams. Infrastructure as Code (bijvoorbeeld Bicep, Terraform of ARM-templates) wordt gebruikt om de configuratie van beide regio's te definiëren, zodat de secundaire regio identiek kan worden uitgerold aan de primaire regio. Dit voorkomt configuratiedrift en maakt het mogelijk om wijzigingen consistent door te voeren in beide regio's. Tijdens de implementatie wordt eerst de secundaire regio opgezet met minimale resources voor replicatie en testen. Vervolgens wordt replicatie geconfigureerd en getest om te verifiëren dat data correct wordt gerepliceerd. Daarna worden failover-tests uitgevoerd, eerst in een gecontroleerde omgeving en later tijdens geplande onderhoudsvensters. Deze tests moeten zowel technische als organisatorische aspecten omvatten: niet alleen moet de techniek werken, maar ook moeten teams weten hoe zij moeten handelen tijdens een failover. Documentatie, trainingen en oefeningen zijn daarom essentieel onderdeel van de implementatie.

Een belangrijk aspect van implementatie is kostenbeheersing. Multi-region architectuur betekent dat resources in meerdere regio's draaien, wat de kosten verhoogt. Voor actief-passief patronen kunnen kosten worden beperkt door in de secundaire regio kleinere instance sizes te gebruiken of door bepaalde resources alleen tijdens failover-tests te activeren. Voor actief-actief patronen zijn de kosten hoger, maar kunnen deze worden gecompenseerd door betere prestaties en lagere latency voor gebruikers. Het is belangrijk om kosten expliciet mee te nemen in de besluitvorming en om regelmatig te evalueren of de gekozen architectuur nog steeds de beste balans biedt tussen beschikbaarheid, prestaties en kosten.

Monitoring en Validatie van Multi-Region Configuratie

Gebruik PowerShell-script multi-region-architecture.ps1 (functie Invoke-Monitoring) – Controleert de multi-region configuratie van Azure-workloads, inclusief replicatiestatus, regio-verdeling en failover-readiness.

Monitoring van een multi-region architectuur is essentieel om te verifiëren dat replicatie werkt, dat beide regio's gezond zijn en dat failover-procedures kunnen worden uitgevoerd wanneer nodig. Azure Monitor, Log Analytics en Application Insights bieden uitgebreide mogelijkheden om de status van resources in meerdere regio's te volgen. Dashboards kunnen worden ingericht die per regio de beschikbaarheid, prestaties en fouten tonen, zodat snel kan worden gedetecteerd wanneer een regio problemen ondervindt. Voor data-replicatie is het belangrijk om specifieke metrics te monitoren zoals replicatielag, replicatiefouten en synchronisatiestatus. Voor Azure SQL Database geo-replicatie kunnen deze metrics worden opgehaald via Azure Monitor of via T-SQL queries. Voor opslagaccounts kan de replicatiestatus worden gecontroleerd via de Azure Portal of via PowerShell. Het bijbehorende PowerShell-script in dit artikel automatiseert deze controles en rapporteert de status van multi-region configuraties, zodat beheerders proactief kunnen ingrijpen wanneer problemen worden gedetecteerd. Naast technische monitoring is het belangrijk om regelmatig failover-tests uit te voeren. Deze tests moeten zowel geplande tests (tijdens onderhoudsvensters) als onverwachte tests omvatten om te verifiëren dat teams weten hoe te handelen. De resultaten van tests moeten worden gedocumenteerd en geëvalueerd, en verbeteracties moeten worden opgepakt wanneer problemen worden gevonden. Dit sluit aan bij BIO-eisen rond periodieke tests van continuïteitsmaatregelen en bij NIS2-verplichtingen voor aantoonbaar werkende incidentrespons-processen.

Governance en Best Practices voor Multi-Region Architectuur

Gebruik PowerShell-script multi-region-architecture.ps1 (functie Invoke-Remediation) – Geeft aanbevelingen voor het verbeteren van multi-region configuraties en het oplossen van gedetecteerde problemen.

Governance van een multi-region architectuur vereist duidelijke richtlijnen en processen. Organisaties moeten expliciet vastleggen welke workloads multi-region moeten zijn, welke regio's mogen worden gebruikt, en welke replicatiestrategieën zijn toegestaan. Deze richtlijnen moeten worden opgenomen in cloud governance-beleid en worden afgedwongen via Azure Policy waar mogelijk. Bijvoorbeeld, een policy kan vereisen dat alle productie-workloads met een bepaalde tag automatisch geo-replicatie moeten hebben ingeschakeld. Change management is cruciaal in een multi-region omgeving. Wijzigingen moeten consistent worden doorgevoerd in beide regio's, en er moet worden gecontroleerd dat configuraties niet uit elkaar lopen. Infrastructure as Code helpt hierbij door ervoor te zorgen dat beide regio's vanuit dezelfde broncode worden gedeployed. Daarnaast moeten wijzigingen worden getest in beide regio's voordat zij in productie gaan, om te voorkomen dat een regio anders werkt dan de andere. Documentatie en training zijn essentieel. Operationele teams moeten weten hoe de multi-region architectuur werkt, hoe replicatie is geconfigureerd, en hoe failover-procedures worden uitgevoerd. Runbooks moeten up-to-date zijn en regelmatig worden getest. Bestuurders en CISO's moeten begrijpen wat de beschikbaarheidsgaranties zijn, wat de risico's zijn wanneer een regio uitvalt, en wat de kosten zijn van de multi-region architectuur. Door deze aspecten expliciet te beheren, ontstaat een volwassen multi-region omgeving die niet alleen technisch robuust is, maar ook organisatorisch geborgd.

Tot slot is het belangrijk om regelmatig te evalueren of de gekozen multi-region architectuur nog steeds voldoet aan de eisen. Nieuwe Azure-services, wijzigingen in compliance-eisen, of veranderingen in de risicoprofiel van de organisatie kunnen aanleiding zijn om de architectuur aan te passen. Door periodiek te reviewen en te verbeteren, blijft de multi-region architectuur aligned met de behoeften van de organisatie en voldoet deze aantoonbaar aan BIO- en NIS2-eisen rond continuïteit en risicobeheersing.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Monitoring en validatie van multi-region architectuur in Azure .DESCRIPTION Voert een controle uit op: - Aanwezigheid van resources in meerdere regio's - Replicatiestatus van opslagaccounts en databases - Configuratie van geo-redundantie - Failover-readiness van kritieke workloads Dit script is bedoeld als praktische control die snel inzicht geeft in de multi-region configuratie van Azure-workloads en sluit aan op het artikel 'Multi-Region Architectuur voor Hoge Beschikbaarheid in Azure'. .NOTES Filename: multi-region-architecture.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/availability/multi-region-architecture.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources, Az.Compute, Az.Network, Az.Storage [CmdletBinding()] param( [Parameter()] [switch]$Monitoring, [Parameter()] [switch]$DebugMode ) $ErrorActionPreference = 'Stop' $PolicyName = "Azure Multi-Region Architectuur - Validatie" function Get-EuRegions { <# .SYNOPSIS Geeft de lijst met geaccepteerde EU-regio's terug #> [CmdletBinding()] param() return @( "westeurope", "northeurope", "germanywestcentral", "germanynorth", "norwayeast", "norwaywest", "swedencentral", "swedensouth", "uksouth", "ukwest", "francecentral", "francesouth", "switzerlandnorth", "switzerlandwest", "italynorth", "spaincentral", "polandcentral" ) } function Connect-RequiredServices { [CmdletBinding()] param( [switch]$DebugMode ) if ($DebugMode) { Write-Verbose "DebugMode is ingeschakeld: er wordt geen verbinding met Azure gemaakt." return } if (-not (Get-AzContext -ErrorAction SilentlyContinue)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Test-MultiRegionConfiguration { <# .SYNOPSIS Controleert multi-region configuratie van Azure-workloads .OUTPUTS PSCustomObject met regio-verdeling, replicatiestatus en aanbevelingen #> [CmdletBinding()] param( [switch]$DebugMode ) $euRegions = Get-EuRegions if ($DebugMode) { # Synthetische testdata voor lokale validatie zonder cloudverbinding return [PSCustomObject]@{ Mode = "Debug" TotalSubscriptions = 2 ResourcesWithMultiRegion = 8 ResourcesSingleRegion = 12 StorageAccountsWithGRS = 5 StorageAccountsWithoutGRS = 2 SqlDatabasesWithGeoReplication = 3 SqlDatabasesWithoutGeoReplication = 1 DetectedRegions = @("westeurope", "northeurope") Recommendations = @( "Overweeg geo-redundantie voor 2 opslagaccounts", "Configureer geo-replicatie voor 1 SQL-database" ) } } $subscriptions = Get-AzSubscription -ErrorAction Stop | Where-Object { $_.State -eq 'Enabled' } $regions = [System.Collections.Generic.HashSet[string]]::new([System.StringComparer]::OrdinalIgnoreCase) $resourcesWithMultiRegion = 0 $resourcesSingleRegion = 0 $storageAccountsWithGRS = 0 $storageAccountsWithoutGRS = 0 $sqlDatabasesWithGeoReplication = 0 $sqlDatabasesWithoutGeoReplication = 0 $recommendations = @() foreach ($sub in $subscriptions) { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null try { $resources = Get-AzResource -ErrorAction SilentlyContinue if ($resources) { foreach ($r in $resources) { if (-not $r.Location) { continue } $null = $regions.Add($r.Location.ToLowerInvariant()) # Eenvoudige heuristiek: resources in meerdere regio's hebben vaak multi-region configuratie $sameTypeInOtherRegions = $resources | Where-Object { $_.ResourceType -eq $r.ResourceType -and $_.Location -ne $r.Location -and $_.Name -like "$($r.Name)*" } if ($sameTypeInOtherRegions) { $resourcesWithMultiRegion++ } else { $resourcesSingleRegion++ } } } } catch { Write-Verbose "Kon resources voor subscription '$($sub.Name)' niet ophalen: $_" } try { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue foreach ($sa in $storageAccounts) { if ($sa.GeoReplicationEnabled -or $sa.Sku.Tier -like "*GRS*" -or $sa.Sku.Tier -like "*GZRS*") { $storageAccountsWithGRS++ } else { $storageAccountsWithoutGRS++ if ($sa.Tags -and $sa.Tags.ContainsKey("Criticality") -and $sa.Tags["Criticality"] -eq "High") { $recommendations += "Overweeg geo-redundantie voor opslagaccount '$($sa.StorageAccountName)' (kritieke workload)" } } } } catch { Write-Verbose "Kon opslagaccounts voor subscription '$($sub.Name)' niet ophalen: $_" } try { $sqlServers = Get-AzSqlServer -ErrorAction SilentlyContinue foreach ($server in $sqlServers) { $databases = Get-AzSqlDatabase -ServerName $server.ServerName -ResourceGroupName $server.ResourceGroupName -ErrorAction SilentlyContinue foreach ($db in $databases) { $geoReplicas = Get-AzSqlDatabaseReplicationLink -ServerName $server.ServerName -DatabaseName $db.DatabaseName -ResourceGroupName $server.ResourceGroupName -ErrorAction SilentlyContinue if ($geoReplicas -and $geoReplicas.Count -gt 0) { $sqlDatabasesWithGeoReplication++ } else { $sqlDatabasesWithoutGeoReplication++ if ($db.Tags -and $db.Tags.ContainsKey("Criticality") -and $db.Tags["Criticality"] -eq "High") { $recommendations += "Overweeg geo-replicatie voor SQL-database '$($db.DatabaseName)' (kritieke workload)" } } } } } catch { Write-Verbose "Kon SQL-databases voor subscription '$($sub.Name)' niet ophalen: $_" } } # Controleer of resources in meerdere EU-regio's zijn verdeeld $euRegionsUsed = $regions | Where-Object { $euRegions -contains $_ } if ($euRegionsUsed.Count -lt 2) { $recommendations += "Overweeg resources te verspreiden over minimaal 2 EU-regio's voor betere beschikbaarheid" } [PSCustomObject]@{ Mode = "Live" TotalSubscriptions = $subscriptions.Count ResourcesWithMultiRegion = $resourcesWithMultiRegion ResourcesSingleRegion = $resourcesSingleRegion StorageAccountsWithGRS = $storageAccountsWithGRS StorageAccountsWithoutGRS = $storageAccountsWithoutGRS SqlDatabasesWithGeoReplication = $sqlDatabasesWithGeoReplication SqlDatabasesWithoutGeoReplication = $sqlDatabasesWithoutGeoReplication DetectedRegions = @($regions) | Sort-Object Recommendations = $recommendations } } try { Connect-RequiredServices -DebugMode:$DebugMode if ($Monitoring) { $result = Test-MultiRegionConfiguration -DebugMode:$DebugMode Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Modus : {0}" -f $result.Mode) -ForegroundColor White Write-Host ("Subscripties : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Resources met multi-region config : {0}" -f $result.ResourcesWithMultiRegion) -ForegroundColor White Write-Host ("Resources in enkele regio : {0}" -f $result.ResourcesSingleRegion) -ForegroundColor White Write-Host ("Opslagaccounts met GRS/GZRS : {0}" -f $result.StorageAccountsWithGRS) -ForegroundColor White Write-Host ("Opslagaccounts zonder GRS/GZRS : {0}" -f $result.StorageAccountsWithoutGRS) -ForegroundColor White Write-Host ("SQL-databases met geo-replicatie : {0}" -f $result.SqlDatabasesWithGeoReplication) -ForegroundColor White Write-Host ("SQL-databases zonder geo-replicatie: {0}" -f $result.SqlDatabasesWithoutGeoReplication) -ForegroundColor White if ($result.DetectedRegions -and $result.DetectedRegions.Count -gt 0) { Write-Host ("Gedetecteerde regio's : {0}" -f ($result.DetectedRegions -join ", ")) -ForegroundColor White } if ($result.Recommendations -and $result.Recommendations.Count -gt 0) { Write-Host "" -ForegroundColor White Write-Host "Aanbevelingen:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -ForegroundColor Yellow } } if ($result.StorageAccountsWithoutGRS -gt 0 -or $result.SqlDatabasesWithoutGeoReplication -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Er zijn resources zonder geo-redundantie gedetecteerd. Overweeg multi-region configuratie voor kritieke workloads." -ForegroundColor Yellow } } else { $result = Test-MultiRegionConfiguration -DebugMode:$DebugMode Write-Host "" Write-Host ("Multi-region architectuur check: {0} subscripties, {1} resources met multi-region, {2} opslagaccounts met GRS, {3} SQL-databases met geo-replicatie" -f ` $result.TotalSubscriptions, ` $result.ResourcesWithMultiRegion, ` $result.StorageAccountsWithGRS, ` $result.SqlDatabasesWithGeoReplication) } } catch { Write-Error $_ exit 1 } # ================================================================================ # Standaard Invoke-* Functions (conform Azure script-schema) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert configuratie (delegeert naar remediatie) #> [CmdletBinding()] param( [switch]$DebugMode ) Invoke-Remediation -DebugMode:$DebugMode } function Invoke-Monitoring { <# .SYNOPSIS Voert de monitoringcheck uit voor multi-region architectuur #> [CmdletBinding()] param( [switch]$DebugMode ) try { Connect-RequiredServices -DebugMode:$DebugMode $result = Test-MultiRegionConfiguration -DebugMode:$DebugMode Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Modus : {0}" -f $result.Mode) -ForegroundColor White Write-Host ("Subscripties : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Resources met multi-region config : {0}" -f $result.ResourcesWithMultiRegion) -ForegroundColor White Write-Host ("Resources in enkele regio : {0}" -f $result.ResourcesSingleRegion) -ForegroundColor White Write-Host ("Opslagaccounts met GRS/GZRS : {0}" -f $result.StorageAccountsWithGRS) -ForegroundColor White Write-Host ("Opslagaccounts zonder GRS/GZRS : {0}" -f $result.StorageAccountsWithoutGRS) -ForegroundColor White Write-Host ("SQL-databases met geo-replicatie : {0}" -f $result.SqlDatabasesWithGeoReplication) -ForegroundColor White Write-Host ("SQL-databases zonder geo-replicatie: {0}" -f $result.SqlDatabasesWithoutGeoReplication) -ForegroundColor White if ($result.DetectedRegions -and $result.DetectedRegions.Count -gt 0) { Write-Host ("Gedetecteerde regio's : {0}" -f ($result.DetectedRegions -join ", ")) -ForegroundColor White } if ($result.Recommendations -and $result.Recommendations.Count -gt 0) { Write-Host "" -ForegroundColor White Write-Host "Aanbevelingen:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -ForegroundColor Yellow } } if ($result.StorageAccountsWithoutGRS -gt 0 -or $result.SqlDatabasesWithoutGeoReplication -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Er zijn resources zonder geo-redundantie gedetecteerd. Overweeg multi-region configuratie voor kritieke workloads om te voldoen aan BIO- en NIS2-eisen rond continuïteit." -ForegroundColor Yellow } } catch { Write-Error $_ exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Ondersteunt remediatie door aanbevelingen te geven voor multi-region configuratie .DESCRIPTION Dit script voert geen automatische remediatie uit, maar geeft duidelijke aanwijzingen om multi-region configuratie te verbeteren en geo-redundantie in te richten voor kritieke workloads. #> [CmdletBinding()] param( [switch]$DebugMode ) Write-Host "[INFO] Dit is een monitoringgerichte control zonder automatische remediatie." -ForegroundColor Yellow Write-Host "[INFO] Gebruik de aanbevelingen om multi-region configuratie te verbeteren:" -ForegroundColor Yellow Write-Host " - Configureer geo-redundantie voor opslagaccounts via Azure Portal of PowerShell" -ForegroundColor Yellow Write-Host " - Stel geo-replicatie in voor SQL-databases via Azure Portal of T-SQL" -ForegroundColor Yellow Write-Host " - Overweeg Azure Site Recovery voor VM-replicatie tussen regio's" -ForegroundColor Yellow Write-Host " - Gebruik Azure Traffic Manager of Front Door voor traffic routing tussen regio's" -ForegroundColor Yellow Write-Host "" Invoke-Monitoring -DebugMode:$DebugMode }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder multi-region architectuur blijven organisaties volledig afhankelijk van de beschikbaarheid van één Azure-regio. Regionale uitval kan leiden tot langdurige onbeschikbaarheid van kritieke diensten, niet-naleving van BIO- en NIS2-eisen rond continuïteit, reputatieschade en verlies van vertrouwen bij burgers en bestuurders.

Management Samenvatting

Een multi-region architectuur verspreidt kritieke workloads over meerdere Azure-regio's binnen de EU Data Boundary, waardoor organisaties beschermd zijn tegen regionale uitval. Door actief-passief of actief-actief patronen te kiezen, data-replicatie in te richten, traffic routing te configureren en regelmatig te monitoren en testen, ontstaat een robuuste architectuur die aantoonbaar bijdraagt aan continuïteit van essentiële diensten zoals vereist door BIO en NIS2.