Sovereign Landing Zone: Infrastrukturkontrolle in Azure für die EU

Pexon Consulting | 10 Min. Lesezeit | 22.05.2026

TL;DR

Die Sovereign Landing Zone ist Microsofts Governance-Erweiterung für Azure: zusätzliche Management Groups und Azure Policies erzwingen Datenresidenz, Customer-Managed Keys und Confidential Computing – ohne die klassische Landing Zone zu ersetzen. Pexon Consulting (80 MA, Microsoft Partner) setzt SLZ in 6-10 Wochen für Banken, Versicherer und Energieversorger um. Ergebnis: nachweisbare Infrastrukturkontrolle für DORA und EU-Anforderungen.

27 % kritischer Cloud-Verträge außerhalb der EU – und trotzdem Azure?

Im Februar 2025 hat die EZB in ihrer Outsourcing-Analyse festgestellt: Fast alle bedeutenden Institute haben Cloud-Verträge für kritische Funktionen – und der Anteil kritischer ICT-Verträge in Nicht-EU-Ländern liegt bei 27 %. Gleichzeitig stieg die durchschnittliche Cloud-Outsourcing-Ausgabe pro Institut auf rund 57 Millionen Euro, ein Plus von 13,5 % gegenüber 2023.

Das ist kein Widerspruch zu Azure. Es ist der Kontext, in dem eine Sovereign Landing Zone Sinn ergibt: Hyperscaler-Technologie nutzen, ohne die Kontrolle über Verschlüsselung, Datenresidenz und administrative Zugriffe aus der Hand zu geben.

Seit dem 17. Januar 2025 gilt DORA vollständig für über 22.000 Finanzunternehmen und ihre ICT-Dienstleister. Wer heute eine Azure-Umgebung plant oder erweitert, braucht keine zweite Cloud – sondern eine Architektur, die regulatorische Anforderungen technisch durchsetzt, nicht nur dokumentiert.

Sovereign Landing Zone vs. klassische Azure Landing Zone

Die kurze Antwort: Die Sovereign Landing Zone ersetzt Ihre Azure Landing Zone nicht. Sie ist eine Variante derselben Referenzarchitektur – mit zusätzlicher Souveränitätsschicht.

Microsoft beschreibt den Unterschied klar in den Design Areas: Bei Billing, Identity und Netzwerk ändert sich nichts. Was sich ändert, ist die Ressourcenorganisation und die Governance-Tiefe.

Klassische Landing Zone: Teams bekommen schnell Ressourcen unter einheitlichen Unternehmens-Policies. Fokus: Agilität, Skalierung, Kostentransparenz.

Sovereign Landing Zone: Dieselbe Basis – plus Management Groups und Policies, die Datenabfluss und nicht-konforme Konfigurationen proaktiv blockieren. Workloads laufen in isolierten Segmenten (Public, Confidential Corp, Confidential Online), die keine unkontrollierte Kommunikation mit offenen Shared Services erlauben.

Unsere klare Empfehlung: Wer bereits eine funktionierende Azure Landing Zone hat, soll SLZ inkrementell darüber legen – nicht neu anfangen. Microsoft formuliert das explizit: Layer sovereign controls, don’t rip and replace.

Was die Sovereign Landing Zone technisch durchsetzt

Geopolitische Instabilität macht Datenhoheit zum Board-Thema. Die SLZ übersetzt das in konkrete Azure-Controls – vier Bausteine, die wir in Projekten bei Versicherern und Banken immer wieder kombinieren.

1. Trennung der Schlüsselgewalt

Customer-Managed Keys (CMK) und External Key Management (EKM) über Managed HSM bleiben beim Unternehmen. Selbst bei physischem Zugriff auf die Infrastruktur bleiben Daten ohne kundeneigene Schlüssel unlesbar. Das ist kein Marketing-Versprechen – es ist die technische Grenze zwischen Cloud-Anbieter und Dateneigentümer.

2. Confidential Computing über „at rest“ hinaus

Verschlüsselung in Ruhe und Transit reicht für sensible Workloads oft nicht. Confidential VMs und Enclaves isolieren Verarbeitung im Speicher. Für Versicherungs-Kernprozesse oder Bank-Analytics mit personenbezogenen Daten sehen wir das zunehmend als Standard-Anforderung, nicht als Nischenfeature. Auf Plattformebene setzt sich diese Anforderung fort, wenn Sie containerisierte Workloads als souveränes Kubernetes in deutschen Rechenzentren betreiben wollen.

3. Präventive Governance statt Audit-Nachlauf

