Failover über mehrere Provider mit der Edge Cloud

TL;DR

Providerunabhängiges Failover trennt den öffentlichen Traffic-Eingang von der Compute-Infrastruktur. Die Edge übernimmt Anycast, DNS, Schutz, TLS und Health Checks, während Backends oder Kubernetes-Cluster bei unterschiedlichen Providern betrieben werden. Backend Cloaking verhindert dabei, dass Failover-Architekturen durch öffentlich erreichbare Ursprungsdienste unnötig exponiert werden.

Einleitung

Ein Multi-Cloud-Failover ist nicht belastbar, wenn lediglich mehrere Backends existieren, aber DNS, Routing und Sicherheitsfunktionen weiterhin an einen einzelnen Provider gebunden sind. Die entscheidende Architekturentscheidung lautet deshalb: Wo endet die Providerabhängigkeit? Wird der öffentliche Eingang von der Compute-Infrastruktur getrennt, kann die Edge den Traffic unabhängig vom jeweiligen Ausführungsort verteilen. Failover wird dann nicht als Umschalten zwischen öffentlich bekannten Endpunkten modelliert, sondern als kontrollierte Änderung innerhalb einer zentralen Traffic- und Schutzschicht. Das reduziert Abhängigkeiten, verlagert aber auch Verantwortung: Health Checks, Zustandsmanagement, Datenreplikation und Betriebsprozesse müssen providerübergreifend geplant werden.

1. Providerunabhängigkeit beginnt am öffentlichen Eingang

Ein einzelner DNS-Provider oder ein providergebundener Loadbalancer kann zum strategischen Engpass werden. Fällt die darunterliegende Plattform aus, ist nicht nur ein Backend betroffen, sondern möglicherweise auch die Möglichkeit, den Traffic umzuleiten. Ein providerunabhängiger Ansatz setzt daher auf eine eigenständige Edge mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System.

Anycast sorgt dabei dafür, dass Anfragen an eine gemeinsame IP-Struktur der Edge gelangen. Die Edge entscheidet anschließend, zu welchem verfügbaren Backend der Traffic weitergeleitet wird. Das ist etwas anderes als ein DNS-basiertes Umschalten zwischen Provideradressen: Die öffentliche Adresse bleibt stabil, während die Auswahl des Backends innerhalb der Edge erfolgt.

Für Unternehmen reduziert diese Trennung die Zahl der direkt gekoppelten Komponenten. Der Compute-Provider muss nicht gleichzeitig DNS, öffentliches Routing und Schutzfunktionen kontrollieren. Die Edge wird damit zu einer unabhängigen Steuerungsebene für den öffentlichen Zugang, während die Providerwahl für die Workloads flexibler bleibt.

2. Backend Cloaking trennt Erreichbarkeit von Sichtbarkeit

Providerunabhängiges Failover darf nicht dazu führen, dass mehrere Ursprungsdienste öffentlich adressierbar und damit direkt angreifbar sind. Werden Backend-IP-Adressen in DNS-Einträgen oder Clientkonfigurationen sichtbar, kann Traffic die zentrale Schutz- und Routingebene umgehen. Außerdem entsteht bei jedem Providerwechsel eine externe Änderung, die Caches, Clients und Betriebsteams berücksichtigen müssen.

Backend Cloaking setzt an diesem Problem an. Die Clients kommunizieren ausschließlich mit der Edge, während die eigentlichen Backends nicht als öffentliche Service-Endpunkte auftreten. Das gilt ebenso für Anwendungen auf unterschiedlichen Kubernetes-Clustern : Ein Cluster kann bei ayedo Managed Kubernetes oder bei einem anderen Provider betrieben werden, ohne dass seine öffentliche Erreichbarkeit zum Architekturprinzip werden muss.

Damit wird die Trennung von Zugang und Ausführung technisch wirksam. TLS Termination, Web Application Firewall, DDoS Protection und Loadbalancing bleiben an der Edge gebündelt. Die Backends müssen weiterhin abgesichert und überwacht werden, sind aber nicht mehr der primäre Ort, an dem öffentliche Traffic-Entscheidungen stattfinden.

3. Failover braucht belastbare Signale und klare Zustände

Anycast allein erkennt keinen Anwendungsausfall. Die Edge benötigt Health Checks, die feststellen, ob ein Backend tatsächlich arbeitsfähig ist. Ein erreichbarer Port beweist beispielsweise nicht, dass eine Anwendung Anfragen korrekt verarbeitet. Für ein belastbares Failover müssen Prüfungen deshalb zur jeweiligen Anwendung passen und zwischen temporärer Störung, Überlastung und dauerhaftem Ausfall unterscheiden.

