Multi-Region SaaS auf Hetzner Cloud: Datenresidenz und niedrige Latenz ohne AWS-Komplexität

Ein deutscher Enterprise-Kunde unterschreibt den Vertrag, dann fragt sein Security-Team, wo die Daten eigentlich liegen. Ein französischer Kunde beschwert sich, dass die App sich im Vergleich zu einem Konkurrenzprodukt träge anfühlt. Ein polnischer Interessent will einen Nachweis, dass nichts einen US-Datencenter berührt. Das sind die drei Zwänge, die ein wachsendes SaaS-Unternehmen in Richtung Multi-Region-Infrastruktur drängen, und Multi-Region-SaaS auf Hetzner Cloud zu betreiben löst alle drei, ohne die Account-Komplexität, die AWS oder GCP auf den Tisch eines kleinen Engineering-Teams legen.

Hetzner betreibt Rechenzentren in Falkenstein und Nürnberg (Deutschland), Helsinki (Finnland) und Ashburn, Virginia. Für ein Produkt, das in den DACH-Raum, nach Frankreich, in die Benelux-Staaten und nach Osteuropa verkauft, geben die drei europäischen Standorte bereits eine bedeutsame geografische Streuung innerhalb der EU, was der Teil ist, der für die DSGVO und für die Latenz zu deinen zahlenden Kunden tatsächlich zählt.

Drei Wege, Multi-Region zu strukturieren

Nicht jedes SaaS-Produkt braucht dieselbe Form von Multi-Region-Deployment, und die falsche Wahl fügt Kosten und operatives Risiko hinzu, ohne dir etwas dafür zu geben.

Active-Active mit geo-bewusstem Routing schickt jeden Request an die nächste gesunde Region und hält Schreibpfade in mehr als einer Region gleichzeitig offen. Das ist das richtige Modell, wenn du echte Nutzung in mehreren Ländern hast und Nutzer erwarten, dass sich die App überall lokal anfühlt. Es ist auch das schwierigste Modell, korrekt zu betreiben, weil du jetzt über Konfliktlösung nachdenken musst, sobald zwei Regionen Schreibzugriffe für denselben Datensatz akzeptieren.

Primary-Secondary mit regionalen Read-Replicas ist ein deutlich kleinerer Aufwand. Schreibvorgänge gehen an eine primäre Region, und lesehungriger Traffic (Dashboards, Reports, Suche) wird von Replicas näher am Nutzer bedient. Die meisten SaaS-Produkte, die glauben, Active-Active zu brauchen, brauchen eigentlich das hier. Die Latenz bei Lesevorgängen sinkt für alle, Schreibvorgänge bleiben einfach, und du vermeidest das Konfliktlösungsproblem komplett.

Eine dedizierte Region pro Enterprise-Kunde ist weniger ein Architekturmuster als eine Vertriebsanforderung, die sich als eins ausgibt. Manche Enterprise-Käufer, besonders in regulierten Branchen, unterschreiben nur, wenn die Daten ihres Tenants in einem isolierten Deployment liegen, auf das sie bei einem Audit zeigen können. Wenn du ein oder zwei solche Kunden hast, ist es oft günstiger, ein separates Hetzner-Projekt pro Kunde in der von ihm angegebenen Region aufzusetzen, als deine Kernarchitektur darum herum neu zu entwerfen.

Die meisten Teams starten mit Primary-Secondary, weil es die unmittelbaren Latenz- und Residenzprobleme löst, ohne sich vor einem nachgewiesenen Bedarf auf den operativen Overhead von Active-Active festzulegen. Wenn dein Traffic und Umsatz später Schreibvorgänge näher am Nutzer rechtfertigen, migrierst du als bewussten Schritt zu Active-Active, statt es auf Verdacht zu bauen.

DNS-Routing und Load Balancing

Hetzner Load Balancer übernehmen die Traffic-Verteilung und Health Checks innerhalb einer Region: Wenn eine Instanz in Falkenstein nicht mehr antwortet, stoppt der Load Balancer innerhalb von Sekunden, ihr Traffic zu schicken. Was Hetzner Load Balancer nicht nativ können, ist geo-bewusstes Routing über Regionen hinweg, weshalb dieser Teil bei Cloudflare vor deiner Hetzner-Infrastruktur liegt.

