Multi-Region Kubernetes für KRITIS: Wie ayedo eine Einzelstandort-Plattform in ein aktiv/aktiv Anycast-System transformiert hat

Wer kritische Infrastruktur betreibt, kann sich keine „gute Verfügbarkeit" leisten – sondern braucht nachweisbare Ausfallsicherheit. Und zwar nicht nur innerhalb eines Rechenzentrums, sondern standortübergreifend. Genau hier scheitern viele Plattformen, die technisch sauber gebaut sind, aber historisch in einer Einzelregion gewachsen sind: Sie sind redundant im Rack, redundant im Cluster, redundant in der Datenbank – und trotzdem ein Single Point of Failure auf Standortebene.

In diesem Beitrag zeigen wir anhand eines anonymisierten Kundenprojekts, wie ayedo eine KRITIS-relevante Steuerungs- und Überwachungsplattform von einem einzelnen Rechenzentrum auf eine Multi-Region-Architektur gehoben hat – mit aktiv/aktiv Kubernetes-Clustern, BGP-basiertem Anycast-Routing, Bring-Your-Own-IP und automatisiertem Failover, das in Tests eine RTO unter 30 Sekunden nachweisbar erreicht.

Der Kunde bleibt anonym. Der Ansatz ist reproduzierbar – insbesondere für Organisationen, die regulatorisch geforderte Business Continuity nicht nur dokumentieren, sondern technisch beweisbar machen müssen.

Ausgangslage: Hochverfügbar – aber nur innerhalb eines Standorts

Der Kunde betreibt eine zentrale Plattform für Betreiber von Strom-, Gas- und Wärmenetzen. Über diese Plattform werden Netzzustandsdaten erfasst, Schalthandlungen koordiniert und regulatorische Meldungen automatisiert. Die Nutzerbasis ist entsprechend sensibel: Mehrere Dutzend Netzbetreiber verlassen sich auf diese Systeme im 24/7-Betrieb. Das Umfeld ist KRITIS, mit Anforderungen aus BSI-Gesetz, NIS-2 und dem IT-Sicherheitskatalog der Bundesnetzagentur.

Technisch war die Plattform in Frankfurt auf einem Kubernetes-Cluster umgesetzt, klassisch redundant innerhalb des Standorts: mehrere Control-Plane-Nodes, mehrere Worker, replizierte Datenbanken, Load Balancing. Für die ersten Jahre reichte das. Das Team hatte die typischen Ausfälle im Griff, Rolling Updates waren etabliert, Node-Failures waren beherrschbar.

Das Problem lag nicht im Cluster, sondern im Standort.

Solange „Frankfurt verfügbar" als Annahme gilt, wirkt ein solches Setup solide. Sobald man die Frage ernsthaft stellt, was bei einem Standortausfall passiert – Brand, Strom, Netz, physischer Vorfall, großflächige Störung – bricht die Architektur in sich zusammen. Denn Redundanz innerhalb eines Standorts hilft nicht gegen den Ausfall des Standorts selbst.

Genau diese Frage wurde mit wachsender Bedeutung des Produkts zur existenziellen. Ein Audit beanstandete die fehlende Georedundanz als wesentlichen Mangel und setzte eine Frist zur Behebung. Gleichzeitig wurden Anforderungen aus Kundensicht konkreter: Multi-Standort als Mindestanforderung, nachweisbares Disaster-Recovery, belastbare Recovery-Zeiten.

Warum „Disaster Recovery per Hand" in KRITIS nicht akzeptabel ist

Es gab einen Disaster-Recovery-Plan – aber er war im Kern manuell: Backups einspielen, DNS umschalten, Dienste hochfahren, Abhängigkeiten prüfen, Kunden informieren. Die geschätzte Recovery-Zeit lag bei mehreren Stunden. In vielen Business-Systemen wäre das schmerzhaft, aber tolerierbar. In einer Plattform, die für Netzbetreiber Echtzeitfunktionen unterstützt und regulatorisch überwacht wird, ist das nicht tragbar.

Das liegt nicht nur an der reinen Downtime, sondern an den Folgeeffekten. Netzbetreiber haben teils feste Firewall-Regeln, dedizierte VPN-Tunnel und starr definierte IP-basierte Freigaben. Wenn sich die Plattform-IP ändert, entsteht nicht „eine Änderung", sondern ein koordinatives Projekt über viele Organisationen hinweg – mit Abstimmungen, Wartungsfenstern, Freigaben. In der Realität dauert so etwas nicht Stunden, sondern Wochen.

