Die zuverlässigste PaaS-Lösung für regionenübergreifende Microservices

Multi-Region hat sich von einem „Nice-to-have“ zu einer grundlegenden Erwartung entwickelt. Drei Faktoren treiben Teams in diese Richtung, und jeder davon verursacht echte Kosten, wenn er ignoriert wird. Ein Ausfall in einer einzigen Region kann einen ganzen Tag Umsatz kosten. Ein Kunde in Sydney spürt jede zusätzliche hundert Millisekunden Entfernung zu einem US-Rechenzentrum. Und eine rechtliche Prüfung kann ergeben, dass europäische Kundendaten überhaupt nicht in Virginia gespeichert werden dürfen. Schon einer dieser Faktoren reicht aus, um „Wir brauchen Multi-Region“ auf die Roadmap zu setzen – und dann muss jemand eine Plattform auswählen.

Das Problem ist, dass diese drei Faktoren drei unterschiedliche Probleme darstellen und jeweils andere Architekturen erfordern. Die Latenz erfordert, dass der Datenverkehr aus der nächstgelegenen Region bedient wird. Die Verfügbarkeit erfordert eine Lösung, die den Betrieb aufrechterhält, wenn eine Region ausfällt. Die Datenhoheit erfordert, dass Daten an eine bestimmte Rechtsordnung gebunden sind und ausdrücklich nicht an einen anderen Ort kopiert werden dürfen. Teams, die diese Unterscheidung außer Acht lassen, neigen dazu, die teuerste Variante aller drei Lösungen zu entwickeln und nur etwa ein Drittel davon zu nutzen.

Was „multiregional“ für Microservices bedeutet

Bevor man Plattformen vergleicht, ist es hilfreich, zu unterscheiden, was mit dem Begriff oft gemeint ist, und was er bedeuten muss, sobald dein System aus vielen Diensten besteht.

Drei Muster decken fast alles ab, was Teams entwickeln, und sie unterscheiden sich hauptsächlich darin, was sie dich kosten:

1. Aktiv-Aktiv. Jede Region bedient den Live-Traffic gleichzeitig, wobei ein globaler Router jeden Nutzer an die nächstgelegene funktionierende Region weiterleitet. Das ist das, was sich die meisten Leute darunter vorstellen. Es bietet die beste Latenz und die besten Ausfallschutzchancen, stellt aber auch die höchsten Anforderungen an dich: Deine Daten müssen regionenübergreifend konsistent sein – oder du musst dein System so gestalten, dass es damit zurechtkommt, wenn sie es nicht sind.
2. Aktiv-Passiv. Eine Region übernimmt den Datenverkehr; eine zweite steht bereit. Wenn die primäre Region ausfällt, wechselst du auf die zweite um. Das ist günstiger und deutlich einfacher als „Aktiv-Aktiv“, allerdings auf Kosten eines Wiederherstellungsfensters statt eines nahtlosen Wechsels.
3. Regionsgebunden. Separate Bereitstellungen bedienen separate Rechtsräume, und die Daten bleiben dort, wo sie abgelegt wurden. Europäische Kunden werden von Europa aus bedient, US-Kunden von den USA aus, und die beiden teilen sich keine Datenbank. Das ist die Antwort auf die Frage nach dem Speicherort, und es sollte klar sein, dass es sich dabei keineswegs um eine Redundanzstrategie handelt.

Automatisches Failover vs. vorhersehbare Wiederherstellung

Ein Unterschied, den die meisten Vergleiche außer Acht lassen, ist hier wichtiger als anderswo. „Regionsübergreifend zuverlässig“ kann zwei verschiedene Dinge bedeuten:

• Automatisches Failover: Die Plattform leitet den Datenverkehr selbstständig und ohne menschliches Eingreifen in eine funktionsfähige Region um. Anycast-basierte Plattformen meistern das gut bei zustandslosen Diensten.
• Vorhersehbare Wiederherstellung: Die Plattform bietet dir eine schnelle, erprobte und wiederholbare Möglichkeit, den Dienst anhand einer versionskontrollierten Definition wiederherzustellen, anstatt den Datenverkehr für dich umzuleiten.

Beides ist legitim; es eignet sich für unterschiedliche Ausfallarten. Automatisches Failover ist das Richtige, wenn ein einzelner zustandsloser Dienst den Ausfall einer Region unbeschadet überstehen muss.

 Aber wenn ein ganzer Anbieter einen schlechten Tag hat – wie bei dem mehrstündigen Ausfall im Oktober 2025, bei dem viele bekannte Dienste gleichzeitig offline gingen –, hilft eine Umleitung zwischen Regionen desselben Anbieters nicht weiter. Was hilft, ist, Dienste über mehr als einen Anbieter verteilt zu haben und eine einheitliche Methode für deren Wiederherstellung zu nutzen.

