Azure-Regionen richtig wählen: Latenz, Recht und Verfügbarkeit

Migrationsprojekte beginnen die Regionsauswahl auffallend oft mit einem Latenztest. Jemand misst aus dem Firmennetz die Antwortzeiten zu einer Handvoll europäischer Standorte, notiert die niedrigste Zahl und schreibt sie ins Architekturdokument. Die Entscheidung ist damit gefallen, bevor irgendjemand gefragt hat, welche Daten in dieser Region eigentlich liegen werden.

Zwei Jahre später steht dieselbe Region im Verzeichnis der Verarbeitungstätigkeiten und in einem Auftragsverarbeitungsvertrag, der einen Speicherort zusagt, den die Region nicht einlöst. Der Umzug in eine andere Region ist dann kein Konfigurationsschritt, sondern ein Projekt mit Datenmigration, neuen Ressourcen-IDs, angepassten Firewall-Regeln und einer Ausfallzeit, die verhandelt werden muss. Die eingesparten Millisekunden haben sich zu diesem Zeitpunkt längst nicht amortisiert.

Warum die Reihenfolge der Kriterien über die Kosten entscheidet

Beide Kriterien lassen sich nachträglich ändern, aber zu völlig unterschiedlichen Preisen. Eine Anwendung, die 5 Millisekunden zu viel Umlaufzeit hat, lässt sich durch Zusammenfassen von Aufrufen, Zwischenspeicher oder eine zweite Instanz näher am Nutzer korrigieren — alles Eingriffe im Code, ohne Datenumzug. Eine Anwendung, die im falschen Rechtsraum liegt, lässt sich nur durch einen Regionswechsel korrigieren, und Azure-Ressourcen sind an ihre Region gebunden.

Daraus folgt die Bearbeitungsreihenfolge. Der Rechtsrahmen ist ein Ausschlusskriterium: Er sagt, welche Regionen nicht in Frage kommen, und diese Aussage ist binär. Die Latenz ist ein Sortierkriterium: Sie sagt, welche der verbliebenen Regionen die günstigste ist, und diese Aussage ist graduell. Ein Ausschlusskriterium zuletzt anzuwenden bedeutet, alle vorangegangenen Überlegungen möglicherweise zu verwerfen.

Die europäischen Azure-Regionen im Überblick

Die Microsoft-Regionsliste führt in der Geografie Europa 19 Regionen des öffentlichen Azure-Bestands (abgerufen am 04.09.2026). Sie unterscheiden sich in drei Merkmalen, die für die Auswahl zählen: Land des Rechenzentrums, allgemeine Verfügbarkeit und Unterstützung von Verfügbarkeitszonen.

Vier dieser 19 Regionen sind zugangsbeschränkt und nur für bestimmte Szenarien wie regionale Wiederherstellung freigegeben — France South (Marseille), Germany North (Berlin), Norway West und Switzerland West (Genf). Alle vier verfügen zudem über keine Verfügbarkeitszonen. Wer sie in einer Architektur einplant, plant mit Regionen, die ohne gesonderten Antrag nicht bereitstehen.

Die erste Zeile ist der Grund, warum die Anforderung „Daten bleiben in Deutschland“ so teuer ist. Sie lässt genau eine allgemein verfügbare Region übrig: Germany West Central in Frankfurt. Die zweite deutsche Region, Germany North in Berlin, ist zugangsbeschränkt und hat keine Verfügbarkeitszonen. Ein Ausweichstandort im selben Land existiert für den Regelbetrieb also nicht.

Was die EU-Datengrenze zusagt — und was sie offenlässt

Die EU-Datengrenze ist eine vertragliche Zusage von Microsoft, Kundendaten und personenbezogene Daten der Unternehmensdienste innerhalb eines definierten geografischen Raums zu speichern und zu verarbeiten. Dieser Raum umfasst die 27 EU-Mitgliedstaaten und die vier EFTA-Staaten Island, Liechtenstein, Norwegen und die Schweiz. Der substanzielle Dokumentationsstand trägt das Datum 26. Februar 2025, die Seite selbst wurde zuletzt am 22. Juli 2026 aktualisiert.

Zwei Punkte werden regelmäßig überlesen. Erstens deckt die Zusage ausdrücklich nicht alles ab: Microsoft schreibt selbst von „begrenzten Umständen“, unter denen Kundendaten, personenbezogene Daten und Daten aus Professional Services weiterhin außerhalb der Grenze übermittelt werden. Personenbezogene Daten in systemgenerierten Protokollen werden pseudonymisiert im Sinne von Art. 4 Nr. 5 DSGVO, nicht anonymisiert — Betriebspersonal greift also auf Daten mit Personenbezug zu, nur eben auf pseudonymisierte. Zweitens gilt die Zusage für regionale Azure-Dienste automatisch, für nicht-regionale Dienste dagegen nur nach gesonderter Konfiguration. Die Regionsauswahl allein bringt eine Umgebung nicht vollständig in die EU-Datengrenze.

Der Rechtsrahmen ist beweglicher als die Infrastruktur