Das Geo-Steering von Cloudflare (verfügbar in deren Load-Balancing-Produkt) routet einen französischen Nutzer basierend auf konfigurierten Nähe-Regeln zu deinem Helsinki- oder Falkenstein-Endpunkt und failovert zu einer gesunden Region, wenn die nächstgelegene ausfällt. Das praktische Setup ist ein Cloudflare Load Balancer, der auf Origin-Pools pro Hetzner-Region zeigt, mit Health Checks, die einen leichtgewichtigen Endpunkt am Ingress jeder Region treffen. Cloudflare terminiert TLS und übernimmt die Failover-Entscheidung; Hetzner Load Balancer übernehmen die Verteilung, sobald der Traffic in einer Region ankommt. Keine der beiden Schichten muss viel über die andere wissen, was die Konfiguration auditierbar hält, statt sich in ein Gewirr von Routing-Regeln zu verwandeln, das niemand mehr sechs Monate später vollständig versteht.

PostgreSQL-Replikation über Falkenstein, Helsinki und Ashburn

Für das Primary-Secondary-Modell übernimmt PostgreSQL-Streaming-Replikation die Hauptarbeit. Ein Primary in Falkenstein streamt sein Write-Ahead-Log an Standby-Replicas in Helsinki und, wenn du US-Kunden bedienst, Ashburn. Lesevorgänge von EU-Nutzern werden an die EU-Replicas geroutet; Lesevorgänge von US-Nutzern gehen an Ashburn; Schreibvorgänge gehen immer zurück nach Falkenstein.

Die Latenz zwischen Falkenstein und Helsinki über das private Netzwerk von Hetzner ist niedrig genug, dass synchrone Replikation machbar ist, wenn du ein Hot-Failover-Ziel ohne Datenverlust willst. Asynchrone Replikation nach Ashburn ist angesichts der transatlantischen Distanz die realistischere Wahl, was ein kleines Replikationsverzögerungsfenster bedeutet und die Akzeptanz, dass ein US-Failover, falls es je passiert, die letzten paar Sekunden an Schreibvorgängen verlieren könnte. Entscheide, welcher Trade-off akzeptabel ist, bevor ein Incident die Entscheidung für dich trifft.

Ein Detail, das beim Setup leicht übersehen wird: Der Replikationstraffic selbst muss innerhalb der EU bleiben, wenn deine Datenresidenz-Zusage EU-only ist. Das bedeutet, die Ashburn-Replica, falls du eine hast, sollte nur je Daten von Kunden erhalten, die vertraglich und technisch dafür vorgesehen sind, nicht ein Spiegel der gesamten Datenbank. Das von Anfang an auf Datenmodell- oder Datenbankebene zu segmentieren, erspart später einen deutlich härteren Umbau.

Die Datenresidenz-Garantie wasserdicht machen

Zu sagen, Daten bleiben in der EU, ist einfach. Es einem Auditor zu beweisen, ist der Teil, bei dem die meisten Teams scheitern. Drei Dinge zählen hier.

Erstens müssen deine Datenbank, Backups und jede Queue oder jeder Cache, der Kundendaten berührt, alle in EU-Regionen liegen, nicht nur die Anwendungsserver. Es kommt häufig vor, dass die App korrekt in Falkenstein deployt ist, während die Error-Logging-Pipeline still und leise Stack Traces (die oft PII enthalten) an ein US-basiertes SaaS-Tool schickt. Prüfe jeden Dienst in deinem Stack, nicht nur die offensichtlichen.

Zweitens müssen Verschlüsselungsschlüssel irgendwo verwaltet werden, wo der US CLOUD Act nicht über einen US-ansässigen Anbieter herankommt. Hetzner ist ein deutsches Unternehmen, daher bleiben über Hetzner-natives Tooling verwaltete und gespeicherte Schlüssel außerhalb dieser Angreifbarkeit auf eine Art, wie es Schlüssel, die über das KMS eines US-Cloud-Anbieters verwaltet werden, nicht sind, selbst wenn die KMS-Region technisch auf Europa gesetzt ist.

Drittens führe Buch darüber, wo Daten bei jedem Verarbeitungsschritt physisch liegen, denn "wir glauben, es ist alles in der EU" ist nicht das, was ein Auditor hören will. Ein kurzes Architekturdokument, das jeden Dienst, seine Region und seinen Datenfluss benennt, ist bei einer Due Diligence mehr wert als ein aufpolierter Pitch Deck.

Über Regionen hinweg deployen, ohne einen beängstigenden Release-Prozess

Eine Änderung gleichzeitig über drei Regionen auszurollen ist, wie aus einem schlechten Deploy statt eines eingegrenzten Vorfalls ein Multi-Region-Ausfall wird. Eine Canary-Sequenz schützt davor: zuerst nach Helsinki deployen, Fehlerraten und Antwortzeiten für ein definiertes Zeitfenster beobachten, dann Falkenstein, dann Ashburn. Wenn Helsinki falsch aussieht, stoppst du, bevor es die Regionen erreicht, die den Großteil deines Traffics bedienen.