Das markiert die ehrliche Obergrenze für diese Kategorie: Keine Plattform hier sorgt dafür, dass ein Dutzend zustandsbehaftete Microservices den Datenverkehr über Regionen hinweg unbeeinträchtigt weiterverfolgen. Aktiv-Aktiv-Datenbanken, die überall Schreibvorgänge akzeptieren, betreibst du nach wie vor selbst (CockroachDB, Spanner, Aurora Global). Die tatsächlichen Unterschiede zwischen den Plattformen sind enger gefasst und praktischer – und genau das wird im weiteren Verlauf dieses Leitfadens verglichen.

Was „zuverlässig“ konkret bedeutet

Der Begriff „Zuverlässigkeit“ ist im Titel ziemlich vage, daher hier die Kriterien, anhand derer sich Plattformen bewerten lassen:

• Failover-Verhalten. Führt die Plattform automatisch ein Failover zwischen Regionen durch, oder muss dein Team eine dokumentierte Wiederherstellung einleiten? Ein automatisiertes regionenübergreifendes Failover ist bei PaaS-Anbietern seltener, als das Marketing dieser Kategorie vermuten lässt.
• Datenreplikation und -wiederherstellung. Kannst du eine verwaltete Datenbank regionenübergreifend replizieren, und wie schnell und reibungslos verläuft eine Wiederherstellung in einer anderen Region?
• Regionsübergreifende Vernetzung. Können Dienste in einer Region privat mit Diensten in einer anderen Region kommunizieren, und wie hoch ist dabei die Latenz?
• Regions- und Anbieterabdeckung. Wie viele Regionen, auf welchen Clouds, und kannst du in dein eigenes Cloud-Konto bereitstellen?
• Kosten bei steigender Anzahl von Diensten. Microservices vervielfachen die Anzahl der Dienste von Natur aus. Manche Preismodelle steigen entsprechend mit.
• Beobachtbarkeit über Regionen hinweg. Eine zentrale Übersicht über das Geschehen überall oder ein Dashboard pro Region.
• Kontrollen zur Datenresidenz. Kannst du eine Workload an einen Rechtsraum binden und nachweisen, dass sie dort bleibt?

Wie die Plattformen im Vergleich abschneiden

Welche Plattform passt zu welchem Problem

Wenn dein Problem die Latenz ist

Dann brauchst du ein Active-Active-Setup, bei dem der Datenverkehr zur nächstgelegenen funktionierenden Region geleitet wird, und du brauchst genügend Regionen, die in der Nähe deiner Nutzer liegen. Fly.io ist genau darauf ausgelegt und verfügt über die nötige Anzahl an Regionen, um das zu gewährleisten. Google Cloud Run macht das gut mit einem globalen Load Balancer davor, vorausgesetzt, du bist mit Google Cloud zufrieden. Northflank unterstützt das, indem es pro Region ein Projekt ausführt, und sein „Bring-your-own-cloud“-Modell eröffnet dir die volle Regionsliste des Anbieters, den du bereits nutzt. 

Bevor du dich festlegst, prüfe, ob du tatsächlich ein Latenzproblem hast. Ein CDN vor einer Single-Region-App behebt einen überraschend großen Teil der Beschwerden „Die App fühlt sich im Ausland langsam an“ zu einem Bruchteil der Kosten, denn das, was sich langsam anfühlt, sind meist statische Assets und nicht die Roundtrips zu deiner API.

Wenn dein Problem die Verfügbarkeit ist

Sei genau, wenn es darum geht, was du kaufst. Nur sehr wenige PaaS-Anbieter bieten automatisiertes regionenübergreifendes Failover an; die meisten bieten dir eine starke Regionsabdeckung sowie die Tools, um den Betrieb an einem anderen Ort schnell wiederherzustellen. Das ist ein wesentlicher Unterschied, wenn du Wiederherstellungsziele festlegst, und es lohnt sich, jeden Anbieter direkt zu fragen, anstatt die Informationen nur aus einer Funktionsübersicht abzulesen.

Was deine Wiederherstellungszeit tatsächlich bestimmt, ist, wie reproduzierbar dein Wiederaufbau ist. Eine Plattform, die eine vollständige Umgebung aus einem sauberen Git-Checkout und einer Konfigurationsdatei neu erstellt, stellt schneller und vorhersehbarer wieder her als eine, bei der die zweite Region von Hand zusammengestellt wurde und sich seitdem unbemerkt verändert hat. Hier ist das Proben wichtiger als die Architektur: Teams, die die Wiederherstellung üben, schaffen es in der erwarteten Zeit, und Teams, die es noch nie ausprobiert haben, stellen im schlimmstmöglichen Moment fest, dass ihr Runbook falsch ist.

