Here is the multi-region Azure pattern I keep reaching for in regulated environments. I have deployed variants of it at reinsurers, insurers, and energy companies — environments where DORA, Solvency II, or KRITIS compliance is not optional, where data residency is a hard constraint, and where an availability zone outage in Frankfurt is not a theoretical risk but a board-level scenario. The pattern is not exotic. It is deliberately conservative. Conservative is what gets through a regulatory review.
Why This Pattern, Why Now
Two forces are converging in European regulated industries.
The first is the DORA regulation (Digital Operational Resilience Act), which became applicable in January 2025 and requires financial entities to demonstrate ICT business continuity across scenarios including the loss of a primary data centre. "We have backups" is no longer sufficient. You need a tested, documented recovery capability with defined RTO and RPO, and the evidence that you have exercised it. This has pushed multi-region from aspirational to mandatory for banks, insurers, and reinsurers across the EU.
The second is the maturation of Azure's German-region footprint. Germany West Central (Frankfurt) is now a mature region with a full feature set. Germany North (Berlin) is the paired region and suitable as a standby. For workloads with strict data residency requirements, this pairing keeps all data in Germany — relevant for energy sector KRITIS compliance and for organisations with German data protection requirements that preclude non-German-region processing.
The pattern I describe here is active-passive, not active-active. I want to explain that choice before going further.
Why active-passive and not active-active
Active-active multi-region is the answer to a specific problem: you need to serve traffic from two regions simultaneously, either for latency reasons or because your resilience requirement is measured in seconds, not minutes. For most regulated European workloads, active-passive with a 15-minute RTO satisfies DORA and equivalent requirements, costs roughly half as much to operate, and eliminates the distributed consistency problems that make active-active architectures genuinely difficult to build correctly. Default to active-passive. Active-active has a real use case; it is just narrower than most architects think.
The Subscription and Management Group Structure
Regulated workloads need clear boundaries. I use the following subscription model:
- Platform subscriptions: Connectivity (hub networking, VPN/ExpressRoute, Azure Firewall, DNS), Management (Log Analytics, Automation, Defender for Cloud), and Identity (Entra ID, domain controllers if required).
- Workload subscriptions: One subscription per workload per environment, named explicitly (
payments-prod,payments-staging,claims-prod). In regulated industries, the subscription boundary also serves as the audit boundary — every action within a subscription is logged to a dedicated Log Analytics workspace with retention policies set to satisfy the applicable regulation (typically 5–7 years for financial services). - Sandbox subscriptions: Isolated from production management groups, with Azure Policy preventing production data from entering sandbox environments.
All subscriptions sit beneath a management group hierarchy where policies at the root enforce non-negotiable controls: allowed regions (Germany only for the regulated workloads), mandatory resource tagging, Defender for Cloud enablement, and diagnostic settings deployment.
Hub-and-Spoke Networking, Replicated
The networking model is hub-and-spoke in each region, connected by global VNet peering. The primary hub in Germany West Central contains:
- Azure Firewall Premium (threat intelligence, TLS inspection, IDPS)
- ExpressRoute or VPN Gateway for on-premises connectivity
- Azure Bastion for secure administrative access (no public RDP or SSH)
- Private DNS zones for all Azure PaaS services
The standby hub in Germany North mirrors this topology. When a failover is triggered — either manually or via automation — the Traffic Manager DNS record switches the application endpoint to the standby region's frontend. Because the network topology is already present and identical, no infrastructure provisioning is required during failover. This is the part that most organisations get wrong: they treat the standby region as something to provision during a disaster, rather than something to keep warm at all times.
The full topology looks like this:
| Network Control | Primary Region | Standby Region | Notes |
|---|---|---|---|
| Azure Firewall Premium | Active | Warm standby | Same policy set, shared Firewall Manager |
| NSGs on all subnets | Active | Active (identical rules) | IaC-managed, drift detection enabled |
| Private Link for all PaaS | Active | Active | No PaaS services on public endpoints |
| DDoS Protection Standard | Active | Active | Per-VNet, billed per region |
| Network Watcher | Active | Active | Flow logs to Log Analytics |
Compute: AKS with Regional Node Pools
Application workloads run on Azure Kubernetes Service. In the primary region, the AKS cluster is production-grade: system node pools on Standard_D4s_v5 or equivalent, user node pools sized to the workload, cluster autoscaler enabled, Availability Zones spread across all three zones in Germany West Central.
In the standby region, the AKS cluster runs at reduced capacity — typically 30–50% of production node count — with autoscaler configured to scale out quickly when promoted to primary. This "warm standby" approach costs roughly 30–50% of full replication while maintaining the 15-minute RTO target, because the cluster bootstraps from pre-pulled images and the data tier is already warm.
Both clusters use:
- Azure AD workload identity for all application pods (no static credentials, no secrets in environment variables)
- Azure Key Vault with the CSI Secrets Store driver for secrets injection
- Azure Policy for Kubernetes (Gatekeeper) enforcing pod security standards
- Defender for Containers enabled on both clusters
- GitOps via Flux or Argo CD, pointing at the same application configuration repository — so promoting the standby region to primary does not require a deployment, just a Traffic Manager flip
The PodDisruptionBudget is your RTO insurance
In a regulated environment, an AKS node upgrade or a zone failure during a critical period is a business event, not just an infrastructure event. Every stateless workload needs a PodDisruptionBudget that prevents more than one pod in a deployment from being unavailable simultaneously. This is the most commonly missed Kubernetes configuration I see in enterprise environments, and it is what causes unnecessarily long recovery times during Azure maintenance windows.
Data Tier: The Hard Part
The data tier is where multi-region architecture gets genuinely difficult, and where regulatory requirements impose the tightest constraints.
Azure SQL (Primary Transactional Data)
Active geo-replication or failover groups between Germany West Central and Germany North. Failover groups give you a single connection string that automatically routes to the current primary, which simplifies application configuration. For DORA compliance, I configure automatic failover disabled by default — a human decision to fail over is required, with an automated failover available as an override after a defined time window (typically 30 minutes of primary unavailability). This preserves the audit trail and the human oversight that regulators expect.
Replication is synchronous for the transaction log, giving sub-one-minute RPO in practice. The standby replica is readable, which lets you offload reporting queries without touching the primary — a significant operational benefit in environments with heavy analytical workloads running against the same database.
Azure Cosmos DB (Operational Document Store)
If the architecture uses Cosmos DB for document or event storage, multi-region writes with the bounded-staleness consistency level gives you strong eventual consistency at low latency. For regulated workloads where strong consistency is required (auditability, financial records), session consistency or strong consistency at the cost of latency is the right trade-off. Strong consistency in Cosmos DB global distribution is expensive in latency terms — benchmark your read patterns before committing.
Azure Storage (Blob and Files)
Geo-redundant storage (GRS) with read access (RA-GRS) on all blob storage used for application data. Archive storage for compliance data (audit logs, regulatory reports) with immutability policies that prevent modification or deletion for the retention period — Blob Storage's WORM capability is what satisfies the immutability requirements in DORA Article 12 and equivalent.
Identity, Access, and Zero Trust Controls
The identity model is Entra ID throughout, with no exceptions for service-to-service authentication. Application components authenticate using managed identities. Human administrators access systems through Privileged Identity Management with just-in-time activation and a four-eyes approval requirement for production write access.
Conditional Access policies enforce:
- MFA for all users, including service accounts where applicable
- Compliant device requirement for access to administrative consoles
- Named location policies that restrict administrative access to corporate IP ranges or Entra-joined devices
- Session token lifetime limits appropriate to the data classification
In regulated environments I also configure Continuous Access Evaluation (CAE), which enables near-real-time token revocation when a user's risk profile changes — relevant when a security event requires immediate access revocation without waiting for token expiry.
Observability and Compliance Logging
All logs — Azure activity logs, resource diagnostic logs, Kubernetes audit logs, application logs, network flow logs — route to a centralised Log Analytics workspace in the Management subscription. Retention is set to the regulatory minimum plus six months buffer.
| Log Source | Destination | Retention | Purpose |
|---|---|---|---|
| Azure Activity Logs | Log Analytics | 7 years | Regulatory audit trail |
| AKS Audit Logs | Log Analytics | 7 years | Change and access audit |
| Network Flow Logs | Log Analytics + Storage | 90 days hot, 7 years cold | Security investigation |
| Application Logs | Log Analytics | 1 year hot | Operational |
| Defender for Cloud Alerts | Log Analytics + Sentinel | 7 years | Security incident record |
Microsoft Sentinel runs on the Management workspace for security event correlation and incident management. Sentinel analytics rules are maintained as code alongside the rest of the infrastructure, reviewed quarterly.
Failover Runbook: What Actually Happens
In a real incident, the failover sequence is:
Azure Monitor alerts fire on primary region health metrics. The on-call engineer is paged via the incident management platform. The incident commander declares a P1 and opens the war room. Traffic Manager health probes confirm primary endpoint is degraded or unavailable.
Confirm the outage scope: is it an availability zone failure (no failover needed, Kubernetes self-heals), a regional failure (failover required), or an application-level failure (rollback, not failover). Incorrect diagnosis at this stage costs more time than the assessment itself. Runbook has explicit decision criteria for each scenario.
Initiate SQL failover group failover. This is the step requiring explicit human authorisation in the runbook — the engineer triggers it via the Azure Portal or CLI, confirms the failover is initiating, and monitors replication lag to zero. For Cosmos DB, no action required — the standby region is already accepting writes if multi-region writes are configured.
Scale the standby AKS cluster to full production node count (autoscaler handles this, but manual trigger accelerates it). Verify application health probes pass on the standby cluster. Update Traffic Manager to direct 100% of traffic to the standby region. Verify end-to-end application health.
Notify stakeholders per the communication plan. Begin incident log. In regulated environments, the incident log is also a regulatory record — document every decision, every action, every timestamp. DORA requires notification to the competent authority within defined timeframes for significant ICT incidents. Know those timeframes before an incident happens, not during.
Infrastructure as Code: No Exceptions
This entire architecture is maintained as Bicep or Terraform. No manual portal deployments. No configuration that exists only in someone's memory. Every resource definition is version-controlled, every change is reviewed via pull request, every environment (staging, production primary, production standby) is deployed from the same templates with environment-specific parameter files.
The standby region's configuration is not a separate set of templates — it is the same templates parameterised for a second region. Drift between primary and standby is detected by running terraform plan or the Bicep what-if operation against both environments in the same CI/CD pipeline. Any difference is a finding.
What This Pattern Costs
A rough operating cost range for a mid-size financial services workload (50–100 pods, 10TB data, EUR-region):
| Component | Primary Region / Month | Standby Region / Month |
|---|---|---|
| AKS (compute) | EUR 4,000–8,000 | EUR 1,500–3,500 |
| Azure SQL (Business Critical) | EUR 3,000–6,000 | EUR 1,000–2,500 |
| Azure Firewall Premium | EUR 1,800 | EUR 1,800 |
| Azure Bastion | EUR 200 | EUR 200 |
| Log Analytics + Sentinel | EUR 1,500–3,000 | Shared |
| Networking and egress | EUR 500–1,500 | EUR 200–600 |
Total range: EUR 15,000–27,000 per month for both regions combined. The standby region adds 30–40% to the single-region cost — which is the cost of a tested, compliant, DORA-ready resilience posture. In my experience, that number is almost always smaller than the board expects when the question of multi-region cost comes up.
The Takeaway
The regulated multi-region Azure pattern is not clever. It is consistent. The value is not in any individual design decision — it is in the combination of deliberate networking topology, pre-warmed standby, synchronous data replication, identity controls that satisfy an auditor, and a failover runbook that has been exercised rather than written and forgotten.
The companies that navigate regulatory reviews without remediation programmes are the ones that built compliance into the architecture from the beginning, not the ones that bolted it on after a Solvency II inspection.
If you are designing or auditing a regulated Azure environment and want a second opinion on the architecture before it goes to a board or a regulator, let's talk — book a 30-minute discovery call. I have walked this pattern through enough compliance reviews to know where the questions will come from.