Die Edge kann Traffic bei einer Störung auf ein anderes Backend oder einen anderen Cluster verteilen. Das löst jedoch keine Probleme, die außerhalb des öffentlichen Routings liegen. Sessions, nicht replizierte Daten, laufende Transaktionen und asynchrone Jobs können bei einem Providerwechsel weiterhin inkonsistent sein. Failover ist daher eine Kombination aus Edge-Entscheidung und zustandsbewusster Anwendungsarchitektur.

Betrieblich entstehen neue Anforderungen: Teams müssen Zuständigkeiten zwischen Edge und Compute definieren, Health Checks versionieren und Umschaltprozesse testen. Multi-Cloud-Failover ist kein Schalter, sondern ein Betriebsmodell. Ohne regelmäßige Tests bleibt unklar, ob Backends, Datenpfade und Wiederanlaufprozesse im Ausfall tatsächlich zusammenpassen.

4. Zentrale Edge-Funktionen reduzieren organisatorische Kopplung

Wenn jeder Provider eigene DNS-, TLS-, WAF- und DDoS-Komponenten bereitstellt, unterscheiden sich Konfigurationen, Betriebsprozesse und Ausfallverhalten. Eine zentrale Edge-Plattform standardisiert diese Funktionen über mehrere Compute-Umgebungen hinweg. Das erleichtert Richtlinien, Monitoring und Änderungen, erhöht aber die Bedeutung der Edge selbst als kritische Infrastrukturkomponente.

Die ayedo Edge Cloud kombiniert dafür Anycast DNS und Multi-Provider-DNS mit Layer-4- und Layer-7-Loadbalancing, TLS Termination, WAF, DDoS Protection, Backend Health Checks und Failover. Durch die eigene Netzwerk-Infrastruktur, das eigene Autonomous System und die verteilte Multi-PoP-Architektur ist die Edge nicht an den Provider gebunden, bei dem ein konkretes Backend läuft. Das Aktiv-Aktiv-Prinzip passt zu diesem Modell, weil der öffentliche Zugang nicht auf einen einzelnen aktiven Standort reduziert werden muss.

Für Platform-Teams bedeutet das eine klare Schichtung: Die Edge verantwortet den Eintritt und die Verteilung, die Compute-Plattform den Betrieb der Workloads. Diese Trennung kann die Providerstrategie vereinfachen, verlangt aber verbindliche Ownership für Konfiguration, Sicherheitsregeln und Störungsanalyse.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API auf einem Kubernetes-Cluster bei Provider A und hält einen zweiten Cluster bei Provider B vor. Beide Cluster werden über dieselbe Edge-Adresse erreicht. Die Edge führt Health Checks aus und leitet Requests bei einem Ausfall von Provider A an Provider B weiter. Die Backend-Adressen werden nicht als öffentliche API-Endpunkte veröffentlicht.

Im Normalbetrieb kann der zweite Cluster als Reserve oder für kontrollierte Lastanteile dienen. Im Fehlerfall bleiben DNS und Clientkonfiguration unverändert. Das Betriebsteam muss jedoch sicherstellen, dass beide Cluster dieselben API-Verträge, Sicherheitsregeln und erforderlichen Datenstände besitzen. Die Edge vereinfacht die Umschaltung; sie ersetzt nicht die Replikation und Konsistenz der Anwendung.

FAQ

Ist Anycast allein ein Multi-Cloud-Failover?

Nein. Anycast bringt den Traffic zur Edge. Erst Health Checks, Backend-Auswahl und eine geeignete Anwendungskonfiguration ermöglichen die Weiterleitung zu einem alternativen Provider.

Verhindert Backend Cloaking jeden direkten Angriff auf ein Backend?

Nein. Es reduziert die öffentliche Sichtbarkeit und verhindert, dass der normale Client-Traffic die Edge umgeht. Backends benötigen weiterhin eigene Zugriffs- und Sicherheitskontrollen.

Muss Kubernetes bei ayedo betrieben werden?

Nein. Die Edge Cloud kann auch Kubernetes-Cluster anbinden, die selbst betrieben oder bei anderen Providern ausgeführt werden.

Fazit

Providerunabhängiges Failover ist vor allem eine Frage der Architekturgrenze. Werden öffentlicher Zugang und Compute getrennt, bleiben Routing, Schutz und Umschaltung unabhängig vom Ausführungsort der Anwendung. Backend Cloaking verhindert, dass diese Flexibilität durch öffentlich exponierte Ursprünge wieder verloren geht. Die ayedo Edge Cloud bildet dafür eine eigenständige Edge-Schicht mit Anycast, eigener Netzwerkinfrastruktur und zentralen Failover-Funktionen. Die technische Verantwortung für Daten, Zustände und betriebliche Tests bleibt jedoch bei der Anwendung und ihren Plattformteams.