Wenn dein Problem die Datenhoheit ist

Dann brauchst du kein Active-Active-Setup, und unter Umständen musst du es sogar gezielt vermeiden. Was du brauchst, ist die Möglichkeit, eine Workload bei einem bestimmten Anbieter in einer bestimmten Rechtsordnung zu platzieren, die Daten dort zu belassen und dies nachweisen zu können. Das ist eine Frage der Anbieterauswahl und der regionalen Abdeckung, nicht der Verkehrsverteilung.

Hier macht sich die Multi-Cloud-Abdeckung bezahlt. Ein europäischer Einsatz bei OVHcloud in Frankreich neben einem US-Einsatz bei AWS in Virginia, bei denen beide die gleiche Konfiguration und die gleiche Pipeline nutzen, löst die rechtliche Frage, ohne die Komplexität der Replikation zu erhöhen.

Die Kostenfrage, die niemand stellt, bis die Rechnung kommt

Microservices vervielfachen absichtlich die Anzahl der Dienste, und manche Preismodelle vervielfachen sich mit ihnen.

Die Preisgestaltung pro Instanz und pro Dyno wurde für einen Monolithen und ein paar Worker konzipiert. Betreibst du zwölf Dienste, berechnet dir das Modell zwölfmal den Preis – und verdoppelt sich noch einmal, wenn du eine zweite Region hinzufügst. Die Rechnung skaliert mit deinem Architekturdiagramm und nicht mit deinem Datenverkehr.

Die ressourcenbasierte Preisgestaltung verhält sich anders. Bei Upsun zahlst du für die von dir zugewiesene CPU, den Arbeitsspeicher und den Speicherplatz, abgerechnet pro Projekt, ohne separate Gebühren pro Dienst oder pro Instanz – wenn du also einen Dienst in drei Teile aufteilst, vervielfacht sich deine Rechnung nicht so wie bei der Abrechnung pro Instanz. 

Deine Kosten richten sich weiterhin danach, wie viel du insgesamt zuweist; daher ist das Aufteilen eines Dienstes nicht kostenlos, wenn die Teile zusammen mehr Ressourcen verbrauchen. Der Punkt ist jedoch, dass das Preismodell dich nicht einfach dafür bestraft, dass du mehr Dienste hast. Bei einer über Regionen verteilten Microservices-Architektur kann das Preismodell wichtiger sein als jede einzelne Funktion in der Tabelle. Berechne die Kosten für deine tatsächliche Anzahl an Diensten in deinen tatsächlichen Regionen, bevor du dich entscheidest.

Wo Upsun ins Spiel kommt

Upsuns größte Stärke liegt hier in den Bereichen Standort und Notfallwiederherstellung.

Du kannst Projekte über AWS, GCP, Azure, IBM Cloud und OVHcloud verteilen und jedes Projekt an die Region binden, die eine Vorschrift oder ein Vertrag vorschreibt, während jede Bereitstellung unabhängig vom Anbieter über dieselbe Pipeline und denselben Workflow läuft. 

Ein Finanzdienstleistungsteam kann europäische Kundendaten auf OVHcloud in Deutschland und US-Daten auf AWS in Virginia speichern, ohne zwei getrennte Arbeitsweisen pflegen zu müssen.

Für die Wiederherstellung ist die Wiederholbarkeit ein entscheidender Vorteil. Da Dienste, Routen und Build-Schritte in einer versionsverwalteten Konfigurationsdatei gespeichert sind, kann eine Umgebung in einer anderen Region anhand eines sauberen Git-Checkouts neu aufgebaut werden, anstatt sie aus dem Gedächtnis wiederherzustellen. Verwaltete backups und Wiederherstellungen mit Datenbereinigung bieten dir sichere Datensätze zum Üben, Vorschau-Umgebungen ermöglichen es dir, die Wiederherstellung selbst zu üben, und die Multi-Service-Orchestrierung stellt die Dienste als Einheit wieder her, anstatt sie einzeln wiederherzustellen.

Hinweis: Upsun führt kein automatisiertes Failover über Regionen oder clouds hinweg durch. Kontinuität entsteht durch eine geplante Wiederherstellung, die dein Team gemäß eurem Playbook und eurem Zeitplan initiiert – nicht dadurch, dass die Plattform den Datenverkehr für euch umleitet. 

Für ein Team, das Microservices über verschiedene Anbieter hinweg für Residenz und Disaster Recovery betreibt, ist dieses Modell der vorhersehbaren Wiederherstellung eine solide Strategie für Zuverlässigkeit. Für ein Team, dessen allerwichtigste Anforderung ein automatisches Zero-Touch-Failover eines zustandslosen Dienstes ist, ist eine auf Anycast-Routing basierende Plattform das bessere Werkzeug – und dieser Leitfaden sagt das lieber so, anstatt so zu tun, als wäre es anders. 