Für Regionen außerhalb der EU hängt die Zulässigkeit an Übermittlungsinstrumenten, deren Bestand nicht garantiert ist. Der Durchführungsbeschluss (EU) 2023/1795 stellt seit Juli 2023 nach Art. 45 DSGVO fest, dass die USA für zertifizierte Organisationen ein angemessenes Schutzniveau gewährleisten. Das Gericht der Europäischen Union hat die Nichtigkeitsklage dagegen am 3. September 2025 in der Rechtssache T-553/23 (Latombe gegen Kommission) abgewiesen. Bestätigt wurde damit die Rechtslage zum Zeitpunkt des Erlasses — nicht der Fortbestand.

Für die Regionsauswahl ergibt sich daraus eine praktische Regel: Je weiter eine Architektur auf einen Angemessenheitsbeschluss oder auf Standardvertragsklauseln angewiesen ist, desto mehr Aufwand entsteht bei jeder Änderung der Rechtslage — Transfer-Folgenabschätzungen sind fortzuschreiben, Verträge nachzuziehen, im Ernstfall Daten zu verlagern. Eine Region innerhalb eines EU-Mitgliedstaats ist gegenüber diesen Bewegungen unempfindlich, weil dort kein Drittlandtransfer stattfindet, der überhaupt zu rechtfertigen wäre.

Wie viel die Latenz zwischen europäischen Regionen tatsächlich kostet

Microsoft veröffentlicht kontinuierlich gemessene Umlaufzeiten zwischen Azure-Regionen als 50. Perzentil über ein 30-Tage-Fenster; der aktuelle Datensatz stammt vom 30. Juli 2026. Von Germany West Central aus gemessen liegen die europäischen Ziele wie folgt: Switzerland North 9 ms, Belgium Central 10 ms, West Europe und Germany North je 11 ms, France Central 12 ms, Austria East und Italy North je 14 ms, Denmark East und UK South je 16 ms, Norway East 22 ms, Poland Central 23 ms, Spain Central und North Europe je 26 ms, Sweden Central 28 ms.

Die gesamte Spanne innerhalb der elf rechtlich unstrittigen EU-Regionen beträgt von Frankfurt aus damit 18 Millisekunden. Selbst der europäische Extremwert — Spain Central nach Sweden Central mit 51 ms — bleibt in einer Größenordnung, die für die meisten Geschäftsanwendungen unterhalb der Wahrnehmungsschwelle liegt. Zum Vergleich: Zwischen Verfügbarkeitszonen derselben Region strebt Microsoft eine Umlaufzeit von weniger als etwa 2 Millisekunden an, bei einem üblichen Abstand von bis zu 100 Kilometern.

Warum die Zahl der Roundtrips schwerer wiegt als die Millisekunden

Der Grund, warum Latenz in Auswahlentscheidungen überschätzt wird, liegt in der Multiplikation. Eine einzelne Umlaufzeit fällt kaum ins Gewicht; entscheidend ist, wie oft sie anfällt. Ein frisch aufgebautes HTTPS-Gespräch kostet bereits zwei Umläufe, bevor das erste Anwendungsbyte fließt — einen für den TCP-Verbindungsaufbau und einen für den Handshake von TLS 1.3 nach RFC 8446. Eine Anwendung, die pro Seitenaufruf 40 Datenbankabfragen nacheinander stellt, zahlt die Umlaufzeit vierzigmal.

Die letzte Zeile trägt die eigentliche Aussage: Die Bündelung von 40 auf 4 Aufrufe spart in diesem Beispiel 936 Millisekunden, der Wechsel von Madrid nach Brüssel dagegen 640. Der Zugriff auf die Anwendungsarchitektur ist also der stärkere Hebel — und er bleibt verfügbar, gleich in welcher Region die Anwendung steht. Genau deshalb taugt Latenz nicht als erstes Auswahlkriterium: Sie beschreibt einen Faktor, den man auch später noch beeinflussen kann.

Regionspaare und Verfügbarkeitszonen leisten Unterschiedliches

Ein verbreiteter Irrtum knüpft an die Regionspaare an. Microsoft ordnet einige Azure-Regionen paarweise einander zu; eine kleine Zahl von Diensten nutzt diese Paare für geografische Replikation, außerdem staffelt Microsoft geplante Aktualisierungen über die Paare hinweg und priorisiert im Katastrophenfall eine Region je Paar für die Wiederherstellung. Die Dokumentation stellt zugleich ausdrücklich klar, dass die Bereitstellung in einer gepaarten Region Ressourcen weder automatisch widerstandsfähiger macht noch Hochverfügbarkeit, Notfallwiederherstellung oder Umschaltung verschafft.

Sechs der 19 europäischen Regionen haben überhaupt kein Paar — Austria East, Belgium Central, Denmark East, Italy North, Poland Central und Spain Central. Alle sechs unterstützen Verfügbarkeitszonen. Umgekehrt ist der Paarpartner von Germany West Central mit Germany North eine zugangsbeschränkte Region ohne Zonen. Als Auswahlkriterium taugt das Vorhandensein eines Paars deshalb wenig; die Zonenunterstützung ist der belastbarere Indikator, weil sie eine Architektur innerhalb einer Region gegen den Ausfall einzelner Rechenzentren absichert.