Der Kunde hatte damit ein zweites, oft unterschätztes Problem: Selbst wenn man technisch schnell failovern könnte, wäre der Netz-Zugang auf Kundenseite ein Bremsklotz. Das ist der Grund, warum klassische „DNS umschalten"-DR-Konzepte in solchen Umfeldern regelmäßig scheitern: DNS ist nicht das Problem, die Netzrealität der Kunden ist es.

Parallel zeigten sich Latenzthemen bei weiter entfernten Nutzern. SCADA-Integrationen und Visualisierungen mit Sub-Sekunden-Anforderungen reagieren empfindlich auf zusätzliche Millisekunden. Ein zentraler Standort erzeugt für bestimmte Regionen spürbare Nachteile – und der Druck steigt, nicht nur ausfallsicher, sondern auch näher an den Kunden zu sein.

Und schließlich kamen Wartungsfenster als Risiko hinzu. Cluster-Upgrades, OS-Patches und Infrastrukturarbeiten sind in einer Einzelregion immer ein Spiel mit reduzierter Redundanz. Selbst wenn technisch „nichts ausfallen sollte", bleibt ein Restrisiko, das Kunden im KRITIS-Kontext nicht mehr akzeptieren wollen. Die Erwartung war klar: Wartung darf den Betrieb nicht gefährden – sie muss architekturell entkoppelt sein.

Der Wendepunkt: Kundenforderung + Audit-Frist + messbare RTO

Der Zeitpunkt, an dem aus „sollten wir mal" ein „müssen wir jetzt" wird, kam durch zwei Faktoren gleichzeitig: die Audit-Frist und ein großer Netzbetreiber, der eine Vertragsverlängerung explizit an georedundante Architektur und automatisiertes Failover knüpfte – mit einer RTO unter 60 Sekunden.

Damit war die Zieldefinition nicht mehr diskutierbar. Es ging nicht um „zweites Rechenzentrum als Backup", sondern um nachweisbare, automatische Übernahmezeiten im Sekundenbereich. Und es ging nicht um ein einmaliges Setup, sondern um eine Architektur, die sich warten lässt, ohne Wartungsfenster, und die sich auditieren lässt, ohne Papierakrobatik.

An dieser Stelle sind wir als ayedo eingestiegen.

ayedos Ansatz: Multi-Region als Betriebsmodell – nicht als Notfallplan

Wir haben die Aufgabe als Plattform- und Netzwerkproblem behandelt, nicht als „zweiten Cluster hinstellen". Denn echte Georedundanz entsteht erst, wenn drei Dinge gleichzeitig gelöst sind:

Erstens: Der Traffic muss ohne DNS-Umschaltung und ohne Kundeneingriffe umschwenken können. Zweitens: Die Workloads müssen aktiv/aktiv laufen, damit Failover nicht „hochfahren", sondern „weiterlaufen" bedeutet. Drittens: Der Nachweis muss systemisch erzeugt werden – durch regelmäßige Tests, messbar, dokumentierbar.

Das Ergebnis war eine Architektur, die Standorte entkoppelt, Betrieb wartbar macht und Failover zu einer Funktion des Netzwerks und der Plattform erklärt – nicht zu einem Runbook.

Architektur: Drei Availability Zones, zwei Regionen, aktiv/aktiv Cluster pro Region

Statt einen einzelnen Kubernetes-Cluster über Standorte zu strecken, haben wir pro Region dedizierte Cluster etabliert. Das ist eine bewusste Entscheidung. Ein „stretched cluster" klingt auf dem Papier elegant, bringt aber im Betrieb harte Nachteile: Komplexität in der Control Plane, empfindliche Abhängigkeit von Interconnects, schwieriges Debugging und eine höhere Wahrscheinlichkeit, dass ein Teilproblem zu einem Clusterproblem wird.

Mit getrennten Clustern pro Region lässt sich der Blast Radius sauber begrenzen. Eine Region kann vollständig ausfallen, ohne die andere zu kompromittieren. Beide Regionen sind aktiv und verarbeiten Traffic gleichzeitig. Damit gibt es keinen „kalten" Standort, der erst im Ernstfall beweisen muss, dass er funktioniert. Jede Region ist im Alltag belastet, sichtbar, getestet.

Die Standorte wurden über redundante, dedizierte Verbindungen gekoppelt, mit niedriger Latenz, um Replikation und zentrale Steuerung stabil zu ermöglichen – ohne eine harte Kopplung, die aus einem Netzwerkproblem ein Plattformproblem macht.

Anycast und BGP: Failover ohne DNS und ohne Kundenkoordination