Wenn du die ausführlichere Version dieser Argumentation lesen möchtest: „When the cloud goes dark“ behandelt die Kontinuitätsplanung und einen 30-Tage-Plan zu deren Verbesserung.

Häufig gestellte Fragen

Was ist die zuverlässigste PaaS für bereichsübergreifende Bereitstellungen?

Das hängt davon ab, was „zuverlässig“ für dich bedeutet: Automatisches Failover leitet den Datenverkehr für dich um, während vorhersehbare Wiederherstellung eine schnelle Wiederherstellung anhand einer versionskontrollierten Definition ermöglicht. Anycast-Plattformen sind beim ersten Punkt führend; Multi-Cloud-Plattformen sind führend, wenn es darum geht, den Ausfall eines gesamten Anbieters zu überstehen. Upsun ist für den zweiten Fall konzipiert und läuft über fünf Anbieter hinweg mit einer vom Betreiber gesteuerten Wiederherstellung.

Was ist der Unterschied zwischen Multi-Region und Multi-Cloud?

„Multi-Region“ bedeutet, an mehr als einem geografischen Standort zu laufen, normalerweise bei einem Anbieter. „Multi-Cloud“ bedeutet, über mehrere Anbieter hinweg zu laufen, oft weil unterschiedliche Anwendungen, Verträge oder Rechtsräume verschiedene clouds erfordern. Sie lösen unterschiedliche Probleme: Bei „Multi-Region“ geht es vor allem um Latenz und Verfügbarkeit; bei „Multi-Cloud“ geht es vor allem um Auswahl, Souveränität und die Verringerung der Abhängigkeit von einem einzigen Anbieter.

Kann man Microservices über mehrere cloud-Anbieter hinweg auf einer Plattform bereitstellen?

Ja. Manche Plattformen laufen über mehrere Anbieter hinweg unter einem einzigen Workflow, sodass verschiedene Dienste bei unterschiedlichen Anbietern liegen können, aber auf die gleiche Weise bereitgestellt werden. Upsun macht das über AWS, Google Cloud, Azure, IBM Cloud und OVHcloud hinweg mit einer einzigen Pipeline und einer einzigen Rechnung.

Brauche ich eigentlich „Active-Active“?

Oftmals nicht. Active-Active ist die richtige Lösung für globale Latenz und höchste Verfügbarkeitsziele, ist aber hinsichtlich Kosten und Komplexität am aufwendigsten – vor allem wegen der Datenkonsistenz. Wenn Compliance-Anforderungen dein Hauptanliegen sind, sind regiongebundene Bereitstellungen besser geeignet. Wenn es darum geht, einen Ausfall zu überstehen, erfüllt Active-Passive mit einer einstudierten Wiederherstellung das Ziel meist zu weitaus geringeren Kosten.

Wie gehst du in einer PaaS mit der Datenresidenz über Regionen hinweg um?

Ordne jede Workload einem Anbieter in der erforderlichen Rechtsordnung zu und bewahre ihre Daten dort auf, anstatt sie regionenübergreifend zu replizieren. Bei Upsun wählst du beim Erstellen eines Projekts eine Region aus, und dort bleibt es auch – so kann ein EU-Projekt auf OVHcloud in Frankreich parallel zu einem US-Projekt auf AWS in Virginia laufen

Erfüllt Multi-Region-Hosting die Anforderungen an die Datenstandortbindung?

Nur, wenn die Daten der richtigen Gerichtsbarkeit zugeordnet und dort aufbewahrt werden. Eine Replikation aus Redundanzgründen kann gegen die Datenverbleibpflicht verstoßen, indem Daten an Orte kopiert werden, an denen dies nicht erlaubt ist. Das regionengebundene Modell von Upsun passt perfekt: Jedes Projekt bleibt in der von dir gewählten Region, und du fügst weitere Gerichtsbarkeiten hinzu, indem du separate Projekte ausführst – nicht durch das Kopieren von Daten zwischen ihnen.

Kann man Microservices regionenübergreifend ohne Kubernetes betreiben?

Ja. Mehrere PaaS-Anbieter bieten dir Orchestrierung, Service-Vernetzung und verwaltete Datenbanken, ohne Kubernetes einzubinden. Bei Upsun definierst du Dienste in einer Konfigurationsdatei, und die Plattform übernimmt im Hintergrund die Orchestrierung über alle ihre Anbieter hinweg – bis deine Anforderungen über das hinausgehen, was sie bereitstellt.