Die Auswahl in fünf Schritten

1. Rechtliche Anforderung schriftlich festhalten Nicht „möglichst in Europa“, sondern die konkrete Stufe: Mitgliedstaat, EU-Datengrenze oder Angemessenheitsbeschluss. Quelle der Anforderung mitschreiben — Vertrag, Aufsichtsvorgabe oder eigene Richtlinie.
2. Regionsmenge daraus ableiten Zugangsbeschränkte Regionen streichen, Regionen ohne Verfügbarkeitszonen kennzeichnen. Aus 19 werden je nach Stufe 15, 13 oder 11 Kandidaten.
3. Dienstverfügbarkeit prüfen Nicht jeder Azure-Dienst und nicht jede Größenklasse existiert in jeder Region. Der Abgleich erfolgt gegen die Produktverfügbarkeit je Region, nicht gegen die Annahme, dass vorhanden ist, was es anderswo gibt.
4. Kapazität und nicht-regionale Dienste klären Ob die benötigten Kontingente in der Wunschregion tatsächlich zugeteilt werden, und wie nicht-regionale Dienste konfiguriert sein müssen, damit die Umgebung insgesamt der Zusage entspricht.
5. Zuletzt die Latenz messen Und zwar aus den Netzen, aus denen die Nutzung tatsächlich stattfindet, gegen die dann noch verbliebenen Kandidaten.

Was diese Reihenfolge nicht leistet

Die Reihenfolge ordnet die Auswahl, ersetzt aber keine der Prüfungen, die daneben stehen. Sie sagt nichts über den Auftragsverarbeitungsvertrag, nichts über Verschlüsselung und Schlüsselverwaltung und nichts über die Frage, ob Zugriffe aus Drittländern im Betrieb stattfinden.

Der richtige Zeitpunkt für die Entscheidung liegt vor dem ersten Terraform-Lauf und nach dem Gespräch mit der Stelle, die den Vertrag verantwortet. Wer sie später trifft, trifft sie in aller Regel nicht neu, sondern bezahlt sie.

Häufige Fragen

Welche Kriterien entscheiden über die Auswahl einer Azure-Region?

Fünf Kriterien, in dieser Reihenfolge: die rechtliche Anforderung an den Speicherort, die allgemeine Verfügbarkeit der Region, die Unterstützung von Verfügbarkeitszonen, die Verfügbarkeit der benötigten Dienste und Kontingente — und zuletzt die Latenz. Die ersten Kriterien schließen Regionen aus, das letzte sortiert nur noch die verbliebenen.

Liegen Daten in einer deutschen Azure-Region automatisch ausschließlich in Deutschland?

Nein. Regionale Azure-Dienste speichern und verarbeiten in der gewählten Region, nicht-regionale Dienste müssen dafür gesondert konfiguriert werden. Zudem behält sich Microsoft in der Dokumentation zur EU-Datengrenze begrenzte Umstände vor, unter denen Daten die Grenze verlassen, und personenbezogene Daten in systemgenerierten Protokollen werden pseudonymisiert, nicht anonymisiert.

Sind die Schweiz und Norwegen von der EU-Datengrenze abgedeckt?

Ja. Die EU-Datengrenze umfasst die 27 EU-Mitgliedstaaten und die vier EFTA-Staaten Island, Liechtenstein, Norwegen und die Schweiz. Wer aber eine Verarbeitung innerhalb der EU zusagt, kann sich darauf nicht stützen: Die Schweiz ist datenschutzrechtlich ein Drittland, und die EU-Datengrenze ist eine vertragliche Zusage von Microsoft, kein Rechtsbegriff der DSGVO. Das Vereinigte Königreich liegt außerhalb der EU-Datengrenze.

Braucht eine Azure-Region ein Regionspaar, um ausfallsicher zu sein?

Nein. Sechs der 19 europäischen Regionen haben kein Paar und unterstützen dennoch Verfügbarkeitszonen. Microsoft weist ausdrücklich darauf hin, dass die Bereitstellung in einer gepaarten Region allein weder Hochverfügbarkeit noch Notfallwiederherstellung oder eine automatische Umschaltung bewirkt. Beides muss ohnehin selbst entworfen werden.

Wie groß sind die Latenzunterschiede zwischen europäischen Azure-Regionen?

Gering. Von Germany West Central aus liegen die P50-Umlaufzeiten zu den übrigen zehn allgemein verfügbaren EU-Regionen zwischen 10 und 28 Millisekunden (Microsoft-Datensatz vom 30. Juli 2026). Der europäische Extremwert zwischen Spain Central und Sweden Central beträgt 51 Millisekunden. Zum Vergleich kostet ein neu aufgebautes HTTPS-Gespräch bereits zwei Umläufe, bevor Anwendungsdaten fließen.