Der zentrale Hebel für die Kundenseite war Anycast – umgesetzt über BGP. Statt eine einzelne IP an einen Standort zu binden, wird dieselbe IP in beiden Regionen announced. Für den Client bleibt alles gleich: gleiche IP, gleiche Firewall-Regel, gleicher VPN-Tunnel. Der Unterschied liegt nur in der Route dahinter.

Fällt eine Region aus, zieht BGP die Route automatisch zurück. Der Traffic fließt zur verbleibenden Region – ohne dass DNS geändert wird, ohne dass Kunden Firewalls anfassen müssen, ohne dass VPN-Konfigurationen angepasst werden. In kritischen Umfeldern ist das der Unterschied zwischen „wir können technisch failovern" und „wir können wirklich failovern".

Das Konzept wurde zusätzlich um Bring-Your-Own-IP erweitert, weil einige Enterprise-Kunden Provider-Independent Address Space nutzen wollen. Solche Anforderungen sind in stark regulierten Netzen üblich: Kunden wollen IP-Ownership und die Möglichkeit, Prefixe über BGP selbst oder über einen Dienstleister announcen zu lassen. BYOIP ist in diesen Projekten kein „nice feature", sondern häufig ein Onboarding-Kriterium.

Mit der Anycast-Architektur wurde nebenbei noch ein zweiter Effekt erreicht: Latenz. Clients landen automatisch beim nächstgelegenen, gesunden Endpoint. Für entfernte Regionen reduziert das spürbar die Round-Trip-Zeit – insbesondere für Interaktionen, die sich aus vielen kleinen Requests zusammensetzen.

Netzwerk und Policies: Cilium Cluster Mesh als verbindende Schicht

In Multi-Cluster-Setups ist Netzwerk nicht nur Transport, sondern Sicherheits- und Betriebslogik. Wir haben Cilium als CNI eingesetzt und Cluster Mesh genutzt, um Service Discovery und Load Balancing über Clustergrenzen hinweg zu ermöglichen, ohne Sicherheitsrichtlinien zu fragmentieren.

Das Entscheidende ist dabei nicht nur, dass Workloads miteinander sprechen können, sondern dass Network Policies zentral und konsistent durchgesetzt werden. In regulierten Umfeldern ist „identische Policies in allen Regionen" ein Audit-Argument und ein Betriebsargument zugleich: Weniger Drift, weniger Sonderfälle, weniger Risiko.

Datenebene: Replikation, die die Realität von Regionen akzeptiert

Georedundanz scheitert oft an der Illusion, man könne „alles synchron" über Regionen betreiben. In der Praxis ist synchrone Replikation über Regionen bei strengen Latenzanforderungen und hoher Verfügbarkeit ein Trade-off, der selten aufgeht. Deshalb wurde die Datenarchitektur bewusst zweistufig gestaltet: innerhalb einer Region synchron, zwischen Regionen asynchron – mit Mechanismen, die Konsistenz garantieren, ohne die Plattform zu blockieren.

Für PostgreSQL bedeutet das: lokale Hochverfügbarkeit durch synchrone Replikation innerhalb der Region, plus asynchrone Cross-Region-Replikation als Basis für Failover. Ergänzt wird das durch Point-in-Time Recovery und georedundante Backups, damit Recovery nicht nur „weiterlaufen", sondern auch „zurückholen" kann, wenn es um Datenkorrektheit geht.

Redis wurde so ausgelegt, dass Sessions regionenübergreifend verfügbar bleiben. Das klingt wie ein Detail, ist aber im Failover-Fall entscheidend: Wenn Nutzer nach einem Region-Umschwenk neu authentifizieren müssen oder Sessions verloren gehen, ist Failover zwar technisch erfolgreich, aber praktisch störend. In kritischen Systemen zählt die Nutzerwahrnehmung.

RabbitMQ wurde über Federation zwischen Regionen gekoppelt, um asynchrone Verarbeitung robust zu halten. Gerade in SCADA-nahen Systemen ist Messaging nicht Bequemlichkeit, sondern die Grundlage dafür, dass Daten auch bei transienten Problemen nicht verloren gehen.

Secrets und Zertifikate wurden über Vault regionenübergreifend repliziert, damit das Failover nicht an „fehlenden Credentials" scheitert. Auch hier gilt: Failover ist so schnell wie die langsamste Abhängigkeit. Wer Secrets manuell synchronisieren muss, hat faktisch keinen automatisierten Failover.

GitOps über Regionen: ArgoCD als Multi-Cluster-Steuerung