Kamal 2 handhabt das gut für Teams, die bereits eine Docker-basierte Deploy-Pipeline betreiben, da es genau um diese Art von Multi-Host-Rollout herum gebaut ist. Eine minimale Multi-Region-Kamal-Konfiguration gruppiert Hosts nach Region und lässt dich eine einzelne Region für ein Deployment ansteuern:

servers:
  web:
    hosts:
      - 10.0.1.10
      - 10.0.1.11
    labels:
      region: falkenstein
  web-helsinki:
    hosts:
      - 10.0.2.10
    labels:
      region: helsinki
  web-ashburn:
    hosts:
      - 10.0.3.10
    labels:
      region: ashburn

kamal deploy -d helsinki auszuführen schickt das Release nur an die Helsinki-Gruppe. Sobald das Canary-Fenster sauber durchläuft, steuert derselbe Befehl die verbleibenden Regionen an. Es ist ein schlichter, nachvollziehbarer Prozess, der weder einen Service Mesh noch eine dedizierte Release-Engineering-Funktion braucht, um zu funktionieren.

Was das gegenüber AWS oder GCP kostet

Ein grober Vergleich, mit der Art von Setup, das ein mittelgroßes SaaS-Produkt betreiben würde: drei Regionen, eine primäre Datenbank mit zwei Read-Replicas, Load Balancing und genug Rechenleistung, um echten Produktions-Traffic zu bewältigen.

Auf Hetzner liegt dieses Setup irgendwo im Bereich von 400 bis 700 Euro im Monat, größtenteils weil die Compute- und Bandbreiten-Preise von Hetzner nur einen Bruchteil der Hyperscaler kosten und weil es keine Gebühr für regionsübergreifenden Datentransfer innerhalb ihres Netzwerks gibt, wie es sie zwischen AWS-Regionen gibt. Das äquivalente Setup auf AWS, mit RDS-Multi-AZ-Read-Replicas, Application Load Balancern pro Region und passend dimensionierten EC2-Instanzen, landet typischerweise zwischen 2.000 und 3.500 Euro im Monat, sobald man die Datentransfergebühren zwischen Regionen einrechnet, die AWS separat berechnet und die sich mit regionsübergreifendem Replikationstraffic schnell summieren.

Der Unterschied ist nicht nur der Listenpreis. Die Multi-Region-Primitiven von AWS (Route-53-Latenz-Routing, regionsübergreifende RDS-Replicas, VPC-Peering) sind in sehr großem Maßstab mächtiger und automatisierter, kommen aber auch mit einer steileren Lernkurve und mehr beweglichen Teilen, die es abzusichern und zu überwachen gilt. Für ein Team ohne dedizierten Platform Engineer ist Hetzner plus Cloudflare plus Kamal ein Setup, das ein oder zwei Backend-Ingenieure tatsächlich end-to-end verantworten können.

Wo das in eine breitere Technologie-Entscheidung passt

Multi-Region-Infrastruktur ist selten eine isoliert getroffene Entscheidung. Sie kommt meist zusammen mit einer größeren Frage auf, ob dein aktueller Stack, deine Hosting-Strategie und dein Deployment-Prozess das tragen können, wohin sich das Unternehmen entwickelt. Wenn du das gegen eine breitere Tech-Stack-Strategie-Prüfung abwägst, oder die Infrastrukturfrage im Rahmen eines größeren Vorstoßes zur digitalen Transformation aufgekommen ist, lohnt es sich, das Gesamtbild durchzuarbeiten, bevor du dich auf eine Regionstopologie festlegst, mit der du jahrelang leben musst.

Wenn deine bestehende Anwendung Arbeit braucht, bevor sie Multi-Region-Deployment sauber unterstützen kann, sei es das Entkoppeln der Datenschicht oder der Umbau von Teilen der Deployment-Pipeline, ist das die Art von Projekt, die wir über Custom Software Development abwickeln.

Wolf-Tech arbeitet mit SaaS-Teams genau an dieser Art von Infrastrukturentscheidung, von der Wahl des richtigen Deployment-Modells bis zum Aufsetzen der Replikations- und Rollout-Prozesse, die es leise im Hintergrund am Laufen halten. Wenn du Hetzner gegen AWS für einen Multi-Region-Build abwägst, melde dich unter hello@wolf-tech.io oder erfahre mehr über unsere Arbeit auf wolf-tech.io.