Statt punktueller Audits setzt die SLZ auf Azure Policy mit Deny-Effekten: nicht erlaubte Regionen, fehlende Verschlüsselung, öffentliche Endpoints – blockiert vor dem Deployment. In der Azure Landing Zones Library (Stand 2026.02) sind für das Landing-Zones-Archetype allein über 50 Policy Assignments hinterlegt.

Ein Beispiel für EU-Regionen-Lockdown per Policy:

# Terraform - Policy-Assignment für erlaubte Regionen (SLZ-Pattern)
resource "azurerm_resource_group_policy_assignment" "allowed_locations" {
  name                 = "slz-allowed-locations-eu"
  resource_group_id    = var.platform_rg_id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-3f7ee6985a1f"
  parameters = jsonencode({
    listOfAllowedLocations = {
      value = [
        "germanywestcentral",
        "westeurope",
        "northeurope",
        "swedencentral"
      ]
    }
  })
}

4. EU Data Boundary und Sovereign Public Cloud als Kontext

Microsoft hat die EU Data Boundary im Februar 2025 abgeschlossen – Kernservices speichern und verarbeiten Kundendaten in EU/EFTA. Im Juni 2025 folgte die Erweiterung um Sovereign Public Cloud mit Data Guardian (Remote-Zugriff nur durch EU-Personal mit europäischer Aufsicht). Die SLZ ist das Governance-Gerüst, das diese Angebote in Ihrer Tenant-Struktur verbindlich macht – nicht optional pro Team.

Wir raten davon ab, Souveränität nur über Vertragsklauseln zu adressieren. Verträge schützen vor Haftung. Policies schützen vor Fehlkonfiguration um 3 Uhr nachts durch ein automatisiertes Deployment.

So setzen wir eine Sovereign Landing Zone in der Praxis um

Die Sovereign Landing Zone ist kein statisches Gebilde – sie reagiert auf neue EU-Vorgaben, weil Policies versioniert und per IaC ausgerollt werden.

Phase 1 – Souveränitäts-Assessment (1-2 Wochen): Welche Workloads brauchen Confidential-Segmente? Wo reicht Public? Mapping gegen DORA-Anforderungen, bestehende ALZ-Lücken, Register-of-Information-Vorbereitung.

Phase 2 – Platform Layer (3-5 Wochen): Management-Group-Hierarchie, Policy-Sets aus der SLZ-Library, CMK-Strategie pro Service, Netzwerk-Isolation für Confidential Corp/Online.

Phase 3 – Workload-Onboarding (laufend): Golden Paths für Teams – welche Subscription, welches Segment, welche Schlüssel. Hier verknüpft sich SLZ mit Platform Engineering: Souveränität darf Entwickler nicht ausbremsen, sondern muss im Self-Service-Portal sichtbar sein.

Deployment-Pfad laut Microsoft: Terraform Azure Verified Modules über den Azure Landing Zone Accelerator – empfohlen. Bicep-Support ist angekündigt, aber noch nicht produktionsreif. Wer heute mit Bicep-only-Teams startet, plant einen Terraform-Track ein oder wartet bewusst ab.

# SLZ-Library-Referenz im ALZ-Provider (Terraform)
# library_references.path = "platform/slz"
terraform init
terraform plan -var-file=sovereign.prod.tfvars
terraform apply -auto-approve=false

Kostenrahmen: Ein SLZ-Rollout über bestehende ALZ liegt in unseren Projekten meist bei 75.000-150.000 Euro – abhängig von Tenant-Größe, Anzahl Workloads und Confidential-Computing-Anteil. Das ist deutlich günstiger als eine parallele „Souverän-Cloud“-Migration, die oft 400.000 Euro und 12+ Monate kostet, ohne den Innovationsvorsprung der Hyperscaler zu behalten.

64 % der Finanzinstitute planen laut Deloitte-Umfrage 2-5 Millionen Euro allein für DORA-Compliance – ein Teil davon fließt sinnvollerweise in die Plattform, die alle nachgelagerten Workloads absichert.

DORA, NIS2 und der Register of Information – warum die Architektur zählt

Aufsichtsbehörden fragen 2026 nicht mehr nur „Nutzen Sie die Cloud?“, sondern „Können Sie Ihre ICT-Lieferkette maschinenlesbar abbilden?“ Der DORA Register of Information (RoI) verlangt genau das – inklusive Sub-Contracting-Ketten bei Hyperscalern.

Eine Sovereign Landing Zone liefert die technische Story dahinter:

• Wo laufen kritische Workloads? → Management Group + Region-Policy
• Wer kontrolliert Verschlüsselung? → CMK/EKM-Nachweis
• Wie wird Abweichung verhindert? → Deny-Policies, nicht Wiki-Richtlinien

Der europäische Sovereign-Cloud-Markt wächst parallel: ABI Research prognostiziert für Europa 197,8 auf 257,6 souveräne Rechenzentrums-Standorte bis 2035 – bei steigender AI-Last von 152 MW auf fast 2 GW. Wer jetzt die Governance-Architektur richtig legt, skaliert mit – wer wartet, patcht später teure Einzelprojekte.

Für Versicherer und Energieversorger gilt dasselbe Muster wie im Banking, nur mit anderen Aufsichtslogiken: Datenresidenz, Lieferketten-Transparenz, Nachweis operativer Kontrolle. Unser Banking– und Versicherungs-Know-how fließt direkt in die Policy-Auswahl ein – nicht als generisches Cloud-Template. Referenzprojekte finden Sie in unseren Case Studies.

Worauf IT-Leiter bei der Auswahl achten sollten

1. Bestehende ALZ prüfen – Greenfield-SLZ nur bei strukturellen Lücken; sonst Layering.
2. Terraform-Kompetenz sichern – SLZ-Produktionspfad läuft über AVM/Terraform, nicht Portal-Klicks.
3. Confidential-Segmente sparsam – Jedes Confidential-Online-Segment kostet Komplexität; nur für echte Hochrisiko-Workloads.
4. CMK-Strategie vor dem ersten Workload – Nachträgliche Schlüssel-Migration ist der teuerste Fehler, den wir sehen.
5. RoI-Daten aus der Architektur ableiten – Management Groups und Tags müssen zum Reporting passen, nicht umgekehrt.
6. Innovation nicht opfern – SLZ blockiert falsche Konfigurationen, nicht Azure OpenAI oder Fabric, wenn Policies richtig geschnitten sind.

Ein Soft-CTA für den Einstieg: Wer unsicher ist, ob SLZ oder klassische ALZ reicht, startet mit einem strukturierten Azure Workshop – Souveränitäts-Check inklusive, ohne gleich sechsstellig zu committen.

Häufig gestellte Fragen

Was kostet eine Sovereign Landing Zone auf Azure?

Kommt auf Ausgangslage und Scope an. Über eine bestehende Azure Landing Zone rechnen wir 75.000-150.000 Euro für Assessment, Platform Layer und initiales Policy-Set – Laufkosten für MHSM und Confidential VMs kommen extra. Greenfield ohne ALZ liegt höher. Ein Cloud Assessment klärt den realistischen Rahmen in 1-2 Wochen.

Muss ich meine bestehende Azure Landing Zone ersetzen?

Nein. Die Sovereign Landing Zone ist eine architektonische Variante, kein Ersatz. Microsoft empfiehlt, souveräne Controls zu layern, solange keine kritischen Strukturlücken bestehen. Migration einzelner Subscriptions in Confidential-Segmente ist der übliche Weg.

Sovereign Landing Zone vs. EU Data Boundary – was ist der Unterschied?

Die EU Data Boundary ist ein Microsoft-Angebot auf Plattformebene (Daten in EU/EFTA). Die Sovereign Landing Zone ist Ihre Tenant-Governance, die das verbindlich für alle Teams durchsetzt – inklusive CMK, Confidential Computing und Policy-Deny. Beides ergänzt sich; eins ersetzt das andere nicht.

Reicht die Sovereign Landing Zone für DORA-Compliance?

Sie deckt einen zentralen Teil ab: technische Kontrolle über Infrastruktur, Verschlüsselung und Residenz. DORA verlangt zusätzlich Prozesse (Incident Reporting, TLPT, Third-Party Risk). SLZ ist das Fundament – nicht das gesamte DORA-Programm.

Warum Terraform und nicht Bicep für SLZ?

Stand Mai 2026 ist die produktionsreife SLZ-Implementierung über Terraform Azure Verified Modules verfügbar; Bicep ist in Entwicklung. Wer Bicep-Teams hat, plant entweder Terraform-Kapazität oder wartet bewusst – ein Hybrid ohne Plan scheitert in der Praxis.

Nächster Schritt

Wenn Ihr Mandant oder Ihre Aufsicht nach „nachweisbarer Kontrolle“ über Cloud-Infrastruktur fragt, ist die Sovereign Landing Zone der pragmatische Hebel: Azure behalten, Souveränität technisch erzwingen.

Verwandte Themen