Multi-Region-Architektur bringt nur dann echte Stabilität, wenn beide Regionen identisch betrieben werden. Unterschiedliche Versionen, unterschiedliche Configs, unterschiedliche Policies sind eine Einladung zu „Failover in die Überraschung".

Deshalb wurde die Deployment-Steuerung zentral über ArgoCD aufgebaut, mit Multi-Cluster-Management. Änderungen werden nachvollziehbar, versioniert und gleichzeitig in alle Regionen ausgerollt. Das schafft zwei Dinge: Drift verschwindet, und Audits bekommen eine klare Wahrheit darüber, was wo läuft.

Nachweisbarkeit: Automatisiertes Failover-Testing als Audit-Artefakt

KRITIS-Anforderungen sind nicht nur technisch – sie sind nachweispflichtig. Deshalb haben wir Failover nicht als seltenen Notfall betrachtet, sondern als regelmäßig getesteten Prozess.

Über automatisierte Chaos-Engineering-Tests wird eine Region kontrolliert „abgeschaltet". Gemessen werden Übernahmezeit, Stabilität der Sessions, Verhalten der Datenreplikation und Auswirkungen auf kritische Dienste. Aus diesen Tests entstehen strukturierte Reports, die archiviert werden. Damit wird Business Continuity nicht „beschrieben", sondern gemessen und belegt – ein entscheidender Unterschied im Umgang mit Auditoren und Regulierern.

Ergebnis: RTO unter 30 Sekunden, keine Wartungsfenster, Audit ohne Beanstandung

Mit der neuen Architektur konnte der Kunde den Single Point of Failure auf Standortebene eliminieren. In Tests wurde eine RTO unter 30 Sekunden nachgewiesen. Der Traffic schwenkt bei regionalen Ausfällen automatisch um, ohne DNS-Umschaltung und ohne Kundeneingriffe – weil BGP-Routing und Anycast die Umschaltung zur Netzfunktion machen.

Die Audit-Frist konnte eingehalten werden, und der zuvor beanstandete Mangel wurde ohne neue Beanstandungen abgenommen. Gleichzeitig wurde die NIS-2-relevante Dokumentation im Betrieb leichter, weil Observability, Failover-Protokolle und Betriebsnachweise systemisch erzeugt werden.

Im Alltag verschwand ein weiterer Reibungspunkt: Wartungsfenster. Kubernetes-Upgrades, OS-Patches und Infrastrukturarbeiten können rollierend pro Region stattfinden. Während eine Region gewartet wird, übernimmt die andere die Last. Aus Sicht der Kunden entsteht eine Verfügbarkeit, die nicht mehr an „geplante Downtimes" gebunden ist.

Zusätzlich verbesserten sich Latenzen für südliche Regionen, weil Anycast Clients automatisch zum näheren Standort führt. Das ist gerade bei SCADA-Integrationen und Echtzeit-Visualisierung ein spürbarer Gewinn.

Und nicht zuletzt: Ein strategisch wichtiger Netzbetreiber verlängerte den Vertrag, weil die geforderte RTO nicht nur versprochen, sondern nachweisbar erreicht wurde.

Warum dieser Ansatz funktioniert: Georedundanz beginnt im Routing, nicht im Runbook

Viele Organisationen starten Georedundanz mit „zweites Rechenzentrum" und enden mit „DNS umschalten". Das ist in kritischen Umfeldern zu langsam, zu fehleranfällig und zu abhängig von Koordination.

Der entscheidende Unterschied ist, Failover in drei Schichten zu verankern:

Im Netzwerk durch BGP Anycast, damit Clients nichts ändern müssen. In der Plattform durch aktiv/aktiv Multi-Cluster, damit nichts „hochfahren" muss. Im Nachweis durch regelmäßige Tests, damit Audit und Realität zusammenfallen.

Das ist Plattformengineering für KRITIS: weniger Hoffnung, mehr Mechanik.

Call to Action

Wenn ihr eine KRITIS-relevante Plattform betreibt und eure Hochverfügbarkeit faktisch am Standort hängt, dann ist das kein Kubernetes-Thema – es ist ein Architekturthema. Und wenn Failover heute noch bedeutet, Backups einzuspielen und DNS umzuschalten, dann habt ihr keinen automatisierten DR-Prozess, sondern ein Risiko.

ayedo unterstützt beim Aufbau georedundanter Plattformen mit Multi-Region Kubernetes, BGP/Anycast und auditierbaren Betriebsnachweisen – so, dass Failover messbar wird und Wartung nicht mehr als Kundenrisiko existiert.

Wenn ihr eure RTO- und Business-Continuity-Ziele technisch beweisbar machen wollt, sprechen wir gern über eure Ausgangslage.