{ "version": "https://jsonfeed.org/version/1.1", "title": "Blog | ayedo", "home_page_url": "https://ayedo.de/", "feed_url": "https://ayedo.de/posts/", "description": "Entdecken Sie unsere neuesten Artikel über Cloud-Native Technologien, Kubernetes, DevOps und moderne Software-Entwicklung.", "icon": "https://ayedo.de/ayedo-logo-color.png", "favicon": "https://ayedo.de/ayedo-logo-color.png", "authors": [ { "name": "Fabian Peter", "url": "https://www.linkedin.com/in/derfabianpeter/" } ], "language": "de", "items": [{ "id": "https://ayedo.de/posts/digitale-souveranitat-endet-nicht-im-rechenzentrum/", "url": "https://ayedo.de/posts/digitale-souveranitat-endet-nicht-im-rechenzentrum/", "title": "Digitale Souveränität endet nicht im Rechenzentrum:", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/digitale-souveranitat-endet-nicht-im-rechenzentrum/digitale-souveranitat-endet-nicht-im-rechenzentrum.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003ch2 id=\"warum-wir-die-ayedo-edge-cloud-gebaut-haben\"\u003eWarum wir die ayedo Edge Cloud gebaut haben\u003c/h2\u003e\n\u003cp\u003eEine Anwendung kann vollständig in Deutschland betrieben werden und trotzdem bei jedem einzelnen Zugriff von US-Infrastruktur abhängig sein.\u003c/p\u003e\n\u003cp\u003eDenn bevor eine Anfrage den ersten Pod im \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n erreicht, ist bereits einiges passiert. DNS hat den Namen aufgelöst. Das Internet hat einen Netzwerkpfad gewählt. Eine öffentliche IP wurde erreicht. TLS wurde terminiert oder weitergeleitet. Traffic wurde geprüft und auf ein Backend verteilt.\u003c/p\u003e\n\u003cp\u003eGenau diese Schicht ist die Edge.\u003c/p\u003e\n\u003cp\u003eUnd genau hier beginnt für uns die Frage, wer die technische Kontrolle über eine Anwendung tatsächlich hat.\u003c/p\u003e\n\u003ch2 id=\"es-beginnt-nicht-mit-dem-server-sondern-mit-dem-routing\"\u003eEs beginnt nicht mit dem Server, sondern mit dem Routing\u003c/h2\u003e\n\u003cp\u003eDie technische Basis unserer Edge Cloud ist ein eigenes Autonomous System. Damit betreiben wir die Netzwerkschicht, über die unsere Edge-Standorte ihre Routen im Internet bekannt geben.\u003c/p\u003e\n\u003cp\u003eZum Start arbeiten fünf Points of Presence in Deutschland: Hamburg, Alsbach und drei Standorte in Frankfurt. Alle fünf sind aktiv und announcen dieselben Anycast-Präfixe.\u003c/p\u003e\n\u003cp\u003eDas ist ein wichtiger Unterschied zu einer Architektur, bei der ein Dienst fest an einen Standort und dessen IP-Adresse gebunden ist.\u003c/p\u003e\n\u003cp\u003eBei Anycast ist dieselbe öffentliche IP gleichzeitig über mehrere Standorte erreichbar. Das Routing entscheidet, über welchen erreichbaren PoP eine neue Verbindung geführt wird. Fällt ein Standort aus, muss nicht erst ein Standby-System aktiviert und anschließend auf die DNS-Propagation gewartet werden. Die verbleibenden PoPs announcen die Route weiterhin.\u003c/p\u003e\n\u003cp\u003eVerfügbarkeit entsteht damit bereits auf Netzwerkebene.\u003c/p\u003e\n\u003ch2 id=\"dns-gehört-zur-infrastruktur\"\u003eDNS gehört zur Infrastruktur\u003c/h2\u003e\n\u003cp\u003eVor fast jeder Verbindung steht eine DNS-Anfrage. Deshalb behandeln wir DNS nicht als externen Zusatzdienst.\u003c/p\u003e\n\u003cp\u003eDNS-Zonen werden über die Edge-Infrastruktur mit Anycast bereitgestellt. Anfragen können damit einen erreichbaren PoP nutzen. Interne und externe Zonen lassen sich zentral verwalten, externe Zonen mit unterstützten DNS-Providern synchronisieren.\u003c/p\u003e\n\u003cp\u003eEntscheidend ist aber auch, wie DNS betrieben wird.\u003c/p\u003e\n\u003cp\u003eDie Konfiguration lässt sich in Automatisierungsprozesse integrieren. DNS wird damit Teil von Infrastructure as Code, CI/CD und GitOps statt einer Konfiguration, die jemand manuell in einem fremden Webinterface pflegt.\u003c/p\u003e\n\u003cp\u003eDas ist für Entwickler praktisch. Für Unternehmen ist es vor allem nachvollziehbar und reproduzierbar.\u003c/p\u003e\n\u003ch2 id=\"die-öffentliche-ip-muss-nicht-dem-cloud-provider-gehören\"\u003eDie öffentliche IP muss nicht dem Cloud-Provider gehören\u003c/h2\u003e\n\u003cp\u003eEin oft unterschätzter Lock-in entsteht bei IP-Adressen.\u003c/p\u003e\n\u003cp\u003eWechselt ein Unternehmen den Provider und damit seine öffentlichen IPs, betrifft das schnell mehr als einen DNS-Record. Allowlists bei Partnern, Firewall-Regeln, APIs, Zertifikatsprozesse und andere Systeme können an diesen Adressen hängen.\u003c/p\u003e\n\u003cp\u003eDeshalb unterstützt die Edge Cloud Bring Your Own IP.\u003c/p\u003e\n\u003cp\u003eUnternehmen können eigene IP-Präfixe einsetzen. Wir announcen und routen diese über unsere Edge-Infrastruktur.\u003c/p\u003e\n\u003cp\u003eDamit kann der öffentliche Adressraum vom Compute-Provider getrennt werden. Ein Backend kann wechseln, ohne dass zwangsläufig auch seine öffentliche Identität im Netz wechseln muss.\u003c/p\u003e\n\u003cp\u003eDas ist ein ziemlich konkreter Unterschied zwischen „wir können theoretisch den Provider wechseln“ und „unsere Architektur ist tatsächlich darauf vorbereitet“.\u003c/p\u003e\n\u003ch2 id=\"edge-und-compute-sind-bewusst-getrennt\"\u003eEdge und Compute sind bewusst getrennt\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud ist nicht an die ayedo Compute Cloud gebunden.\u003c/p\u003e\n\u003cp\u003eDie Anwendung kann in unserer Compute Cloud laufen, in einem anderen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n, bei einem anderen Provider oder on-premises. DNS und Traffic können trotzdem über die Edge bereitgestellt werden.\u003c/p\u003e\n\u003cp\u003eDas verändert die Architektur grundlegend.\u003c/p\u003e\n\u003cp\u003eDer öffentliche Einstiegspunkt und der Ort, an dem Compute stattfindet, werden zu zwei getrennten Entscheidungen.\u003c/p\u003e\n\u003cp\u003eEin Unternehmen kann also seinen Compute-Standort verändern, ohne gleichzeitig die komplette externe Erreichbarkeit neu bauen zu müssen. Umgekehrt kann die Edge-Infrastruktur ausgetauscht oder erweitert werden, ohne die Anwendungsarchitektur grundsätzlich zu verändern.\u003c/p\u003e\n\u003cp\u003eGenau diese Entkopplung reduziert Abhängigkeiten.\u003c/p\u003e\n\u003ch2 id=\"vom-internet-bis-zum-pod-ist-der-pfad-klar-definiert\"\u003eVom Internet bis zum Pod ist der Pfad klar definiert\u003c/h2\u003e\n\u003cp\u003eTechnisch sieht der Weg einer Anfrage bei \u003ca href=\"/kubernetes/\"\u003eKubernetes-Workloads\u003c/a\u003e\n so aus:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eClient → ayedo Edge / Loadbalancer → Node → Ingress Controller oder Gateway Proxy → Service → Pod.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eDie einzelnen Schichten haben unterschiedliche Aufgaben.\u003c/p\u003e\n\u003cp\u003eDer Edge-Loadbalancer hält die öffentliche virtuelle IP, führt Health-Checks durch und kann TCP- oder HTTP-Traffic terminieren beziehungsweise weiterleiten. Im Cluster übernimmt anschließend der Ingress Controller oder Gateway Proxy das Routing nach Hostname und Pfad. TLS kann dort terminiert oder per Passthrough weitergereicht werden.\u003c/p\u003e\n\u003cp\u003eFür bestehende \u003ca href=\"/kubernetes/\"\u003eKubernetes-Workloads\u003c/a\u003e\n unterstützen wir NGINX Ingress mit den etablierten \u003ccode\u003eIngress\u003c/code\u003e- und \u003ccode\u003eIngressClass\u003c/code\u003e-Ressourcen.\u003c/p\u003e\n\u003cp\u003eFür neue Architekturen steht Envoy Gateway mit der Kubernetes Gateway API zur Verfügung. Routing wird dort über Ressourcen wie \u003ccode\u003eGateway\u003c/code\u003e, \u003ccode\u003eHTTPRoute\u003c/code\u003e und \u003ccode\u003eTLSRoute\u003c/code\u003e beschrieben.\u003c/p\u003e\n\u003cp\u003eDas ist bewusst keine proprietäre ayedo-Routing-API, die Anwendungen technisch an unsere Plattform bindet.\u003c/p\u003e\n\u003ch2 id=\"schutz-findet-statt-bevor-der-traffic-die-anwendung-erreicht\"\u003eSchutz findet statt, bevor der Traffic die Anwendung erreicht\u003c/h2\u003e\n\u003cp\u003eZur Edge gehören deshalb auch die Sicherheitsfunktionen, die vor dem eigentlichen Workload greifen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bündelt DNS, TLS, Layer-4- und Layer-7-Loadbalancing, Web Application Firewall, DDoS-Schutz und Health-Checks.\u003c/p\u003e\n\u003cp\u003eDie WAF sitzt damit nicht irgendwo innerhalb der Anwendung, sondern kann HTTP(S)-Traffic bereits am Edge prüfen. Erst danach erreicht legitimer Traffic Cluster-Ingress, Services und Pods.\u003c/p\u003e\n\u003cp\u003eHealth-Checks erfüllen eine ebenso wichtige Funktion: Eine Route kann technisch erreichbar sein, obwohl das dahinterliegende Backend nicht mehr funktioniert. Deshalb reicht Netzwerk-Redundanz allein nicht. Die Edge muss auch wissen, welche Ziele tatsächlich verfügbar sind.\u003c/p\u003e\n\u003cp\u003eNetzwerk, Routing, Anwendungsgesundheit und Schutzmechanismen gehören deshalb zusammen.\u003c/p\u003e\n\u003ch2 id=\"eine-europäische-cloud-braucht-eine-europäische-netzwerkschicht\"\u003eEine europäische Cloud braucht eine europäische Netzwerkschicht\u003c/h2\u003e\n\u003cp\u003eCloudflare hat gezeigt, wie wertvoll es ist, DNS, Routing, Loadbalancing und Security an einer globalen Edge zusammenzuführen.\u003c/p\u003e\n\u003cp\u003eDas Problem ist nicht dieses technische Modell. Im Gegenteil: Es ist sehr gut.\u003c/p\u003e\n\u003cp\u003eDas Problem entsteht, wenn wir in Europa Anwendungen, Datenbanken und \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n unter europäischen Bedingungen betreiben, den gesamten öffentlichen Zugang aber dauerhaft über Infrastruktur kontrollieren lassen, die außerhalb Europas betrieben wird.\u003c/p\u003e\n\u003cp\u003eDeshalb bauen wir diese Schicht selbst.\u003c/p\u003e\n\u003cp\u003eMit eigenem Autonomous System. Eigener Edge-Infrastruktur in der EU. Anycast über mehrere aktive PoPs. Eigenem Routing. Anycast DNS. Loadbalancing. WAF und DDoS-Schutz. Offenen Kubernetes-Schnittstellen. Und der Möglichkeit, Compute und sogar den öffentlichen IP-Adressraum unabhängig vom Plattformanbieter zu halten.\u003c/p\u003e\n\u003cp\u003eDenn die entscheidende Frage ist nicht nur, \u003cstrong\u003ewo eine Anwendung läuft\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eSondern wer DNS, IP-Adressen, Routing und den Weg bis zu dieser Anwendung kontrolliert.\u003c/p\u003e\n", "summary": "\nWarum wir die ayedo Edge Cloud gebaut haben Eine Anwendung kann vollständig in Deutschland betrieben werden und trotzdem bei jedem einzelnen Zugriff von US-Infrastruktur abhängig sein.\nDenn bevor eine Anfrage den ersten Pod im Kubernetes-Cluster erreicht, ist bereits einiges passiert. DNS hat den Namen aufgelöst. Das Internet hat einen Netzwerkpfad gewählt. Eine öffentliche IP wurde erreicht. TLS wurde terminiert oder weitergeleitet. Traffic wurde geprüft und auf ein Backend verteilt.\nGenau diese Schicht ist die Edge.\n", "image": "https://ayedo.de/digitale-souveranitat-endet-nicht-im-rechenzentrum.png", "date_published": "2026-09-09T08:26:13Z", "date_modified": "2026-09-09T08:26:13Z", "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}], "tags": ["kubernetes","digital-sovereignty","politics","operations","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht/", "url": "https://ayedo.de/posts/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht/", "title": "DNS, Routing, Anycast: Warum Europas Cloud auch eine eigene Edge braucht", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003eWir haben vor Kurzem die ayedo Edge Cloud vorgestellt. Eine europäische Edge-Infrastruktur für DNS, Anycast, Loadbalancing, Web Application Firewall, DDoS-Schutz und den kontrollierten Zugang zu Anwendungen.\u003c/p\u003e\n\u003cp\u003eDie Reaktion darauf hat uns gezeigt, dass sich ein genauerer Blick auf die Technik lohnt. Denn eine Edge Cloud ist weit mehr als ein vorgeschalteter Loadbalancer.\u003c/p\u003e\n\u003cp\u003eSie kontrolliert einen entscheidenden Teil der Infrastruktur: den Weg aus dem öffentlichen Internet bis zur eigentlichen Anwendung.\u003c/p\u003e\n\u003cp\u003eBevor eine Anfrage den ersten Pod im \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n erreicht, ist bereits einiges passiert. DNS hat einen Namen aufgelöst. Das Internet hat anhand von BGP-Routen einen Netzwerkpfad gewählt. Eine öffentliche IP wurde erreicht. Eine Verbindung wurde angenommen, Traffic geprüft und anschließend an ein verfügbares Backend weitergeleitet.\u003c/p\u003e\n\u003cp\u003eWer diese Komponenten betreibt, kontrolliert einen erheblichen Teil des Zugangs zur Anwendung.\u003c/p\u003e\n\u003cp\u003eDeshalb haben wir bei unserer Edge Cloud nicht bei einem einzelnen Produktfeature angefangen. Wir haben die darunterliegende Infrastruktur aufgebaut.\u003c/p\u003e\n\u003ch2 id=\"ein-eigenes-autonomous-system-als-grundlage\"\u003eEin eigenes Autonomous System als Grundlage\u003c/h2\u003e\n\u003cp\u003eDie technische Basis unserer Edge Cloud ist unser eigenes Autonomous System.\u003c/p\u003e\n\u003cp\u003eEin Autonomous System, kurz AS, ist vereinfacht gesagt ein eigenständig verwalteter Teil des Internets mit einer eigenen Routing-Policy. Über BGP tauschen solche Netze untereinander aus, welche IP-Netze über sie erreichbar sind.\u003c/p\u003e\n\u003cp\u003eFür unsere Edge bedeutet das: Wir betreiben die Netzwerkschicht, über die unsere Standorte ihre Routen im Internet bekannt geben.\u003c/p\u003e\n\u003cp\u003eZum Start arbeiten fünf Points of Presence in Deutschland: Hamburg, Alsbach und drei Standorte in Frankfurt. Alle fünf sind aktiv und announcen dieselben Anycast-Präfixe.\u003c/p\u003e\n\u003ch2 id=\"eine-ip-adresse-mehrere-standorte\"\u003eEine IP-Adresse, mehrere Standorte\u003c/h2\u003e\n\u003cp\u003eAnycast ist ein zentraler Bestandteil dieser Architektur.\u003c/p\u003e\n\u003cp\u003eDabei wird dasselbe IP-Präfix gleichzeitig von mehreren Standorten angekündigt. Ein Nutzer verbindet sich also beispielsweise immer mit derselben öffentlichen IP-Adresse – diese IP ist aber nicht an einen einzelnen Server oder einen einzelnen Standort gebunden.\u003c/p\u003e\n\u003cp\u003eBGP bestimmt anhand der verfügbaren Routen, über welchen PoP die Verbindung die Edge erreicht.\u003c/p\u003e\n\u003cp\u003eDas hat einen entscheidenden Vorteil: Fällt ein Standort aus und seine Route wird zurückgezogen, bleiben die anderen Standorte erreichbar. Neue Verbindungen können über einen anderen PoP geführt werden. Dafür muss weder eine öffentliche IP geändert noch auf die Aktualisierung eines DNS-Eintrags gewartet werden.\u003c/p\u003e\n\u003cp\u003eRedundanz beginnt damit nicht erst beim Server, sondern bereits im Routing.\u003c/p\u003e\n\u003ch2 id=\"auch-dns-läuft-über-die-edge\"\u003eAuch DNS läuft über die Edge\u003c/h2\u003e\n\u003cp\u003eNoch vor der eigentlichen Verbindung steht in den meisten Fällen DNS. Deshalb gehört auch diese Ebene zur Edge Cloud.\u003c/p\u003e\n\u003cp\u003eDNS-Zonen werden über unsere Edge-Infrastruktur mit Anycast bereitgestellt. Damit ist auch die Namensauflösung nicht an einen einzelnen Standort gebunden.\u003c/p\u003e\n\u003cp\u003eGleichzeitig behandeln wir DNS nicht als Konfiguration, die ausschließlich über ein Webinterface verwaltet werden kann. DNS lässt sich automatisieren und in Infrastructure-as-Code-, CI/CD- und GitOps-Prozesse integrieren.\u003c/p\u003e\n\u003cp\u003eDas ist gerade für Plattformteams wichtig: Infrastruktur bleibt reproduzierbar und kann mit denselben Prozessen verwaltet werden wie der Rest des Stacks.\u003c/p\u003e\n\u003ch2 id=\"die-öffentliche-ip-muss-nicht-uns-gehören\"\u003eDie öffentliche IP muss nicht uns gehören\u003c/h2\u003e\n\u003cp\u003eEin weiterer Bestandteil ist Bring Your Own IP, kurz BYOIP.\u003c/p\u003e\n\u003cp\u003eUnternehmen können eigene IP-Präfixe mitbringen, die wir über unsere Edge-Infrastruktur announcen und routen.\u003c/p\u003e\n\u003cp\u003eDas klingt zunächst nach einem Detail für Netzwerkadministratoren. Für die Unabhängigkeit einer Infrastruktur ist es aber relevant.\u003c/p\u003e\n\u003cp\u003eÖffentliche IP-Adressen landen mit der Zeit in Firewall-Regeln, Allowlists von Geschäftspartnern, APIs und anderen Konfigurationen. Gehören diese Adressen dem Cloud-Anbieter, kann ein Providerwechsel deshalb weit mehr bedeuten als den Umzug einiger Workloads.\u003c/p\u003e\n\u003cp\u003eMit BYOIP bleiben die Adressen beim Unternehmen. Der öffentliche Adressraum und die darunterliegende Compute-Infrastruktur werden voneinander getrennt.\u003c/p\u003e\n\u003ch2 id=\"edge-und-compute-sind-zwei-unterschiedliche-entscheidungen\"\u003eEdge und Compute sind zwei unterschiedliche Entscheidungen\u003c/h2\u003e\n\u003cp\u003eDiese Trennung zieht sich durch die gesamte Architektur.\u003c/p\u003e\n\u003cp\u003eDie Anwendung hinter unserer Edge muss nicht in der ayedo Compute Cloud laufen. Sie kann dort betrieben werden, in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei einem anderen Provider oder in eigener Infrastruktur.\u003c/p\u003e\n\u003cp\u003eDie Edge übernimmt den öffentlichen Zugang und leitet Traffic zum definierten Backend.\u003c/p\u003e\n\u003cp\u003eDamit werden zwei Dinge voneinander entkoppelt, die bei Cloud-Plattformen häufig zusammenfallen: \u003cstrong\u003eWo läuft meine Anwendung – und über wessen Infrastruktur ist sie erreichbar?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eDas macht hybride und Multi-Provider-Architekturen möglich, ohne für jeden Compute-Standort eine komplett eigene öffentliche Zugriffsschicht aufbauen zu müssen.\u003c/p\u003e\n\u003ch2 id=\"vom-internet-bis-zum-kubernetes-pod\"\u003eVom Internet bis zum Kubernetes-Pod\u003c/h2\u003e\n\u003cp\u003eBei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n lässt sich dieser Weg sehr konkret nachvollziehen:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eClient → ayedo Edge / Loadbalancer → Node → Ingress Controller oder Gateway Proxy → Service → Pod\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eDer Edge-Loadbalancer hält die öffentliche virtuelle IP, prüft die Erreichbarkeit der Backends und leitet TCP- oder HTTP-Traffic weiter beziehungsweise terminiert ihn.\u003c/p\u003e\n\u003cp\u003eInnerhalb des Clusters übernimmt anschließend ein Ingress Controller oder Gateway Proxy das anwendungsspezifische Routing. Dort wird beispielsweise anhand von Hostname und Pfad entschieden, welcher Service eine HTTP-Anfrage erhält.\u003c/p\u003e\n\u003cp\u003eFür bestehende \u003ca href=\"/kubernetes/\"\u003eKubernetes-Architekturen\u003c/a\u003e\n unterstützen wir NGINX Ingress mit \u003ccode\u003eIngress\u003c/code\u003e und \u003ccode\u003eIngressClass\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eFür neue Architekturen steht Envoy Gateway mit der Kubernetes Gateway API und Ressourcen wie \u003ccode\u003eGateway\u003c/code\u003e, \u003ccode\u003eHTTPRoute\u003c/code\u003e und \u003ccode\u003eTLSRoute\u003c/code\u003e zur Verfügung.\u003c/p\u003e\n\u003cp\u003eDas ist für uns ein wichtiger Architekturgrundsatz: Der Übergang von unserer Infrastruktur zum \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n basiert auf etablierten Cloud-Native-Standards und nicht auf einer proprietären ayedo-Routinglogik.\u003c/p\u003e\n\u003ch2 id=\"security-gehört-vor-die-anwendung\"\u003eSecurity gehört vor die Anwendung\u003c/h2\u003e\n\u003cp\u003eAuf derselben Ebene sitzen die Schutzmechanismen.\u003c/p\u003e\n\u003cp\u003eZur Edge Cloud gehören deshalb Layer-4- und Layer-7-Loadbalancing, TLS, Web Application Firewall, DDoS-Schutz und Health-Checks.\u003c/p\u003e\n\u003cp\u003eDie WAF kann HTTP(S)-Traffic prüfen, bevor er die dahinterliegenden Anwendungen erreicht. DDoS-Schutz setzt bereits auf der vorgelagerten Infrastruktur an. Health-Checks stellen sicher, dass Traffic nicht einfach an ein Ziel geschickt wird, nur weil dessen Netzwerkroute noch existiert.\u003c/p\u003e\n\u003cp\u003eDas ist ein wichtiger Unterschied: Ein erreichbarer Server ist noch lange kein funktionierender Service.\u003c/p\u003e\n\u003cp\u003eEdge-Infrastruktur muss deshalb Routing, Verfügbarkeit und Security gemeinsam betrachten.\u003c/p\u003e\n\u003ch2 id=\"eine-europäische-alternative-muss-technisch-überzeugen\"\u003eEine europäische Alternative muss technisch überzeugen\u003c/h2\u003e\n\u003cp\u003eCloudflare hat diese Infrastrukturschicht sehr erfolgreich zu einem Produkt gemacht. DNS, Anycast, Routing, Loadbalancing und Security aus einer Hand zu bekommen, löst reale technische Probleme.\u003c/p\u003e\n\u003cp\u003eEine europäische Alternative kann deshalb nicht darin bestehen, dasselbe Konzept mit einem EU-Label zu versehen.\u003c/p\u003e\n\u003cp\u003eSie braucht eigene Infrastruktur.\u003c/p\u003e\n\u003cp\u003eEin eigenes Autonomous System. Eigenes Routing. Mehrere aktive PoPs. Anycast. DNS. Loadbalancing. WAF und DDoS-Schutz. Offene Schnittstellen zu \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Die Möglichkeit, Compute unabhängig zu wählen. Und mit BYOIP sogar die Möglichkeit, den eigenen öffentlichen Adressraum zu behalten.\u003c/p\u003e\n\u003cp\u003eGenau diese Infrastruktur bauen wir mit der ayedo Edge Cloud.\u003c/p\u003e\n\u003cp\u003eDenn europäische Cloud-Infrastruktur ist erst dann eine echte Alternative, wenn sie nicht nur regulatorisch anders aufgestellt ist, sondern technisch die Kontrolle über die entscheidenden Schichten zurückholt.\u003c/p\u003e\n", "summary": "\nWir haben vor Kurzem die ayedo Edge Cloud vorgestellt. Eine europäische Edge-Infrastruktur für DNS, Anycast, Loadbalancing, Web Application Firewall, DDoS-Schutz und den kontrollierten Zugang zu Anwendungen.\nDie Reaktion darauf hat uns gezeigt, dass sich ein genauerer Blick auf die Technik lohnt. Denn eine Edge Cloud ist weit mehr als ein vorgeschalteter Loadbalancer.\nSie kontrolliert einen entscheidenden Teil der Infrastruktur: den Weg aus dem öffentlichen Internet bis zur eigentlichen Anwendung.\n", "image": "https://ayedo.de/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht.png", "date_published": "2026-09-09T08:19:24Z", "date_modified": "2026-09-09T08:19:24Z", "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}], "tags": ["kubernetes","cloud-native","security","politics","cloud"], "language": "de" },{ "id": "https://ayedo.de/posts/building-the-edge-part-1/", "url": "https://ayedo.de/posts/building-the-edge-part-1/", "title": "Building the Edge — Part 1", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/building-the-edge-part-1/building-the-edge-part-1.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003ch2 id=\"die-unterschätzte-architektur-moderner-anwendungen\"\u003eDie unterschätzte Architektur moderner Anwendungen\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eModerne Anwendungen beginnen nicht mehr im Rechenzentrum.\u003c/em\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eEs gibt eine merkwürdige Eigenschaft moderner Software.\u003c/p\u003e\n\u003cp\u003eJe leistungsfähiger unsere Plattformen geworden sind, desto einfacher scheint ihre Architektur auf den ersten Blick geworden zu sein.\u003c/p\u003e\n\u003cp\u003eHeute sprechen wir über \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, GitOps, Infrastructure as Code oder Continuous Deployment, als wären sie selbstverständliche Bestandteile jeder Anwendung. Innerhalb weniger Minuten entstehen Cluster, \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n werden automatisch skaliert und neue Versionen erreichen den Produktivbetrieb, ohne dass ein Benutzer davon überhaupt Notiz nimmt. Verglichen mit der Infrastruktur vergangener Jahrzehnte wirkt moderne Software beinahe elegant.\u003c/p\u003e\n\u003cp\u003eVielleicht sogar erstaunlich einfach.\u003c/p\u003e\n\u003cp\u003eDoch dieser Eindruck täuscht.\u003c/p\u003e\n\u003cp\u003eNicht deshalb, weil moderne Systeme komplizierter wären als ihre Vorgänger.\u003c/p\u003e\n\u003cp\u003eSondern weil sich ihre Komplexität an einen Ort verlagert hat, über den wir erstaunlich selten sprechen.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eBetrachten wir für einen Moment, wie die meisten Architekturdiagramme beginnen.text\nAnwendung\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e +----------------------+\n | Kubernetes |\n +----------------------+\n |\n +----------------------+\n | Datenbank |\n +----------------------+\n |\n Internet ☁\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEs ist ein Diagramm, das vermutlich jeder kennt.\u003c/p\u003e\n\u003cp\u003eLinks befindet sich das Internet.\u003c/p\u003e\n\u003cp\u003eDanach folgt ein Loadbalancer, vielleicht noch ein Ingress Controller, anschließend \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und schließlich die eigentliche Anwendung.\u003c/p\u003e\n\u003cp\u003eInteressanterweise diskutieren wir fast ausschließlich über den rechten Teil dieses Diagramms.\u003c/p\u003e\n\u003cp\u003eWir sprechen über \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eÜber Datenbanken.\u003c/p\u003e\n\u003cp\u003eÜber Replikation.\u003c/p\u003e\n\u003cp\u003eÜber Observability.\u003c/p\u003e\n\u003cp\u003eÜber Deployments.\u003c/p\u003e\n\u003cp\u003eDer linke Teil verschwindet dagegen häufig hinter einer kleinen Wolke mit der Beschriftung \u003cem\u003eInternet\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003eAls wäre zwischen einem Benutzer und unserer Plattform nichts weiter von Bedeutung.\u003c/p\u003e\n\u003cp\u003eVielleicht ist genau das eines der größten Missverständnisse moderner Infrastruktur.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eDie Vorstellung, dass eine Anwendung dort beginnt, wo der erste Prozess gestartet oder der erste Pod geplant wird, stammt aus einer Zeit, in der Anwendungen und Infrastruktur nahezu deckungsgleich waren.\u003c/p\u003e\n\u003cp\u003eEin Webserver war eine Anwendung.\u003c/p\u003e\n\u003cp\u003eEine Anwendung war ein Server.\u003c/p\u003e\n\u003cp\u003eZwischen dem Browser eines Benutzers und der eigentlichen Software lagen vergleichsweise wenige technische Schichten. Ein Router leitete Pakete weiter, ein Webserver beantwortete HTTP-Anfragen und eine Datenbank speicherte Informationen. Routing, Transport und Anwendung bildeten eine Einheit, die sich noch auf einem Blatt Papier erklären ließ.\u003c/p\u003e\n\u003cp\u003eHeute wirkt dieses Bild beinahe nostalgisch.\u003c/p\u003e\n\u003cp\u003eNicht, weil es falsch gewesen wäre.\u003c/p\u003e\n\u003cp\u003eSondern weil es eine Welt beschreibt, die in dieser Form kaum noch existiert.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eIn den vergangenen anderthalb Jahrzehnten haben wir enorme Anstrengungen unternommen, Anwendungen von ihrer Infrastruktur zu entkoppeln.\u003c/p\u003e\n\u003cp\u003eVirtuelle Maschinen ersetzten physische Server.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n machten Anwendungen portabel.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n löste Workloads von einzelnen Hosts.\u003c/p\u003e\n\u003cp\u003eInfrastructure as Code ersetzte manuelle Konfigurationen.\u003c/p\u003e\n\u003cp\u003eGitOps machte Infrastruktur reproduzierbar.\u003c/p\u003e\n\u003cp\u003eJede dieser Entwicklungen verfolgte dasselbe Ziel.\u003c/p\u003e\n\u003cp\u003eDie Komplexität innerhalb einer Plattform zu reduzieren.\u003c/p\u003e\n\u003cp\u003eUnd sie war außerordentlich erfolgreich.\u003c/p\u003e\n\u003cp\u003eVielleicht liegt genau darin jedoch eine bemerkenswerte Ironie.\u003c/p\u003e\n\u003cp\u003eDenn während wir Anwendungen immer weiter abstrahierten, entstand außerhalb dieser Plattformen eine vollkommen neue Architekturschicht, deren Verantwortung kontinuierlich wuchs.\u003c/p\u003e\n\u003cp\u003eInfrastruktur ist nicht einfacher geworden.\u003c/p\u003e\n\u003cp\u003eSie ist gewandert.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eDer erste Kontakt zwischen einem Benutzer und einer modernen Anwendung findet heute längst nicht mehr im Rechenzentrum statt.\u003c/p\u003e\n\u003cp\u003eEr findet an einer Stelle statt, die in Architekturdiagrammen häufig überhaupt nicht vorkommt.\u003c/p\u003e\n\u003cp\u003eNoch bevor \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n einen Pod auswählt.\u003c/p\u003e\n\u003cp\u003eNoch bevor ein Service entscheidet, welches Backend eine Anfrage verarbeitet.\u003c/p\u003e\n\u003cp\u003eNoch bevor eine einzige Zeile Anwendungscode ausgeführt wird.\u003c/p\u003e\n\u003cp\u003eExistiert bereits eine Infrastruktur, deren einzige Aufgabe darin besteht, genau diese Entscheidungen vorzubereiten.\u003c/p\u003e\n\u003cp\u003eSie bestimmt, welchen Weg eine Verbindung durch das Internet nimmt.\u003c/p\u003e\n\u003cp\u003eAn welchem Standort sie endet.\u003c/p\u003e\n\u003cp\u003eOb sie verschlüsselt wird.\u003c/p\u003e\n\u003cp\u003eOb sie legitim ist.\u003c/p\u003e\n\u003cp\u003eOb sie überhaupt bis zur eigentlichen Anwendung gelangen darf.\u003c/p\u003e\n\u003cp\u003eVielleicht erscheint diese Unterscheidung zunächst subtil.\u003c/p\u003e\n\u003cp\u003eTatsächlich verändert sie jedoch unseren gesamten Blick auf moderne Plattformen.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eDenn plötzlich beginnt eine Anwendung nicht mehr dort, wo sie ausgeführt wird.\u003c/p\u003e\n\u003cp\u003eSie beginnt dort, wo ein Benutzer zum ersten Mal mit ihr interagiert.\u003c/p\u003e\n\u003cp\u003eDieser Gedanke wirkt zunächst beinahe selbstverständlich.\u003c/p\u003e\n\u003cp\u003eUnd doch behandeln wir unsere Systeme meist so, als wäre genau das nicht der Fall.\u003c/p\u003e\n\u003cp\u003eWir investieren Wochen in die Planung unserer \u003ca href=\"/kubernetes/\"\u003eKubernetes-Architektur\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eWir diskutieren über Storage-Klassen, Deployment-Strategien oder Service Meshes.\u003c/p\u003e\n\u003cp\u003eGleichzeitig verschwindet der gesamte Weg bis dorthin häufig hinter einer einzigen Linie mit der Beschriftung \u003cem\u003eInternet\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003eVielleicht liegt genau darin das eigentliche Problem.\u003c/p\u003e\n\u003cp\u003eDas Internet ist keine Wolke.\u003c/p\u003e\n\u003cp\u003eEs ist keine Verbindung zwischen zwei Kästen in einem Diagramm.\u003c/p\u003e\n\u003cp\u003eUnd schon gar kein transparenter Transportkanal, durch den Requests einfach hindurchfließen.\u003c/p\u003e\n\u003cp\u003eEs ist vermutlich das größte verteilte System, das jemals gebaut wurde.\u003c/p\u003e\n\u003cp\u003eEin System, das Routingentscheidungen trifft.\u003c/p\u003e\n\u003cp\u003eDas Netzwerke miteinander verbindet.\u003c/p\u003e\n\u003cp\u003eDas kontinuierlich bewertet, welche Wege erreichbar sind und welche nicht.\u003c/p\u003e\n\u003cp\u003eUnd das jeden einzelnen Request bereits lange beeinflusst, bevor eine Anwendung überhaupt Gelegenheit erhält zu antworten.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eGute Infrastruktur besitzt eine bemerkenswerte Eigenschaft.\u003c/p\u003e\n\u003cp\u003eSie verschwindet.\u003c/p\u003e\n\u003cp\u003eNiemand interessiert sich für DNS, solange sich eine Domain zuverlässig auflösen lässt.\u003c/p\u003e\n\u003cp\u003eNiemand denkt über Routing nach, solange Webseiten innerhalb weniger Millisekunden laden.\u003c/p\u003e\n\u003cp\u003eNiemand beschäftigt sich mit TLS, solange im Browser das kleine Schlosssymbol erscheint.\u003c/p\u003e\n\u003cp\u003eUnd kaum jemand fragt sich, welchen Weg eine Anfrage tatsächlich genommen hat, solange die Antwort schnell genug zurückkommt.\u003c/p\u003e\n\u003cp\u003eGute Infrastruktur erzeugt keine Aufmerksamkeit.\u003c/p\u003e\n\u003cp\u003eSie erzeugt Vertrauen.\u003c/p\u003e\n\u003cp\u003eVielleicht fällt es uns gerade deshalb so schwer, über sie nachzudenken.\u003c/p\u003e\n\u003cp\u003eWir sehen sie meist erst dann, wenn sie versagt.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eVielleicht ist es deshalb an der Zeit, unsere Architekturdiagramme an einem anderen Punkt beginnen zu lassen.\u003c/p\u003e\n\u003cp\u003eNicht hier.text\nInternet ☁\n|\nKubernetes\n|\nAnwendung\u003c/p\u003e\n\u003cp\u003eSondern hier.text\u003c/p\u003e\n\u003cp\u003eBrowser\n|\nDNS\n|\nRouting\n|\nPeering\n|\nAnycast\n|\nTLS\n|\nEdge\n|\nLoadbalancing\n|\nKubernetes\n|\nAnwendung\u003c/p\u003e\n\u003cp\u003eDenn moderne Anwendungen beginnen längst nicht mehr im Rechenzentrum.\u003c/p\u003e\n\u003cp\u003eVielleicht haben sie dort nie begonnen.\u003c/p\u003e\n", "summary": "\nDie unterschätzte Architektur moderner Anwendungen Moderne Anwendungen beginnen nicht mehr im Rechenzentrum.\nEs gibt eine merkwürdige Eigenschaft moderner Software.\nJe leistungsfähiger unsere Plattformen geworden sind, desto einfacher scheint ihre Architektur auf den ersten Blick geworden zu sein.\nHeute sprechen wir über Kubernetes , GitOps, Infrastructure as Code oder Continuous Deployment, als wären sie selbstverständliche Bestandteile jeder Anwendung. Innerhalb weniger Minuten entstehen Cluster, Container werden automatisch skaliert und neue Versionen erreichen den Produktivbetrieb, ohne dass ein Benutzer davon überhaupt Notiz nimmt. Verglichen mit der Infrastruktur vergangener Jahrzehnte wirkt moderne Software beinahe elegant.\n", "image": "https://ayedo.de/building-the-edge-part-1.png", "date_published": "2026-09-09T07:38:27Z", "date_modified": "2026-09-09T07:38:27Z", "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}], "tags": ["kubernetes","operations","software-delivery","cloud-native","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/tls-zertifikate-fur-offentliche-kubernetes-endpunkte/", "url": "https://ayedo.de/posts/tls-zertifikate-fur-offentliche-kubernetes-endpunkte/", "title": "TLS-Zertifikate für öffentliche Kubernetes-Endpunkte", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-zertifikate-fur-offentliche-kubernetes-endpunkte/tls-zertifikate-fur-offentliche-kubernetes-endpunkte.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eTLS für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n endet nicht zwingend am Ingress. Eine zentrale TLS-Termination an der ayedo Edge Cloud vereinfacht Zertifikatsverwaltung, WAF-Integration und Traffic-Steuerung. Zusätzliche Verschlüsselung bis zum Cluster schützt jedoch weitere Netzwerkabschnitte. Die richtige Entscheidung hängt von Trust Boundaries, Betriebsmodell, \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n und gewünschter Fehlerisolierung ab.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin öffentlich erreichbarer \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Endpunkt benötigt mehr als ein Zertifikat am Ingress. Entscheidend ist, an welcher Stelle die TLS-Verbindung endet und welche Strecke anschließend noch geschützt werden muss. Wird TLS ausschließlich an der Edge terminiert, erhält das Backend typischerweise HTTP oder eine andere unverschlüsselte Weiterleitung innerhalb der Infrastruktur. Das kann betrieblich effizient sein, verschiebt aber die Vertrauensgrenze. Eine zweite TLS-Strecke bis zum \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Service erhöht dagegen Schutz und Komplexität. Für TLS für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist deshalb nicht die Frage „Edge oder Ingress?“ entscheidend, sondern die saubere Zuordnung von Verantwortung, Zertifikatslebenszyklus und Netzwerkvertrauen.\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-an-der-edge-als-zentrale-architektur\"\u003e1. TLS-Termination an der Edge als zentrale Architektur\u003c/h2\u003e\n\u003cp\u003eBei der TLS-Termination an der Edge nimmt die ayedo Edge Cloud die öffentliche HTTPS-Verbindung entgegen. Das Zertifikat für den externen Hostnamen wird dort verwaltet und der verschlüsselte Datenstrom an der Edge entschlüsselt. Anschließend kann die Edge den Traffic anhand von Hostnamen, Pfaden und weiteren Regeln an ein \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Backend weiterleiten.\u003c/p\u003e\n\u003cp\u003eDieser Ansatz zentralisiert eine wesentliche Betriebsaufgabe. Zertifikate müssen nicht in jedem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster, Namespace oder Ingress Controller ausgerollt werden. Rotation, Zuordnung mehrerer Domains und die öffentliche Erreichbarkeit werden an einem vorgelagerten Punkt behandelt. Gleichzeitig kann die Edge Cloud Funktionen wie WAF, DDoS Protection und Lastverteilung auf dem bereits entschlüsselten HTTP-/HTTPS-Traffic anwenden.\u003c/p\u003e\n\u003cp\u003eDie Konsequenz ist eine klare Trust Boundary: Zwischen Edge und Backend muss das Netzwerk als ausreichend vertrauenswürdig betrachtet oder separat abgesichert werden. Besonders bei mehreren Providern, verteilten Clustern oder administrativ getrennten Plattformen sollte diese Annahme dokumentiert und regelmäßig überprüft werden.\u003c/p\u003e\n\u003ch2 id=\"2-verschlüsselung-bis-zum-kubernetes-backend\"\u003e2. Verschlüsselung bis zum Kubernetes-Backend\u003c/h2\u003e\n\u003cp\u003eEine zusätzliche TLS-Verbindung vom Edge-Standort bis zum \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Backend reduziert die unverschlüsselte Vertrauenszone. Der Traffic bleibt auch auf dem Abschnitt zwischen Edge und Cluster verschlüsselt. Das ist relevant, wenn Netzwerkpfade über gemeinsam genutzte Infrastruktur führen, Cluster außerhalb der eigenen Netzdomäne betrieben werden oder interne Sicherheitsvorgaben eine Ende-zu-Ende-Absicherung verlangen.\u003c/p\u003e\n\u003cp\u003eDabei entsteht jedoch eine zweite Zertifikatsverantwortung. Das Backend benötigt ein Zertifikat, dessen Hostname zur Verbindung passt oder dessen Prüfung gezielt konfiguriert wird. Zusätzlich müssen Trust Stores, Zertifikatsrotation und Fehlerdiagnose berücksichtigt werden. Ein öffentliches Zertifikat ist dafür nicht immer erforderlich; für die interne Strecke kann eine eigene vertrauenswürdige Zertifikatskette verwendet werden, sofern alle beteiligten Komponenten sie korrekt validieren.\u003c/p\u003e\n\u003cp\u003eWichtig ist die begriffliche Trennung: TLS-Termination an der Edge bedeutet nicht automatisch, dass die Backend-Strecke unverschlüsselt sein muss. Zwischen Client und Edge sowie zwischen Edge und Backend können zwei getrennte TLS-Sitzungen bestehen. Das ist keine technische Ende-zu-Ende-Verbindung im kryptografischen Sinn, weil die Edge den Traffic terminieren und verarbeiten kann. Es ist aber eine verschlüsselte Verbindung über beide Netzwerkabschnitte.\u003c/p\u003e\n\u003ch2 id=\"3-zertifikatsverwaltung-über-mehrere-endpunkte\"\u003e3. Zertifikatsverwaltung über mehrere Endpunkte\u003c/h2\u003e\n\u003cp\u003e[Kubernetes]-Anwendungen veröffentlichen häufig mehrere Endpunkte: unterschiedliche Domains, APIs, Mandanten oder Umgebungen. Die Zertifikatsverwaltung muss deshalb mit dem Routingmodell übereinstimmen. Ein Zertifikat kann mehrere DNS-Namen über Subject Alternative Names abdecken, getrennte Zertifikate können Verantwortlichkeiten und Rotation dagegen klarer isolieren. Entscheidend sind SNI, Host-Header und die Zuordnung zwischen öffentlichem Namen, Edge-Konfiguration und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Ingress.\u003c/p\u003e\n\u003cp\u003eBei zentraler Termination liegt die Verwaltung der öffentlichen Zertifikate an der Edge. Der Ingress benötigt dann nur die Konfiguration für den internen Weiterleitungsweg. Werden Zertifikate zusätzlich im Cluster eingesetzt, müssen deren Gültigkeit und Rotation unabhängig davon funktionieren. Ein Fehler in einer internen Zertifikatskette darf nicht erst beim Ablauf des öffentlichen Zertifikats sichtbar werden.\u003c/p\u003e\n\u003cp\u003eFür Plattformteams bedeutet das: Zertifikatsverwaltung ist kein isolierter \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Task. DNS, Edge-Routing, Ingress-Regeln, Secret-Verteilung und Monitoring bilden eine gemeinsame Betriebskette. Die ayedo Edge Cloud kann dabei als providerunabhängiger öffentlicher Eingang vor eigenen oder bei anderen Providern betriebenen [Kubernetes]-Clustern dienen. Das verhindert, dass jedes Cluster seine öffentliche TLS- und Traffic-Architektur vollständig separat abbilden muss.\u003c/p\u003e\n\u003ch2 id=\"4-verantwortungsgrenzen-und-betriebliche-auswirkungen\"\u003e4. Verantwortungsgrenzen und betriebliche Auswirkungen\u003c/h2\u003e\n\u003cp\u003eDie wichtigste Architekturentscheidung ist die Aufteilung der Zuständigkeiten. Die Edge Cloud übernimmt den öffentlichen Eingang, TLS-Termination, Schutz und Weiterleitung. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n verantwortet dagegen typischerweise Service Discovery, Ingress-Regeln innerhalb des Clusters und die Anwendung selbst. Diese Trennung reduziert Kopplung, ersetzt aber keine klare Dokumentation der Datenflüsse.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb müssen mindestens vier Fehlerbilder unterscheidbar sein: ein abgelaufenes Edge-Zertifikat, ein nicht erreichbares Backend, ein Fehler bei der internen TLS-Prüfung und ein falsches Routing für Hostname oder SNI. Traffic- und Usage-Statistiken an der Edge können die Analyse des öffentlichen Datenstroms unterstützen. Health Checks und Failover sind relevant, wenn mehrere Backends oder Cluster als Ziel dienen.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking ergänzt dieses Modell: Öffentliche Clients müssen die tatsächlichen [Kubernetes]-Endpunkte nicht kennen. Dadurch bleiben Cluster-Adressen und interne Topologie aus dem öffentlichen DNS- und Routing-Modell heraus. Die Edge Cloud übernimmt damit nicht nur eine Zertifikatsfunktion, sondern bildet eine kontrollierte Grenze zwischen Internet und Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-api-mit-getrennten-trust-boundaries\"\u003ePraxisszenario: API mit getrennten Trust Boundaries\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster und veröffentlicht sie unter \u003ccode\u003eapi.example.org\u003c/code\u003e. Die TLS-Verbindung vom Client endet an der ayedo Edge Cloud. Dort werden WAF-Regeln, DDoS-Schutz und Routing angewendet. Für einen geschützten internen Netzwerkpfad wird anschließend eine zweite TLS-Verbindung zum Ingress aufgebaut.\u003c/p\u003e\n\u003cp\u003eDie öffentliche Zertifikatsrotation bleibt bei der Edge. Das Cluster verwaltet nur das Zertifikat für die interne Verbindung und dessen Trust Chain. In einer weniger abgeschotteten Umgebung könnte die Weiterleitung unverschlüsselt erfolgen, wenn der Netzwerkpfad kontrolliert ist. Die Entscheidung sollte jedoch bewusst anhand von Datenklassifizierung, Providergrenzen und Betriebsaufwand getroffen werden – nicht aus Gewohnheit.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-das-kubernetes-ingress-immer-ein-eigenes-öffentliches-zertifikat-besitzen\"\u003eMuss das \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Ingress immer ein eigenes öffentliches Zertifikat besitzen?\u003c/h3\u003e\n\u003cp\u003eNein. Bei TLS-Termination an der Edge benötigt das Ingress kein öffentliches Zertifikat. Für eine zusätzliche verschlüsselte Backend-Strecke braucht es jedoch eine passende interne Zertifikats- und Vertrauenskonfiguration.\u003c/p\u003e\n\u003ch3 id=\"ist-tls-passthrough-gleichbedeutend-mit-tls-termination\"\u003eIst TLS-Passthrough gleichbedeutend mit TLS-Termination?\u003c/h3\u003e\n\u003cp\u003eNein. Beim Passthrough bleibt die TLS-Verbindung bis zum Backend bestehen. Bei der Termination entschlüsselt die Edge den Traffic und kann ihn prüfen, routen und absichern.\u003c/p\u003e\n\u003ch3 id=\"wie-viele-zertifikate-sind-für-mehrere-kubernetes-cluster-nötig\"\u003eWie viele Zertifikate sind für mehrere \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster nötig?\u003c/h3\u003e\n\u003cp\u003eDas hängt von Domains, Trust Boundaries und der gewählten Terminierung ab. Ein öffentliches Zertifikat an der Edge kann mehrere Backends bedienen; interne TLS-Strecken können jeweils eigene Zertifikate erfordern.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eTLS für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist eine Architekturfrage, keine reine Ingress-Konfiguration. Zentrale TLS-Termination an der Edge reduziert Zertifikats- und Betriebsaufwand und schafft einen einheitlichen öffentlichen Eingang. Zusätzliche Verschlüsselung bis zum Backend schützt weitere Netzwerkabschnitte, verlangt aber mehr Zertifikats- und Trust-Management. Die ayedo Edge Cloud ordnet diese Aufgaben vor der Compute-Infrastruktur ein und ermöglicht damit eine bewusste Trennung von öffentlichem Traffic, Edge-Verantwortung und [Kubernetes]-Betrieb.\u003c/p\u003e\n", "summary": "\nTL;DR TLS für Kubernetes endet nicht zwingend am Ingress. Eine zentrale TLS-Termination an der ayedo Edge Cloud vereinfacht Zertifikatsverwaltung, WAF-Integration und Traffic-Steuerung. Zusätzliche Verschlüsselung bis zum Cluster schützt jedoch weitere Netzwerkabschnitte. Die richtige Entscheidung hängt von Trust Boundaries, Betriebsmodell, Compliance und gewünschter Fehlerisolierung ab.\nEinleitung Ein öffentlich erreichbarer Kubernetes -Endpunkt benötigt mehr als ein Zertifikat am Ingress. Entscheidend ist, an welcher Stelle die TLS-Verbindung endet und welche Strecke anschließend noch geschützt werden muss. Wird TLS ausschließlich an der Edge terminiert, erhält das Backend typischerweise HTTP oder eine andere unverschlüsselte Weiterleitung innerhalb der Infrastruktur. Das kann betrieblich effizient sein, verschiebt aber die Vertrauensgrenze. Eine zweite TLS-Strecke bis zum Kubernetes -Service erhöht dagegen Schutz und Komplexität. Für TLS für Kubernetes ist deshalb nicht die Frage „Edge oder Ingress?“ entscheidend, sondern die saubere Zuordnung von Verantwortung, Zertifikatslebenszyklus und Netzwerkvertrauen.\n", "image": "https://ayedo.de/tls-zertifikate-fur-offentliche-kubernetes-endpunkte.png", "date_published": "2026-09-08T17:15:05Z", "date_modified": "2026-09-08T17:15:05Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","compliance","security","operations","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud/", "url": "https://ayedo.de/posts/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud/", "title": "DNS-Automatisierung für Kubernetes hinter der Edge Cloud", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-DNS und öffentliche Namensauflösung lösen unterschiedliche Probleme. Cluster-Ressourcen kennen Services, Ingresses und Workloads; die Edge Cloud verwaltet öffentliche Endpunkte, DNS-Zonen und die Weiterleitung zum Backend. Ein belastbares Betriebsmodell trennt diese Zuständigkeiten, automatisiert aber ihre Übergaben über klar definierte Schnittstellen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n -Umgebungen behandeln DNS-Automatisierung zunächst als Aufgabe des Clusters. Das funktioniert für interne Service-Namen, greift bei öffentlichen Endpunkten jedoch zu kurz. Sobald Anwendungen über eine vorgeschaltete Edge Cloud erreichbar sind, entstehen mindestens zwei getrennte Zustände: Kubernetes kennt die gewünschte Anwendung und ihren Service, während DNS die öffentliche Erreichbarkeit und die Edge den tatsächlichen Traffic-Pfad abbildet. Werden beide Ebenen direkt miteinander vermischt, entstehen unklare Verantwortlichkeiten, versehentlich veröffentlichte Endpunkte und schwer nachvollziehbare Betriebsprozesse. Kubernetes DNS-Automatisierung sollte deshalb nicht bedeuten, dass jede Cluster-Ressource unmittelbar in einer öffentlichen Zone landet.\u003c/p\u003e\n\u003ch2 id=\"1-interne-namensauflösung-und-öffentliche-endpunkte-trennen\"\u003e1. Interne Namensauflösung und öffentliche Endpunkte trennen\u003c/h2\u003e\n\u003cp\u003eKubernetes verwendet DNS primär für die Kommunikation innerhalb des Clusters. Services erhalten stabile Namen, über die Pods Anwendungen erreichen, obwohl sich deren IP-Adressen ändern können. Diese Namen gehören zum internen Cluster-Modell und müssen nicht öffentlich auflösbar sein.\u003c/p\u003e\n\u003cp\u003eEin öffentlicher Endpunkt erfüllt dagegen eine andere Funktion. Er beschreibt einen fachlich oder technisch stabilen Namen wie \u003ccode\u003eapi.example.com\u003c/code\u003e, der über die Edge Cloud erreichbar ist. Die öffentliche DNS-Zone verweist dabei nicht direkt auf Pod- oder Node-Adressen. Sie zeigt auf einen Edge-Service, der Traffic annimmt, schützt, terminiert, verteilt und anschließend an ein geeignetes Backend weiterleitet.\u003c/p\u003e\n\u003cp\u003eDiese Trennung reduziert das Risiko, interne Topologie nach außen offenzulegen. Sie ermöglicht außerdem, Workloads im Cluster zu verschieben, ohne öffentliche DNS-Einträge oder Client-Konfigurationen zu ändern. Backend Cloaking ist dabei ein wichtiges Architekturprinzip: Für externe Nutzer bleibt der öffentliche Edge-Endpunkt konstant, während sich die dahinterliegende Infrastruktur verändern kann.\u003c/p\u003e\n\u003ch2 id=\"2-zuständigkeiten-über-zonen-und-namensräume-organisieren\"\u003e2. Zuständigkeiten über Zonen und Namensräume organisieren\u003c/h2\u003e\n\u003cp\u003eEin praktikables Betriebsmodell beginnt mit einer klaren Aufteilung der DNS-Zonen. Die zentrale Unternehmens- oder Domainverwaltung bleibt für die übergeordnete Zone zuständig. Teams oder Plattformen können darunter delegierte Bereiche erhalten, etwa \u003ccode\u003eapps.example.com\u003c/code\u003e oder \u003ccode\u003ecluster-a.example.com\u003c/code\u003e. Entscheidend ist nicht die konkrete Benennung, sondern die nachvollziehbare Ownership.\u003c/p\u003e\n\u003cp\u003eKubernetes-Ressourcen sollten dabei nicht automatisch Schreibrechte auf die gesamte öffentliche Zone erhalten. Eine Automatisierung kann aus Ingress- oder Gateway-Definitionen einen gewünschten öffentlichen Endpunkt ableiten. Die Veröffentlichung erfolgt anschließend kontrolliert in einem dafür vorgesehenen Namensraum und wird einem Edge-Service zugeordnet. Dazu gehören beispielsweise Hostname, Protokoll, TLS-Konfiguration und Backend-Referenz.\u003c/p\u003e\n\u003cp\u003eSo bleiben fachliche DNS-Entscheidungen und technische Clusterzustände unterscheidbar. Ein gelöschter Ingress muss nicht zwangsläufig sofort einen produktiven DNS-Eintrag entfernen; abhängig vom Betriebsmodell können Schutzfristen, Freigaben oder Prüfungen erforderlich sein. Diese Regeln sind keine unnötige Bürokratie, sondern verhindern, dass kurzlebige Testressourcen öffentliche Namen oder produktive Endpunkte unbeabsichtigt beeinflussen.\u003c/p\u003e\n\u003ch2 id=\"3-anycast-dns-und-multi-provider-dns-richtig-einordnen\"\u003e3. Anycast DNS und Multi-Provider-DNS richtig einordnen\u003c/h2\u003e\n\u003cp\u003eAnycast DNS verteilt DNS-Anfragen über eine verteilte Infrastruktur und kann dadurch die Abhängigkeit von einem einzelnen erreichbaren Standort reduzieren. Für öffentliche Kubernetes-Anwendungen ist das relevant, weil DNS der erste Schritt des Verbindungsaufbaus ist. Eine robuste Auflösung nützt jedoch wenig, wenn der danach verwendete Endpunkt nicht erreichbar ist. DNS-Verfügbarkeit und Traffic-Verfügbarkeit müssen deshalb gemeinsam betrachtet werden.\u003c/p\u003e\n\u003cp\u003eMulti-Provider-DNS ergänzt dieses Modell um eine zusätzliche organisatorische und technische Entkopplung. Autoritative DNS-Dienste können über mehrere Provider betrieben werden, sodass Konfiguration, Ausfallverhalten und Änderungsprozesse nicht ausschließlich an einer Plattform hängen. Das erhöht allerdings die Anforderungen an Konsistenz, Monitoring und Änderungsmanagement. Unterschiedliche TTLs, verzögerte Synchronisation oder abweichende Zonenkonfigurationen können sonst zu schwer erklärbaren Effekten führen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt Anycast DNS und Multi-Provider-DNS als Bestandteile ihrer Edge-Plattform bereit. Im Kontext von \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n bedeutet das: Der öffentliche Name kann unabhängig vom Cluster modelliert werden, während seine Zuordnung auf einen Edge-Service zentral verwaltet wird. Die Anwendung bleibt damit providerunabhängig betreibbar, ohne dass öffentliche DNS-Einträge auf Cluster-IP-Adressen zeigen müssen.\u003c/p\u003e\n\u003ch2 id=\"4-automatisierung-braucht-eine-kontrollierte-übergabe\"\u003e4. Automatisierung braucht eine kontrollierte Übergabe\u003c/h2\u003e\n\u003cp\u003eKubernetes DNS-Automatisierung sollte als Übergabeprozess zwischen zwei Steuerungsebenen entworfen werden. Die Cluster-Seite beschreibt, welcher öffentliche Endpunkt für eine Anwendung benötigt wird. Die Edge-Seite entscheidet, wie dieser Endpunkt veröffentlicht, geschützt und an ein Backend angebunden wird. Zwischen beiden Ebenen muss eine eindeutig definierte Zustands- und Berechtigungsgrenze liegen.\u003c/p\u003e\n\u003cp\u003eTechnisch kann die Automatisierung beispielsweise Änderungen an Ingress- oder Gateway-Ressourcen beobachten, daraus einen gewünschten Hostnamen ableiten und die benötigte Zuordnung an die Edge-Plattform übergeben. Dabei sollten Validierungen prüfen, ob die Zone freigegeben ist, der Name dem vorgesehenen Namensschema entspricht und das Ziel-Backend zulässig ist. Ebenso wichtig sind Statusmeldungen: Ein Kubernetes-Objekt sollte unterscheiden können, ob DNS veröffentlicht, der Edge-Service aktiv oder das Backend gesund ist.\u003c/p\u003e\n\u003cp\u003eBetrieblich entstehen dadurch klare Verantwortlichkeiten. Das Plattformteam verwaltet Cluster-Integration und Ressourcenmodelle; Netzwerk- oder Edge-Verantwortliche kontrollieren Zonen, öffentliche Endpunkte und Sicherheitsrichtlinien. Mit ayedo Managed Kubernetes oder eigenen Kubernetes-Clustern bei anderen Providern kann dieses Muster unabhängig vom Compute-Standort genutzt werden. Die Edge Cloud bleibt dabei die zentrale Eintrittsschicht, nicht das interne DNS des Clusters.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-drei-ebenen-ein-öffentlicher-name\"\u003ePraxisszenario: Drei Ebenen, ein öffentlicher Name\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem eigenen \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n -Cluster und veröffentlicht sie unter \u003ccode\u003eapi.example.com\u003c/code\u003e. Im Cluster existiert ein Ingress mit diesem Hostnamen. Die Automatisierung prüft die delegierte Zone und erzeugt keinen direkten DNS-Eintrag auf einen Node, sondern ordnet den Hostnamen einem Edge-Service zu.\u003c/p\u003e\n\u003cp\u003eDie öffentliche DNS-Auflösung verweist auf die Anycast-fähige Edge-Infrastruktur. Dort wird TLS terminiert, der Traffic anhand des Hostnamens verarbeitet und über einen geschützten Backend-Pfad an den Cluster weitergeleitet. Fällt ein Backend aus, greifen die konfigurierten Health Checks und Failover-Mechanismen der Edge-Schicht. Wird die API später in einen Cluster bei einem anderen Provider verschoben, bleiben DNS-Name und Edge-Service bestehen; angepasst wird nur die Backend-Zuordnung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-jede-kubernetes-service-ressource-öffentliches-dns-erhalten\"\u003eMuss jede Kubernetes-Service-Ressource öffentliches DNS erhalten?\u003c/h3\u003e\n\u003cp\u003eNein. Nur explizit veröffentlichte Anwendungen benötigen öffentliche Endpunkte. Interne Services bleiben über \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes-DNS\u003c/a\u003e\n erreichbar und werden nicht in öffentliche Zonen übernommen.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-anycast-dns-die-traffic-verteilung-der-edge\"\u003eErsetzt Anycast DNS die Traffic-Verteilung der Edge?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast DNS verteilt DNS-Anfragen. Die anschließende Verarbeitung, TLS-Terminierung, WAF, Lastverteilung und Backend-Anbindung sind Aufgaben der Edge-Service-Schicht.\u003c/p\u003e\n\u003ch3 id=\"kann-das-modell-mit-einem-cluster-außerhalb-von-ayedo-funktionieren\"\u003eKann das Modell mit einem Cluster außerhalb von ayedo funktionieren?\u003c/h3\u003e\n\u003cp\u003eJa. Die Edge Cloud kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS-Automatisierung für \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n ist belastbar, wenn interne Cluster-Namen und öffentliche Endpunkte nicht als derselbe Zuständigkeitsbereich behandelt werden. Kubernetes beschreibt den gewünschten Anwendungszustand; DNS und Edge Cloud stellen die öffentliche Erreichbarkeit her. Anycast DNS und Multi-Provider-DNS ergänzen dieses Modell, ersetzen aber keine klare Ownership. Die ayedo Edge Cloud ist dafür als providerunabhängige öffentliche Eintrittsschicht relevant: Sie verbindet Namensauflösung, Edge-Service und Backend-Anbindung, ohne die DNS-Verantwortung mit dem Cluster zu vermischen.\u003c/p\u003e\n", "summary": "\nTL;DR Kubernetes-DNS und öffentliche Namensauflösung lösen unterschiedliche Probleme. Cluster-Ressourcen kennen Services, Ingresses und Workloads; die Edge Cloud verwaltet öffentliche Endpunkte, DNS-Zonen und die Weiterleitung zum Backend. Ein belastbares Betriebsmodell trennt diese Zuständigkeiten, automatisiert aber ihre Übergaben über klar definierte Schnittstellen.\nEinleitung Viele Kubernetes -Umgebungen behandeln DNS-Automatisierung zunächst als Aufgabe des Clusters. Das funktioniert für interne Service-Namen, greift bei öffentlichen Endpunkten jedoch zu kurz. Sobald Anwendungen über eine vorgeschaltete Edge Cloud erreichbar sind, entstehen mindestens zwei getrennte Zustände: Kubernetes kennt die gewünschte Anwendung und ihren Service, während DNS die öffentliche Erreichbarkeit und die Edge den tatsächlichen Traffic-Pfad abbildet. Werden beide Ebenen direkt miteinander vermischt, entstehen unklare Verantwortlichkeiten, versehentlich veröffentlichte Endpunkte und schwer nachvollziehbare Betriebsprozesse. Kubernetes DNS-Automatisierung sollte deshalb nicht bedeuten, dass jede Cluster-Ressource unmittelbar in einer öffentlichen Zone landet.\n", "image": "https://ayedo.de/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud.png", "date_published": "2026-09-08T17:15:04Z", "date_modified": "2026-09-08T17:15:04Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","automation","cloud-native","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen/", "url": "https://ayedo.de/posts/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen/", "title": "Ingress und Edge Cloud: Zuständigkeiten sauber trennen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress und Edge Cloud lösen unterschiedliche Aufgaben. Die Edge Cloud kontrolliert den öffentlichen Eingang, schützt Anwendungen und terminiert TLS. Kubernetes Ingress beschreibt dagegen die Weiterleitung innerhalb des Clusters. Eine klare Trennung verhindert doppelte Regeln, widersprüchliche Sicherheitskonfigurationen und schwer nachvollziehbare Betriebszustände.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Kubernetes-Architekturen behandeln Ingress als vollständige Eintrittsschicht für Anwendungen. Das funktioniert technisch, vermischt aber zwei Verantwortungsbereiche: den öffentlichen Netzwerkzugang und das Routing innerhalb des Clusters. Sobald TLS, WAF, DDoS-Schutz und Backend-Erreichbarkeit zusätzlich an einer externen Edge-Plattform geregelt werden, entstehen schnell doppelte oder widersprüchliche Konfigurationen. Ein Hostname kann dann an mehreren Stellen terminiert, geprüft und weitergeleitet werden. Die entscheidende Architekturfrage lautet deshalb nicht, ob Kubernetes Ingress oder eine Edge Cloud verwendet wird. Entscheidend ist, welche Ebene welche Verantwortung übernimmt und wo die jeweilige Konfiguration verbindlich ist.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-ingress-beschreibt-den-zugang-zu-cluster-services\"\u003e1. Kubernetes Ingress beschreibt den Zugang zu Cluster-Services\u003c/h2\u003e\n\u003cp\u003eEine Kubernetes-Ingress-Ressource ist zunächst eine deklarative Beschreibung für HTTP- und HTTPS-Routing. Sie ordnet beispielsweise Hostnamen und Pfade bestimmten Services im Cluster zu. Die Ressource selbst verarbeitet keinen Traffic. Diese Aufgabe übernimmt ein Ingress Controller, der die Konfiguration in eine konkrete Proxy- oder Loadbalancer-Konfiguration übersetzt.\u003c/p\u003e\n\u003cp\u003eDamit liegt die Kernverantwortung des Ingress im Cluster: Ein eingehender Request wird nach der Übergabe an den Kubernetes-Service weitergeleitet. Dazu gehören etwa Regeln wie \u003ccode\u003eapi.example.de\u003c/code\u003e zu einem API-Service oder \u003ccode\u003e/checkout\u003c/code\u003e zu einem bestimmten Backend. Auch die Aufteilung zwischen Services, Namespaces oder Versionen kann dort modelliert werden.\u003c/p\u003e\n\u003cp\u003eDiese Ebene ist eng mit dem Deployment-Modell verbunden. Änderungen an Services, Pods und Ingress-Ressourcen lassen sich gemeinsam über Kubernetes-Workflows verwalten. Das ist sinnvoll, solange die Aufgabe auf die interne Erreichbarkeit und das Routing zu Workloads begrenzt bleibt. Der Ingress sollte jedoch nicht automatisch als vollständige Sicherheits- und Internetzugangsschicht verstanden werden.\u003c/p\u003e\n\u003ch2 id=\"2-die-edge-cloud-übernimmt-den-öffentlichen-eingang\"\u003e2. Die Edge Cloud übernimmt den öffentlichen Eingang\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud liegt architektonisch vor dem Cluster. Sie nimmt öffentlichen Traffic an, verteilt ihn über eine verteilte Multi-PoP-Infrastruktur und leitet zulässige Verbindungen an definierte Backends weiter. Bei ayedo geschieht dies über Anycast-basiertes Layer-4- und Layer-7-Loadbalancing. Die Edge Cloud ist damit nicht lediglich ein vorgeschalteter Loadbalancer für ayedo Managed Kubernetes, sondern kann auch vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden.\u003c/p\u003e\n\u003cp\u003eAuf dieser Ebene liegen Aufgaben, die unabhängig von einzelnen Kubernetes-Services gelten. Dazu gehören TLS-Termination, WAF-Regeln, DDoS Protection und Scrubbing an der Edge sowie Backend-Cloaking. Beim Backend-Cloaking bleiben interne Zieladressen gegenüber dem öffentlichen Client verborgen. Backend Health Checks und Failover entscheiden zusätzlich, ob ein Ziel erreichbar ist und wohin Traffic bei Störungen weitergeleitet wird.\u003c/p\u003e\n\u003cp\u003eDiese Zentralisierung reduziert den Druck, sicherheitsrelevante Regeln in jedem Cluster separat abzubilden. Gleichzeitig bleibt das Cluster für die eigentliche Anwendungs- und Servicekonfiguration verantwortlich.\u003c/p\u003e\n\u003ch2 id=\"3-routing-und-tls-brauchen-eine-eindeutige-besitzerschaft\"\u003e3. Routing und TLS brauchen eine eindeutige Besitzerschaft\u003c/h2\u003e\n\u003cp\u003eRouting wird problematisch, wenn dieselbe Entscheidung an mehreren Stellen getroffen wird. Ein Beispiel: Die Edge Cloud leitet \u003ccode\u003e/api\u003c/code\u003e an einen Cluster-Endpunkt weiter, während der Ingress denselben Pfad nochmals aufteilt. Das ist nicht grundsätzlich falsch, erhöht aber die Zahl der Regeln, die bei Änderungen synchron bleiben müssen. Unterschiedliche Prioritäten, Rewrite-Regeln oder Statuscodes erschweren die Fehlersuche.\u003c/p\u003e\n\u003cp\u003eEine belastbare Struktur trennt deshalb grob zwischen äußerem und innerem Routing. Die Edge Cloud entscheidet, welcher öffentliche Hostname oder Service welchen geschützten Backend-Endpunkt erreicht. Der Kubernetes Ingress entscheidet anschließend, welcher Service innerhalb des Clusters den Request verarbeitet. Diese Aufteilung sollte dokumentiert und anhand von Request-Fluss, Zuständigkeit und Änderungsprozess überprüfbar sein.\u003c/p\u003e\n\u003cp\u003eDasselbe gilt für TLS-Termination. Wird TLS an der Edge beendet, erhält der Ingress typischerweise bereits eine weitergeleitete Verbindung. Dann müssen Protokoll, ursprüngliches Schema und gegebenenfalls Client-Informationen konsistent übertragen werden. Wird TLS zusätzlich im Cluster terminiert, handelt es sich um eine bewusste Ende-zu-Ende-Entscheidung mit eigenem Zertifikats- und Betriebsaufwand, nicht um eine zufällige Doppelkonfiguration.\u003c/p\u003e\n\u003ch2 id=\"4-sicherheitslogik-gehört-an-die-passende-grenze\"\u003e4. Sicherheitslogik gehört an die passende Grenze\u003c/h2\u003e\n\u003cp\u003eWAF und DDoS-Schutz wirken am sinnvollsten, bevor schädlicher oder übermäßiger Traffic das Cluster erreicht. Eine Edge-Plattform kann diese Prüfungen am öffentlichen Eingang durchführen und nur den zugelassenen Traffic an die Kubernetes-Umgebung weitergeben. Das schützt nicht nur einzelne Ingress-Regeln, sondern die Erreichbarkeit der vorgelagerten Anwendungsschicht insgesamt.\u003c/p\u003e\n\u003cp\u003eDer Ingress bleibt trotzdem sicherheitsrelevant. Er begrenzt, welche Services intern über HTTP erreichbar sind, und kann Routing- oder Authentifizierungsanforderungen der Anwendung unterstützen. Er ersetzt aber keine Edge-Schutzfunktionen, wenn Angriffe oder große Traffic-Spitzen bereits Netzwerk- und Clusterressourcen beanspruchen.\u003c/p\u003e\n\u003cp\u003eOrganisatorisch ist entscheidend, wer Regeln ändern darf und wie Änderungen getestet werden. Edge-Regeln sollten nicht unkontrolliert aus einzelnen Deployment-Repositories entstehen, während Ingress-Konfigurationen gleichzeitig globale öffentliche Erreichbarkeit verändern. Ein gemeinsames Modell aus Verantwortlichkeiten, Versionsverwaltung und Beobachtung der Traffic- und Usage-Statistiken verhindert, dass Sicherheits- und Routinglogik zwischen Plattform- und Anwendungsteams auseinanderläuft.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt ein Kubernetes-Cluster bei einem externen Provider. Die öffentliche API soll unter \u003ccode\u003eapi.example.de\u003c/code\u003e erreichbar sein. Die ayedo Edge Cloud übernimmt Anycast-DNS, TLS-Termination, WAF, DDoS-Schutz und das Backend-Cloaking. Als Backend ist ein öffentlich erreichbarer Cluster-Endpunkt hinterlegt; Health Checks erkennen, ob dieser verfügbar ist.\u003c/p\u003e\n\u003cp\u003eIm Cluster beschreibt eine Kubernetes-Ingress-Ressource nur noch die Weiterleitung von \u003ccode\u003eapi.example.de\u003c/code\u003e zu den Services \u003ccode\u003eapi-v1\u003c/code\u003e und \u003ccode\u003eapi-v2\u003c/code\u003e. Die Edge Cloud entscheidet nicht über interne Pod- oder Service-Namen, der Ingress kennt keine globalen DDoS- oder WAF-Regeln. Fällt der Cluster-Endpunkt aus, greift das Edge-seitige Failover. Ändert das Team die Versionierung der API, bleibt die Änderung auf die Cluster-Konfiguration begrenzt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-die-ayedo-edge-cloud-den-kubernetes-ingress\"\u003eErsetzt die ayedo Edge Cloud den Kubernetes Ingress?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud übernimmt den öffentlichen Eingang und Schutzfunktionen. Kubernetes Ingress routet innerhalb des Clusters zu Services und bleibt Teil der anwendungsnahen Konfiguration.\u003c/p\u003e\n\u003ch3 id=\"muss-tls-immer-an-der-edge-terminiert-werden\"\u003eMuss TLS immer an der Edge terminiert werden?\u003c/h3\u003e\n\u003cp\u003eNein. TLS-Termination an der Edge ist eine Architekturentscheidung. Eine zusätzliche Verschlüsselung bis zum Backend kann erforderlich sein, muss aber hinsichtlich Zertifikaten und Betriebsaufwand bewusst geplant werden.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-cloud-vor-jedem-kubernetes-cluster-eingesetzt-werden\"\u003eKann die Edge Cloud vor jedem Kubernetes-Cluster eingesetzt werden?\u003c/h3\u003e\n\u003cp\u003eSie kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden. Maßgeblich sind definierte, erreichbare Backends und ein konsistenter Request-Fluss.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress und Edge Cloud sind keine konkurrierenden Implementierungen derselben Schicht. Der Ingress organisiert die Weiterleitung zu Services im Cluster; die Edge Cloud kontrolliert den öffentlichen Zugang, Schutz, TLS-Termination und die Erreichbarkeit der Backends. Diese Trennung reduziert Konfigurationskonflikte und macht Verantwortlichkeiten prüfbar. Für Unternehmen mit mehreren Clustern oder Providern schafft eine providerunabhängige Edge-Plattform zudem eine konsistente äußere Architektur, während Teams ihre interne \u003ca href=\"/kubernetes/\"\u003eKubernetes-Konfiguration\u003c/a\u003e\n eigenständig weiterentwickeln können.\u003c/p\u003e\n", "summary": "\nTL;DR Kubernetes Ingress und Edge Cloud lösen unterschiedliche Aufgaben. Die Edge Cloud kontrolliert den öffentlichen Eingang, schützt Anwendungen und terminiert TLS. Kubernetes Ingress beschreibt dagegen die Weiterleitung innerhalb des Clusters. Eine klare Trennung verhindert doppelte Regeln, widersprüchliche Sicherheitskonfigurationen und schwer nachvollziehbare Betriebszustände.\nEinleitung Viele Kubernetes-Architekturen behandeln Ingress als vollständige Eintrittsschicht für Anwendungen. Das funktioniert technisch, vermischt aber zwei Verantwortungsbereiche: den öffentlichen Netzwerkzugang und das Routing innerhalb des Clusters. Sobald TLS, WAF, DDoS-Schutz und Backend-Erreichbarkeit zusätzlich an einer externen Edge-Plattform geregelt werden, entstehen schnell doppelte oder widersprüchliche Konfigurationen. Ein Hostname kann dann an mehreren Stellen terminiert, geprüft und weitergeleitet werden. Die entscheidende Architekturfrage lautet deshalb nicht, ob Kubernetes Ingress oder eine Edge Cloud verwendet wird. Entscheidend ist, welche Ebene welche Verantwortung übernimmt und wo die jeweilige Konfiguration verbindlich ist.\n", "image": "https://ayedo.de/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen.png", "date_published": "2026-09-08T17:15:04Z", "date_modified": "2026-09-08T17:15:04Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","cloud-native","development","cloud"], "language": "de" },{ "id": "https://ayedo.de/posts/kubernetes-api-server-sicher-uber-die-edge-erreichbar/", "url": "https://ayedo.de/posts/kubernetes-api-server-sicher-uber-die-edge-erreichbar/", "title": "Kubernetes-API-Server sicher über die Edge erreichbar", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-api-server-sicher-uber-die-edge-erreichbar/kubernetes-api-server-sicher-uber-die-edge-erreichbar.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin öffentlich erreichbarer \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Server\u003c/a\u003e\n muss nicht direkt aus dem Internet auf seine Backend-Adresse zugreifen lassen. Eine vorgeschaltete Edge-Schicht kann Routing, TLS, DDoS-Schutz und Backend-Cloaking übernehmen. Entscheidend bleibt die Trennung zwischen öffentlicher Erreichbarkeit, kryptografischer Authentisierung und tatsächlicher Berechtigung im Cluster.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, einen öffentlich benötigten \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Server\u003c/a\u003e\n direkt auf einer öffentlichen IP-Adresse des Clusters zu betreiben. Dadurch werden nicht nur Port und Endpoint sichtbar, sondern oft auch Netzwerkpfade und Betriebsstrukturen, die für Angreifer relevant sind. Die Alternative ist kein vollständig abgeschotteter API-Server, sondern ein kontrollierter öffentlicher Eingang: Der Client erreicht einen definierten Endpoint, während das eigentliche Backend verborgen bleibt. Diese Architektur verschiebt jedoch keine Verantwortung automatisch. TLS, \u003ca href=\"/kubernetes/\"\u003eKubernetes-Authentisierung\u003c/a\u003e\n, Autorisierung, Rate Limiting und Netzwerkregeln müssen weiterhin passend zusammenspielen.\u003c/p\u003e\n\u003ch2 id=\"1-öffentliche-erreichbarkeit-ist-nicht-gleich-offene-erreichbarkeit\"\u003e1. Öffentliche Erreichbarkeit ist nicht gleich offene Erreichbarkeit\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Server\u003c/a\u003e\n benötigt öffentliche Erreichbarkeit, wenn externe Administratoren, CI/CD-Systeme, GitOps-Komponenten oder Plattformdienste außerhalb des Clusters auf ihn zugreifen. Daraus folgt aber nicht, dass der API-Server direkt an einer öffentlich gerouteten Backend-Adresse hängen muss.\u003c/p\u003e\n\u003cp\u003eSinnvoller ist ein dedizierter öffentlicher API-Endpunkt, der ausschließlich den vorgesehenen Traffic annimmt und an das API-Server-Backend weiterleitet. Der öffentliche DNS-Name muss dabei nicht auf die Infrastrukturadresse des Clusters zeigen. Eine Edge-Schicht kann die Erreichbarkeit über Anycast und Loadbalancing herstellen, während das Backend selbst nicht öffentlich adressierbar bleibt.\u003c/p\u003e\n\u003cp\u003eFür die Betriebsführung ist diese Trennung relevant: Adressänderungen, Failover und die Ablösung einzelner API-Server müssen nicht zwingend die externe Endpoint-Definition verändern. Gleichzeitig reduziert Backend-Cloaking die Menge an Informationen, die aus dem Internet über die interne Topologie ableitbar ist. Es ersetzt jedoch weder Authentisierung noch Autorisierung.\u003c/p\u003e\n\u003ch2 id=\"2-tls-und-zugriffssteuerung-müssen-getrennt-betrachtet-werden\"\u003e2. TLS und Zugriffssteuerung müssen getrennt betrachtet werden\u003c/h2\u003e\n\u003cp\u003eTLS schützt die Verbindung zwischen Client und öffentlichem Endpoint. Bei einer TLS-Terminierung an der Edge endet die äußere Verbindung dort; die weitere Absicherung bis zum Backend muss als eigene Architekturentscheidung behandelt werden. Je nach Sicherheitsmodell kann die Verbindung zum API-Server erneut verschlüsselt oder in einer anderen geeigneten Form abgesichert werden. Entscheidend ist, dass ein sicherer äußerer TLS-Kanal nicht automatisch die gesamte Strecke schützt.\u003c/p\u003e\n\u003cp\u003eEbenso wichtig ist die Unterscheidung zwischen Transport- und Zugriffsschutz. Ein gültiges Zertifikat bestätigt die Identität eines Endpunkts, erteilt aber keine \u003ca href=\"/kubernetes/\"\u003eKubernetes-Berechtigung\u003c/a\u003e\n. Der API-Server muss Clients weiterhin über seine vorgesehenen Mechanismen authentisieren und die Zugriffe über RBAC und weitere Clusterregeln autorisieren.\u003c/p\u003e\n\u003cp\u003eDie Edge kann den öffentlichen Eingang schützen und unerwünschten Traffic früh verwerfen. Sie sollte aber nicht als Ersatz für \u003ca href=\"/kubernetes/\"\u003eKubernetes-Identitäten\u003c/a\u003e\n, kurzlebige Zugangsdaten oder restriktive Rollen verstanden werden. Gerade bei administrativen Endpunkten ist die Kombination aus Netzwerkbegrenzung und starker Anwendungsauthentisierung erforderlich.\u003c/p\u003e\n\u003ch2 id=\"3-edge-routing-für-den-api-server-ist-kein-anwendungstraffic\"\u003e3. Edge-Routing für den API-Server ist kein Anwendungstraffic\u003c/h2\u003e\n\u003cp\u003eDer \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Server\u003c/a\u003e\n ist kein gewöhnlicher Webservice. Neben HTTPS-Anfragen für Ressourcen verarbeitet er beispielsweise Streaming-Verbindungen, Watch-Aufrufe und Interaktionen, die sich im Betriebsverhalten von normalem Anwendungstraffic unterscheiden. Deshalb müssen Timeout-, Keepalive- und Protokolleinstellungen zum API-Server passen.\u003c/p\u003e\n\u003cp\u003eFür den öffentlichen API-Endpunkt ist Layer-4-Loadbalancing häufig die klarere Grundlage, weil der Edge-Service den Kubernetes-Traffic nicht wie eine klassische Webanwendung interpretieren muss. Layer-7-Funktionen wie eine Web Application Firewall können für HTTP-/HTTPS-Services sinnvoll sein, dürfen aber nicht pauschal auf den API-Server angewendet werden. Eine Regel, die für REST-Anwendungen funktioniert, kann lange Verbindungen oder spezielle API-Requests unerwartet beeinflussen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS-Terminierung, DDoS-Schutz und Health Checks. Für einen \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Server\u003c/a\u003e\n ist daher eine spezifische Routing- und Prüfstrategie erforderlich. Anwendungstraffic und Control-Plane-Traffic sollten getrennte Endpoints und Regeln erhalten.\u003c/p\u003e\n\u003ch2 id=\"4-ddos-schutz-reduziert-betriebsrisiken-ersetzt-aber-keine-isolation\"\u003e4. DDoS-Schutz reduziert Betriebsrisiken, ersetzt aber keine Isolation\u003c/h2\u003e\n\u003cp\u003eEin öffentlicher API-Endpunkt ist unabhängig von seiner eigentlichen Funktion ein erreichbarer Angriffspunkt. Auch wenn \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Authentisierungsfehler korrekt zurückweist, müssen die Anfragen zunächst verarbeitet werden. Große Mengen unerwünschten Traffics können deshalb Netzwerkpfade, Loadbalancer oder API-Server belasten, bevor eine Berechtigungsprüfung greift.\u003c/p\u003e\n\u003cp\u003eDDoS-Schutz und Scrubbing an der Edge verlagern die Abwehr näher an den öffentlichen Eingang. Das ist besonders relevant, wenn der API-Server nicht mit denselben Schutzmechanismen wie ein öffentliches Webfrontend betrieben werden soll. Health Checks und Failover helfen zusätzlich, nur funktionsfähige Backends in die Verteilung einzubeziehen. Sie lösen allerdings keine Fehlkonfigurationen in der Control Plane.\u003c/p\u003e\n\u003cp\u003eFür die Architektur bedeutet das: Der API-Server braucht einen eigenen Sicherheits- und Verfügbarkeitskontext. Backend-Cloaking, dedizierte DNS-Einträge, restriktive Firewall-Regeln und \u003ca href=\"/kubernetes/\"\u003eKubernetes-seitige Autorisierung\u003c/a\u003e\n bilden zusammen eine Kontrollkette. Die Edge Cloud kann diese Kette als öffentlicher Eingang unterstützen – unabhängig davon, ob der Cluster bei ayedo, einem anderen Provider oder in eigener Infrastruktur betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei einem externen Provider. Externe Plattformteams müssen den API-Server erreichen, während die Control Plane nicht mit einer direkt beworbenen Backend-Adresse im Internet stehen soll. Dafür wird ein dedizierter DNS-Name an einen Edge-Endpunkt gebunden. Die Edge übernimmt Anycast-Routing, DDoS-Schutz und die Annahme der TLS-Verbindung. Der eigentliche API-Server bleibt hinter dem Edge-Endpunkt verborgen; Health Checks steuern die Weiterleitung auf verfügbare Backends.\u003c/p\u003e\n\u003cp\u003eDer Vergleich ist eindeutig: Bei direkter Veröffentlichung müssen Backend-Adressen, Schutzmechanismen und Failover am Cluster selbst betrieben werden. Bei vorgeschaltetem Edge-Eingang wird die öffentliche Erreichbarkeit zentralisiert, während Authentisierung und Autorisierung weiterhin im \u003ca href=\"/kubernetes/\"\u003eKubernetes-Kontext\u003c/a\u003e\n bleiben.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-ein-kubernetes-api-server-öffentlich-erreichbar-sein\"\u003eMuss ein \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Server\u003c/a\u003e\n öffentlich erreichbar sein?\u003c/h3\u003e\n\u003cp\u003eNein. Er muss nur für die Systeme erreichbar sein, die ihn benötigen. Das kann über private Netzwerke, VPNs oder einen kontrollierten öffentlichen Endpoint erfolgen.\u003c/p\u003e\n\u003ch3 id=\"ist-backend-cloaking-ein-ersatz-für-rbac\"\u003eIst Backend-Cloaking ein Ersatz für RBAC?\u003c/h3\u003e\n\u003cp\u003eNein. Backend-Cloaking verbirgt die interne Zieladresse. RBAC entscheidet, welche authentisierten Identitäten \u003ca href=\"/kubernetes/\"\u003eKubernetes-Ressourcen\u003c/a\u003e\n lesen oder verändern dürfen.\u003c/p\u003e\n\u003ch3 id=\"sollte-die-waf-jeden-api-server-traffic-prüfen\"\u003eSollte die WAF jeden API-Server-Traffic prüfen?\u003c/h3\u003e\n\u003cp\u003eNicht pauschal. \u003ca href=\"/kubernetes/\"\u003eKubernetes-API-Traffic\u003c/a\u003e\n benötigt passende Protokoll-, Timeout- und Regelkonfigurationen. Für viele Szenarien ist ein gezielt konfiguriertes Layer-4-Routing geeigneter.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n lässt sich öffentlich erreichbar machen, ohne seine Backend-Struktur unnötig offenzulegen. Dafür müssen Edge-Routing, TLS, DDoS-Schutz und Backend-Cloaking sauber von \u003ca href=\"/kubernetes/\"\u003eKubernetes-Authentisierung\u003c/a\u003e\n und Autorisierung getrennt werden. Die ayedo Edge Cloud ist in diesem Modell der kontrollierte öffentliche Eingang – nicht der Ersatz für Cluster-Sicherheitskontrollen. Entscheidend ist die Architekturgrenze zwischen Edge, Control Plane und Anwendungstraffic.\u003c/p\u003e\n", "summary": "\nTL;DR Ein öffentlich erreichbarer Kubernetes-API-Server muss nicht direkt aus dem Internet auf seine Backend-Adresse zugreifen lassen. Eine vorgeschaltete Edge-Schicht kann Routing, TLS, DDoS-Schutz und Backend-Cloaking übernehmen. Entscheidend bleibt die Trennung zwischen öffentlicher Erreichbarkeit, kryptografischer Authentisierung und tatsächlicher Berechtigung im Cluster.\nEinleitung Ein häufiger Architekturfehler besteht darin, einen öffentlich benötigten Kubernetes-API-Server direkt auf einer öffentlichen IP-Adresse des Clusters zu betreiben. Dadurch werden nicht nur Port und Endpoint sichtbar, sondern oft auch Netzwerkpfade und Betriebsstrukturen, die für Angreifer relevant sind. Die Alternative ist kein vollständig abgeschotteter API-Server, sondern ein kontrollierter öffentlicher Eingang: Der Client erreicht einen definierten Endpoint, während das eigentliche Backend verborgen bleibt. Diese Architektur verschiebt jedoch keine Verantwortung automatisch. TLS, Kubernetes-Authentisierung , Autorisierung, Rate Limiting und Netzwerkregeln müssen weiterhin passend zusammenspielen.\n", "image": "https://ayedo.de/kubernetes-api-server-sicher-uber-die-edge-erreichbar.png", "date_published": "2026-09-08T17:15:04Z", "date_modified": "2026-09-08T17:15:04Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","software-delivery","cloud-native","development","operations"], "language": "de" },{ "id": "https://ayedo.de/posts/loadbalancer-fur-kubernetes-providerunabhangig-betreiben/", "url": "https://ayedo.de/posts/loadbalancer-fur-kubernetes-providerunabhangig-betreiben/", "title": "Loadbalancer für Kubernetes providerunabhängig betreiben", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/loadbalancer-fur-kubernetes-providerunabhangig-betreiben/loadbalancer-fur-kubernetes-providerunabhangig-betreiben.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Service vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e bindet den öffentlichen Zugang häufig an den jeweiligen Cloud- oder Infrastrukturprovider. Eine eigenständige Edge-Schicht trennt diese Verantwortung vom Cluster: Routing, Schutz, TLS und Erreichbarkeit werden zentral organisiert, während Kubernetes bei ayedo oder einem anderen Provider betrieben werden kann. Das reduziert Providerabhängigkeiten und vereinfacht Multi-Cloud-Architekturen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Loadbalancer ist nicht nur eine technische Ressource, sondern eine Architekturentscheidung: Wird der öffentliche Zugang zu einem Service vom Compute-Provider kontrolliert oder als eigenständige Netzwerkschicht betrieben? In vielen Clustern erzeugt ein \u003ccode\u003eService\u003c/code\u003e vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e automatisch eine providergebundene Infrastruktur. Das ist für einzelne Umgebungen pragmatisch, erschwert aber Migrationen, Multi-Cloud-Betrieb und eine einheitliche Sicherheitsarchitektur. Wer Kubernetes providerunabhängig betreiben will, muss deshalb die Zuständigkeiten zwischen Cluster und öffentlichem Traffic-Eingang sauber trennen.\u003c/p\u003e\n\u003ch2 id=\"1-providergebundene-loadbalancer-einfach-aber-eng-gekoppelt\"\u003e1. Providergebundene Loadbalancer: einfach, aber eng gekoppelt\u003c/h2\u003e\n\u003cp\u003eDer klassische Ansatz nutzt die Loadbalancer-Integration des jeweiligen Kubernetes- oder Cloud-Providers. Eine Service-Ressource löst die Bereitstellung eines externen Endpunkts aus. Der Provider übernimmt typischerweise Adressierung, Weiterleitung und gegebenenfalls Health Checks. Der operative Vorteil liegt in der kurzen Integrationsstrecke: Cluster, Netzwerk und Loadbalancer stammen aus derselben Plattform.\u003c/p\u003e\n\u003cp\u003eDiese Kopplung hat jedoch Konsequenzen. Öffentliche IP-Adressen, DNS-Anbindungen, Firewall-Regeln und Betriebsprozesse orientieren sich an den Vorgaben eines Providers. Beim Wechsel des Clusters oder beim Aufbau einer zweiten Cloud müssen diese Abhängigkeiten erneut modelliert werden. Auch Sicherheitsfunktionen sind dann häufig über mehrere Provider verteilt. Das erhöht die Zahl unterschiedlicher Konfigurationen und erschwert eine konsistente Auswertung von Traffic und Fehlern.\u003c/p\u003e\n\u003cp\u003eFür eine einzelne, stabile Umgebung kann ein providergebundener \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Loadbalancer sinnvoll sein. Er ist aber kein neutraler Baustein für providerunabhängiges Kubernetes. Die zentrale Frage lautet daher nicht nur, wie ein Service erreichbar wird, sondern wo die Verantwortung für den öffentlichen Eingang dauerhaft liegen soll.\u003c/p\u003e\n\u003ch2 id=\"2-eine-eigenständige-edge-schicht-trennt-zuständigkeiten\"\u003e2. Eine eigenständige Edge-Schicht trennt Zuständigkeiten\u003c/h2\u003e\n\u003cp\u003eBei einer unabhängigen Edge-Architektur endet die Verantwortung des Clusters nicht erst am externen Loadbalancer. Die Edge Cloud übernimmt den öffentlichen Traffic-Eingang und leitet Anfragen kontrolliert an die Backends weiter. Der Cluster bleibt für Workloads, Services und interne Verteilung zuständig; die Edge organisiert Erreichbarkeit, Routing und Schutz vor dem Backend.\u003c/p\u003e\n\u003cp\u003eDiese Trennung verändert die Architekturgrenzen. Ein [Kubernetes]-Cluster kann bei ayedo, in einer Public Cloud oder in einer eigenen Infrastruktur betrieben werden, ohne dass der öffentliche Endpunkt an die Loadbalancer-Implementierung des jeweiligen Compute-Providers gebunden ist. Die Edge kann dabei Layer-4- und Layer-7-Traffic per Anycast verteilen. Backend Cloaking verhindert, dass die eigentlichen Backend-Adressen zum öffentlichen Bestandteil der Architektur werden.\u003c/p\u003e\n\u003cp\u003eMit eigener Netzwerk-Infrastruktur und eigenem Autonomous System bildet ayedo eine eigenständige Netzwerkschicht vor den Clustern. Das ist mehr als ein ausgelagerter Loadbalancer: DNS, Routing, Terminierung und Schutzfunktionen liegen an einem zentralen öffentlichen Eingang. Die Compute-Plattform kann dadurch unabhängig weiterentwickelt oder ausgetauscht werden.\u003c/p\u003e\n\u003ch2 id=\"3-zentralisierung-schafft-einheitliche-schutz--und-routingregeln\"\u003e3. Zentralisierung schafft einheitliche Schutz- und Routingregeln\u003c/h2\u003e\n\u003cp\u003eProviderunabhängigkeit ist nur dann belastbar, wenn nicht lediglich der Loadbalancer verschoben wird, während DNS, TLS und Security weiterhin pro Provider getrennt betrieben werden. Eine zentrale Edge-Schicht bündelt diese Funktionen an der Stelle, an der der Traffic erstmals kontrolliert werden kann.\u003c/p\u003e\n\u003cp\u003eFür HTTP- und HTTPS-Services können TLS Termination und Web Application Firewall an der Edge erfolgen. DDoS Protection und Scrubbing halten schädlichen Traffic möglichst vor den Backends ab. Anycast DNS und Multi-Provider-DNS unterstützen eine öffentliche Namensauflösung, die nicht ausschließlich von einer einzelnen Compute-Plattform abhängt. Health Checks und Failover ergänzen die Architektur um eine kontrollierte Reaktion auf nicht erreichbare Backends.\u003c/p\u003e\n\u003cp\u003eDas reduziert nicht automatisch jede Komplexität. Routingentscheidungen müssen nachvollziehbar dokumentiert, Zertifikate und Policies zentral verantwortet und Backend-Ziele sauber segmentiert werden. Dafür entstehen einheitliche Betriebs- und Security-Prozesse über mehrere Cluster hinweg. Traffic- und Usage-Statistiken liefern zudem eine gemeinsame Sicht auf den öffentlichen Eingang, statt Daten aus unterschiedlichen Provider-Loadbalancern nachträglich zusammenzuführen.\u003c/p\u003e\n\u003ch2 id=\"4-anycast-und-aktiv-aktiv-verändern-den-betriebsansatz\"\u003e4. Anycast und Aktiv-Aktiv verändern den Betriebsansatz\u003c/h2\u003e\n\u003cp\u003eEin providergebundener Loadbalancer ist meist an die Verfügbarkeit und Netzarchitektur einer einzelnen Plattform gekoppelt. Eine verteilte Edge-Schicht kann den öffentlichen Zugang dagegen über mehrere Points of Presence und eine Aktiv-Aktiv-Architektur organisieren. Anycast sorgt dabei dafür, dass Anfragen über die Edge-Infrastruktur zum geeigneten Eingang gelangen, ohne dass der Cluster selbst diese globale Verteilung abbilden muss.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist entscheidend, dass diese Verteilung nicht mit der Skalierung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n verwechselt wird. Kubernetes skaliert Pods und Services innerhalb der Compute-Ebene. Die Edge verteilt und schützt den externen Traffic vor dieser Ebene. Beide Systeme benötigen eigene Health Checks und klare Fehlerdomänen. Fällt ein Backend aus, kann die Edge auf ein anderes Ziel oder einen anderen Cluster umschalten; fällt ein Pod aus, reagiert Kubernetes innerhalb des Clusters.\u003c/p\u003e\n\u003cp\u003eDiese Entkopplung ist für Multi-Cloud relevant. Ein Unternehmen kann beispielsweise einen primären Cluster bei einem Provider und einen zweiten Cluster bei einem anderen betreiben, ohne für jede Umgebung einen eigenen öffentlichen Einstieg zu etablieren. Die konkrete Failover-Logik bleibt eine Architekturentscheidung und muss zu Datenhaltung, Session-Verhalten und Anwendung passen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei [Kubernetes]-Clustern: Der primäre Cluster läuft in einer Public Cloud, der zweite bei einem unabhängigen Infrastrukturprovider. Mit providergebundenen Loadbalancern entstehen zwei öffentliche Endpunkte, getrennte DNS- und Security-Konfigurationen sowie unterschiedliche Betriebsprozesse.\u003c/p\u003e\n\u003cp\u003eAlternativ liegt der öffentliche Endpunkt in einer Edge-Schicht. Anycast Loadbalancing nimmt den Traffic entgegen, TLS Termination und WAF-Regeln werden zentral angewendet. Die Edge verwendet Health Checks für beide Backend-Ziele und kann bei einer Störung umschalten. Die [Kubernetes]-Cluster bleiben technisch unterschiedlich betreibbar. Der Preis dafür ist zusätzliche Architekturarbeit bei Routing, Zustandsmanagement und Failover-Tests. Der Gewinn ist ein einheitlicher öffentlicher Zugang unabhängig vom Compute-Provider.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-providergebundener-kubernetes-loadbalancer-grundsätzlich-falsch\"\u003eIst ein providergebundener \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Loadbalancer grundsätzlich falsch?\u003c/h3\u003e\n\u003cp\u003eNein. Für einen einzelnen Cluster kann er effizient und ausreichend sein. Problematisch wird die Kopplung, wenn Providerwechsel, Multi-Cloud oder zentrale Security- und Routingregeln Anforderungen sind.\u003c/p\u003e\n\u003ch3 id=\"muss-die-edge-cloud-kubernetes-beim-selben-provider-betreiben\"\u003eMuss die Edge Cloud \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n beim selben Provider betreiben?\u003c/h3\u003e\n\u003cp\u003eNein. Eine Edge-Schicht kann vor ayedo Managed Kubernetes sowie vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-den-kubernetes-service\"\u003eErsetzt die Edge den \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Service?\u003c/h3\u003e\n\u003cp\u003eNein. Der \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Service bleibt für die interne beziehungsweise clusterbezogene Erreichbarkeit relevant. Die Edge übernimmt den öffentlichen Eingang, Routing, Schutz und die Weiterleitung zu den Backends.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderunabhängiges \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n erfordert eine klare Trennung zwischen Compute und öffentlichem Traffic. Providergebundene Loadbalancer reduzieren den Startaufwand, verankern aber DNS, Adressierung und Schutz häufig in einer einzelnen Plattform. Eine eigenständige Edge-Schicht schafft einen stabilen öffentlichen Eingang über Cluster- und Providergrenzen hinweg. Die ayedo Edge Cloud ordnet sich hier als Anycast-basierte, aktiv-aktive Traffic- und Schutzebene ein, die Kubernetes bei ayedo oder anderen Providern anbinden kann.\u003c/p\u003e\n", "summary": "\nTL;DR Ein Kubernetes Service vom Typ LoadBalancer bindet den öffentlichen Zugang häufig an den jeweiligen Cloud- oder Infrastrukturprovider. Eine eigenständige Edge-Schicht trennt diese Verantwortung vom Cluster: Routing, Schutz, TLS und Erreichbarkeit werden zentral organisiert, während Kubernetes bei ayedo oder einem anderen Provider betrieben werden kann. Das reduziert Providerabhängigkeiten und vereinfacht Multi-Cloud-Architekturen.\nEinleitung Ein Kubernetes Loadbalancer ist nicht nur eine technische Ressource, sondern eine Architekturentscheidung: Wird der öffentliche Zugang zu einem Service vom Compute-Provider kontrolliert oder als eigenständige Netzwerkschicht betrieben? In vielen Clustern erzeugt ein Service vom Typ LoadBalancer automatisch eine providergebundene Infrastruktur. Das ist für einzelne Umgebungen pragmatisch, erschwert aber Migrationen, Multi-Cloud-Betrieb und eine einheitliche Sicherheitsarchitektur. Wer Kubernetes providerunabhängig betreiben will, muss deshalb die Zuständigkeiten zwischen Cluster und öffentlichem Traffic-Eingang sauber trennen.\n", "image": "https://ayedo.de/loadbalancer-fur-kubernetes-providerunabhangig-betreiben.png", "date_published": "2026-09-08T17:15:04Z", "date_modified": "2026-09-08T17:15:04Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","cloud","cloud-native","operations"], "language": "de" },{ "id": "https://ayedo.de/posts/security-entscheidungen-an-der-edge-nachvollziehbar-machen/", "url": "https://ayedo.de/posts/security-entscheidungen-an-der-edge-nachvollziehbar-machen/", "title": "Security-Entscheidungen an der Edge nachvollziehbar machen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/security-entscheidungen-an-der-edge-nachvollziehbar-machen/security-entscheidungen-an-der-edge-nachvollziehbar-machen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEdge Security Monitoring macht sichtbar, wie sich Schutzmaßnahmen auf den öffentlichen Traffic auswirken. Traffic- und Usage-Statistiken helfen, WAF-Regeln, DDoS-Schutz und exponierte Endpunkte betrieblich zu bewerten. Sie erklären jedoch weder individuelle Angriffe vollständig noch ersetzen sie Logs, Traces und anwendungsnahe Security-Telemetrie.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eSecurity-Entscheidungen an der Edge werden häufig einmal getroffen und anschließend nur bei Störungen hinterfragt. Das ist problematisch: Eine aktivierte WAF-Regel kann legitime Requests blockieren, ein DDoS-Schutz kann Muster verändern und ein öffentlich erreichbarer Endpunkt kann deutlich mehr Traffic erhalten als erwartet. Ohne statistische Sichtbarkeit bleibt unklar, ob eine Maßnahme wirksam, zu restriktiv oder operativ relevant ist. Edge Security Monitoring schafft hier eine belastbare Beobachtungsebene. Es verbindet Traffic- und Usage-Statistiken mit den Entscheidungen, die am öffentlichen Eingang einer Anwendung getroffen werden. Diese Sicht ist wertvoll, aber nicht vollständig: Aggregierte Daten bewerten Muster und Auswirkungen, nicht jede einzelne Anfrage oder die gesamte fachliche Ursache eines Vorfalls.\u003c/p\u003e\n\u003ch2 id=\"1-welche-fragen-traffic-statistiken-beantworten\"\u003e1. Welche Fragen Traffic-Statistiken beantworten\u003c/h2\u003e\n\u003cp\u003eTraffic-Statistiken schaffen zunächst eine gemeinsame quantitative Grundlage für Security- und Betriebsentscheidungen. Sie zeigen beispielsweise, wie viel Traffic einen öffentlichen Service erreicht, wie sich das Volumen über Zeiträume verändert und ob einzelne Endpunkte auffällig stark genutzt werden. Damit lässt sich prüfen, ob ein erwartetes Nutzungsmuster mit der tatsächlichen Exponierung übereinstimmt.\u003c/p\u003e\n\u003cp\u003eFür die Security-Analyse sind außerdem Veränderungen entscheidend: Steigt der Request-Anteil eines Endpunkts plötzlich? Entsteht eine ungewöhnliche Lastspitze? Verändert sich das Verhältnis zwischen erlaubtem und abgewehrtem Traffic nach einer Regeländerung? Solche Fragen lassen sich auf Edge-Ebene schneller beantworten als ausschließlich aus Backend-Logs, weil die Edge den Traffic vor der Weiterleitung beobachtet.\u003c/p\u003e\n\u003cp\u003eDie Statistiken unterstützen damit Priorisierung und Kapazitätsentscheidungen. Ein öffentlich erreichbarer Endpoint mit dauerhaft hoher Nutzung verdient eine andere Prüfung als ein selten verwendeter Verwaltungszugang. Sie liefern jedoch keine automatische Bewertung der fachlichen Legitimität eines Requests. Dafür bleiben Anwendungslogs und Identitätsinformationen erforderlich.\u003c/p\u003e\n\u003ch2 id=\"2-waf-monitoring-als-überprüfbarer-betriebsprozess\"\u003e2. WAF Monitoring als überprüfbarer Betriebsprozess\u003c/h2\u003e\n\u003cp\u003eEine Web Application Firewall ist nicht allein durch ihre Aktivierung wirksam. Entscheidend ist, ob Regeln relevante Angriffe erkennen, legitime Nutzung passieren lassen und im Betrieb beherrschbar bleiben. WAF Monitoring sollte deshalb nicht nur geblockte Requests zählen, sondern Regeländerungen mit Traffic- und Usage-Entwicklungen verbinden.\u003c/p\u003e\n\u003cp\u003eWird eine Regel aktiviert oder verschärft, können Statistiken Hinweise auf ihre betriebliche Wirkung liefern: Verändert sich die Zahl abgewiesener Requests? Sind bestimmte öffentliche Services stärker betroffen als andere? Tritt der Effekt nur während eines einzelnen Ereignisses oder dauerhaft auf? Diese Informationen helfen, Fehlkonfigurationen von tatsächlichen Angriffsmustern zu unterscheiden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt Traffic- und Usage-Statistiken im Kontext ihrer Edge-Funktionen bereit. Dadurch können Betreiber die Wirkung der WAF dort bewerten, wo der öffentliche HTTP- und HTTPS-Traffic verarbeitet wird. Für eine belastbare Entscheidung müssen diese Daten mit WAF-Ereignissen, Release-Zeitpunkten und bekannten Nutzungsmustern korreliert werden. Eine aggregierte Statistik ersetzt keine Detailprüfung einzelner Requests.\u003c/p\u003e\n\u003ch2 id=\"3-ddos-schutz-und-öffentliche-endpunkte-bewerten\"\u003e3. DDoS-Schutz und öffentliche Endpunkte bewerten\u003c/h2\u003e\n\u003cp\u003eBei DDoS-Schutz ist die zentrale Frage nicht nur, ob Traffic abgewehrt wurde. Relevant ist auch, welcher Traffic die Backends erreicht, ob sich Lastspitzen auf bestimmte Services konzentrieren und ob legitime Nutzung während eines Ereignisses weiterhin verfügbar bleibt. Traffic-Statistiken machen diese Entwicklung über die Edge hinweg sichtbar und unterstützen die nachträgliche Betriebsbewertung.\u003c/p\u003e\n\u003cp\u003eFür öffentliche Endpunkte lässt sich außerdem prüfen, ob die technische Exponierung zur vorgesehenen Architektur passt. Ein Endpoint, der nur für einen begrenzten Nutzerkreis gedacht ist, aber dauerhaft hohe oder stark schwankende Zugriffsmuster zeigt, sollte hinsichtlich Routing, Authentisierung und Erreichbarkeit untersucht werden. Die Edge kann dabei den öffentlichen Zugang schützen und verteilen, aber die fachliche Berechtigung eines Aufrufs nicht allein aus Traffic-Mengen ableiten.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kombiniert Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit DDoS Protection und Scrubbing an der Edge. Für die Betriebsanalyse ist wichtig, diese Funktionen nicht getrennt von der Traffic-Sicht zu betrachten: Schutzwirkung, Weiterleitung und Backend-Belastung bilden eine zusammenhängende Betrachtungskette.\u003c/p\u003e\n\u003ch2 id=\"4-wo-aggregierte-sichtbarkeit-endet\"\u003e4. Wo aggregierte Sichtbarkeit endet\u003c/h2\u003e\n\u003cp\u003eStatistiken beantworten Fragen zu Volumen, Verteilung, zeitlichen Veränderungen und Auswirkungen auf den öffentlichen Eingang. Sie beantworten jedoch nicht zuverlässig, welcher Benutzer eine Anfrage ausgelöst hat, welche Daten verarbeitet wurden oder ob ein fachlich gültiger Vorgang missbraucht wurde. Ebenso lässt sich aus einem erhöhten Request-Volumen allein nicht sicher auf einen Angriff schließen.\u003c/p\u003e\n\u003cp\u003eFür forensische Analysen benötigen Teams zusätzliche Ebenen: detaillierte WAF- und Access-Logs, Korrelation mit Identitäten, Applikationslogs, Traces sowie Informationen aus Authentisierung und Backend-Systemen. Erst diese Verbindung kann die Ursache eines Vorfalls und seinen fachlichen Schaden hinreichend erklären.\u003c/p\u003e\n\u003cp\u003eAuch organisatorisch ist die Abgrenzung relevant. Edge-Teams bewerten Schutzwirkung und Traffic-Muster, während Application- und Security-Teams die Bedeutung einzelner Requests untersuchen. Ein gemeinsames Zeitmodell, konsistente Service-Namen und nachvollziehbare Änderungen an Regeln erleichtern die Korrelation. Edge Security Monitoring ist damit eine Kontroll- und Bewertungsebene, aber kein Ersatz für vollständige Anwendungsobservability oder Incident Response.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche API und einen webbasierten Self-Service. Nach einer Verschärfung einer WAF-Regel steigen die blockierten Requests deutlich. Die Traffic-Statistik zeigt, dass der Anstieg fast ausschließlich die API betrifft und zeitgleich ein neues Client-Release ausgerollt wurde. Die Edge-Sicht liefert damit einen belastbaren Hinweis auf die betroffene Zone, aber noch keinen Beweis für die Ursache. Das Team korreliert die Werte mit WAF-Ereignissen, API-Logs und Release-Informationen. So kann es die Regel gezielt anpassen, statt den gesamten Schutz zurückzunehmen. Bei einem parallelen DDoS-Ereignis würde dieselbe Statistik zusätzlich zeigen, ob die Backends entlastet wurden und welche Endpunkte weiterhin legitimen Traffic verarbeiten.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sind-traffic-statistiken-ein-sicherheitsnachweis\"\u003eSind Traffic-Statistiken ein Sicherheitsnachweis?\u003c/h3\u003e\n\u003cp\u003eNein. Sie belegen beobachtbare Muster und betriebliche Auswirkungen. Für einen Sicherheitsnachweis müssen zusätzlich Regelkonfigurationen, Ereignislogs, Anwendungsdaten und organisatorische Prozesse betrachtet werden.\u003c/p\u003e\n\u003ch3 id=\"was-sollte-beim-waf-monitoring-korreliert-werden\"\u003eWas sollte beim WAF Monitoring korreliert werden?\u003c/h3\u003e\n\u003cp\u003eWAF-Ereignisse sollten mit Traffic-Volumen, betroffenen Services, Regeländerungen, Deployments und Backend-Fehlern korreliert werden. Erst dadurch lassen sich Schutzwirkung und Fehlblockierungen sinnvoll unterscheiden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-edge-monitoring-ein-siem\"\u003eErsetzt Edge Monitoring ein SIEM?\u003c/h3\u003e\n\u003cp\u003eNein. Edge-Statistiken können eine wichtige Datenquelle sein. Ein SIEM oder vergleichbare Analyseprozesse übernehmen zusätzlich Korrelation, Aufbewahrung, Alarmierung und die Einordnung weiterer Infrastruktur- und Anwendungsdaten.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eNachvollziehbare Security-Entscheidungen benötigen eine Beobachtungsebene, die Schutzmaßnahmen mit ihrem realen Betriebseffekt verbindet. Traffic- und Usage-Statistiken helfen, WAF-Regeln, DDoS-Schutz und öffentliche Endpunkte auf Muster und Auswirkungen zu prüfen. Sie müssen aber bewusst von forensischer Anwendungsanalyse getrennt werden. Die ayedo Edge Cloud ordnet diese Sicht in eine verteilte Edge-Plattform mit Schutz, Routing und Lastverteilung ein. Entscheidend bleibt die Kombination aus Edge-Daten und anwendungsnaher Telemetrie.\u003c/p\u003e\n", "summary": "\nTL;DR Edge Security Monitoring macht sichtbar, wie sich Schutzmaßnahmen auf den öffentlichen Traffic auswirken. Traffic- und Usage-Statistiken helfen, WAF-Regeln, DDoS-Schutz und exponierte Endpunkte betrieblich zu bewerten. Sie erklären jedoch weder individuelle Angriffe vollständig noch ersetzen sie Logs, Traces und anwendungsnahe Security-Telemetrie.\nEinleitung Security-Entscheidungen an der Edge werden häufig einmal getroffen und anschließend nur bei Störungen hinterfragt. Das ist problematisch: Eine aktivierte WAF-Regel kann legitime Requests blockieren, ein DDoS-Schutz kann Muster verändern und ein öffentlich erreichbarer Endpunkt kann deutlich mehr Traffic erhalten als erwartet. Ohne statistische Sichtbarkeit bleibt unklar, ob eine Maßnahme wirksam, zu restriktiv oder operativ relevant ist. Edge Security Monitoring schafft hier eine belastbare Beobachtungsebene. Es verbindet Traffic- und Usage-Statistiken mit den Entscheidungen, die am öffentlichen Eingang einer Anwendung getroffen werden. Diese Sicht ist wertvoll, aber nicht vollständig: Aggregierte Daten bewerten Muster und Auswirkungen, nicht jede einzelne Anfrage oder die gesamte fachliche Ursache eines Vorfalls.\n", "image": "https://ayedo.de/security-entscheidungen-an-der-edge-nachvollziehbar-machen.png", "date_published": "2026-09-08T17:10:09Z", "date_modified": "2026-09-08T17:10:09Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln/", "url": "https://ayedo.de/posts/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln/", "title": "DDoS-Schutz an der Edge mit Anwendungslogik koppeln", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDDoS-Schutz und Anwendungssicherheit adressieren unterschiedliche Angriffsebenen. Die Edge kann Volumen, Protokolle, Verbindungsraten und Request-Muster bewerten und schädlichen Traffic frühzeitig verwerfen. Ob ein gültiger Request fachlich missbräuchlich ist, lässt sich jedoch meist erst im Anwendungskontext erkennen. Wirksamer Schutz kombiniert daher beide Ebenen mit klaren Zuständigkeiten.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin erfolgreicher HTTP-Request ist nicht automatisch ein legitimer Geschäftsvorgang. Ein Angreifer kann gültige URLs aufrufen, korrekte TLS-Verbindungen aufbauen und sich innerhalb technischer Grenzwerte bewegen – etwa indem er Login-, Such- oder Warenkorb-Funktionen gezielt belastet. Ein klassischer DDoS-Schutz erkennt dabei möglicherweise keinen volumetrischen Angriff. Umgekehrt kann eine Anwendung den eingehenden Traffic nicht wirtschaftlich bewerten, wenn bereits große Mengen schädlicher Pakete und Verbindungen die Infrastruktur erreichen. Die entscheidende Architekturfrage lautet deshalb nicht, ob Edge oder Anwendung schützt. Sie lautet, welche Signale jede Ebene zuverlässig bewerten kann und wie beide Schutzmechanismen zusammenspielen.\u003c/p\u003e\n\u003ch2 id=\"1-die-edge-bewertet-technische-angriffssignale\"\u003e1. Die Edge bewertet technische Angriffssignale\u003c/h2\u003e\n\u003cp\u003eDDoS Protection und Scrubbing arbeiten netzwerk- und transportnah. Sie analysieren beispielsweise Paket- und Verbindungsvolumen, Protokollverhalten, Quellen, Zielsysteme sowie auffällige Raten von Requests oder Verbindungsaufbauten. Auf Layer 4 stehen TCP- oder UDP-Muster im Mittelpunkt; auf Layer 7 können HTTP-Requests, Header und Pfade in die Bewertung einfließen. Der Vorteil liegt in der Position vor dem Backend: Schädlicher Traffic wird verworfen, bevor er Anwendungsserver, \u003ca href=\"/kubernetes/\"\u003eKubernetes-Ingress\u003c/a\u003e\n oder Datenbanken belastet.\u003c/p\u003e\n\u003cp\u003eFür diesen Schutz ist die technische Identität des Requests entscheidend, nicht seine fachliche Bedeutung. Eine ungewöhnlich hohe Zahl von Verbindungen, ungültige Protokollsequenzen oder ein stark verändertes Request-Muster sind erkennbare Signale. Ein einzelner, formal korrekter Login-Request kann dagegen technisch unauffällig sein. Die Edge Cloud von ayedo verbindet dafür Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit DDoS Protection, Scrubbing und einer verteilten Aktiv-Aktiv-Architektur. Sie bildet damit eine Schutz- und Routingebene vor den Backends, nicht nur einen nachgelagerten Verteiler.\u003c/p\u003e\n\u003ch2 id=\"2-fachlicher-missbrauch-beginnt-hinter-dem-gültigen-request\"\u003e2. Fachlicher Missbrauch beginnt hinter dem gültigen Request\u003c/h2\u003e\n\u003cp\u003eAnwendungssicherheit muss bewerten, ob ein Vorgang im Geschäftsprozess zulässig ist. Dazu gehören etwa zu viele fehlgeschlagene Logins pro Benutzerkonto, ungewöhnliche Passwort-Reset-Anfragen, die wiederholte Abfrage teurer Suchoperationen oder der Missbrauch von Gutscheinen und Bestellprozessen. Solche Muster lassen sich nicht zuverlässig allein aus IP-Adresse, Transportprotokoll oder globaler Request-Rate ableiten.\u003c/p\u003e\n\u003cp\u003eHier liegen die relevanten Signale in Identität, Session, Mandant, Berechtigungen, Ressourcenverbrauch und Prozesszustand. Ein Rate Limit von 100 Requests pro Minute kann für eine öffentliche Produktliste angemessen, für einen Login-Endpunkt aber zu großzügig sein. Umgekehrt kann ein globales Limit legitime Nutzer hinter NAT oder Unternehmens-Proxies treffen. Missbrauchsschutz gehört deshalb in die Anwendungslogik oder in einen dafür verantwortlichen Dienst. Die Edge kann diese Entscheidungen unterstützen, aber sie sollte keine fachliche Autorität simulieren, die sie nicht besitzt. Ihre Aufgabe ist, technische Last und erkennbare Angriffsmuster früh zu reduzieren.\u003c/p\u003e\n\u003ch2 id=\"3-kopplung-braucht-signale-statt-vermischter-zuständigkeiten\"\u003e3. Kopplung braucht Signale statt vermischter Zuständigkeiten\u003c/h2\u003e\n\u003cp\u003eDie Verbindung beider Ebenen entsteht durch abgestimmte Regeln und verwertbare Signale. Die Edge kann beispielsweise Requests zu sensiblen Pfaden schützen, offensichtliche Anomalien blockieren und den verbleibenden Traffic an das richtige Backend verteilen. Die Anwendung kann fachliche Ereignisse auswerten und daraus strengere Kontrollen ableiten. Dazu zählen anwendungsbezogene Rate Limits, temporäre Sperren oder zusätzliche Authentifizierungsanforderungen.\u003c/p\u003e\n\u003cp\u003eWichtig ist eine klare Richtung der Verantwortung: Die Edge entscheidet über technische Erreichbarkeit und Weiterleitung; die Anwendung entscheidet über fachliche Zulässigkeit. Werden beide Ebenen vermischt, entstehen entweder zu grobe Blockaden oder unnötige Last im Backend. TLS Termination an der Edge kann dabei die HTTP-nahe Prüfung vor dem Backend ermöglichen. Gleichzeitig bleiben Identität, Session und Business-Kontext in der Anwendung. Traffic- und Usage-Statistiken helfen, technische Muster und betriebliche Auswirkungen getrennt zu beobachten. So lässt sich feststellen, ob eine Regel den Angriff reduziert oder lediglich legitime Nutzung beeinträchtigt.\u003c/p\u003e\n\u003ch2 id=\"4-architektur-und-betrieb-müssen-fehlentscheidungen-einkalkulieren\"\u003e4. Architektur und Betrieb müssen Fehlentscheidungen einkalkulieren\u003c/h2\u003e\n\u003cp\u003eJede Schutzregel kann falsch klassifizieren. Ein Edge-Limit kann bei einer Kampagne oder einem API-Client anschlagen, obwohl kein Angriff vorliegt. Eine Anwendungssperre kann dagegen zu spät greifen, wenn bereits viele TLS-Verbindungen, Requests oder teure Vorverarbeitungsschritte Ressourcen verbrauchen. Deshalb braucht die Architektur mehrere Schutzstufen: grobe Filter und Scrubbing am öffentlichen Eingang, gezielte HTTP-Kontrollen an der Edge sowie fachliche Regeln im Backend.\u003c/p\u003e\n\u003cp\u003eBetrieblich entscheidend sind nachvollziehbare Metriken und ein kontrollierter Failover. Teams müssen erkennen können, ob der Traffic an der Edge verworfen, weitergeleitet oder erst in der Anwendung abgelehnt wurde. Backend Health Checks und Failover begrenzen dabei nicht automatisch den Missbrauch, verhindern aber, dass ein bereits beeinträchtigtes Ziel unkontrolliert weiter belastet wird. Providerunabhängige Nutzung ist relevant, wenn Anwendungen in eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n laufen. Die Edge bleibt dann die zentrale Schutz- und Routingebene, während die fachliche Kontrolle dort verbleibt, wo der Anwendungskontext vorhanden ist.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEine API bietet Login, Produktsuche und Bestellungen an. Ein volumetrischer Angriff auf die API wird an der Edge durch Scrubbing und technische Filter reduziert. Gleichzeitig sendet ein Bot gültige Login-Requests mit wechselnden IP-Adressen und bleibt unter einem globalen Request-Limit. Die Edge erkennt das Muster nur eingeschränkt. Die Anwendung erkennt dagegen viele Fehlversuche pro Konto und erhöht gezielt die Kontrolle für diesen Vorgang.\u003c/p\u003e\n\u003cp\u003eFür die Produktsuche kann ein höheres Rate Limit gelten, während Login und Passwort-Reset strenger behandelt werden. Die Edge schützt weiterhin die Gesamtkapazität und die öffentlichen Endpunkte. Die Anwendung entscheidet, welche Identitäten oder Sessions missbräuchlich handeln. Beide Ebenen lösen damit unterschiedliche Probleme, ohne dieselbe Regel doppelt oder widersprüchlich zu implementieren.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-ddos-schutz-die-anwendungssicherheit\"\u003eErsetzt DDoS-Schutz die Anwendungssicherheit?\u003c/h3\u003e\n\u003cp\u003eNein. DDoS-Schutz reduziert technische Angriffsvolumen. Fachlicher Missbrauch erfordert Informationen über Identität, Session, Berechtigungen und Geschäftsprozesse, die meist nur die Anwendung besitzt.\u003c/p\u003e\n\u003ch3 id=\"ist-rate-limiting-eine-aufgabe-der-edge-oder-der-anwendung\"\u003eIst Rate Limiting eine Aufgabe der Edge oder der Anwendung?\u003c/h3\u003e\n\u003cp\u003eBeides ist möglich, aber mit unterschiedlichem Ziel. Die Edge begrenzt technische Last und grobe Muster. Die Anwendung setzt kontextbezogene Limits für Benutzer, Mandanten, Sessions oder Geschäftsoperationen.\u003c/p\u003e\n\u003ch3 id=\"warum-reicht-eine-waf-regel-nicht-aus\"\u003eWarum reicht eine WAF-Regel nicht aus?\u003c/h3\u003e\n\u003cp\u003eEine WAF kann HTTP-Strukturen und bekannte Muster prüfen. Sie erkennt jedoch nicht zuverlässig, ob ein formal gültiger Vorgang fachlich missbraucht wird. Dafür sind zusätzliche Anwendungsdaten erforderlich.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDDoS-Schutz und Anwendungssicherheit sind keine konkurrierenden Mechanismen, sondern Schutzebenen mit unterschiedlichen Informationsgrundlagen. Die Edge reduziert Volumen, Protokollmissbrauch und erkennbare Request-Anomalien, bevor sie Backends erreichen. Die Anwendung bewertet fachliche Legitimität und Missbrauch. Die ayedo Edge Cloud ist in diesem Modell die öffentliche, verteilte Schutz- und Routingebene vor Anwendungen und APIs – auch dann, wenn deren \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes-\u003c/a\u003e\n oder Compute-Infrastruktur unabhängig betrieben wird.\u003c/p\u003e\n", "summary": "\nTL;DR DDoS-Schutz und Anwendungssicherheit adressieren unterschiedliche Angriffsebenen. Die Edge kann Volumen, Protokolle, Verbindungsraten und Request-Muster bewerten und schädlichen Traffic frühzeitig verwerfen. Ob ein gültiger Request fachlich missbräuchlich ist, lässt sich jedoch meist erst im Anwendungskontext erkennen. Wirksamer Schutz kombiniert daher beide Ebenen mit klaren Zuständigkeiten.\nEinleitung Ein erfolgreicher HTTP-Request ist nicht automatisch ein legitimer Geschäftsvorgang. Ein Angreifer kann gültige URLs aufrufen, korrekte TLS-Verbindungen aufbauen und sich innerhalb technischer Grenzwerte bewegen – etwa indem er Login-, Such- oder Warenkorb-Funktionen gezielt belastet. Ein klassischer DDoS-Schutz erkennt dabei möglicherweise keinen volumetrischen Angriff. Umgekehrt kann eine Anwendung den eingehenden Traffic nicht wirtschaftlich bewerten, wenn bereits große Mengen schädlicher Pakete und Verbindungen die Infrastruktur erreichen. Die entscheidende Architekturfrage lautet deshalb nicht, ob Edge oder Anwendung schützt. Sie lautet, welche Signale jede Ebene zuverlässig bewerten kann und wie beide Schutzmechanismen zusammenspielen.\n", "image": "https://ayedo.de/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln.png", "date_published": "2026-09-08T17:10:08Z", "date_modified": "2026-09-08T17:10:08Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","security","operations","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/multi-cloud-security-mit-zentraler-edge-architektur/", "url": "https://ayedo.de/posts/multi-cloud-security-mit-zentraler-edge-architektur/", "title": "Multi-Cloud-Security mit zentraler Edge-Architektur", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/multi-cloud-security-mit-zentraler-edge-architektur/multi-cloud-security-mit-zentraler-edge-architektur.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMulti-Cloud Security scheitert häufig nicht an fehlenden Schutzfunktionen, sondern an ihrer verteilten Umsetzung. Eine zentrale Edge-Architektur bündelt öffentlichen Zugang, WAF, DDoS-Schutz, TLS-Terminierung und Routing vor heterogenen Backends. Provider-Unabhängigkeit, eigenes Autonomous System und Aktiv-Aktiv-Betrieb reduzieren dabei Kontroll- und Abhängigkeitspunkte.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eMulti-Cloud-Architekturen verteilen Workloads über mehrere Provider, Regionen und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen. Häufig wird jedoch auch der öffentliche Zugang je Plattform separat betrieben: eigener Loadbalancer, eigene WAF, eigenes DNS und individuelle Failover-Logik. Dadurch entstehen unterschiedliche Sicherheitsmodelle, Konfigurationen und Betriebsprozesse. Der technische Trade-off ist klar: Die Backends gewinnen an Verteilbarkeit, während der Internetzugang komplexer und schwerer kontrollierbar wird. Eine zentrale Edge-Architektur setzt vor diesen heterogenen Umgebungen eine einheitliche Kontrollschicht. Sie trennt den öffentlichen Traffic-Eingang von der jeweiligen Compute-Infrastruktur und schafft damit einen konsistenten Ort für Schutz, Routing und Lastverteilung.\u003c/p\u003e\n\u003ch2 id=\"1-zentrale-edge-als-kontrollschicht-vor-heterogenen-backends\"\u003e1. Zentrale Edge als Kontrollschicht vor heterogenen Backends\u003c/h2\u003e\n\u003cp\u003eIn einer Multi-Cloud-Umgebung sollten Anwendungen nicht zwingend über die jeweiligen öffentlichen Einstiegspunkte ihrer Provider erreichbar sein. Stattdessen kann eine vorgelagerte Edge den eingehenden Traffic annehmen, prüfen und an Backends in unterschiedlichen Clouds oder \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern weiterleiten. Diese Backends können bei ayedo, bei anderen Providern oder in eigener Infrastruktur betrieben werden.\u003c/p\u003e\n\u003cp\u003eTechnisch bündelt die Edge dabei mehrere Funktionen: Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS Termination, Web Application Firewall, DDoS Protection und Backend Health Checks. Routing- und Failover-Entscheidungen werden damit nicht in jedem Backend-Cluster separat implementiert. Das reduziert Konfigurationsdivergenz und erleichtert die Durchsetzung einheitlicher Sicherheitsregeln.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Abgrenzung: Die Edge ersetzt nicht die Sicherheitsmaßnahmen innerhalb der Workloads. Netzwerksegmentierung, Identitäten, Secrets und Laufzeitschutz bleiben Aufgaben der jeweiligen Compute-Umgebung. Die Edge konzentriert sich auf den öffentlichen Eingang und verhindert, dass jede Plattform ihre eigene, voneinander abweichende Perimeterschicht etablieren muss.\u003c/p\u003e\n\u003ch2 id=\"2-provider-unabhängigkeit-reduziert-abhängigkeitspunkte\"\u003e2. Provider-Unabhängigkeit reduziert Abhängigkeitspunkte\u003c/h2\u003e\n\u003cp\u003eProvider-Unabhängigkeit bedeutet nicht, dass jede Infrastruktur identisch aufgebaut sein muss. Sie bedeutet, dass der öffentliche Zugang und zentrale Sicherheitsfunktionen nicht untrennbar an die Implementierung eines einzelnen Cloud- oder \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Providers gekoppelt sind. Ein solcher Ansatz erleichtert Migrationen, Failover-Szenarien und die Verteilung von Workloads über mehrere Umgebungen.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking unterstützt dieses Modell, indem die eigentlichen Ursprungsadressen nicht als öffentliche Einstiegspunkte verwendet werden. Die Edge kommuniziert mit den Backends, während Clients ausschließlich den zentralen öffentlichen Zugang adressieren. Das reduziert die direkte Angriffsfläche und verhindert, dass sich die interne Topologie unnötig nach außen abbildet. Ergänzend können Proxy Protocol und Health Checks für eine kontrollierte Weitergabe von Verbindungsinformationen und die Bewertung der Backend-Erreichbarkeit eingesetzt werden.\u003c/p\u003e\n\u003cp\u003eBetrieblich entsteht ein einheitlicher Übergabepunkt für DNS, Zertifikate, Routing und Statistiken. Das vereinfacht Zuständigkeiten, verlangt aber klare Prozesse: Änderungen an der Edge betreffen potenziell mehrere Anwendungen und Provider. Eine zentrale Architektur reduziert also verteilte Kontrollpunkte, erhöht jedoch die Bedeutung von Governance, Tests und nachvollziehbaren Freigaben.\u003c/p\u003e\n\u003ch2 id=\"3-autonomous-system-und-eigene-netzwerk-infrastruktur\"\u003e3. Autonomous System und eigene Netzwerk-Infrastruktur\u003c/h2\u003e\n\u003cp\u003eEin eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n ist zunächst eine Routing- und Betriebsentscheidung, kein automatischer Sicherheitsgewinn. Es schafft jedoch die Grundlage, die öffentliche Erreichbarkeit und die Anbindung der Edge unabhängiger von einzelnen Upstream- oder Cloud-Netzen zu gestalten. Zusammen mit eigener Netzwerk-Infrastruktur entsteht eine klarere Trennung zwischen Edge-Betrieb und den Netzen, in denen die Backends ausgeführt werden.\u003c/p\u003e\n\u003cp\u003eFür Multi-Cloud Security ist diese Trennung relevant, weil Sicherheits- und Routingentscheidungen nicht vollständig innerhalb einzelner Providergrenzen liegen. Anycast DNS sowie Multi-Provider-DNS können dabei helfen, den öffentlichen Zugang über mehrere Netze und Umgebungen zu organisieren. Die Edge Cloud übernimmt die Verarbeitung und Verteilung des Traffics, während die Compute-Plattformen ihre jeweilige interne Betriebsverantwortung behalten.\u003c/p\u003e\n\u003cp\u003eDie Sicherheitswirkung liegt vor allem in der Reduktion von Abhängigkeiten und im kontrollierbaren Zuständigkeitsmodell. Ein eigenes Autonomous System beseitigt weder Fehlkonfigurationen noch Angriffsrisiken. Es erweitert aber den architektonischen Handlungsspielraum bei Routing, Providerwechseln und der Entkopplung vom öffentlichen Einstiegspunkt einzelner Clouds.\u003c/p\u003e\n\u003ch2 id=\"4-aktiv-aktiv-statt-zentralem-single-point-of-failure\"\u003e4. Aktiv-Aktiv statt zentralem Single Point of Failure\u003c/h2\u003e\n\u003cp\u003eEine zentrale Edge darf nicht mit einem einzelnen zentralen System gleichgesetzt werden. Werden öffentliche Zugänge, WAF und Routing in nur einer Instanz betrieben, kann die Konsolidierung selbst zum Ausfallrisiko werden. Für eine belastbare Architektur muss die Kontrollschicht verteilt und redundant ausgelegt sein.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt dafür eine verteilte Multi-PoP-Architektur und ein Aktiv-Aktiv-Prinzip. Mehrere Edge-Instanzen können gleichzeitig Traffic verarbeiten, statt dass eine passive Reserve auf die Übernahme wartet. Das verbessert die Ausfallsicherheit und vermeidet, dass ein einzelner Standort oder eine einzelne aktive Komponente den öffentlichen Zugang bestimmt.\u003c/p\u003e\n\u003cp\u003eFür die Sicherheitsarchitektur ist entscheidend, dass Schutzfunktionen und Routing im Fehlerfall nicht auf einen anderen Provider-spezifischen Einstiegspunkt zurückfallen müssen. Health Checks und Failover können Backends abhängig von ihrer Erreichbarkeit berücksichtigen. Aktiv-Aktiv reduziert damit nicht jede Betriebsstörung, aber es begrenzt die Zahl kritischer Ausfall- und Abhängigkeitspunkte vor den Backends.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-dienst-drei-ausführungsumgebungen\"\u003ePraxisszenario: Ein Dienst, drei Ausführungsumgebungen\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung in einem ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Cluster, eine zweite Instanz in einem anderen Kubernetes-Cluster und ein API-Backend bei einem weiteren Cloud-Provider. Ohne zentrale Edge benötigt jede Umgebung eigene öffentliche Endpunkte, Zertifikate, WAF-Regeln und Failover-Mechanismen.\u003c/p\u003e\n\u003cp\u003eMit einer providerunabhängigen Edge erhalten alle Clients einen gemeinsamen öffentlichen Zugang. TLS wird an der Edge terminiert, der Traffic durch WAF und DDoS-Schutz verarbeitet und anschließend anhand von Health Checks an verfügbare Backends verteilt. Die Cluster bleiben intern adressierbar, während Backend Cloaking ihre öffentlichen Ursprungsadressen verbirgt. Fällt eine Umgebung aus, kann die Edge den Traffic auf ein gesundes Backend lenken, ohne dass der Client die Providerstruktur kennen muss.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-zentrale-edge-für-jede-multi-cloud-umgebung-sinnvoll\"\u003eIst eine zentrale Edge für jede Multi-Cloud-Umgebung sinnvoll?\u003c/h3\u003e\n\u003cp\u003eNein. Bei wenigen, eng gekoppelten Workloads kann eine providernahe Lösung ausreichen. Relevant wird die zentrale Edge vor allem bei mehreren Clouds, Clustern, öffentlichen APIs und unterschiedlichen Betriebsmodellen.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-die-security-funktionen-der-cloud-provider\"\u003eErsetzt die Edge die Security-Funktionen der Cloud-Provider?\u003c/h3\u003e\n\u003cp\u003eNein. Sie ergänzt sie am öffentlichen Eingang. Identitätsmanagement, interne Segmentierung, Workload-Schutz und Absicherung der Backends bleiben weiterhin Aufgaben der jeweiligen Plattform.\u003c/p\u003e\n\u003ch3 id=\"macht-ein-eigenes-autonomous-system-die-architektur-automatisch-sicherer\"\u003eMacht ein eigenes Autonomous System die Architektur automatisch sicherer?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert bestimmte Netzwerkabhängigkeiten und erweitert die Kontrolle über Routing und Erreichbarkeit. Sicherheitsgewinne entstehen erst durch passende Betriebsprozesse, Redundanz und konsistente Schutzregeln.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eMulti-Cloud Security ist nicht nur eine Frage einzelner WAF-Regeln oder Provider-Services. Entscheidend ist, wo der öffentliche Zugang kontrolliert, geschützt und betrieben wird. Eine verteilte, providerunabhängige Edge-Architektur bündelt diese Verantwortung vor heterogenen Backends, ohne Compute und Edge zu vermischen. Eigenes Autonomous System, eigene Netzwerk-Infrastruktur und Aktiv-Aktiv-Betrieb unterstützen dabei eine Architektur mit weniger Abhängigkeitspunkten. Die ayedo Edge Cloud ist in diesem Modell die zentrale Eingangsschicht vor unterschiedlichen Cloud- und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen.\u003c/p\u003e\n", "summary": "\nTL;DR Multi-Cloud Security scheitert häufig nicht an fehlenden Schutzfunktionen, sondern an ihrer verteilten Umsetzung. Eine zentrale Edge-Architektur bündelt öffentlichen Zugang, WAF, DDoS-Schutz, TLS-Terminierung und Routing vor heterogenen Backends. Provider-Unabhängigkeit, eigenes Autonomous System und Aktiv-Aktiv-Betrieb reduzieren dabei Kontroll- und Abhängigkeitspunkte.\nEinleitung Multi-Cloud-Architekturen verteilen Workloads über mehrere Provider, Regionen und Kubernetes -Umgebungen. Häufig wird jedoch auch der öffentliche Zugang je Plattform separat betrieben: eigener Loadbalancer, eigene WAF, eigenes DNS und individuelle Failover-Logik. Dadurch entstehen unterschiedliche Sicherheitsmodelle, Konfigurationen und Betriebsprozesse. Der technische Trade-off ist klar: Die Backends gewinnen an Verteilbarkeit, während der Internetzugang komplexer und schwerer kontrollierbar wird. Eine zentrale Edge-Architektur setzt vor diesen heterogenen Umgebungen eine einheitliche Kontrollschicht. Sie trennt den öffentlichen Traffic-Eingang von der jeweiligen Compute-Infrastruktur und schafft damit einen konsistenten Ort für Schutz, Routing und Lastverteilung.\n", "image": "https://ayedo.de/multi-cloud-security-mit-zentraler-edge-architektur.png", "date_published": "2026-09-08T17:10:08Z", "date_modified": "2026-09-08T17:10:08Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","kubernetes","cloud","cloud-native","operations"], "language": "de" },{ "id": "https://ayedo.de/posts/offentliche-angriffsflachen-systematisch-reduzieren/", "url": "https://ayedo.de/posts/offentliche-angriffsflachen-systematisch-reduzieren/", "title": "Öffentliche Angriffsflächen systematisch reduzieren", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/offentliche-angriffsflachen-systematisch-reduzieren/offentliche-angriffsflachen-systematisch-reduzieren.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine öffentliche Angriffsfläche entsteht nicht nur durch einzelne Schwachstellen, sondern durch die gesamte Internet-exponierte Architektur. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination und Backend Cloaking müssen deshalb als zusammenhängende Security-Zone vor den Backends betrachtet werden. Entscheidend ist, welcher Traffic die Backends überhaupt erreicht und unter welchen Bedingungen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Unternehmen bewerten öffentliche Endpunkte einzeln: eine API erhält eine WAF-Regel, ein \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n wird per Loadbalancer veröffentlicht, ein weiterer Dienst bekommt einen separaten DDoS-Schutz. Technisch kann jede Maßnahme sinnvoll sein. Architektonisch entsteht trotzdem schnell eine uneinheitliche und schwer kontrollierbare Angriffsfläche. Der zentrale Fehler liegt darin, Sicherheitsfunktionen als isolierte Produkte statt als Verarbeitungskette zu planen. Eine belastbare Edge Security Architektur beginnt deshalb mit einer klaren Frage: Welche Schicht nimmt den Internet-Traffic an, welche Prüfungen finden dort statt und wie wird verhindert, dass Angreifer die Backends direkt erreichen?\u003c/p\u003e\n\u003ch2 id=\"1-öffentliche-endpunkte-als-zusammenhängende-zone-modellieren\"\u003e1. Öffentliche Endpunkte als zusammenhängende Zone modellieren\u003c/h2\u003e\n\u003cp\u003eDie öffentliche Angriffsfläche umfasst mehr als DNS-Einträge und IP-Adressen. Sie beinhaltet auch TLS-Endpunkte, Routingpfade, exponierte Ports, API-Gateways, Kubernetes-Ingresses und die erreichbaren Backend-Netze. Jede zusätzliche direkte Verbindung zum Internet vergrößert den Kontrollaufwand und schafft potenziell einen alternativen Pfad an zentralen Sicherheitsregeln vorbei.\u003c/p\u003e\n\u003cp\u003eEine vorgelagerte Edge-Zone trennt den öffentlichen Eingang von der Compute-Infrastruktur. In dieser Zone werden Verbindungen angenommen, geroutet, geprüft und an geeignete Backends verteilt. Die Backends müssen dadurch nicht selbst die gesamte öffentliche Last und jede Sicherheitsfunktion übernehmen. Wichtig ist die konsequente Durchsetzung: Ein Service ist erst wirklich abgeschirmt, wenn sein Backend nicht parallel über eine zweite öffentliche Route erreichbar bleibt.\u003c/p\u003e\n\u003cp\u003eFür das Angriffsflächenmanagement bedeutet das eine Inventarisierung nach Endpunkten und Datenflüssen, nicht nur nach Anwendungen. Zu jedem öffentlichen Dienst gehören mindestens DNS-Ziel, Protokoll, Port, TLS-Verhalten, Schutzregeln, Backend-Ziel und Failover-Verhalten. So wird sichtbar, welche Systeme tatsächlich exponiert sind und wo Sicherheitskontrollen uneinheitlich angewendet werden.\u003c/p\u003e\n\u003ch2 id=\"2-anycast-loadbalancing-und-ddos-protection-verbinden\"\u003e2. Anycast Loadbalancing und DDoS Protection verbinden\u003c/h2\u003e\n\u003cp\u003eAnycast Loadbalancing verteilt den öffentlichen Zugangspunkt über eine verteilte Netzwerkarchitektur. Anfragen werden nicht an einen einzelnen zentralen Eingang gebunden, sondern an die Edge-Infrastruktur gerichtet. Für Layer-4- und Layer-7-Traffic lassen sich damit unterschiedliche Anforderungen abbilden: TCP-Verbindungen benötigen andere Prüf- und Weiterleitungslogiken als HTTP-Requests mit Hostnames, Pfaden oder Headern.\u003c/p\u003e\n\u003cp\u003eDDoS Protection ergänzt diese Verteilung um die Fähigkeit, volumetrische oder protokollbezogene Angriffe an der Edge zu behandeln, bevor sie die Compute-Umgebung belasten. Der Sicherheitsgewinn entsteht nicht allein durch die Existenz eines Schutzmechanismus, sondern durch seine Position im Datenpfad. Je später Traffic gefiltert wird, desto mehr Netzwerk-, Firewall- oder Anwendungskapazität ist bereits gebunden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit DDoS Protection und Scrubbing an der Edge. Ihre eigene Netzwerk-Infrastruktur und das eigene Autonomous System bilden dabei den infrastrukturellen Rahmen. Das reduziert nicht automatisch jedes Risiko, schafft aber eine klar definierte Stelle, an der öffentlicher Traffic angenommen, verteilt und vor dem Backend-Zugriff bewertet wird.\u003c/p\u003e\n\u003ch2 id=\"3-waf-und-tls-termination-an-der-richtigen-stelle-einsetzen\"\u003e3. WAF und TLS Termination an der richtigen Stelle einsetzen\u003c/h2\u003e\n\u003cp\u003eEine WAF schützt HTTP- und HTTPS-Services auf Anwendungsebene. Sie kann Requests anhand von Merkmalen bewerten, die ein reines Layer-4-Loadbalancing nicht kennt. Dazu gehören beispielsweise HTTP-Methoden, Pfade oder Header. Damit die WAF wirksam bleibt, darf der relevante Traffic nicht an ihr vorbeigeführt werden. Direkte Backend-Zugriffe, alternative Ingress-Pfade oder separate öffentliche Listener unterlaufen die zentrale Kontrolle.\u003c/p\u003e\n\u003cp\u003eTLS Termination an der Edge verschiebt die Entschlüsselung an den öffentlichen Eingang. Dort können HTTPS-Anfragen verarbeitet und anschließend kontrolliert an das Backend weitergeleitet werden. Das vereinfacht die zentrale Durchsetzung von Zertifikats- und Routinglogik, verändert aber auch die Vertrauensgrenzen: Der Pfad zwischen Edge und Backend muss bewusst modelliert und abgesichert werden. Verschlüsselung an der Edge ist daher kein Ersatz für eine klare Backend-Architektur.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud lassen sich TLS Termination und WAF für HTTP-/HTTPS-Services mit dem vorgelagerten Routing kombinieren. Die Edge wird damit zur durchgängigen Verarbeitungsschicht: Verbindung annehmen, TLS beenden, Request prüfen und nur zugelassenen Traffic an das passende Backend weiterleiten. Die konkrete Sicherheitswirkung hängt weiterhin von passenden Regeln, Ausnahmen und einem kontrollierten Backend-Zugang ab.\u003c/p\u003e\n\u003ch2 id=\"4-backend-cloaking-als-durchsetzungsprinzip\"\u003e4. Backend Cloaking als Durchsetzungsprinzip\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking bezeichnet nicht lediglich das Verbergen einer IP-Adresse. Es beschreibt eine Architektur, in der Backends keine direkt nutzbaren öffentlichen Adressen oder alternative Zugangspfade benötigen. Der öffentliche Client kennt den Edge-Endpunkt; das Backend bleibt hinter der vorgelagerten Verarbeitungsschicht. Dadurch werden Angriffe auf exponierte Service-Adressen, direkte Portscans und Umgehungsversuche erschwert.\u003c/p\u003e\n\u003cp\u003eTechnisch muss dafür mehr als DNS angepasst werden. Firewall-Regeln, Routing, Quelladressvalidierung und Health Checks müssen sicherstellen, dass nur vorgesehener Traffic die Anwendung erreicht. Proxy Protocol kann dabei relevante Verbindungsinformationen an das Backend übermitteln, ohne den öffentlichen Eingang wieder direkt an die Anwendung zu verlagern. Health Checks und Failover steuern zusätzlich, welches Backend aktuell Traffic erhält.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt Backend Cloaking, Proxy Protocol sowie Backend Health Checks und Failover. Das ist besonders relevant in Umgebungen, in denen Anwendungen über mehrere Cluster, Provider oder eigene Infrastrukturen verteilt sind. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n muss dabei nicht zwingend in ayedo Managed Kubernetes betrieben werden: Die Edge-Funktionen können auch vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden. So bleibt die Security-Zone vom jeweiligen Compute-Ort getrennt.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche Webanwendung, eine API und mehrere interne Services in Kubernetes-Clustern bei unterschiedlichen Providern. Im ersten Modell besitzt jeder Cluster eigene öffentliche Loadbalancer, TLS-Konfigurationen und WAF-Regeln. Ausfälle, Regeländerungen und neue Endpunkte werden je Umgebung separat behandelt. Im zweiten Modell zeigen DNS-Einträge auf die Edge-Zone. Anycast Loadbalancing nimmt den Traffic an, DDoS Protection und WAF prüfen ihn, TLS wird an der Edge terminiert und nur zugelassene Requests erreichen die Backends. Die Cluster bleiben providerunabhängig. Der operative Vorteil liegt nicht in weniger Komponenten, sondern in einer eindeutigen Kontrollgrenze: Änderungen an der öffentlichen Zugangslogik erfolgen zentral, während die Compute-Teams ihre Backends getrennt betreiben können.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-eine-waf-ein-systematisches-angriffsflächenmanagement\"\u003eErsetzt eine WAF ein systematisches Angriffsflächenmanagement?\u003c/h3\u003e\n\u003cp\u003eNein. Eine WAF bewertet vor allem HTTP-/HTTPS-Anfragen. Sie verhindert weder direkte Backend-Erreichbarkeit noch unkontrollierte Ports, DNS-Fehlkonfigurationen oder alternative Zugangswege.\u003c/p\u003e\n\u003ch3 id=\"muss-die-anwendung-dafür-in-ayedo-managed-kubernetes-laufen\"\u003eMuss die Anwendung dafür in ayedo Managed Kubernetes laufen?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch vor eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n eingesetzt werden. Edge und Compute bleiben getrennte Verantwortungsbereiche.\u003c/p\u003e\n\u003ch3 id=\"ist-backend-cloaking-gleichbedeutend-mit-vollständiger-unsichtbarkeit\"\u003eIst Backend Cloaking gleichbedeutend mit vollständiger Unsichtbarkeit?\u003c/h3\u003e\n\u003cp\u003eNein. Die Backends bleiben für die Edge erreichbar. Ziel ist, direkte öffentliche Zugänge zu vermeiden und den kontrollierten Edge-Pfad als vorgesehenen Eingang durchzusetzen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine öffentliche Angriffsfläche lässt sich nicht zuverlässig durch das Addieren einzelner Sicherheitsfunktionen reduzieren. Entscheidend ist eine Architektur, die öffentlichen Traffic an einer klar definierten Edge-Zone annimmt, verteilt, prüft und kontrolliert an verborgene Backends weiterleitet. Anycast, DDoS Protection, WAF, TLS Termination und Backend Cloaking erfüllen dabei unterschiedliche Aufgaben innerhalb derselben Verarbeitungskette. Die ayedo Edge Cloud ordnet diese Funktionen in einer providerunabhängigen, aktiv-aktiven Edge-Infrastruktur ein und trennt sie konsequent von der Compute-Verantwortung.\u003c/p\u003e\n", "summary": "\nTL;DR Eine öffentliche Angriffsfläche entsteht nicht nur durch einzelne Schwachstellen, sondern durch die gesamte Internet-exponierte Architektur. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination und Backend Cloaking müssen deshalb als zusammenhängende Security-Zone vor den Backends betrachtet werden. Entscheidend ist, welcher Traffic die Backends überhaupt erreicht und unter welchen Bedingungen.\nEinleitung Viele Unternehmen bewerten öffentliche Endpunkte einzeln: eine API erhält eine WAF-Regel, ein Kubernetes-Service wird per Loadbalancer veröffentlicht, ein weiterer Dienst bekommt einen separaten DDoS-Schutz. Technisch kann jede Maßnahme sinnvoll sein. Architektonisch entsteht trotzdem schnell eine uneinheitliche und schwer kontrollierbare Angriffsfläche. Der zentrale Fehler liegt darin, Sicherheitsfunktionen als isolierte Produkte statt als Verarbeitungskette zu planen. Eine belastbare Edge Security Architektur beginnt deshalb mit einer klaren Frage: Welche Schicht nimmt den Internet-Traffic an, welche Prüfungen finden dort statt und wie wird verhindert, dass Angreifer die Backends direkt erreichen?\n", "image": "https://ayedo.de/offentliche-angriffsflachen-systematisch-reduzieren.png", "date_published": "2026-09-08T17:10:08Z", "date_modified": "2026-09-08T17:10:08Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","operations","development","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/security-funktionen-zwischen-edge-und-anwendung-verteilen/", "url": "https://ayedo.de/posts/security-funktionen-zwischen-edge-und-anwendung-verteilen/", "title": "Security-Funktionen zwischen Edge und Anwendung verteilen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/security-funktionen-zwischen-edge-und-anwendung-verteilen/security-funktionen-zwischen-edge-und-anwendung-verteilen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eSecurity-Funktionen gehören nicht pauschal an einen einzigen Ort. Die Edge eignet sich für Schutzmaßnahmen mit hoher Sichtbarkeit, großem Skalierungsbedarf und standardisierbaren Regeln. Die Anwendung bleibt für Identität, Autorisierung und fachliche Zugriffskontrollen verantwortlich. Entscheidend sind Kontextbedarf, Fehlkonfigurationsrisiko und die Frage, wie früh ein Angriff erkannt und begrenzt werden kann.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, Sicherheitsverantwortung vollständig an die Edge oder vollständig in die Anwendung zu verlagern. Beides erzeugt blinde Flecken: Eine Edge kann volumetrische Angriffe und viele HTTP-Muster früh abfangen, kennt aber meist nicht die fachliche Bedeutung einer Transaktion. Die Anwendung kann Benutzer, Rollen und Geschäftsobjekte bewerten, erreicht diese Entscheidung jedoch erst, nachdem Traffic Infrastruktur und Laufzeit bereits belastet. Ein belastbares Modell verteilt Security-Funktionen deshalb entlang ihrer Sichtbarkeit, ihres Kontextbedarfs und ihrer Skalierungsanforderungen. Dabei müssen auch Fehlkonfigurationen berücksichtigt werden: Eine falsch platzierte oder zu weit gefasste Regel kann entweder Schutzwirkung verlieren oder legitime Anfragen blockieren.\u003c/p\u003e\n\u003ch2 id=\"1-sichtbarkeit-bestimmt-den-passenden-security-layer\"\u003e1. Sichtbarkeit bestimmt den passenden Security Layer\u003c/h2\u003e\n\u003cp\u003eDie Edge sieht den öffentlichen Traffic, bevor er die Backends erreicht. Sie kann Quellnetze, Protokolle, Ports, TLS-Verbindungen, HTTP-Anfragen, Header und typische Angriffsmuster auswerten. Diese Sichtbarkeit reicht für DDoS-Abwehr, Rate-Limiting-Konzepte, grobe Zugriffsmuster und viele WAF-Prüfungen aus. Der Vorteil liegt in der frühen Entscheidung: Schädlicher Traffic verbraucht weniger Ressourcen in Loadbalancing, Cluster und Anwendung.\u003c/p\u003e\n\u003cp\u003eDie Anwendung besitzt dagegen zusätzliche Informationen. Sie kennt Benutzerkonten, Rollen, Mandanten, Warenkörbe, Freigabestatus oder die zulässigen Zustandsübergänge einer Transaktion. Diese Informationen sind für fachliche Zugriffskontrollen unverzichtbar. Eine Edge-Regel kann erkennen, dass eine Anfrage \u003ccode\u003e/api/orders/123\u003c/code\u003e aufruft. Sie weiß ohne Anwendungskontext aber nicht, ob der authentisierte Benutzer diese Bestellung sehen darf. Sichtbarkeit ist damit das erste Entscheidungskriterium: Was am Netzwerk- oder HTTP-Rand erkennbar ist, kann dort geschützt werden; was Geschäftslogik erfordert, muss in der Anwendung entschieden werden.\u003c/p\u003e\n\u003ch2 id=\"2-skalierung-spricht-für-frühe-abwehr\"\u003e2. Skalierung spricht für frühe Abwehr\u003c/h2\u003e\n\u003cp\u003eDDoS-Abwehr und standardisierbare WAF-Prüfungen profitieren von einer vorgelagerten, verteilten Durchsetzung. Je früher ungültige oder missbräuchliche Anfragen verworfen werden, desto weniger Arbeit entsteht in Firewalls, Ingress-Komponenten, API-Prozessen und Datenbanken. Das ist nicht nur eine Security-Frage, sondern auch eine Frage der Verfügbarkeit und der Betriebskosten. Schutz direkt in der Anwendung skaliert mit deren Ressourcen und kann bei hohem Angriffsdruck selbst zum Engpass werden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud übernimmt als öffentlicher Eingang DDoS Protection und Scrubbing an der Edge sowie WAF-Funktionen für HTTP- und HTTPS-Services. TLS Termination kann zusätzlich dazu beitragen, verschlüsselte Anfragen vor der Weiterleitung zentral zu prüfen. Backend Cloaking reduziert dabei die direkte Sichtbarkeit der eigentlichen Backends. Diese Funktionen ersetzen keine Anwendungssecurity. Sie verschieben jedoch die erste Schutzentscheidung an einen Ort, an dem Traffic zentral, verteilt und vor der Compute-Infrastruktur bewertet werden kann.\u003c/p\u003e\n\u003ch2 id=\"3-identität-und-autorisierung-brauchen-anwendungskontext\"\u003e3. Identität und Autorisierung brauchen Anwendungskontext\u003c/h2\u003e\n\u003cp\u003eAuthentifizierung und Autorisierung werden häufig vermischt. Authentifizierung beantwortet, wer ein Aufrufer ist. Autorisierung entscheidet, was dieser Aufrufer unter bestimmten Bedingungen tun darf. Eine zentrale Edge-Komponente kann je nach Architektur die Prüfung von Tokens oder Client-Zertifikaten übernehmen. Ob diese Funktion sinnvoll ist, hängt von den vorhandenen Identitätsquellen, Protokollen und Vertrauensgrenzen ab. Sie darf nicht automatisch als Ersatz für jede Prüfung in der Anwendung verstanden werden.\u003c/p\u003e\n\u003cp\u003eDie Anwendung muss weiterhin sicherstellen, dass Identität, Mandant, Ressource und Aktion zusammenpassen. Besonders bei APIs reicht eine grobe Regel wie „angemeldete Benutzer dürfen \u003ccode\u003e/orders\u003c/code\u003e aufrufen“ nicht aus. Erforderlich kann sein, dass ein Benutzer nur Bestellungen seines Mandanten lesen oder eine Transaktion nur in einem bestimmten Status ändern darf. Solche Regeln gehören in die Anwendung oder in eine eng daran gekoppelte Policy-Schicht. Eine Edge-Prüfung kann Last reduzieren und offensichtlich ungültige Zugriffe abweisen, aber die fachliche Entscheidung nicht zuverlässig vorwegnehmen.\u003c/p\u003e\n\u003ch2 id=\"4-fehlkonfiguration-als-eigenes-entscheidungskriterium\"\u003e4. Fehlkonfiguration als eigenes Entscheidungskriterium\u003c/h2\u003e\n\u003cp\u003eJede Security-Schicht erzeugt Betriebsrisiken. Eine zu restriktive WAF-Regel kann legitime Requests blockieren, eine zu großzügige Regel lässt Angriffe passieren. In der Anwendung können dagegen uneinheitliche Prüfungen entstehen: Ein Endpoint validiert Mandantenzugehörigkeit, ein anderer vergisst sie. Die Verteilung sollte daher nicht nur nach technischer Machbarkeit erfolgen, sondern auch nach der Wahrscheinlichkeit und Auswirkung von Fehlkonfigurationen.\u003c/p\u003e\n\u003cp\u003eEdge-Regeln eignen sich für zentral sichtbare, nachvollziehbare Schutzanforderungen: erlaubte Protokolle, bekannte Angriffsmuster, grobe Request-Limits oder die Abschirmung nicht öffentlicher Backends. Fachliche Policies sollten nahe an den Domänenmodellen liegen und mit Tests, Code-Reviews sowie nachvollziehbaren Änderungsprozessen betrieben werden. Wichtig ist außerdem die Beobachtbarkeit: Blockierungen an der Edge und Ablehnungen in der Anwendung müssen unterscheidbar sein. Traffic- und Usage-Statistiken der Edge können dabei die Wirkung vorgelagerter Regeln sichtbar machen; Anwendungslogs erklären, warum eine fachliche Entscheidung abgelehnt wurde.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche API auf einem \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n Cluster. Die Edge übernimmt Anycast-basiertes Layer-7-Loadbalancing, TLS Termination, WAF-Prüfungen und DDoS-Abwehr. Nicht öffentliche Backend-Adressen werden durch Backend Cloaking verborgen. Die Anwendung prüft anschließend Token, Mandantenzugehörigkeit und die Berechtigung für einzelne Ressourcen.\u003c/p\u003e\n\u003cp\u003eBei einer Änderung wird ein neuer Parameter eingeführt, den die WAF zunächst als verdächtig blockiert. Die Edge-Statistiken zeigen erhöhte Ablehnungen, während die Anwendung keine entsprechenden Requests sieht. Die Regel kann gezielt angepasst werden, ohne die fachlichen Autorisierungsprüfungen zu verändern. Umgekehrt bleibt eine fehlerhafte Mandantenprüfung ein Anwendungsproblem und wird nicht durch eine generische Edge-Regel gelöst. Dieses Modell trennt Infrastruktur- und Domänenverantwortung klar.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sollte-jede-waf-regel-zusätzlich-in-der-anwendung-umgesetzt-werden\"\u003eSollte jede WAF-Regel zusätzlich in der Anwendung umgesetzt werden?\u003c/h3\u003e\n\u003cp\u003eNein. WAF-Regeln und Anwendungsvalidierung haben unterschiedliche Ziele. Sicherheitskritische Eingaben müssen in der Anwendung unabhängig davon validiert werden, weil nur sie ihren fachlichen Kontext kennt.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-autorisierung-vollständig-übernehmen\"\u003eKann die Edge Autorisierung vollständig übernehmen?\u003c/h3\u003e\n\u003cp\u003eNur für klar definierte, kontextarme Regeln. Ressourcen- und transaktionsbezogene Berechtigungen gehören in die Anwendung, da dort Identität, Mandant und Geschäftsstatus zusammengeführt werden.\u003c/p\u003e\n\u003ch3 id=\"warum-reicht-ddos-schutz-in-der-anwendung-nicht-aus\"\u003eWarum reicht DDoS-Schutz in der Anwendung nicht aus?\u003c/h3\u003e\n\u003cp\u003eDie Anwendung wird erst aktiv, nachdem Traffic Netzwerk, Routing und Laufzeit erreicht hat. Vorgelagerte Abwehr reduziert Ressourcenverbrauch und schützt auch dann, wenn die Anwendung selbst bereits überlastet ist.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eSecurity-Funktionen sollten entlang ihrer Entscheidungsgrundlage verteilt werden. Die Edge schützt, was früh sichtbar, standardisierbar und skalierungsrelevant ist. Die Anwendung entscheidet dort, wo Identität, Ressourcen und Geschäftslogik zusammenwirken. Für Unternehmen entsteht daraus kein Entweder-oder, sondern ein abgestimmtes Security-Layer-Modell. Die ayedo Edge Cloud ist in diesem Modell der öffentliche Schutz- und Verteilungspunkt; Autorisierung und fachliche Zugriffskontrolle bleiben Verantwortung der jeweiligen Anwendung.\u003c/p\u003e\n", "summary": "\nTL;DR Security-Funktionen gehören nicht pauschal an einen einzigen Ort. Die Edge eignet sich für Schutzmaßnahmen mit hoher Sichtbarkeit, großem Skalierungsbedarf und standardisierbaren Regeln. Die Anwendung bleibt für Identität, Autorisierung und fachliche Zugriffskontrollen verantwortlich. Entscheidend sind Kontextbedarf, Fehlkonfigurationsrisiko und die Frage, wie früh ein Angriff erkannt und begrenzt werden kann.\nEinleitung Ein häufiger Architekturfehler besteht darin, Sicherheitsverantwortung vollständig an die Edge oder vollständig in die Anwendung zu verlagern. Beides erzeugt blinde Flecken: Eine Edge kann volumetrische Angriffe und viele HTTP-Muster früh abfangen, kennt aber meist nicht die fachliche Bedeutung einer Transaktion. Die Anwendung kann Benutzer, Rollen und Geschäftsobjekte bewerten, erreicht diese Entscheidung jedoch erst, nachdem Traffic Infrastruktur und Laufzeit bereits belastet. Ein belastbares Modell verteilt Security-Funktionen deshalb entlang ihrer Sichtbarkeit, ihres Kontextbedarfs und ihrer Skalierungsanforderungen. Dabei müssen auch Fehlkonfigurationen berücksichtigt werden: Eine falsch platzierte oder zu weit gefasste Regel kann entweder Schutzwirkung verlieren oder legitime Anfragen blockieren.\n", "image": "https://ayedo.de/security-funktionen-zwischen-edge-und-anwendung-verteilen.png", "date_published": "2026-09-08T17:10:08Z", "date_modified": "2026-09-08T17:10:08Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","cloud-native","operations","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/tls-waf-und-backend-eine-schichtenarchitektur/", "url": "https://ayedo.de/posts/tls-waf-und-backend-eine-schichtenarchitektur/", "title": "TLS, WAF und Backend: Eine Schichtenarchitektur", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-waf-und-backend-eine-schichtenarchitektur/tls-waf-und-backend-eine-schichtenarchitektur.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine belastbare \u003cstrong\u003eSecurity-Schichtenarchitektur\u003c/strong\u003e verteilt Schutzaufgaben auf unterschiedliche Ebenen: TLS schützt die Transportverbindung, die WAF bewertet HTTP-Anfragen und das Backend bleibt für Autorisierung, Validierung und Datenschutz verantwortlich. Entscheidend sind die Übergabepunkte zwischen diesen Schichten. Jede Entschlüsselung, Weiterleitung und Protokollumwandlung erzeugt dabei eigene Vertrauens- und Betriebsanforderungen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eTLS, WAF und Backend werden in der Praxis häufig als ein zusammenhängender Schutzmechanismus behandelt. Das führt zu einer problematischen Annahme: Ist TLS aktiv und eine WAF vorgeschaltet, sei die Anwendung automatisch ausreichend abgesichert. Tatsächlich erfüllen die drei Komponenten unterschiedliche Aufgaben und sehen jeweils nur einen Teil des Datenverkehrs. TLS schützt primär den Transportweg, die WAF analysiert Anwendungsanfragen und das Backend muss Geschäftslogik, Identitäten und Daten selbst absichern. Eine Security-Schichtenarchitektur ist deshalb vor allem eine Frage sauber definierter Zuständigkeiten, Übergabepunkte und verbleibender Risiken.\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-definiert-die-erste-vertrauensgrenze\"\u003e1. TLS Termination definiert die erste Vertrauensgrenze\u003c/h2\u003e\n\u003cp\u003eTLS schützt die Vertraulichkeit und Integrität einer Verbindung zwischen Client und einem TLS-Endpunkt. Bei \u003cstrong\u003eTLS Termination\u003c/strong\u003e an der Edge endet diese Verbindung nicht erst am Backend, sondern bereits an der Edge-Plattform. Dort wird der verschlüsselte HTTP-Traffic entschlüsselt und kann für nachgelagerte Sicherheitsfunktionen ausgewertet werden.\u003c/p\u003e\n\u003cp\u003eDiese Architektur ist technisch notwendig, wenn eine WAF HTTP-Methoden, Header, Cookies oder Request-Bodies prüfen soll. Eine WAF kann verschlüsselten Inhalt ohne Entschlüsselung nicht sinnvoll bewerten. Gleichzeitig entsteht an der Edge eine neue Vertrauensgrenze: Der entschlüsselte Datenverkehr liegt dort im Klartext vor und muss innerhalb der Plattform entsprechend verarbeitet und weitergeleitet werden.\u003c/p\u003e\n\u003cp\u003eFür das Backend folgt daraus eine klare Prüfpflicht. Die Absicherung der Client-zu-Edge-Verbindung sagt nichts über die Verbindung von der Edge zum Backend aus. Diese Strecke benötigt eine eigene Transport- und Vertrauensentscheidung. TLS Termination reduziert also nicht automatisch jedes Backend-Risiko; sie verschiebt einen Teil der Sicherheitsverantwortung an einen definierten Übergabepunkt.\u003c/p\u003e\n\u003ch2 id=\"2-die-waf-arbeitet-auf-der-anwendungsschicht\"\u003e2. Die WAF arbeitet auf der Anwendungsschicht\u003c/h2\u003e\n\u003cp\u003eEine WAF schützt HTTP- und HTTPS-Services, indem sie Requests anhand von Eigenschaften der Anwendungsschicht bewertet. Dazu zählen beispielsweise Methoden, Pfade, Header, Parameter oder typische Angriffsmuster. Ihre Stärke liegt dort, wo Netzwerk- und Transportschutz nicht ausreichen: bei missbrauchbaren Requests, unerwarteten Eingaben und bekannten Angriffsmustern gegen Webanwendungen.\u003c/p\u003e\n\u003cp\u003eDie WAF ist jedoch keine Ersatzinstanz für TLS und kein vollständiger Schutz des Backends. Sie kann nur Daten prüfen, die sie tatsächlich erreicht und interpretieren kann. Protokollabweichungen, unklare Header-Weitergabe oder fehlerhafte TLS-Konfigurationen können deshalb die Analyse beeinflussen. Ebenso bleiben fachliche Fehler möglich, wenn ein Request technisch korrekt aussieht, aber gegen die Geschäftslogik verstößt.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud liegt die WAF vor den eigentlichen Backends und kann mit der TLS Termination an der Edge verbunden werden. Damit entsteht ein zentraler Prüfpunkt vor der Compute-Infrastruktur. Die Anwendung bleibt dennoch für Authentifizierung, Autorisierung, Eingabevalidierung und sichere Verarbeitung verantwortlich.\u003c/p\u003e\n\u003ch2 id=\"3-backend-sicherheit-beginnt-hinter-der-waf\"\u003e3. Backend-Sicherheit beginnt hinter der WAF\u003c/h2\u003e\n\u003cp\u003eDas Backend darf nicht als passiver Empfänger bereits geprüfter Requests betrachtet werden. Es muss seine eigenen Sicherheitsannahmen validieren: Identitäten und Berechtigungen sind zu prüfen, Eingaben müssen kontextbezogen validiert werden, und sensible Operationen benötigen serverseitige Kontrollen. Eine WAF kann Angriffsindikatoren erkennen, aber keine fachliche Autorisierung ersetzen.\u003c/p\u003e\n\u003cp\u003eBesonders relevant ist die Frage, welche Header und Quellinformationen an das Backend weitergegeben werden. Werden Client-IP, Host oder Protokollinformationen für Logging, Rate Limits oder Sicherheitsentscheidungen verwendet, muss ihre Herkunft eindeutig sein. Der \u003cstrong\u003eProxy Protocol\u003c/strong\u003e-Mechanismus kann solche Verbindungsinformationen strukturiert an nachgelagerte Systeme übertragen. Das Backend muss dieses Protokoll jedoch korrekt unterstützen und darf unvalidierte Header nicht als vertrauenswürdig behandeln.\u003c/p\u003e\n\u003cp\u003eZusätzlich sollte das Backend nicht direkt öffentlich erreichbar sein, wenn der gesamte externe Traffic über die Edge geführt werden soll. Backend Cloaking reduziert diese Angriffsfläche, indem die internen Ziele nicht als öffentlicher Einstiegspunkt dienen. Health Checks und Failover helfen beim Betrieb, ersetzen aber weder Zugriffskontrollen noch die Absicherung der Backend-Verbindung.\u003c/p\u003e\n\u003ch2 id=\"4-übergabepunkte-bestimmen-die-verbleibenden-risiken\"\u003e4. Übergabepunkte bestimmen die verbleibenden Risiken\u003c/h2\u003e\n\u003cp\u003eJede Schicht kann nur ihre eigene Sicht auf den Traffic bewerten. Zwischen Client, Edge und Backend entstehen deshalb Übergabepunkte, an denen Protokolle beendet, Informationen ergänzt oder Sicherheitsentscheidungen weitergereicht werden. Genau dort liegen häufig die schwer erkennbaren Fehlkonfigurationen.\u003c/p\u003e\n\u003cp\u003eEin typisches Beispiel ist die unterschiedliche Interpretation von URL-Pfaden oder Headern an Edge, WAF und Anwendung. Wenn die WAF eine Anfrage anders normalisiert als das Backend, kann ein Request an der Schutzschicht unauffällig erscheinen, aber im Backend eine andere Bedeutung erhalten. Ähnliche Risiken entstehen durch nicht konsistente TLS-, Host- oder Proxy-Protocol-Annahmen.\u003c/p\u003e\n\u003cp\u003eEine belastbare Security-Schichtenarchitektur dokumentiert daher für jede Strecke: Wer terminiert TLS? Welche Instanz sieht den Klartext? Welche Informationen werden weitergegeben? Welche Quelle gilt als vertrauenswürdig? Und welche Prüfung erfolgt erst im Backend? In der ayedo Edge Cloud lassen sich öffentliche Routing-, Schutz- und Weiterleitungsfunktionen zentral vor den Workloads bündeln. Die konkrete Sicherheitsqualität hängt jedoch von der konsistenten Konfiguration aller beteiligten Schichten ab.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei einem Cloud-Provider. Der öffentliche DNS-Eintrag zeigt auf die ayedo Edge Cloud. Dort endet TLS, die WAF prüft die HTTP-Anfragen und der Traffic wird anschließend an das Backend weitergeleitet. Das Backend ist nicht direkt öffentlich exponiert und akzeptiert nur den vorgesehenen Weiterleitungspfad.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb müssen nun mehrere Punkte getrennt überwacht werden: Zertifikatsstatus und TLS-Fehler an der Edge, blockierte oder auffällige Requests in der WAF sowie Authentifizierungs- und Autorisierungsfehler in der API. Fällt ein Backend aus, können Health Checks die Weiterleitung beeinflussen. Sie sagen jedoch nichts darüber aus, ob die Anwendung fachlich korrekt oder sicher arbeitet. Erst die getrennte Betrachtung macht die Ursache eines Fehlers sichtbar.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"schützt-tls-termination-auch-die-verbindung-zum-backend\"\u003eSchützt TLS Termination auch die Verbindung zum Backend?\u003c/h3\u003e\n\u003cp\u003eNein. TLS Termination schützt die Verbindung bis zum TLS-Endpunkt an der Edge. Die Strecke zwischen Edge und Backend muss separat bewertet und entsprechend den Schutzanforderungen der Anwendung abgesichert werden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-eine-waf-die-validierung-im-backend\"\u003eErsetzt eine WAF die Validierung im Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Eine WAF erkennt bestimmte HTTP-basierte Angriffsmuster. Fachliche Autorisierung, Eingabevalidierung, Geschäftslogik und der Schutz sensibler Daten bleiben Aufgaben der Anwendung.\u003c/p\u003e\n\u003ch3 id=\"warum-sind-übergabepunkte-sicherheitsrelevant\"\u003eWarum sind Übergabepunkte sicherheitsrelevant?\u003c/h3\u003e\n\u003cp\u003eAn Übergabepunkten werden Verbindungen beendet, Informationen weitergereicht oder Protokolle interpretiert. Abweichende Annahmen zwischen Edge, WAF und Backend können dadurch Schutzmechanismen unwirksam machen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine \u003cstrong\u003eSecurity-Schichtenarchitektur\u003c/strong\u003e ist kein einzelnes Produktfeature, sondern eine klare Verteilung von Sicherheitsaufgaben. TLS schützt den Transport bis zur definierten Termination, die WAF bewertet HTTP-Anfragen und das Backend trägt die Verantwortung für Identität, Geschäftslogik und Daten. Die ayedo Edge Cloud kann diese vorgelagerten Funktionen zentral bündeln und Backends providerunabhängig anbinden. Entscheidend bleibt, die Übergabepunkte explizit zu gestalten und jedes verbleibende Risiko einer konkreten Schicht zuzuordnen.\u003c/p\u003e\n", "summary": "\nTL;DR Eine belastbare Security-Schichtenarchitektur verteilt Schutzaufgaben auf unterschiedliche Ebenen: TLS schützt die Transportverbindung, die WAF bewertet HTTP-Anfragen und das Backend bleibt für Autorisierung, Validierung und Datenschutz verantwortlich. Entscheidend sind die Übergabepunkte zwischen diesen Schichten. Jede Entschlüsselung, Weiterleitung und Protokollumwandlung erzeugt dabei eigene Vertrauens- und Betriebsanforderungen.\nEinleitung TLS, WAF und Backend werden in der Praxis häufig als ein zusammenhängender Schutzmechanismus behandelt. Das führt zu einer problematischen Annahme: Ist TLS aktiv und eine WAF vorgeschaltet, sei die Anwendung automatisch ausreichend abgesichert. Tatsächlich erfüllen die drei Komponenten unterschiedliche Aufgaben und sehen jeweils nur einen Teil des Datenverkehrs. TLS schützt primär den Transportweg, die WAF analysiert Anwendungsanfragen und das Backend muss Geschäftslogik, Identitäten und Daten selbst absichern. Eine Security-Schichtenarchitektur ist deshalb vor allem eine Frage sauber definierter Zuständigkeiten, Übergabepunkte und verbleibender Risiken.\n", "image": "https://ayedo.de/tls-waf-und-backend-eine-schichtenarchitektur.png", "date_published": "2026-09-08T17:10:08Z", "date_modified": "2026-09-08T17:10:08Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","digital-sovereignty","kubernetes","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/backend-cloaking-als-baustein-der-edge-security/", "url": "https://ayedo.de/posts/backend-cloaking-als-baustein-der-edge-security/", "title": "Backend Cloaking als Baustein der Edge-Security", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-cloaking-als-baustein-der-edge-security/backend-cloaking-als-baustein-der-edge-security.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking reduziert die direkte öffentliche Erreichbarkeit von Ursprungsdiensten, indem Clients nicht unmittelbar mit den Backends kommunizieren. Das senkt die öffentliche Angriffsfläche, ersetzt aber weder WAF-Regeln noch Anwendungsschutz. Entscheidend sind sauberes Routing, kontrollierte Backend-Zugriffe und ein Betriebsmodell für Health Checks und Failover.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin öffentlich erreichbarer Ursprungsserver ist nicht nur ein technisches Ziel für legitime Requests, sondern auch eine zusätzliche Angriffsfläche. Selbst wenn der gesamte reguläre Traffic über eine Edge-Plattform läuft, kann eine bekannte oder falsch veröffentlichte Backend-Adresse direkte Zugriffe ermöglichen. Backend Cloaking setzt an diesem Problem an: Die Anwendung wird über die Edge adressiert, während die Ursprungsdienste nicht mehr als primärer öffentlicher Einstiegspunkt dienen. Damit verändert sich jedoch auch das Routingmodell. Backends müssen Anfragen aus der Edge verarbeiten, Zustände korrekt bewerten und Ausfälle melden können. Cloaking ist deshalb eine eigenständige Security-Maßnahme – aber keine vollständige Sicherheitsarchitektur.\u003c/p\u003e\n\u003ch2 id=\"backend-cloaking-reduziert-den-direkten-zugriffspfad\"\u003eBackend Cloaking reduziert den direkten Zugriffspfad\u003c/h2\u003e\n\u003cp\u003eBeim Backend Cloaking wird die öffentliche Verbindung zwischen Client und Anwendung an der Edge terminiert. Der Client kommuniziert mit der Edge-Adresse; diese leitet den Traffic anschließend an ein definiertes Backend weiter. Die Origin-Adresse muss dabei nicht als öffentlich sichtbares Ziel der Anwendung verwendet werden. Für den Client entsteht ein einheitlicher Zugangspunkt, während die eigentlichen Ursprungsdienste hinter der Edge liegen.\u003c/p\u003e\n\u003cp\u003eDiese Trennung reduziert die öffentliche Angriffsfläche auf Netzwerkebene. Direkte Scans, unkontrollierte Zugriffe auf Origin-Adressen oder der Versuch, die Edge-Verarbeitung zu umgehen, werden erschwert. Voraussetzung ist allerdings, dass Backends nicht weiterhin uneingeschränkt aus dem Internet erreichbar sind. Cloaking verliert einen wesentlichen Teil seiner Wirkung, wenn die Origin-Adresse bekannt bleibt und jeder Absender dort Verbindungen aufbauen kann.\u003c/p\u003e\n\u003cp\u003eIm Kontext der ayedo Edge Cloud ist Backend Cloaking Teil der vorgelagerten Edge-Funktionen. Anycast-basiertes Layer-4- und Layer-7-Loadbalancing nimmt den öffentlichen Traffic auf und verteilt ihn an die konfigurierten Backends. Die Edge ist damit nicht bloß ein zusätzlicher Proxy, sondern der kontrollierte öffentliche Eingang vor den Ursprungsdiensten.\u003c/p\u003e\n\u003ch2 id=\"routing-erreichbarkeit-und-failover-müssen-zusammenpassen\"\u003eRouting, Erreichbarkeit und Failover müssen zusammenpassen\u003c/h2\u003e\n\u003cp\u003eCloaking verändert die Frage, wie ein Backend erreichbar ist. Der Dienst muss Verbindungen aus der Edge annehmen können, darf aber nicht unkontrolliert als direkter Internet-Endpunkt dienen. In der Praxis sind dafür abgestimmte Netzwerkregeln, Routingpfade und Zuständigkeiten erforderlich. Besonders wichtig ist die Unterscheidung zwischen der Adresse, die Clients erreichen, und dem Ziel, zu dem die Edge intern weiterleitet.\u003c/p\u003e\n\u003cp\u003eAuch Health Checks sind Teil dieses Modells. Ein Backend kann aus Sicht des Netzwerks erreichbar sein, während die Anwendung selbst keine Requests mehr korrekt verarbeitet. Werden solche Zustände nicht erkannt, verteilt die Edge weiterhin Traffic an einen technisch verfügbaren, aber funktional gestörten Dienst. Backend Health Checks und Failover müssen deshalb zur Anwendung, zum Deployment-Modell und zu den erwarteten Fehlerbildern passen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt Backend Health Checks und Failover sowie eine Aktiv-Aktiv-Architektur über eine verteilte Multi-PoP-Infrastruktur. Das beseitigt nicht die Notwendigkeit einer passenden Backend-Konfiguration. Es schafft jedoch die Grundlage, den öffentlichen Einstieg und die Weiterleitung zu den Ursprüngen unabhängig von einem einzelnen Edge- oder Backend-Pfad zu betreiben.\u003c/p\u003e\n\u003ch2 id=\"cloaking-ersetzt-weder-waf-noch-anwendungsschutz\"\u003eCloaking ersetzt weder WAF noch Anwendungsschutz\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking schützt primär den Zugangspfad zum Ursprung. Es entscheidet nicht automatisch, ob ein HTTP-Request fachlich zulässig ist, ob ein Benutzer authentifiziert ist oder ob ein Payload eine Schwachstelle ausnutzt. Ein Angreifer kann einen Dienst weiterhin über die Edge erreichen und dort gültig aussehende, aber schädliche Requests senden. Genau deshalb darf Cloaking nicht mit vollständigem Anwendungsschutz gleichgesetzt werden.\u003c/p\u003e\n\u003cp\u003eEine WAF ergänzt das Routingmodell um Regeln für HTTP- und HTTPS-Services. Sie kann beispielsweise Anfragen anhand von Protokollmerkmalen, Pfaden oder bekannten Angriffsmustern bewerten. DDoS Protection adressiert wiederum volumetrische oder protokollbezogene Überlastung an der Edge. Diese Schichten verfolgen unterschiedliche Ziele: Cloaking reduziert direkte Origin-Erreichbarkeit, die WAF prüft Anwendungstraffic, und DDoS-Schutz begrenzt bestimmte Angriffsformen vor dem Backend.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud können diese Funktionen in einer gemeinsamen Edge-Plattform zusammenspielen. TLS Termination, WAF und DDoS Protection liegen dabei vor dem Ursprung. Die Sicherheitswirkung entsteht nicht durch eine einzelne Funktion, sondern durch die klare Trennung der Aufgaben und eine Konfiguration, die den vorgesehenen Pfad tatsächlich erzwingt.\u003c/p\u003e\n\u003ch2 id=\"betriebsmodell-und-verantwortungsgrenzen-klar-definieren\"\u003eBetriebsmodell und Verantwortungsgrenzen klar definieren\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking verschiebt Verantwortung, es entfernt sie nicht. Teams müssen festlegen, wer DNS-Einträge, Edge-Routing, Backend-Freigaben, Zertifikate und Health-Check-Endpunkte betreibt. Änderungen am Origin dürfen nicht isoliert erfolgen, wenn sie Erreichbarkeit, Quelladressierung oder Failover beeinflussen. Besonders bei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen ist wichtig, die Edge nicht mit dem Cluster-Eingang gleichzusetzen: Die Edge Cloud übernimmt den öffentlichen Traffic-Eingang, während der Cluster die Workloads ausführt.\u003c/p\u003e\n\u003cp\u003eFür Diagnose und Zugriffskontrolle müssen außerdem Quellinformationen nachvollziehbar bleiben. Je nach Routingmodell kann Proxy Protocol relevant sein, wenn ein Backend die ursprüngliche Client-Adresse oder Verbindungsinformationen benötigt. Das muss mit den verwendeten Proxies, Firewalls und Anwendungen kompatibel sein. Werden Quelladressen falsch interpretiert, entstehen fehlerhafte Rate Limits, unbrauchbare Logs oder unnötige Freigaben.\u003c/p\u003e\n\u003cp\u003eEin weiterer Vorteil des Modells ist die providerunabhängige Nutzung. Die ayedo Edge Cloud kann mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ebenso wie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden. Dadurch bleibt die Edge als eigenständiger Sicherheits- und Routingbereich bestehen, auch wenn sich die Compute-Infrastruktur ändert.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster bei einem externen Cloud-Provider. Ohne Cloaking zeigt ein DNS-Eintrag direkt auf einen öffentlichen Loadbalancer des Clusters. Die Edge Cloud wird später vorgeschaltet, der alte Endpunkt bleibt jedoch erreichbar. Ein Angreifer kann dadurch WAF- und Rate-Limit-Regeln umgehen.\u003c/p\u003e\n\u003cp\u003eMit Backend Cloaking zeigt der öffentliche DNS-Eintrag nur noch auf die Edge. Das Backend akzeptiert Verbindungen ausschließlich über den vorgesehenen Edge-Pfad und meldet seinen Anwendungszustand über passende Health Checks. Die Edge verteilt Requests auf verfügbare Backends. Die WAF bleibt für die Prüfung des HTTP-Traffics zuständig; Cloaking reduziert lediglich den direkten Origin-Zugriff.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"verbirgt-backend-cloaking-die-origin-adresse-vollständig\"\u003eVerbirgt Backend Cloaking die Origin-Adresse vollständig?\u003c/h3\u003e\n\u003cp\u003eNein. Adressen können durch Fehlkonfigurationen, Leaks oder externe Informationen bekannt werden. Cloaking reduziert die direkte Nutzbarkeit, ersetzt aber keine restriktiven Netzwerkregeln und kein sorgfältiges Asset- und DNS-Management.\u003c/p\u003e\n\u003ch3 id=\"ist-backend-cloaking-nur-für-kubernetes-relevant\"\u003eIst Backend Cloaking nur für Kubernetes relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Das Prinzip gilt für alle öffentlich erreichbaren Anwendungen und APIs. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bietet zusätzliche Routing- und Betriebsvarianten, ist aber keine Voraussetzung für die Trennung zwischen Edge und Backend.\u003c/p\u003e\n\u003ch3 id=\"muss-die-anwendung-für-cloaking-angepasst-werden\"\u003eMuss die Anwendung für Cloaking angepasst werden?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Sie muss jedoch mit dem Edge-Routing, TLS-Modell, Health Checks und gegebenenfalls Proxy Protocol kompatibel sein. Logging, Client-IP-Auswertung und Access Controls sollten gezielt geprüft werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking ist eine klar abgegrenzte Maßnahme zur Reduktion der öffentlichen Angriffsfläche. Es schützt den Ursprung, indem es ihn aus dem direkten öffentlichen Zugriffspfad nimmt, löst aber keine Probleme auf Anwendungsebene. Wirksam wird das Modell erst durch abgestimmtes Routing, restriktive Backend-Erreichbarkeit, belastbare Health Checks und ergänzende Edge-Security wie WAF und DDoS Protection. Die ayedo Edge Cloud ordnet diese Aufgaben in einer eigenständigen, providerunabhängigen Edge-Plattform ein.\u003c/p\u003e\n", "summary": "\nTL;DR Backend Cloaking reduziert die direkte öffentliche Erreichbarkeit von Ursprungsdiensten, indem Clients nicht unmittelbar mit den Backends kommunizieren. Das senkt die öffentliche Angriffsfläche, ersetzt aber weder WAF-Regeln noch Anwendungsschutz. Entscheidend sind sauberes Routing, kontrollierte Backend-Zugriffe und ein Betriebsmodell für Health Checks und Failover.\nEinleitung Ein öffentlich erreichbarer Ursprungsserver ist nicht nur ein technisches Ziel für legitime Requests, sondern auch eine zusätzliche Angriffsfläche. Selbst wenn der gesamte reguläre Traffic über eine Edge-Plattform läuft, kann eine bekannte oder falsch veröffentlichte Backend-Adresse direkte Zugriffe ermöglichen. Backend Cloaking setzt an diesem Problem an: Die Anwendung wird über die Edge adressiert, während die Ursprungsdienste nicht mehr als primärer öffentlicher Einstiegspunkt dienen. Damit verändert sich jedoch auch das Routingmodell. Backends müssen Anfragen aus der Edge verarbeiten, Zustände korrekt bewerten und Ausfälle melden können. Cloaking ist deshalb eine eigenständige Security-Maßnahme – aber keine vollständige Sicherheitsarchitektur.\n", "image": "https://ayedo.de/backend-cloaking-als-baustein-der-edge-security.png", "date_published": "2026-09-08T17:10:07Z", "date_modified": "2026-09-08T17:10:07Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend/", "url": "https://ayedo.de/posts/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend/", "title": "DDoS-Schutz an der Edge und seine Grenzen im Backend", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDDoS-Schutz an der Edge reduziert volumetrischen und netzwerkseitigen Angriffsdruck, bevor er die öffentliche Infrastruktur eines Unternehmens erreicht. Scrubbing schützt damit den Eingang zu Anwendungen und APIs. Es ersetzt jedoch weder Backend-Sicherheit noch Authentisierung, Ressourcenlimits oder fachliche Prüfungen gegen missbräuchliche Nutzung.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDDoS-Schutz scheitert häufig nicht an fehlender Filterleistung, sondern an einer falschen Abgrenzung der Schutzschichten. Ein Angriff kann am Netzwerkrand wirksam gebremst werden und trotzdem Backend-Ressourcen erschöpfen, wenn jede gültige Anfrage aufwendige Verarbeitung auslöst. Umgekehrt ist ein Backend kaum in der Lage, große Mengen unerwünschten Traffics wirtschaftlich und stabil selbst zu verarbeiten. Die zentrale Architekturentscheidung lautet deshalb nicht „Edge oder Backend“, sondern: Welche Art von Belastung wird an welcher Stelle erkannt und behandelt? DDoS Protection und Scrubbing an der Edge adressieren vor allem den öffentlichen Eingang. Authentisierung, Autorisierung und fachlicher Missbrauch bleiben Aufgaben der Anwendung.\u003c/p\u003e\n\u003ch2 id=\"1-was-ddos-schutz-an-der-edge-leisten-kann\"\u003e1. Was DDoS-Schutz an der Edge leisten kann\u003c/h2\u003e\n\u003cp\u003eEin DDoS-Angriff zielt zunächst häufig auf Verfügbarkeit: Leitungen, Netzwerkkomponenten, Loadbalancer oder Server sollen durch hohe Anfrage- oder Paketmengen beeinträchtigt werden. Eine Edge-Plattform kann diesen Druck abfangen, bevor die eigentlichen Backends erreicht werden. DDoS Protection und Scrubbing analysieren eingehenden Traffic und filtern unerwünschte Muster möglichst nahe am öffentlichen Eingang.\u003c/p\u003e\n\u003cp\u003eBei einer verteilten Edge-Architektur wird der Traffic nicht erst an einen einzelnen Standort weitergeleitet. Die ayedo Edge Cloud nutzt dafür eine Anycast-basierte, verteilte Infrastruktur mit eigenem Autonomous System und Aktiv-Aktiv-Prinzip. Das ist kein Beleg dafür, dass jeder Angriff automatisch gelöst wird. Es schafft jedoch eine Architektur, in der Schutz- und Routingfunktionen vor den Backends angesiedelt sind und nicht ausschließlich von deren eigener Kapazität abhängen.\u003c/p\u003e\n\u003ch2 id=\"2-warum-scrubbing-den-öffentlichen-eingang-schützt\"\u003e2. Warum Scrubbing den öffentlichen Eingang schützt\u003c/h2\u003e\n\u003cp\u003eScrubbing erfüllt eine andere Aufgabe als ein Sicherheitsmechanismus innerhalb der Anwendung. Ziel ist, schädlichen oder nicht erwünschten Traffic aus dem Datenstrom zu entfernen, bevor er Netzwerkpfade und Ressourcen der Backend-Umgebung belastet. Das betrifft insbesondere volumetrische Angriffe sowie bestimmte netzwerk- oder protokollbezogene Belastungen.\u003c/p\u003e\n\u003cp\u003eDie Wirkung entsteht durch die Position der Schutzfunktion. Wenn DNS, Routing, Lastverteilung und DDoS-Abwehr an der Edge zusammenwirken, bleibt der öffentliche Eingang von Anwendungen und APIs unter zentraler Kontrolle. Die Backends müssen dann nicht jede eintreffende Verbindung selbst annehmen und verarbeiten. Backend Cloaking verstärkt diese Trennung: Die eigentlichen Ursprungsadressen müssen nicht öffentlich als direkte Angriffspunkte sichtbar sein.\u003c/p\u003e\n\u003cp\u003eDiese Architektur reduziert den Angriffsraum, beseitigt ihn aber nicht. Auch nach dem Scrubbing gelangen legitime Anfragen weiter. Für diese muss das Backend weiterhin ausreichende Kapazität, geeignete Timeouts und kontrollierte Verarbeitung bereitstellen.\u003c/p\u003e\n\u003ch2 id=\"3-wo-edge-schutz-an-grenzen-stößt\"\u003e3. Wo Edge-Schutz an Grenzen stößt\u003c/h2\u003e\n\u003cp\u003eNicht jede schädliche Anfrage ist auf Netzwerkebene als Angriff erkennbar. Ein Angreifer kann gültige TCP-Verbindungen aufbauen, korrekte HTTP-Anfragen senden und sich sogar erfolgreich authentisieren. Technisch sieht der Traffic dann zunächst wie reguläre Nutzung aus. DDoS-Schutz an der Edge kann solche Anfragen nicht anhand ihrer fachlichen Absicht zuverlässig bewerten.\u003c/p\u003e\n\u003cp\u003eDie nächste Grenze liegt bei Ressourcenerschöpfung durch teure Operationen. Eine einzelne gültige API-Anfrage kann beispielsweise Datenbankabfragen, externe Aufrufe oder komplexe Berechnungen auslösen. Werden solche Anfragen in hoher Zahl gestellt, entsteht ein Application-Layer-Problem. Schutzmechanismen wie Rate Limits, Quotas, Concurrency-Limits, Caching, Backpressure und gezielte Kontingente müssen dort greifen, wo die fachliche Bedeutung bekannt ist.\u003c/p\u003e\n\u003cp\u003eAuch Authentisierung und Autorisierung bleiben Backend-Aufgaben. Die Edge kann den Eingang schützen und HTTP-/HTTPS-Services über eine WAF absichern. Sie entscheidet jedoch nicht automatisch, ob ein authentisierter Nutzer eine bestimmte Ressource fachlich missbraucht.\u003c/p\u003e\n\u003ch2 id=\"4-backend-sicherheit-als-zweite-schutzebene\"\u003e4. Backend-Sicherheit als zweite Schutzebene\u003c/h2\u003e\n\u003cp\u003eBackend-Sicherheit beginnt mit der Annahme, dass Edge-Schutz keine Vertrauensgrenze für die Anwendung ersetzt. Anwendungen müssen eingehende Identitäten, Berechtigungen und Eingabeparameter selbst prüfen. Zusätzlich sollten sie Ressourcen pro Nutzer, Mandant, API-Key oder Client begrenzen. So lässt sich verhindern, dass ein gültiger Zugang unkontrolliert große Mengen an Verarbeitung auslöst.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb sind messbare Schutzgrenzen entscheidend: maximale Request-Dauer, Queue-Größe, Verbindungslimits, Fehlerquoten und kontrollierte Abbruchbedingungen. Health Checks und Failover helfen dabei, nicht verfügbare Backends aus dem Traffic zu nehmen. Sie verhindern allerdings keine fachlich gültigen, aber schädlichen Requests. Wird ein Backend auf mehrere Cluster oder Provider verteilt, kann die Edge den öffentlichen Traffic providerunabhängig zuführen und verteilen. Die Sicherheitslogik innerhalb dieser Ziele muss dennoch konsistent umgesetzt werden.\u003c/p\u003e\n\u003cp\u003eWirtschaftlich ist die Trennung ebenfalls relevant. Edge-Scrubbing kann verhindern, dass unnötiger Traffic teure Netzwerk- und Compute-Ressourcen verbraucht. Investitionen in Anwendungsschutz bleiben trotzdem erforderlich, weil ein kleinerer, aber fachlich teurer Angriff weiterhin Kosten und Betriebsrisiken erzeugen kann.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche API auf einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster. Ein volumetrischer Angriff erzeugt große Mengen unerwünschter Pakete und HTTP-Anfragen. Ohne vorgeschaltete Edge-Schutzschicht müssen Cluster, Ingress und Provideranbindung den Angriffsverkehr zumindest teilweise aufnehmen. Mit DDoS Protection und Scrubbing an der ayedo Edge Cloud wird der öffentliche Eingang vor dem Backend geschützt; nur bereinigter Traffic wird weitergeleitet.\u003c/p\u003e\n\u003cp\u003eSpäter nutzt ein Angreifer gültige Zugangsdaten, um wiederholt eine kostenintensive Suchfunktion aufzurufen. Dieser Traffic ist fachlich plausibel und passiert die Edge. Erst Rate Limits pro Identität, ein Request-Budget und eine Begrenzung paralleler Suchvorgänge im Backend verhindern die Ressourcenerschöpfung. Beide Schutzebenen lösen unterschiedliche Probleme.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"schützt-ddos-schutz-an-der-edge-automatisch-jede-api-anwendung\"\u003eSchützt DDoS-Schutz an der Edge automatisch jede API-Anwendung?\u003c/h3\u003e\n\u003cp\u003eNein. Er reduziert vor allem unerwünschten Traffic am öffentlichen Eingang. Authentisierung, Autorisierung, Rate Limits und fachliche Missbrauchsregeln müssen weiterhin in API und Backend umgesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"was-ist-der-unterschied-zwischen-scrubbing-und-einer-waf\"\u003eWas ist der Unterschied zwischen Scrubbing und einer WAF?\u003c/h3\u003e\n\u003cp\u003eScrubbing adressiert primär schädlichen oder übermäßigen Traffic auf Netzwerk- und Transportebene. Eine WAF untersucht HTTP-/HTTPS-Anfragen und kann anwendungsnahe Angriffsmuster filtern. Beide Funktionen liegen vor dem Backend, verfolgen aber unterschiedliche Schutzaufgaben.\u003c/p\u003e\n\u003ch3 id=\"reicht-backend-sicherheit-ohne-edge-schutz-aus\"\u003eReicht Backend-Sicherheit ohne Edge-Schutz aus?\u003c/h3\u003e\n\u003cp\u003eBei kleinen Angriffen möglicherweise, als verlässliche Architektur jedoch selten. Das Backend muss den Traffic zunächst erreichen und verarbeiten. Edge-Schutz reduziert diese Vorlast; die Anwendung benötigt dennoch eigene Sicherheits- und Begrenzungsmechanismen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDDoS-Schutz an der Edge und Backend-Sicherheit sind keine konkurrierenden Maßnahmen. Die Edge schützt den öffentlichen Eingang, filtert volumetrischen Druck und hält unerwünschten Traffic möglichst von Netzwerk- und Compute-Ressourcen fern. Das Backend bewertet dagegen Identitäten, Berechtigungen und fachliche Kosten einer Anfrage. Die ayedo Edge Cloud ist in diesem Modell die vorgelagerte, verteilte Schutz- und Routingplattform; ihre Wirkung entsteht zusammen mit belastbaren Grenzen innerhalb der Anwendungen.\u003c/p\u003e\n", "summary": "\nTL;DR DDoS-Schutz an der Edge reduziert volumetrischen und netzwerkseitigen Angriffsdruck, bevor er die öffentliche Infrastruktur eines Unternehmens erreicht. Scrubbing schützt damit den Eingang zu Anwendungen und APIs. Es ersetzt jedoch weder Backend-Sicherheit noch Authentisierung, Ressourcenlimits oder fachliche Prüfungen gegen missbräuchliche Nutzung.\nEinleitung DDoS-Schutz scheitert häufig nicht an fehlender Filterleistung, sondern an einer falschen Abgrenzung der Schutzschichten. Ein Angriff kann am Netzwerkrand wirksam gebremst werden und trotzdem Backend-Ressourcen erschöpfen, wenn jede gültige Anfrage aufwendige Verarbeitung auslöst. Umgekehrt ist ein Backend kaum in der Lage, große Mengen unerwünschten Traffics wirtschaftlich und stabil selbst zu verarbeiten. Die zentrale Architekturentscheidung lautet deshalb nicht „Edge oder Backend“, sondern: Welche Art von Belastung wird an welcher Stelle erkannt und behandelt? DDoS Protection und Scrubbing an der Edge adressieren vor allem den öffentlichen Eingang. Authentisierung, Autorisierung und fachlicher Missbrauch bleiben Aufgaben der Anwendung.\n", "image": "https://ayedo.de/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend.png", "date_published": "2026-09-08T17:10:07Z", "date_modified": "2026-09-08T17:10:07Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","security","development","operations","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/posts/tls-termination-an-der-edge-architektonisch-planen/", "url": "https://ayedo.de/posts/tls-termination-an-der-edge-architektonisch-planen/", "title": "TLS Termination an der Edge architektonisch planen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-termination-an-der-edge-architektonisch-planen/tls-termination-an-der-edge-architektonisch-planen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eTLS Termination an der Edge verkürzt den Weg von Client zu geschütztem Einstiegspunkt, verschiebt aber Verantwortlichkeiten. Zertifikate, Vertrauensgrenzen und Backend-Verbindungen müssen deshalb getrennt geplant werden. Die zentrale Frage lautet nicht, ob TLS am öffentlichen Eingang endet, sondern welche Verbindungen danach weiterhin verschlüsselt und wie ihre Identitäten geprüft werden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eTLS Termination am öffentlichen Eingang ist keine rein technische Optimierung. Sie legt fest, wo Zertifikate verwaltet werden, welche Komponente HTTP-Anfragen entschlüsseln darf und welche Vertrauensgrenzen zwischen Edge und Backend entstehen. Ein häufiger Architekturfehler besteht darin, die Verschlüsselung bis zur Edge zu planen und die interne Weiterleitung anschließend als automatisch vertrauenswürdig zu behandeln. Damit wird aus einer klaren äußeren Schutzgrenze schnell eine unkontrollierte interne Zone. Eine belastbare TLS-Architektur trennt daher drei Fragen: Wo endet die öffentliche TLS-Verbindung? Wie wird die Verbindung zum Backend geschützt? Und welche Komponente trägt jeweils Verantwortung für Identität, Verschlüsselung und Zugriffskontrolle?\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-verschiebt-die-vertrauensgrenze\"\u003e1. TLS Termination verschiebt die Vertrauensgrenze\u003c/h2\u003e\n\u003cp\u003eBei einer TLS-Terminierung an der ayedo Edge Cloud endet die Client-Verbindung nicht am Anwendungsserver, sondern an der verteilten Edge-Infrastruktur. Dort werden Zertifikate präsentiert, der TLS-Handshake verarbeitet und der verschlüsselte Datenstrom für die weitere Verarbeitung zugänglich gemacht. Das ist architektonisch sinnvoll, weil WAF, Routing, Loadbalancing und Health Checks auf Anwendungsebene erst nach der Entschlüsselung möglich sind.\u003c/p\u003e\n\u003cp\u003eGleichzeitig wird die Edge zu einer bewusst definierten Vertrauenskomponente. Sie kann HTTP-Header, Pfade und Inhalte verarbeiten und muss deshalb in das Bedrohungsmodell aufgenommen werden. Das Zertifikat und der zugehörige private Schlüssel liegen nicht mehr ausschließlich in der Compute-Umgebung. Für Unternehmen bedeutet das: Zertifikatszugriff, Rollen, Rotation und Auditierbarkeit müssen für die Edge genauso geregelt sein wie für Ingress-Komponenten im Cluster. TLS Termination ist damit eine Entscheidung über Zuständigkeiten, nicht nur über Netzwerkpfade.\u003c/p\u003e\n\u003ch2 id=\"2-zertifikatsmanagement-zentralisieren-aber-zuständigkeiten-trennen\"\u003e2. Zertifikatsmanagement zentralisieren, aber Zuständigkeiten trennen\u003c/h2\u003e\n\u003cp\u003eDie zentrale Terminierung reduziert die Zahl der öffentlichen TLS-Endpunkte. Statt Zertifikate an mehreren Clustern, Ingress-Controllern oder Providern separat zu verteilen, kann der öffentliche Eingang konsistent an der Edge betrieben werden. Das vereinfacht Zertifikatsmanagement, Rotation und die Durchsetzung gemeinsamer TLS-Richtlinien. Besonders bei Multi-Cluster- oder Multi-Provider-Architekturen reduziert das operative Abhängigkeiten.\u003c/p\u003e\n\u003cp\u003eDiese Vereinfachung darf jedoch nicht mit einer einzigen globalen Zertifikatsverantwortung verwechselt werden. Öffentliche Zertifikate für Kundenzugriffe, interne Zertifikate für Backend-Verbindungen und gegebenenfalls dienstspezifische Identitäten erfüllen unterschiedliche Aufgaben. Ein Zertifikat für \u003ccode\u003eapi.example.com\u003c/code\u003e beweist nicht automatisch die Identität eines internen Services. Ebenso ersetzt zentrale Terminierung keine Kontrolle darüber, welcher Edge-Pfad welches Backend erreichen darf. Verantwortlichkeiten sollten deshalb nach Verbindung getrennt dokumentiert werden: Client zu Edge, Edge zu Backend und gegebenenfalls Service zu Service.\u003c/p\u003e\n\u003ch2 id=\"3-die-backend-verbindung-ist-eine-eigene-sicherheitsentscheidung\"\u003e3. Die Backend-Verbindung ist eine eigene Sicherheitsentscheidung\u003c/h2\u003e\n\u003cp\u003eNach der TLS Termination muss die Verbindung zum Backend separat bewertet werden. Eine unverschlüsselte Weiterleitung kann in einer streng kontrollierten, lokal begrenzten Umgebung vertretbar sein, setzt aber voraus, dass Netzwerkpfad, Zugriffsschutz und Datenklassifizierung diesen Vertrauensannahmen entsprechen. In verteilten Umgebungen, über Providergrenzen hinweg oder bei sensiblen Daten ist diese Annahme deutlich schwieriger zu begründen.\u003c/p\u003e\n\u003cp\u003eDie Alternative ist eine erneute TLS-Verbindung zwischen Edge und Backend. Damit bleibt der Datenverkehr auch nach der öffentlichen Terminierung verschlüsselt. Allerdings entstehen zusätzliche Anforderungen: Das Backend muss die Identität der Gegenstelle prüfen, Zertifikate müssen ausgestellt und rotiert werden, und Hostname sowie Zertifikatskette müssen zur Zielarchitektur passen. Die Edge kann dann zwar den öffentlichen TLS-Endpunkt bereitstellen, aber die Backend-Seite benötigt weiterhin ein eigenes Zertifikats- und Vertrauensmodell. Verschlüsselung allein genügt nicht; entscheidend ist, ob beide Seiten die erwartete Gegenstelle authentifizieren.\u003c/p\u003e\n\u003ch2 id=\"4-protokollierung-und-identität-müssen-die-terminierung-berücksichtigen\"\u003e4. Protokollierung und Identität müssen die Terminierung berücksichtigen\u003c/h2\u003e\n\u003cp\u003eTLS Termination verändert auch die technische Interpretation von Requests. Das Backend sieht als direkte Netzwerkverbindung nicht den ursprünglichen Client, sondern die Edge. Für Rate Limiting, Auditierung, Incident Response oder anwendungsbezogene Zugriffskontrolle müssen deshalb vertrauenswürdige Informationen zur ursprünglichen Verbindung korrekt weitergegeben und verarbeitet werden. Proxy Protocol kann dabei Netzwerkmetadaten transportieren; HTTP-Header benötigen eine klare Vertrauensregelung und dürfen nicht unkritisch aus beliebigen Quellen übernommen werden.\u003c/p\u003e\n\u003cp\u003eDiese Fragen gehören zur TLS-Architektur, weil eine verschlüsselte Verbindung nicht automatisch eine verlässliche Clientidentität liefert. Die Anwendung muss wissen, welche Informationen von der Edge stammen und welche sie selbst validieren muss. Gleichzeitig sollte Backend Cloaking verhindern, dass interne Ziele öffentlich erreichbar sind. Die ayedo Edge Cloud verbindet an diesem Punkt TLS Termination mit Backend-Schutz, Routing und Health Checks. Sie ersetzt jedoch nicht die Entscheidung, welche Identitäts- und Autorisierungsinformationen innerhalb der Anwendung gelten.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. Die ayedo Edge Cloud terminiert das öffentliche TLS, prüft den verfügbaren Backend-Pfad und verteilt Anfragen auf die gesunden Cluster. Variante A leitet innerhalb eines abgeschotteten Netzwerks unverschlüsselt weiter. Das reduziert Zertifikatsaufwand, erweitert aber die Vertrauenszone bis zum Backend. Variante B verwendet zwischen Edge und beiden Clustern erneut TLS. Dadurch bleiben Provider- und Clustergrenzen auch auf dem Transportweg geschützt, während zusätzliche Zertifikatsrotation und Backend-Validierung notwendig werden. Die Entscheidung sollte anhand von Datenklassifizierung, Netzwerkkontrolle, \u003ca href=\"https://compliance/\" target=\"_blank\" rel=\"noopener\"\u003eCompliance\u003c/a\u003e\n -Anforderungen und Betriebsfähigkeit getroffen werden, nicht anhand der bloßen Existenz einer Edge-Terminierung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-tls-termination-an-der-edge-automatisch-ende-zu-ende-verschlüsselung\"\u003eIst TLS Termination an der Edge automatisch Ende-zu-Ende-Verschlüsselung?\u003c/h3\u003e\n\u003cp\u003eNein. Die Client-Verbindung ist bis zur Edge verschlüsselt. Für eine durchgängige Verschlüsselung muss auch die Verbindung von der Edge zum Backend separat per TLS geschützt werden.\u003c/p\u003e\n\u003ch3 id=\"wer-verwaltet-die-zertifikate-nach-der-terminierung\"\u003eWer verwaltet die Zertifikate nach der Terminierung?\u003c/h3\u003e\n\u003cp\u003eDas hängt von der Architektur ab. Öffentliche Zertifikate liegen in der Verantwortung des Edge-Betriebs; interne Backend-Zertifikate bleiben Teil des jeweiligen Backend- und Plattformmodells.\u003c/p\u003e\n\u003ch3 id=\"kann-das-backend-weiterhin-den-ursprünglichen-client-erkennen\"\u003eKann das Backend weiterhin den ursprünglichen Client erkennen?\u003c/h3\u003e\n\u003cp\u003eNur über vertrauenswürdig weitergegebene Metadaten und eine passende Validierung. Die direkte TCP-Verbindung stammt von der Edge, nicht vom ursprünglichen Client.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eTLS Termination an der ayedo Edge Cloud schafft einen zentralen, verteilten öffentlichen TLS-Endpunkt und kann Zertifikatsmanagement über mehrere Backends hinweg vereinfachen. Sie definiert zugleich eine neue Vertrauensgrenze. Deshalb müssen Backend-Verschlüsselung, Identitätsprüfung, Metadatenweitergabe und Zugriffsschutz eigenständig geplant werden. Die richtige Architektur ist nicht pauschal „TLS an der Edge“ oder „TLS überall“, sondern eine dokumentierte Aufteilung der Verschlüsselungs- und Betriebsverantwortung.\u003c/p\u003e\n", "summary": "\nTL;DR TLS Termination an der Edge verkürzt den Weg von Client zu geschütztem Einstiegspunkt, verschiebt aber Verantwortlichkeiten. Zertifikate, Vertrauensgrenzen und Backend-Verbindungen müssen deshalb getrennt geplant werden. Die zentrale Frage lautet nicht, ob TLS am öffentlichen Eingang endet, sondern welche Verbindungen danach weiterhin verschlüsselt und wie ihre Identitäten geprüft werden.\nEinleitung TLS Termination am öffentlichen Eingang ist keine rein technische Optimierung. Sie legt fest, wo Zertifikate verwaltet werden, welche Komponente HTTP-Anfragen entschlüsseln darf und welche Vertrauensgrenzen zwischen Edge und Backend entstehen. Ein häufiger Architekturfehler besteht darin, die Verschlüsselung bis zur Edge zu planen und die interne Weiterleitung anschließend als automatisch vertrauenswürdig zu behandeln. Damit wird aus einer klaren äußeren Schutzgrenze schnell eine unkontrollierte interne Zone. Eine belastbare TLS-Architektur trennt daher drei Fragen: Wo endet die öffentliche TLS-Verbindung? Wie wird die Verbindung zum Backend geschützt? Und welche Komponente trägt jeweils Verantwortung für Identität, Verschlüsselung und Zugriffskontrolle?\n", "image": "https://ayedo.de/tls-termination-an-der-edge-architektonisch-planen.png", "date_published": "2026-09-08T17:10:07Z", "date_modified": "2026-09-08T17:10:07Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","kubernetes","security","operations","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle/", "url": "https://ayedo.de/posts/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle/", "title": "WAF an der Edge: Regeln, Grenzen und Betriebsmodelle", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine WAF an der Edge prüft HTTP- und HTTPS-Anfragen, bevor sie Backends erreichen. Sie eignet sich für protokoll- und anfragespezifische Muster wie Injection, unerlaubte Methoden oder auffällige Request-Strukturen. Fachlicher Kontext, Geschäftslogik und komplexe Autorisierung bleiben jedoch Aufgabe der Anwendung. Entscheidend ist ein Betriebsmodell, das Schutzwirkung und Fehlalarmrisiko kontrolliert.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEine WAF ist kein Ersatz für Anwendungssicherheit. Der typische Architekturfehler besteht darin, sämtliche Sicherheitsentscheidungen in ein zentrales Regelwerk vor dem Backend zu verlagern. Das funktioniert bei klar erkennbaren Angriffsmustern, scheitert aber an fachlichen Zusammenhängen: Ob eine Bestellung zulässig ist, hängt nicht nur von URL und HTTP-Methode ab, sondern von Benutzer, Bestand, Status und Geschäftsprozess. Eine belastbare WAF-Architektur trennt deshalb generische Filterung an der Edge von kontextabhängiger Validierung in der Anwendung. Die ayedo Edge Cloud bildet den öffentlichen Eingang vor HTTP-/HTTPS-Services und kann Requests dort per Web Application Firewall prüfen, bevor sie an die Backends verteilt werden.\u003c/p\u003e\n\u003ch2 id=\"1-welche-anfragen-eine-waf-sinnvoll-an-der-edge-prüft\"\u003e1. Welche Anfragen eine WAF sinnvoll an der Edge prüft\u003c/h2\u003e\n\u003cp\u003eEine WAF ist besonders wirksam, wenn sich ein Angriff aus Eigenschaften des Requests ableiten lässt. Dazu gehören verdächtige Payloads in Query-Parametern, Pfaden, Formularfeldern oder HTTP-Headern, typische Muster für SQL Injection und Cross-Site Scripting sowie unzulässige HTTP-Methoden. Auch Größenlimits, auffällige Content-Typen, ungewöhnliche Request-Strukturen oder bekannte Signaturen lassen sich zentral bewerten.\u003c/p\u003e\n\u003cp\u003eDer Vorteil der Edge-Position liegt im Zeitpunkt der Prüfung: Schädlicher Traffic wird vor der Anwendung verworfen und belastet weder Backend-Prozesse noch nachgelagerte Sicherheitskomponenten. Das ist insbesondere bei öffentlich erreichbaren APIs und Webanwendungen relevant. Die WAF wird dabei nicht zur einzigen Schutzschicht. TLS kann an der Edge terminiert werden, während das Backend verborgen bleibt und nur den von der Edge weitergeleiteten Traffic verarbeitet. Die Filterung reduziert damit die Angriffsfläche, ersetzt aber weder sichere Implementierung noch Patch- und Berechtigungsmanagement.\u003c/p\u003e\n\u003ch2 id=\"2-waf-regeln-zwischen-standard-und-anwendungskontext\"\u003e2. WAF-Regeln zwischen Standard und Anwendungskontext\u003c/h2\u003e\n\u003cp\u003eRegelwerke lassen sich grob in generische und anwendungsspezifische Regeln unterteilen. Generische Regeln erkennen bekannte Angriffsklassen unabhängig von der konkreten Fachanwendung. Anwendungsspezifische Regeln berücksichtigen dagegen definierte Pfade, erlaubte Methoden, Parameterformate oder erwartete Content-Typen einer API. Je genauer eine Regel den legitimen Datenverkehr beschreibt, desto höher kann ihre Schutzwirkung sein – gleichzeitig steigt der Pflegeaufwand.\u003c/p\u003e\n\u003cp\u003eEine WAF sollte nicht jede ungewöhnliche Eingabe blockieren. Viele valide Anwendungen akzeptieren Sonderzeichen, große JSON-Dokumente oder dynamische Parameter. Zu restriktive Regeln erzeugen Fehlalarme und können reguläre Geschäftsprozesse unterbrechen. Deshalb müssen Regeln beobachtbar eingeführt, anhand realer Requests bewertet und mit klarer Zuständigkeit betrieben werden. Die technische Entscheidung lautet nicht nur „blockieren oder erlauben“, sondern auch, welche Regel in welchem Modus gilt, wer Ausnahmen verantwortet und wie Änderungen nachvollziehbar bleiben.\u003c/p\u003e\n\u003ch2 id=\"3-betriebsmodelle-und-umgang-mit-fehlalarmen\"\u003e3. Betriebsmodelle und Umgang mit Fehlalarmen\u003c/h2\u003e\n\u003cp\u003eIn der Praxis haben sich drei Betriebsmodi etabliert: Überwachung, gezielte Blockierung und umfassende Durchsetzung. Im Überwachungsmodus protokolliert die WAF Treffer, ohne Requests abzulehnen. Das eignet sich für die Einführungsphase und für neue Regelgruppen. Gezielte Blockierung beschränkt sich auf belastbare Regeln oder besonders kritische Endpunkte. Eine umfassende Durchsetzung setzt voraus, dass Anwendung, Datenformate und Ausnahmefälle ausreichend bekannt sind.\u003c/p\u003e\n\u003cp\u003eEntscheidend ist ein definierter Feedbackprozess zwischen Plattform-, Security- und Anwendungsteams. Ein Fehlalarm ist nicht nur ein technisches Problem: Er kann Umsatzprozesse, Integrationen oder interne APIs unterbrechen. Umgekehrt darf eine hohe Zahl beobachteter Treffer nicht automatisch als Sicherheitsvorfall interpretiert werden. Benötigt werden Kontext, Priorisierung und eine Entscheidung, ob eine Ausnahme die WAF-Regel präzisiert oder ein Fehler in der Anwendung vorliegt. Traffic- und Usage-Statistiken an der Edge können dabei die Bewertung des Datenverkehrs unterstützen, ersetzen aber keine fachliche Analyse.\u003c/p\u003e\n\u003ch2 id=\"4-wo-edge-filterung-endet-und-anwendungsschutz-beginnt\"\u003e4. Wo Edge-Filterung endet und Anwendungsschutz beginnt\u003c/h2\u003e\n\u003cp\u003eEine WAF kann erkennen, dass ein Request formal verdächtig ist. Sie kann jedoch meist nicht zuverlässig beurteilen, ob ein authentifizierter Benutzer eine bestimmte Ressource verändern darf oder ob ein Geschäftsprozess in der richtigen Reihenfolge abläuft. Diese Entscheidungen gehören in die Anwendung oder in dafür vorgesehene Autorisierungsdienste. Gleiches gilt für Plausibilitätsprüfungen, Transaktionskonsistenz, Mandantentrennung und Missbrauchslogik mit Domänenwissen.\u003c/p\u003e\n\u003cp\u003eDie Trennung der Verantwortlichkeiten verbessert auch die Architektur. Die Edge übernimmt den öffentlichen Traffic-Eingang, TLS-nahe Verarbeitung, WAF-Prüfung und Verteilung; das Backend validiert Identität, Berechtigungen und fachliche Semantik. Durch Backend Cloaking muss die Anwendung nicht direkt öffentlich adressierbar sein. Bei mehreren Backends oder Ausfallpfaden bleiben Health Checks und Failover Aufgaben der Edge-Infrastruktur, während die Anwendung weiterhin für die Korrektheit ihrer Entscheidungen verantwortlich bleibt. Eine WAF-Architektur ist damit eine zusätzliche Kontrollschicht, kein zentraler Ersatz für Secure Coding.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEine öffentliche API akzeptiert JSON-Anfragen für Kontoänderungen. An der ayedo Edge Cloud werden zunächst nur HTTPS-Requests auf den vorgesehenen API-Pfaden angenommen. Die WAF prüft Methode, Content-Typ, Request-Größe und bekannte Angriffsmuster. Neue Regeln laufen zunächst im Überwachungsmodus. Nach der Auswertung werden eindeutig unzulässige Methoden blockiert, während fachliche Prüfungen – etwa ob das Konto dem authentifizierten Mandanten gehört – im Backend verbleiben.\u003c/p\u003e\n\u003cp\u003eWürde diese Mandantenprüfung an die Edge verlagert, müsste das Regelwerk fachliche Daten und Anwendungszustände kennen. Jede Änderung am Geschäftsmodell würde dann auch die zentrale Filterlogik beeinflussen. Die Edge bleibt deshalb stabil auf Protokoll- und Request-Ebene, während die Anwendung ihre Domänenlogik unabhängig weiterentwickelt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"kann-eine-waf-alle-api-angriffe-verhindern\"\u003eKann eine WAF alle API-Angriffe verhindern?\u003c/h3\u003e\n\u003cp\u003eNein. Sie erkennt viele protokoll- und payloadbezogene Angriffsmuster. Autorisierung, Geschäftslogik, Missbrauchserkennung und sichere Implementierung müssen weiterhin in der Anwendung umgesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"sollte-jede-waf-regel-sofort-blockieren\"\u003eSollte jede WAF-Regel sofort blockieren?\u003c/h3\u003e\n\u003cp\u003eNein. Neue oder komplexe Regeln sollten zunächst beobachtet und anhand legitimer Requests bewertet werden. Blockierung eignet sich für Regeln mit geringer Fehlalarmwahrscheinlichkeit und klarer technischer Grundlage.\u003c/p\u003e\n\u003ch3 id=\"wo-wird-die-waf-in-der-architektur-platziert\"\u003eWo wird die WAF in der Architektur platziert?\u003c/h3\u003e\n\u003cp\u003eVor den öffentlich erreichbaren Backends, typischerweise an der Edge. Dort kann sie Requests prüfen, bevor diese TLS-terminiert, verteilt und an die eigentlichen Anwendungen weitergeleitet werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine tragfähige WAF-Architektur verteilt Sicherheitsaufgaben bewusst: Die Edge filtert erkennbare Angriffs- und Protokollmuster, die Anwendung entscheidet über Identität, Berechtigung und fachliche Zulässigkeit. Für die ayedo Edge Cloud bedeutet das eine klare Rolle als öffentlicher Eingang mit WAF-Prüfung vor den Backends – nicht als Ersatz für Anwendungsschutz. Entscheidend sind kontrollierte Regeländerungen, nachvollziehbare Ausnahmen und ein Betriebsmodell, das Fehlalarme ebenso ernst nimmt wie echte Angriffe.\u003c/p\u003e\n", "summary": "\nTL;DR Eine WAF an der Edge prüft HTTP- und HTTPS-Anfragen, bevor sie Backends erreichen. Sie eignet sich für protokoll- und anfragespezifische Muster wie Injection, unerlaubte Methoden oder auffällige Request-Strukturen. Fachlicher Kontext, Geschäftslogik und komplexe Autorisierung bleiben jedoch Aufgabe der Anwendung. Entscheidend ist ein Betriebsmodell, das Schutzwirkung und Fehlalarmrisiko kontrolliert.\nEinleitung Eine WAF ist kein Ersatz für Anwendungssicherheit. Der typische Architekturfehler besteht darin, sämtliche Sicherheitsentscheidungen in ein zentrales Regelwerk vor dem Backend zu verlagern. Das funktioniert bei klar erkennbaren Angriffsmustern, scheitert aber an fachlichen Zusammenhängen: Ob eine Bestellung zulässig ist, hängt nicht nur von URL und HTTP-Methode ab, sondern von Benutzer, Bestand, Status und Geschäftsprozess. Eine belastbare WAF-Architektur trennt deshalb generische Filterung an der Edge von kontextabhängiger Validierung in der Anwendung. Die ayedo Edge Cloud bildet den öffentlichen Eingang vor HTTP-/HTTPS-Services und kann Requests dort per Web Application Firewall prüfen, bevor sie an die Backends verteilt werden.\n", "image": "https://ayedo.de/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle.png", "date_published": "2026-09-08T17:10:07Z", "date_modified": "2026-09-08T17:10:07Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/health-checks-als-grundlage-stabiler-traffic-pfade/", "url": "https://ayedo.de/posts/health-checks-als-grundlage-stabiler-traffic-pfade/", "title": "Health Checks als Grundlage stabiler Traffic-Pfade", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/health-checks-als-grundlage-stabiler-traffic-pfade/health-checks-als-grundlage-stabiler-traffic-pfade.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHealth Checks im Loadbalancing bewerten nicht nur, ob ein Backend-Netzwerkziel erreichbar ist. Entscheidend ist, ob der Service tatsächlich Anfragen verarbeiten kann. Die Ergebnisse beeinflussen Pool-Zustände, Failover und Traffic-Steuerung. Damit werden Health Checks zur Grundlage verlässlicher Backend-Auswahl und stabiler öffentlicher Zugriffspfade.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin erreichbarer Server ist nicht automatisch ein funktionsfähiges Backend. Ein Netzwerkziel kann auf Verbindungsversuche reagieren, während der Webserver, die Anwendung oder eine abhängige Datenbank bereits ausgefallen ist. Wird dieser Unterschied im Loadbalancing nicht berücksichtigt, bleibt Traffic auf einem technisch erreichbaren, aber praktisch unbrauchbaren Ziel liegen.\u003c/p\u003e\n\u003cp\u003eHealth Checks schaffen hier eine belastbare Entscheidungsgrundlage. Sie liefern der Edge-Plattform Informationen darüber, welche Backends aktuell für Traffic geeignet sind. Das beeinflusst nicht nur die Verteilung eingehender Anfragen, sondern auch Failover-Verhalten, Fehlerraten und die Wiederherstellung nach Störungen. Health Checks sind deshalb keine optionale Ergänzung zum Loadbalancing, sondern Teil seiner eigentlichen Steuerungslogik.\u003c/p\u003e\n\u003ch2 id=\"1-erreichbarkeit-und-nutzbarkeit-sind-unterschiedliche-zustände\"\u003e1. Erreichbarkeit und Nutzbarkeit sind unterschiedliche Zustände\u003c/h2\u003e\n\u003cp\u003eDie einfachste Prüfung stellt fest, ob ein Backend auf Netzwerkebene erreichbar ist. Eine Verbindung kann aufgebaut werden, ein Port kann antworten oder ein Ziel kann grundsätzlich Daten zurückliefern. Für die Backend-Verfügbarkeit ist das jedoch nur eine notwendige, nicht zwangsläufig eine hinreichende Bedingung.\u003c/p\u003e\n\u003cp\u003eEin Service kann beispielsweise Verbindungen annehmen, obwohl seine Request-Verarbeitung blockiert ist. Ebenso kann ein HTTP-Endpunkt antworten, während die Anwendung intern keine Geschäftslogik mehr ausführt oder eine kritische Abhängigkeit nicht erreicht. Ein Health Check muss deshalb zu dem Dienst passen, dessen Nutzbarkeit bewertet werden soll.\u003c/p\u003e\n\u003cp\u003eArchitektonisch bedeutet das: Der Prüfpunkt sollte möglichst nah an der tatsächlichen Funktion des Backends liegen, ohne selbst unnötig viele Abhängigkeiten einzuführen. Ein zu oberflächlicher Check lässt fehlerhafte Ziele im Pool. Ein zu komplexer Check kann dagegen durch einzelne nachgelagerte Störungen falsche Ausfälle signalisieren. Die Prüflogik ist damit eine bewusste Abwägung zwischen Aussagekraft und Stabilität.\u003c/p\u003e\n\u003ch2 id=\"2-aus-prüfergebnissen-werden-pool-zustände\"\u003e2. Aus Prüfergebnissen werden Pool-Zustände\u003c/h2\u003e\n\u003cp\u003eHealth Checks sind erst dann operativ relevant, wenn ihre Ergebnisse in Zustände übersetzt werden. Ein Backend ist aus Sicht des Loadbalancings nicht einfach „da“ oder „nicht da“. Es kann als nutzbar bewertet werden, aus dem Traffic genommen werden oder nach einer Erholung wieder in die Auswahl gelangen. Diese Zustände bilden die Grundlage für Routingentscheidungen.\u003c/p\u003e\n\u003cp\u003eFällt ein Ziel aus, sollte die Traffic-Steuerung nicht auf einzelne Fehlermeldungen warten müssen. Die Edge kann ein als nicht nutzbar bewertetes Backend aus der aktiven Auswahl nehmen und Anfragen an andere geeignete Ziele weiterleiten. Dafür müssen mehrere Backends vorhanden und korrekt gruppiert sein. Failover ist keine Eigenschaft eines einzelnen Health Checks, sondern das Zusammenspiel aus Prüfung, Pool-Konfiguration und Routingverhalten.\u003c/p\u003e\n\u003cp\u003eEbenso wichtig ist die Rückkehr in den aktiven Pool. Ein kurzfristiger Fehler darf nicht zu unnötigem Flattern zwischen Zuständen führen. Umgekehrt sollte ein Backend nicht zu früh wieder Traffic erhalten, wenn seine Erholung noch nicht belastbar ist. Die konkrete Bewertung muss daher zur Fehlercharakteristik des jeweiligen Services passen.\u003c/p\u003e\n\u003ch2 id=\"3-health-checks-beeinflussen-den-betrieb-vor-dem-incident\"\u003e3. Health Checks beeinflussen den Betrieb vor dem Incident\u003c/h2\u003e\n\u003cp\u003eOhne belastbare Health Checks wird ein Ausfall häufig erst durch Nutzerfehler sichtbar. Monitoring, Supportmeldungen oder steigende Fehlerraten zeigen dann, dass Traffic bereits auf ungeeignete Ziele gelangt. Health Checks verschieben die Reaktion an einen früheren Punkt: Die Plattform kann Backend-Zustände in die Traffic-Steuerung einbeziehen, bevor jeder einzelne Client den Fehler erfährt.\u003c/p\u003e\n\u003cp\u003eDas reduziert nicht automatisch die Ursache eines Ausfalls. Es begrenzt aber dessen Ausbreitung. Ein defektes Backend bleibt aus dem aktiven Traffic-Pfad, während andere Ziele weiterhin Anfragen übernehmen können. Für den Betrieb bedeutet das eine klarere Trennung zwischen Fehlererkennung, Routingreaktion und Ursachenanalyse.\u003c/p\u003e\n\u003cp\u003eDie Auswertung muss dennoch mit der Anwendung abgestimmt werden. Ein Check, der nur die Infrastruktur prüft, kann Anwendungsausfälle übersehen. Ein Check, der jede externe Abhängigkeit einbezieht, kann bei einem begrenzten Teilausfall den gesamten Service aus dem Pool nehmen. Teams müssen deshalb definieren, welche Funktion für die öffentliche Erreichbarkeit entscheidend ist und welche Fehler separat behandelt werden sollten.\u003c/p\u003e\n\u003ch2 id=\"4-edge-basierte-bewertung-reduziert-abhängigkeiten-im-traffic-pfad\"\u003e4. Edge-basierte Bewertung reduziert Abhängigkeiten im Traffic-Pfad\u003c/h2\u003e\n\u003cp\u003eWerden Health Checks erst hinter mehreren Netzwerk- oder Providergrenzen durchgeführt, kann die Bewertung vom tatsächlich genutzten Zugriffspfad abweichen. Ein Backend ist dann vielleicht aus einer bestimmten Monitoring-Zone erreichbar, für den öffentlichen Traffic aber nicht zuverlässig nutzbar. Die Position der Prüfung ist daher ein Bestandteil der Architektur.\u003c/p\u003e\n\u003cp\u003eIn einer verteilten Edge-Plattform wie der ayedo Edge Cloud fließen Backend Health Checks in die Auswahl geeigneter Ziele ein. Die Edge Cloud bildet den öffentlichen Eingang vor Anwendungen und APIs und übernimmt neben Routing und Lastverteilung auch Failover. Dadurch wird die Bewertung der Backend-Verfügbarkeit direkt mit dem Traffic-Pfad verbunden, den die Plattform steuert.\u003c/p\u003e\n\u003cp\u003eDas ist besonders relevant bei providerunabhängigen Architekturen und bei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n -Umgebungen, die nicht zwingend bei ayedo betrieben werden. Die Edge-Funktionen bleiben vom jeweiligen Compute-Standort getrennt: Kubernetes oder andere Infrastrukturen führen die Workloads aus, während die Edge deren öffentliche Erreichbarkeit bewertet und Traffic auf nutzbare Backends verteilt. So wird Backend-Verfügbarkeit zu einer übergreifenden Routing-Frage statt zu einer lokalen Clusterfunktion.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei Backend-Pools: ein Cluster in der eigenen Infrastruktur und ein weiteres bei einem Cloud-Provider. Beide Ziele sind über das Netzwerk erreichbar. Im primären Pool nimmt der API-Prozess jedoch Verbindungen an, kann Anfragen wegen eines internen Fehlers nicht mehr abschließen.\u003c/p\u003e\n\u003cp\u003eEin reiner TCP-Check würde das Ziel möglicherweise weiterhin als verfügbar bewerten. Der Traffic bliebe dort, obwohl Clients Fehler oder Timeouts erhalten. Ein auf die tatsächliche Servicefunktion abgestimmter Health Check erkennt den Zustand dagegen als nicht nutzbar. Die ayedo Edge Cloud kann das Backend aus der aktiven Auswahl nehmen und den Traffic im Rahmen der konfigurierten Failover-Logik auf den anderen Pool lenken. Die Anwendung bleibt dabei unabhängig davon erreichbar, welcher Compute-Standort den Traffic verarbeitet.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"prüfen-health-checks-automatisch-die-gesamte-anwendung\"\u003ePrüfen Health Checks automatisch die gesamte Anwendung?\u003c/h3\u003e\n\u003cp\u003eNein. Sie bewerten nur die im jeweiligen Check definierte Funktion. Welche Abhängigkeiten einbezogen werden, muss zur Rolle des Services und zur gewünschten Ausfallreaktion passen.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-wenn-alle-backends-als-nicht-verfügbar-gelten\"\u003eWas passiert, wenn alle Backends als nicht verfügbar gelten?\u003c/h3\u003e\n\u003cp\u003eDann kann kein normales Failover auf ein nutzbares Ziel erfolgen. Die daraus resultierende Reaktion hängt von der Routing- und Servicekonfiguration ab; Health Checks ersetzen keine redundante Backend-Architektur.\u003c/p\u003e\n\u003ch3 id=\"sind-health-checks-nur-für-kubernetes-relevant\"\u003eSind Health Checks nur für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Sie sind ein allgemeines Loadbalancing-Prinzip und gelten ebenso für virtuelle Maschinen, Bare-Metal-Systeme oder Backends bei unterschiedlichen Providern.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eHealth Checks im Loadbalancing bestimmen, welche Backends nicht nur erreichbar, sondern für Traffic tatsächlich geeignet sind. Ihre Qualität hängt von der Prüflogik, der Pool-Auswertung und der Failover-Architektur ab. Unternehmen sollten Health Checks deshalb als Teil des Routingdesigns behandeln. Die ayedo Edge Cloud verbindet diese Bewertung mit ihrem öffentlichen Traffic-Eingang und schafft damit eine Grundlage für providerunabhängige, kontrollierte Backend-Auswahl.\u003c/p\u003e\n", "summary": "\nTL;DR Health Checks im Loadbalancing bewerten nicht nur, ob ein Backend-Netzwerkziel erreichbar ist. Entscheidend ist, ob der Service tatsächlich Anfragen verarbeiten kann. Die Ergebnisse beeinflussen Pool-Zustände, Failover und Traffic-Steuerung. Damit werden Health Checks zur Grundlage verlässlicher Backend-Auswahl und stabiler öffentlicher Zugriffspfade.\nEinleitung Ein erreichbarer Server ist nicht automatisch ein funktionsfähiges Backend. Ein Netzwerkziel kann auf Verbindungsversuche reagieren, während der Webserver, die Anwendung oder eine abhängige Datenbank bereits ausgefallen ist. Wird dieser Unterschied im Loadbalancing nicht berücksichtigt, bleibt Traffic auf einem technisch erreichbaren, aber praktisch unbrauchbaren Ziel liegen.\n", "image": "https://ayedo.de/health-checks-als-grundlage-stabiler-traffic-pfade.png", "date_published": "2026-09-08T17:04:59Z", "date_modified": "2026-09-08T17:04:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/l7-routing-fur-apis-regeln-pools-und-backends/", "url": "https://ayedo.de/posts/l7-routing-fur-apis-regeln-pools-und-backends/", "title": "L7-Routing für APIs: Regeln, Pools und Backends", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/l7-routing-fur-apis-regeln-pools-und-backends/l7-routing-fur-apis-regeln-pools-und-backends.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eL7-Routing verteilt API-Anfragen nicht nur nach IP-Adresse oder Port, sondern nach Merkmalen der Anwendung. Pfad, Hostname, HTTP-Methode oder Header können unterschiedliche Backend-Pools ansprechen. Entscheidend sind klare Regeln, definierte Prioritäten und eine saubere Grenze zwischen Edge-Routing und anwendungsinterner Logik.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin gemeinsamer Backend-Pool für sämtliche API-Anfragen ist einfach zu konfigurieren, führt aber schnell zu unnötiger Kopplung. Versionierte APIs, administrative Endpunkte und öffentliche Ressourcen haben oft unterschiedliche Skalierungs-, Sicherheits- und Betriebsanforderungen. Werden sie pauschal an dieselben Backends weitergeleitet, muss die Anwendung diese Unterschiede selbst auswerten.\u003c/p\u003e\n\u003cp\u003eL7-Routing verlagert einen Teil dieser Entscheidung an den öffentlichen Eingang. Die Edge analysiert HTTP-Merkmale und ordnet Requests passenden Services oder Backend-Pools zu. Damit entsteht eine klare Trennung: Die Edge entscheidet über die grobe Zielrichtung des Traffics, während die Anwendung ihre fachliche Logik weiterhin selbst verantwortet.\u003c/p\u003e\n\u003ch2 id=\"1-l7-routing-beginnt-mit-einer-expliziten-regelstruktur\"\u003e1. L7-Routing beginnt mit einer expliziten Regelstruktur\u003c/h2\u003e\n\u003cp\u003eEine Routingregel besteht fachlich aus drei Teilen: einem Match-Kriterium, einem Ziel und einer definierten Reihenfolge. Das Match-Kriterium beschreibt, für welche Requests die Regel gilt. Typische Merkmale sind Hostname, URL-Pfad, HTTP-Methode oder ausgewählte Header. Das Ziel verweist auf einen Service beziehungsweise einen Backend-Pool, der die Anfrage verarbeiten soll.\u003c/p\u003e\n\u003cp\u003eDie Reihenfolge ist entscheidend. Eine allgemeine Regel wie \u003ccode\u003e/api/*\u003c/code\u003e darf keine spezifischere Regel für \u003ccode\u003e/api/v2/*\u003c/code\u003e überdecken. Deshalb sollten Regeln von spezifisch nach allgemein angeordnet oder durch eine eindeutig definierte Priorität bewertet werden. Eine abschließende Default-Regel verhindert, dass nicht gematchte Requests unkontrolliert an ein beliebiges Backend gelangen.\u003c/p\u003e\n\u003cp\u003eFür die ayedo Edge Cloud bedeutet L7-Loadbalancing, dass HTTP- und HTTPS-Traffic anhand solcher Anwendungsmerkmale auf unterschiedliche Ziele verteilt werden kann. Die konkrete Regelstruktur sollte dabei als Teil der Architektur dokumentiert werden, nicht nur als Konfiguration einzelner Teams.\u003c/p\u003e\n\u003ch2 id=\"2-backend-pools-bilden-technische-verantwortungsgrenzen\"\u003e2. Backend-Pools bilden technische Verantwortungsgrenzen\u003c/h2\u003e\n\u003cp\u003eEin Backend-Pool ist mehr als eine Liste von Servern. Er beschreibt eine Gruppe von Backends, die denselben API-Traffic fachlich und betrieblich verarbeiten soll. Ein Pool für \u003ccode\u003e/api/v1\u003c/code\u003e kann beispielsweise von einem anderen Deployment bedient werden als ein Pool für \u003ccode\u003e/api/v2\u003c/code\u003e. Ebenso können öffentliche und administrative Endpunkte getrennt werden.\u003c/p\u003e\n\u003cp\u003eDiese Trennung wirkt sich auf Skalierung, Release-Prozesse und Fehlerbilder aus. Wird ein Pool für eine neue API-Version unabhängig skaliert, beeinflusst das nicht automatisch die Last der alten Version. Ein fehlerhaftes Deployment bleibt auf den zugeordneten Traffic begrenzt, sofern die Routingregeln keine gemeinsame Abhängigkeit erzeugen.\u003c/p\u003e\n\u003cp\u003eHealth Checks und Failover ergänzen diese Struktur. Sie prüfen, ob Backends grundsätzlich erreichbar und dienstfähig sind. Sie ersetzen jedoch keine fachliche Fehlerbehandlung: Ein Backend kann HTTP 200 liefern und trotzdem falsche Daten zurückgeben. Die Edge entscheidet über Verfügbarkeit und Weiterleitung, nicht über die Korrektheit der API-Antwort.\u003c/p\u003e\n\u003ch2 id=\"3-api-routing-muss-mit-versionierung-und-releases-zusammenpassen\"\u003e3. API-Routing muss mit Versionierung und Releases zusammenpassen\u003c/h2\u003e\n\u003cp\u003eL7-Routing eignet sich besonders für kontrollierte Übergänge zwischen API-Versionen oder Deployments. Ein Pfad wie \u003ccode\u003e/v1/\u003c/code\u003e kann dauerhaft auf einen stabilen Pool zeigen, während \u003ccode\u003e/v2/\u003c/code\u003e an eine neue Implementierung weitergeleitet wird. Alternativ können Header oder Hostnamen genutzt werden, wenn Versionen oder Mandanten nicht im Pfad sichtbar sein sollen.\u003c/p\u003e\n\u003cp\u003eWichtig ist, die Routingentscheidung nicht mit vollständiger Anwendungslogik zu verwechseln. Die Edge kann Requests anhand sichtbarer Protokollmerkmale einordnen. Sie sollte jedoch nicht die fachliche Autorisierung, komplexe Mandantenlogik oder die Konsistenz von Geschäftsprozessen übernehmen. Diese Aufgaben bleiben im API-Service.\u003c/p\u003e\n\u003cp\u003eAuch bei Canary-Releases braucht es klare Grenzen. Eine Aufteilung nach einem stabilen technischen Merkmal ist nachvollziehbarer als eine Vielzahl schwer prüfbarer Sonderregeln. Werden beispielsweise nur bestimmte Header für Testzugriffe verwendet, müssen Clients, Monitoring und Rollback-Prozess diese Konvention unterstützen. Sonst wird die Edge-Konfiguration selbst zum versteckten Release-System.\u003c/p\u003e\n\u003ch2 id=\"4-die-übergabe-an-das-backend-definiert-die-betriebsgrenze\"\u003e4. Die Übergabe an das Backend definiert die Betriebsgrenze\u003c/h2\u003e\n\u003cp\u003eZwischen Edge und Anwendung müssen Header, TLS und Quellinformationen eindeutig behandelt werden. Bei TLS-Termination an der Edge muss das Backend erkennen können, dass der ursprüngliche Request über HTTPS eingegangen ist. Für Logging, Zugriffskontrolle und Diagnose ist außerdem relevant, welche Client- und Proxy-Informationen an die Anwendung weitergegeben werden.\u003c/p\u003e\n\u003cp\u003eProxy Protocol kann hierfür in passenden Architekturen die Verbindung zwischen Edge und Backend um Informationen zur ursprünglichen Verbindung ergänzen. Das Backend muss dieses Protokoll allerdings explizit erwarten. Eine inkonsistente Konfiguration führt nicht zu einem bloßen Routingfehler, sondern kann den Verbindungsaufbau zwischen Edge und Service verhindern.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking verschiebt die öffentliche Sichtbarkeit vollständig zur Edge: Clients müssen die internen Backend-Adressen nicht kennen. Das reduziert die direkte Angriffsfläche und verhindert, dass sich API-Clients an einzelne Workload-Adressen koppeln. In der ayedo Edge Cloud liegt damit der öffentliche Zugang vor den eigentlichen Backends; die Anwendung bleibt für die fachliche Verarbeitung zuständig.\u003c/p\u003e\n\u003ch2 id=\"praxis-zwei-api-versionen-mit-getrennten-pools\"\u003ePraxis: Zwei API-Versionen mit getrennten Pools\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt \u003ccode\u003e/api/v1\u003c/code\u003e und \u003ccode\u003e/api/v2\u003c/code\u003e parallel. Beide Versionen sind unter demselben Hostnamen erreichbar, unterscheiden sich aber in Datenmodell und Skalierungsbedarf. Eine allgemeine Weiterleitung auf einen gemeinsamen Pool würde die Versionserkennung in die Anwendung verlagern und erschwert Rollbacks.\u003c/p\u003e\n\u003cp\u003eStattdessen wird eine spezifische Regel für \u003ccode\u003e/api/v2/*\u003c/code\u003e vor einer allgemeineren Regel für \u003ccode\u003e/api/v1/*\u003c/code\u003e ausgewertet. Beide Regeln verweisen auf getrennte Backend-Pools. Health Checks entfernen nicht erreichbare Backends aus dem jeweiligen Pool. Ein Rollback von Version 2 verändert dann nur die Zuordnung dieses Pfads, während Version 1 unverändert bleibt. Die Edge steuert die Zielrichtung; Authentifizierung und fachliche Validierung verbleiben in den APIs.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"welche-merkmale-eignen-sich-für-l7-routing\"\u003eWelche Merkmale eignen sich für L7-Routing?\u003c/h3\u003e\n\u003cp\u003eTypische Kriterien sind Hostname, URL-Pfad, HTTP-Methode und ausgewählte Header. Entscheidend ist, dass das Merkmal stabil, für Clients nachvollziehbar und für Betrieb sowie Monitoring sichtbar ist.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-l7-routing-einen-api-gateway-service\"\u003eErsetzt L7-Routing einen API-Gateway-Service?\u003c/h3\u003e\n\u003cp\u003eNein. L7-Routing verteilt Requests. Funktionen wie fachliche Autorisierung, Transformationen oder komplexe Quotenlogik gehören weiterhin in dafür vorgesehene API- oder Plattformkomponenten.\u003c/p\u003e\n\u003ch3 id=\"wann-reicht-ein-gemeinsamer-backend-pool-aus\"\u003eWann reicht ein gemeinsamer Backend-Pool aus?\u003c/h3\u003e\n\u003cp\u003eEin gemeinsamer Pool kann genügen, wenn API-Versionen, Skalierungsprofile und Releasezyklen identisch sind. Sobald sich diese Eigenschaften unterscheiden, schafft eine getrennte Zuordnung meist klarere Betriebsgrenzen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eL7-Routing für APIs ist vor allem eine Frage sauberer Verantwortungsgrenzen. Regeln bestimmen die Zielrichtung, Backend-Pools bündeln vergleichbare Betriebsanforderungen und die Übergabe definiert, welche Informationen ein Service erhält. Die ayedo Edge Cloud kann diese Entscheidungen als öffentlicher Eingang für HTTP- und HTTPS-Services zentral umsetzen – unabhängig davon, ob die Backends in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, einem eigenen Cluster oder bei einem anderen Provider betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR L7-Routing verteilt API-Anfragen nicht nur nach IP-Adresse oder Port, sondern nach Merkmalen der Anwendung. Pfad, Hostname, HTTP-Methode oder Header können unterschiedliche Backend-Pools ansprechen. Entscheidend sind klare Regeln, definierte Prioritäten und eine saubere Grenze zwischen Edge-Routing und anwendungsinterner Logik.\nEinleitung Ein gemeinsamer Backend-Pool für sämtliche API-Anfragen ist einfach zu konfigurieren, führt aber schnell zu unnötiger Kopplung. Versionierte APIs, administrative Endpunkte und öffentliche Ressourcen haben oft unterschiedliche Skalierungs-, Sicherheits- und Betriebsanforderungen. Werden sie pauschal an dieselben Backends weitergeleitet, muss die Anwendung diese Unterschiede selbst auswerten.\n", "image": "https://ayedo.de/l7-routing-fur-apis-regeln-pools-und-backends.png", "date_published": "2026-09-08T17:04:59Z", "date_modified": "2026-09-08T17:04:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","development","kubernetes","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/traffic-pfade-mit-tls-und-proxy-protocol-steuern/", "url": "https://ayedo.de/posts/traffic-pfade-mit-tls-und-proxy-protocol-steuern/", "title": "Traffic-Pfade mit TLS und Proxy Protocol steuern", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/traffic-pfade-mit-tls-und-proxy-protocol-steuern/traffic-pfade-mit-tls-und-proxy-protocol-steuern.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin stabiler Traffic-Pfad endet nicht bei der TLS Termination. Entscheidend ist das abgestimmte Zusammenspiel aus TLS-Endpunkt, Routing, Backend-Auswahl, Health Checks und \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n. Die Edge bestimmt den öffentlichen Verbindungsweg; die Anwendung muss festlegen, wie sie übertragene Client-Informationen verarbeitet und welche Protokollparameter sie akzeptiert.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eTLS Termination, Routing und \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n werden in der Praxis häufig getrennt konfiguriert. Genau daraus entstehen Fehler: Ein Backend erhält zwar Verbindungen, kann aber die zusätzliche Proxy-Protocol-Zeile nicht verarbeiten. Oder die Edge terminiert TLS, während die Anwendung weiterhin von einer direkten HTTPS-Verbindung des Clients ausgeht. Der Traffic-Pfad muss deshalb als durchgängiger Ablauf betrachtet werden. Jede Komponente verändert die Verbindung oder ergänzt Informationen. Die zentrale Architekturfrage lautet nicht nur, wo TLS endet, sondern auch, welche Identität und Metadaten danach an das Backend übergeben werden und welche Verantwortung dort verbleibt.\u003c/p\u003e\n\u003ch2 id=\"1-der-traffic-pfad-beginnt-am-tls-endpunkt\"\u003e1. Der Traffic-Pfad beginnt am TLS-Endpunkt\u003c/h2\u003e\n\u003cp\u003eBei einer Verbindung zu einem öffentlichen Service erreicht der Client zunächst einen Anycast-basierten Edge-Einstiegspunkt. Für HTTP- und HTTPS-Services kann die ayedo Edge Cloud TLS an der Edge terminieren. Der TLS-Endpunkt übernimmt damit die Aushandlung mit dem Client und stellt der nachgelagerten Verarbeitung bereits eine entschlüsselte Verbindung zur Verfügung.\u003c/p\u003e\n\u003cp\u003eDiese Entscheidung trennt zwei Verantwortungsbereiche. Die Edge verantwortet den öffentlichen TLS-Eingang, die Anwendung bleibt für ihre eigene Protokoll- und Sicherheitslogik zuständig. Ein Backend darf daher nicht automatisch davon ausgehen, dass die Verbindung zu ihm weiterhin dem ursprünglichen Client-TLS-Kanal entspricht. Informationen wie das ursprünglich verwendete Protokoll müssen über definierte Header oder andere Übergabemechanismen ausgewertet werden, sofern sie für die Anwendung relevant sind.\u003c/p\u003e\n\u003cp\u003eFür die Konfiguration sind insbesondere Zertifikat, Hostname, Listener und das erwartete Anwendungsprotokoll aufeinander abzustimmen. Ein TLS-Fehler am Edge-Endpunkt ist dabei etwas anderes als ein Fehler zwischen Edge und Backend. Diese Pfade sollten in Monitoring und Fehlersuche getrennt betrachtet werden.\u003c/p\u003e\n\u003ch2 id=\"2-nach-der-termination-entscheidet-die-edge-über-das-ziel\"\u003e2. Nach der Termination entscheidet die Edge über das Ziel\u003c/h2\u003e\n\u003cp\u003eNach der TLS Termination folgt die Routingentscheidung. Bei HTTP-Services können dabei unter anderem Hostname oder URL-Pfad zur Auswahl des Zielservices beitragen. Auf Layer 4 bleibt die Entscheidung stärker an Netzwerkparametern wie IP und Port orientiert. Welche Ebene verwendet wird, hängt vom Dienst und seinem Protokoll ab.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet diese Routinglogik mit Backend-Pools, Health Checks und Failover. Ein Pool beschreibt dabei nicht nur eine Liste erreichbarer Ziele, sondern einen betrieblichen Entscheidungsraum: Welche Backends gelten als verfügbar, und wohin wird Traffic verteilt, wenn einzelne Ziele ausfallen? Die Routingkonfiguration muss deshalb mit den tatsächlich exponierten Ports, Protokollen und Gesundheitsprüfungen übereinstimmen.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Grenze zwischen Edge und Anwendung: Die Edge entscheidet, welches Backend die Verbindung erhält. Sie entscheidet nicht, ob die Anwendung fachlich autorisiert ist oder eine Anfrage korrekt verarbeitet. Ein erfolgreiches Routing und ein erfolgreicher Health Check belegen nur die technische Erreichbarkeit beziehungsweise den definierten Prüfzustand, nicht die fachliche Funktionsfähigkeit des Services.\u003c/p\u003e\n\u003ch2 id=\"3-proxy-protocol-übergibt-verbindungsmetadaten\"\u003e3. \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n übergibt Verbindungsmetadaten\u003c/h2\u003e\n\u003cp\u003eWird Proxy Protocol für einen Backend-Pool aktiviert, erhält der Backend-Dienst vor den eigentlichen Nutzdaten eine zusätzliche Information über die ursprüngliche Verbindung. Dazu gehören insbesondere Quell- und Zielinformationen auf Verbindungsebene. Das ist relevant, wenn ein Service die Client-IP für Protokollierung, Zugriffskontrolle, Rate-Limiting oder forensische Auswertung benötigt.\u003c/p\u003e\n\u003cp\u003eDiese Funktion verändert jedoch das erwartete Eingangsprotokoll. Ein HTTP-Server, TLS-Listener oder TCP-Dienst muss Proxy Protocol ausdrücklich unterstützen und an der richtigen Stelle auswerten. Ein Backend, das unmittelbar mit HTTP- oder TLS-Daten rechnet, kann die zusätzliche Übergabe andernfalls als ungültige Nutzlast interpretieren. Das Problem liegt dann nicht zwingend im Routing, sondern an einer nicht abgestimmten Backend-Integration.\u003c/p\u003e\n\u003cp\u003eProxy Protocol ist außerdem kein Ersatz für eine fachliche Identität. Die übertragenen Verbindungsinformationen müssen innerhalb der vertrauenswürdigen Edge-zu-Backend-Strecke verarbeitet werden. Anwendungen sollten daraus keine uneingeschränkte Benutzeridentität ableiten. Für Authentisierung und Autorisierung bleiben geeignete Anwendungsmechanismen zuständig.\u003c/p\u003e\n\u003ch2 id=\"4-edge--und-anwendungskonfiguration-müssen-getrennt-geprüft-werden\"\u003e4. Edge- und Anwendungskonfiguration müssen getrennt geprüft werden\u003c/h2\u003e\n\u003cp\u003eEin vollständiger Test muss jede Übergabestelle berücksichtigen: TLS-Verbindung zum Edge-Endpunkt, Zertifikats- und Hostname-Prüfung, Routingregel, Auswahl des Backend-Pools, Health-Check-Zustand, Proxy-Protocol-Verarbeitung und anschließende Anwendungskommunikation. Einzelne Tests am Backend reichen nicht aus, wenn sie den tatsächlichen öffentlichen Traffic-Pfad umgehen.\u003c/p\u003e\n\u003cp\u003eAuch die Protokollgrenzen müssen klar dokumentiert sein. Die Edge verarbeitet und verteilt eingehenden Traffic; das Backend entscheidet, wie Proxy Protocol, HTTP-Header und die eigentliche Nutzlast interpretiert werden. Für die Anwendung ist besonders wichtig, ob sie die Verbindung als HTTP, HTTPS oder reines TCP erwartet. Wird TLS am Edge beendet, muss die Anwendung ihre Annahmen über den ursprünglichen Transport entsprechend abbilden.\u003c/p\u003e\n\u003cp\u003eBei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n kommt eine weitere Integrationsgrenze hinzu: Die Edge muss den extern erreichbaren Service und seine Backends erreichen können, während der Kubernetes-Service oder Ingress den erwarteten Listener bereitstellt. Das gilt unabhängig davon, ob der Cluster mit ayedo Managed Kubernetes oder bei einem anderen Provider betrieben wird. Providerunabhängigkeit ändert nicht die Protokollanforderungen des Backends.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine HTTPS-API in einem eigenen Kubernetes-Cluster. Der öffentliche Traffic erreicht die ayedo Edge Cloud, TLS wird dort terminiert und anhand des Hostnamens an einen Backend-Pool geroutet. Der Pool nutzt Health Checks und übergibt die Client-Verbindungsdaten per Proxy Protocol.\u003c/p\u003e\n\u003cp\u003eDer erste Test gegen den Service schlägt fehl, weil der vorgeschaltete Listener nur HTTP erwartet und Proxy Protocol nicht aktiviert verarbeitet. Nach der Anpassung des Listeners funktioniert die Verbindung. Ein zweiter Test zeigt jedoch, dass die Anwendung Redirects mit dem Schema \u003ccode\u003ehttp\u003c/code\u003e erzeugt, weil sie die TLS Termination nicht berücksichtigt. Das Problem liegt nun nicht mehr in Proxy Protocol, sondern in der Anwendungslogik zur Ermittlung des ursprünglichen Schemas. Beide Fehler entstehen entlang desselben Traffic-Pfads, benötigen aber unterschiedliche Verantwortliche und Prüfungen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-tls-am-edge-immer-terminiert-werden\"\u003eMuss TLS am Edge immer terminiert werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Entscheidung hängt von Sicherheitsmodell, Protokoll und Backend-Anforderungen ab. Wird TLS an der Edge terminiert, müssen die nachgelagerten Protokoll- und Vertrauensgrenzen ausdrücklich definiert werden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-proxy-protocol-http-header-für-die-client-ip\"\u003eErsetzt Proxy Protocol HTTP-Header für die Client-IP?\u003c/h3\u003e\n\u003cp\u003eNein. Proxy Protocol übergibt Verbindungsinformationen auf Transportebene. HTTP-Header gehören zur Anwendungsebene und verfolgen andere Anforderungen an Verarbeitung, Vertrauen und Validierung.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-proxy-protocol-mit-jedem-backend\"\u003eFunktioniert Proxy Protocol mit jedem Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Der Backend-Listener muss das Protokoll unterstützen und korrekt konfigurieren. Andernfalls werden die zusätzlichen Daten vor der eigentlichen Nutzlast als ungültige Anfrage interpretiert.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eTLS Termination, Routing und \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n sind keine unabhängigen Schalter, sondern aufeinanderfolgende Stationen eines Traffic-Pfads. Jede Station verändert den Kontext der Verbindung und verschiebt einen Teil der Verantwortung zwischen Edge und Anwendung. Die ayedo Edge Cloud bündelt diese Aufgaben am öffentlichen Eingang und kann Traffic über Edge-Routing, Backend-Pools, Health Checks und Proxy Protocol weitergeben. Stabil wird die Architektur erst, wenn die Protokollerwartungen an jeder Übergabe explizit dokumentiert und getestet werden.\u003c/p\u003e\n", "summary": "\nTL;DR Ein stabiler Traffic-Pfad endet nicht bei der TLS Termination. Entscheidend ist das abgestimmte Zusammenspiel aus TLS-Endpunkt, Routing, Backend-Auswahl, Health Checks und Proxy Protocol . Die Edge bestimmt den öffentlichen Verbindungsweg; die Anwendung muss festlegen, wie sie übertragene Client-Informationen verarbeitet und welche Protokollparameter sie akzeptiert.\nEinleitung TLS Termination, Routing und Proxy Protocol werden in der Praxis häufig getrennt konfiguriert. Genau daraus entstehen Fehler: Ein Backend erhält zwar Verbindungen, kann aber die zusätzliche Proxy-Protocol-Zeile nicht verarbeiten. Oder die Edge terminiert TLS, während die Anwendung weiterhin von einer direkten HTTPS-Verbindung des Clients ausgeht. Der Traffic-Pfad muss deshalb als durchgängiger Ablauf betrachtet werden. Jede Komponente verändert die Verbindung oder ergänzt Informationen. Die zentrale Architekturfrage lautet nicht nur, wo TLS endet, sondern auch, welche Identität und Metadaten danach an das Backend übergeben werden und welche Verantwortung dort verbleibt.\n", "image": "https://ayedo.de/traffic-pfade-mit-tls-und-proxy-protocol-steuern.png", "date_published": "2026-09-08T17:04:59Z", "date_modified": "2026-09-08T17:04:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/anycast-und-backend-failover-im-aktiv-aktiv-betrieb/", "url": "https://ayedo.de/posts/anycast-und-backend-failover-im-aktiv-aktiv-betrieb/", "title": "Anycast und Backend-Failover im Aktiv-Aktiv-Betrieb", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-und-backend-failover-im-aktiv-aktiv-betrieb/anycast-und-backend-failover-im-aktiv-aktiv-betrieb.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv-Failover entsteht nicht durch einen einzelnen Mechanismus, sondern durch das Zusammenspiel von Anycast, verteilten Edge-PoPs, belastbaren Health Checks und dynamischer Backend-Auswahl. Fällt ein Backend aus, muss die Edge den Zustand erkennen und neue Verbindungen gezielt an verfügbare Backends verteilen, ohne einen zentralen Primärpfad vorauszusetzen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, Anycast mit Hochverfügbarkeit gleichzusetzen. Eine global erreichbare IP-Adresse reduziert zwar die Abhängigkeit von einem einzelnen Einstiegspunkt, verhindert aber keinen Ausfall der Anwendung. Erst wenn die Edge den Zustand der Backends kontinuierlich bewertet und Routingentscheidungen daran ausrichtet, entsteht ein belastbarer Aktiv-Aktiv-Betrieb. Dabei wirken zwei Ebenen zusammen: Anycast und verteilte Edge-PoPs halten den öffentlichen Zugang verfügbar, während Backend-Failover den Datenverkehr innerhalb der verfügbaren Anwendungsinfrastruktur steuert. Die Qualität dieser Architektur hängt deshalb weniger von einem einzelnen Failover-Schalter ab als von der Fehlererkennung, der Auswahl geeigneter Ziele und dem Umgang mit bestehenden Verbindungen.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-verteilt-den-eingang-nicht-automatisch-die-anwendung\"\u003e1. Anycast verteilt den Eingang, nicht automatisch die Anwendung\u003c/h2\u003e\n\u003cp\u003eBei Anycast wird dieselbe IP-Adresse von mehreren geografisch verteilten Netzwerkknoten angekündigt. Das Routing im Internet führt Pakete typischerweise zu einem aus Netzwerksicht geeigneten erreichbaren PoP. Dadurch existiert kein einzelner öffentlicher Einstiegspunkt, dessen Ausfall den gesamten Traffic blockieren muss. Eine verteilte Edge kann den Zugang damit robuster gegen Ausfälle einzelner Standorte oder Netzwerkpfade gestalten.\u003c/p\u003e\n\u003cp\u003eAnycast löst jedoch nicht die Frage, ob das dahinterliegende Backend verfügbar ist. Ein Edge-PoP kann erreichbar sein, während eine Anwendung, ein Cluster oder ein einzelner Service Fehler liefert. Ebenso kann ein Backend nur für bestimmte Protokolle oder Pfade gestört sein. Hochverfügbarkeit erfordert deshalb eine zweite Entscheidungsebene: Die Edge muss für neue Verbindungen ein gesundes Backend auswählen. Bei ayedo bildet die Anycast-basierte Edge mit mehreren verteilten PoPs und Aktiv-Aktiv-Prinzip die Eingangsebene; das Backend-Failover entscheidet anschließend über die erreichbaren Anwendungsziele.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-sind-die-grundlage-für-backend-failover\"\u003e2. Health Checks sind die Grundlage für Backend-Failover\u003c/h2\u003e\n\u003cp\u003eBackend-Failover beginnt mit der Frage, wann ein Ziel als nicht verfügbar gilt. Ein einfacher TCP-Check bestätigt lediglich, dass ein Port erreichbar ist. Für HTTP- oder HTTPS-Anwendungen kann zusätzlich relevant sein, ob ein definierter Endpunkt den erwarteten Status liefert. Ein zu oberflächlicher Check lässt fehlerhafte Backends im Pool; ein zu strenger Check entfernt funktionierende Ziele unnötig aus dem Routing.\u003c/p\u003e\n\u003cp\u003eEntscheidend ist außerdem die zeitliche Bewertung. Einzelne Paketverluste oder kurze Antwortverzögerungen dürfen nicht sofort zu einer instabilen Umschaltung führen. Umgekehrt darf die Erkennung eines tatsächlichen Ausfalls nicht so lange dauern, dass weitere Requests auf ein defektes Ziel treffen. Health Checks sollten daher zur Anwendung, zum Protokoll und zur Fehlerdomäne passen. Sie müssen außerdem zwischen Erreichbarkeit und Dienstfähigkeit unterscheiden. Für die ayedo Edge Cloud sind Backend Health Checks und Failover zentrale Bausteine, um Traffic dynamisch an verfügbare Ziele weiterzuleiten.\u003c/p\u003e\n\u003ch2 id=\"3-aktiv-aktiv-verändert-die-failover-logik\"\u003e3. Aktiv-Aktiv verändert die Failover-Logik\u003c/h2\u003e\n\u003cp\u003eIm Aktiv-Aktiv-Betrieb sind mehrere Backends gleichzeitig für Traffic vorgesehen. Failover bedeutet dann nicht primär, von einem aktiven auf einen passiven Server umzuschalten. Stattdessen wird die Menge der verfügbaren Ziele dynamisch angepasst: Ein gesundes Backend bleibt im Pool, ein fehlerhaftes wird für neue Verbindungen nicht mehr berücksichtigt. Der Traffic verteilt sich auf die verbleibenden Ziele, sofern diese die Last aufnehmen können.\u003c/p\u003e\n\u003cp\u003eDas reduziert die Abhängigkeit von einem definierten Primärpfad, stellt aber höhere Anforderungen an die Anwendung. Zustände müssen entweder repliziert, extern gehalten oder so behandelt werden, dass Requests zwischen Backends wechseln können. Auch Datenbankverbindungen, Sessions und lang laufende Streams benötigen eine eigene Betrachtung. Health Checks beeinflussen meist vor allem neue Verbindungen; bereits bestehende Sessions können bei einem Backend-Ausfall trotzdem abbrechen. Aktiv-Aktiv ist daher keine automatische Reparatur für zustandsbehaftete Workloads, sondern eine Architekturentscheidung mit Konsequenzen für Datenhaltung, Kapazitätsplanung und Fehlerbehandlung.\u003c/p\u003e\n\u003ch2 id=\"4-fehlerdomänen-und-betriebsgrenzen-müssen-getrennt-betrachtet-werden\"\u003e4. Fehlerdomänen und Betriebsgrenzen müssen getrennt betrachtet werden\u003c/h2\u003e\n\u003cp\u003eEin Backend-Ausfall, ein Edge-PoP-Ausfall und ein Fehler im Upstream-Routing sind unterschiedliche Ereignisse. Backend-Failover kann ein nicht erreichbares Anwendungsziel aus dem Pool entfernen. Es kann aber nicht jede Störung kompensieren, etwa wenn alle Backends betroffen sind oder eine gemeinsame Datenabhängigkeit ausfällt. Umgekehrt kann Anycast den Traffic zu einem anderen Edge-PoP führen, ohne dass das Backend selbst gewechselt wird.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist diese Trennung wichtig. Monitoring und Incident Response müssen erkennen lassen, ob der Fehler am öffentlichen Eingang, an der Verbindung zur Anwendung oder im Backend selbst liegt. Eine verteilte Aktiv-Aktiv-Architektur braucht deshalb Kapazitätsreserven, konsistente Konfigurationen und nachvollziehbare Health-Check-Signale. Die eigene Netzwerk-Infrastruktur und das eigene Autonomous System der ayedo Edge Cloud sind in diesem Zusammenhang relevant, weil die Edge als zusammenhängende, verteilte Eingangsschicht betrieben wird. Sie ersetzen jedoch keine resiliente Backend-Architektur.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern bei unterschiedlichen Providern. Beide Cluster sind aktiv und über die Edge erreichbar. Ein Health Check erkennt, dass der API-Service in einem Cluster zwar TCP-Verbindungen annimmt, aber den definierten HTTP-Endpunkt nicht mehr erfolgreich beantwortet. Die Edge berücksichtigt dieses Ziel für neue Verbindungen nicht weiter und verteilt den Traffic auf das verbleibende Backend. Der öffentliche DNS- oder Anycast-Einstieg bleibt unverändert. Gleichzeitig müssen Betreiber prüfen, ob das verbleibende Cluster ausreichend Kapazität besitzt und ob laufende Verbindungen kontrolliert beendet werden. Nach der Wiederherstellung darf das Backend nicht allein aufgrund eines einzelnen erfolgreichen Checks sofort wieder vollständig belastet werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-allein-ein-aktiv-aktiv-failover\"\u003eIst Anycast allein ein Aktiv-Aktiv-Failover?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast verteilt den öffentlichen Zugang auf erreichbare Edge-PoPs. Aktiv-Aktiv-Failover benötigt zusätzlich \u003ca href=\"/kubernetes/\"\u003eHealth Checks\u003c/a\u003e\n und eine dynamische Auswahl gesunder Backends.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-mit-bestehenden-verbindungen\"\u003eWas passiert mit bestehenden Verbindungen?\u003c/h3\u003e\n\u003cp\u003eDas hängt vom Protokoll und vom Fehler ab. Backend-Failover wirkt typischerweise auf neue Verbindungen. Bestehende Sessions können bei einem Backend-Ausfall abbrechen und müssen gegebenenfalls durch die Anwendung wiederaufgebaut werden.\u003c/p\u003e\n\u003ch3 id=\"kann-backend-failover-datenbankausfälle-kompensieren\"\u003eKann Backend-Failover Datenbankausfälle kompensieren?\u003c/h3\u003e\n\u003cp\u003eNein. Es kann Traffic von fehlerhaften Anwendungszielen fernhalten. Gemeinsame Datenbanken, Replikation und Zustandskonsistenz bleiben separate Anforderungen der Anwendung und ihrer Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit entsteht zwischen Edge und Compute, nicht ausschließlich an einer dieser Ebenen. Anycast und verteilte PoPs halten den öffentlichen Zugang belastbarer; \u003ca href=\"/kubernetes/\"\u003eHealth Checks\u003c/a\u003e\n und Backend-Failover sorgen dafür, dass neue Verbindungen verfügbare Anwendungsziele erreichen. Das Aktiv-Aktiv-Prinzip vermeidet einen einzelnen Primärpfad, verlangt aber konsistente Backends und ausreichende Reserven. Die ayedo Edge Cloud ordnet diese Funktionen in einer eigenen, verteilten Edge-Infrastruktur ein – unabhängig davon, wo die Kubernetes- oder sonstigen Backends betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR Aktiv-Aktiv-Failover entsteht nicht durch einen einzelnen Mechanismus, sondern durch das Zusammenspiel von Anycast, verteilten Edge-PoPs, belastbaren Health Checks und dynamischer Backend-Auswahl. Fällt ein Backend aus, muss die Edge den Zustand erkennen und neue Verbindungen gezielt an verfügbare Backends verteilen, ohne einen zentralen Primärpfad vorauszusetzen.\nEinleitung Ein häufiger Architekturfehler besteht darin, Anycast mit Hochverfügbarkeit gleichzusetzen. Eine global erreichbare IP-Adresse reduziert zwar die Abhängigkeit von einem einzelnen Einstiegspunkt, verhindert aber keinen Ausfall der Anwendung. Erst wenn die Edge den Zustand der Backends kontinuierlich bewertet und Routingentscheidungen daran ausrichtet, entsteht ein belastbarer Aktiv-Aktiv-Betrieb. Dabei wirken zwei Ebenen zusammen: Anycast und verteilte Edge-PoPs halten den öffentlichen Zugang verfügbar, während Backend-Failover den Datenverkehr innerhalb der verfügbaren Anwendungsinfrastruktur steuert. Die Qualität dieser Architektur hängt deshalb weniger von einem einzelnen Failover-Schalter ab als von der Fehlererkennung, der Auswahl geeigneter Ziele und dem Umgang mit bestehenden Verbindungen.\n", "image": "https://ayedo.de/anycast-und-backend-failover-im-aktiv-aktiv-betrieb.png", "date_published": "2026-09-08T17:04:58Z", "date_modified": "2026-09-08T17:04:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/netzwerk-routing-und-application-routing-trennen/", "url": "https://ayedo.de/posts/netzwerk-routing-und-application-routing-trennen/", "title": "Netzwerk-Routing und Application-Routing trennen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/netzwerk-routing-und-application-routing-trennen/netzwerk-routing-und-application-routing-trennen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eNetzwerk-Routing und Application-Routing lösen unterschiedliche Probleme. Anycast und Layer 4 bestimmen, wie Traffic einen Edge-Einstieg erreicht und zu welchem Transportziel weiterläuft. Layer 7 entscheidet dagegen anhand von Hostnames, Pfaden oder HTTP-Eigenschaften, welcher Service die Anfrage verarbeitet. Diese Ebenen müssen getrennt modelliert werden, damit Architektur, Betrieb und Fehlersuche beherrschbar bleiben.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, eine Anfrage vom öffentlichen Netzwerkpfad bis zum Backend als eine einzige Routingentscheidung zu betrachten. Dadurch werden Anycast, Layer-4-Weiterleitung und anwendungsbezogene Regeln vermischt. Das erschwert nicht nur die Fehlersuche: Auch Sicherheitsregeln, Health Checks und Failover greifen dann an Stellen, an denen sie ihre Wirkung nicht zuverlässig entfalten.\u003c/p\u003e\n\u003cp\u003eIn einer Edge-Architektur sollte deshalb klar sein, welche Entscheidung auf Basis von Netzwerk- und Transportinformationen getroffen wird und welche erst nach der Protokollterminierung möglich ist. Anycast bestimmt den erreichbaren Edge-Einstieg. Layer 4 arbeitet mit IP-Adressen, Ports und Transportprotokollen. Application-Routing auf Layer 7 versteht dagegen Hostnames, Pfade und HTTP-Services. Diese Trennung ist die Grundlage für vorhersehbare Betriebsmodelle.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-und-layer-4-bestimmen-den-transportpfad\"\u003e1. Anycast und Layer 4 bestimmen den Transportpfad\u003c/h2\u003e\n\u003cp\u003eAnycast ist zunächst eine Entscheidung auf Netzwerkebene. Mehrere Edge-Standorte oder PoPs können dieselbe IP-Adresse ankündigen. Das Routing im Internet führt eine Anfrage zu einem geeigneten erreichbaren Einstiegspunkt. Damit ist jedoch noch nicht entschieden, welche Anwendung oder welcher konkrete Service die Anfrage verarbeitet. Anycast beantwortet vor allem die Frage: Wo gelangt der Traffic in die Edge-Infrastruktur?\u003c/p\u003e\n\u003cp\u003eLayer 4 setzt auf diesem Transportpfad auf. Die Entscheidung basiert auf Informationen wie Ziel-IP, Port und Transportprotokoll, etwa TCP oder UDP. Ein Layer-4-Listener kann beispielsweise eingehende Verbindungen auf Port 443 an einen definierten Backend-Pool weiterleiten, ohne den HTTP-Inhalt der Verbindung auszuwerten.\u003c/p\u003e\n\u003cp\u003eDiese Trennung hat betriebliche Konsequenzen. Änderungen an IP- oder Portstrukturen betreffen den Transportpfad, während die Anwendung möglicherweise unverändert bleibt. Umgekehrt kann eine neue HTTP-Route eingeführt werden, ohne das Anycast- oder Layer-4-Modell zu verändern. Die ayedo Edge Cloud verbindet Anycast mit Layer-4- und Layer-7-Loadbalancing und stellt damit beide Steuerungsebenen innerhalb einer Edge-Plattform bereit.\u003c/p\u003e\n\u003ch2 id=\"2-application-routing-beginnt-mit-dem-anwendungsprotokoll\"\u003e2. Application-Routing beginnt mit dem Anwendungsprotokoll\u003c/h2\u003e\n\u003cp\u003eApplication-Routing wird erforderlich, sobald die Weiterleitung von Merkmalen der Anwendung abhängt. Bei HTTP und HTTPS können das Hostnames wie \u003ccode\u003eapi.example.com\u003c/code\u003e, Pfade wie \u003ccode\u003e/checkout\u003c/code\u003e oder Eigenschaften einer Anfrage sein. Ein Layer-7-Router kann dadurch mehrere virtuelle Services über einen gemeinsamen öffentlichen Einstieg unterscheiden.\u003c/p\u003e\n\u003cp\u003eDer Ablauf ist dabei logisch getrennt: Zuerst erreicht die Verbindung über Anycast und den passenden Transportport die Edge. Anschließend wird das Anwendungsprotokoll ausgewertet. Bei HTTPS kann TLS an der Edge terminiert werden, damit Hostname, Pfad und weitere HTTP-Merkmale für die Routingentscheidung verfügbar sind. Danach wird die Anfrage an den passenden Backend-Service verteilt.\u003c/p\u003e\n\u003cp\u003eDiese Ebene eignet sich auch für eine klare Trennung von APIs, Webanwendungen und einzelnen Services. Sie ersetzt aber nicht das Netzwerk-Routing. Ein Pfad kann nur ausgewertet werden, wenn die Verbindung den richtigen Edge-Einstieg erreicht und das Protokoll dies zulässt. Application-Routing ist daher keine alternative Bezeichnung für Anycast, sondern eine nachgelagerte Steuerungsebene mit anderem Informationsmodell und anderen Betriebsrisiken.\u003c/p\u003e\n\u003ch2 id=\"3-getrennte-ebenen-verbessern-security-und-fehlersuche\"\u003e3. Getrennte Ebenen verbessern Security und Fehlersuche\u003c/h2\u003e\n\u003cp\u003eDie Unterscheidung zwischen Netzwerk-Routing und Application-Routing wirkt sich direkt auf Security und Incident Response aus. Eine DDoS-Abwehr oder ein Layer-4-Filter arbeitet an einer anderen Stelle als eine Web Application Firewall, die HTTP-Anfragen auf Anwendungsmuster prüft. Werden diese Funktionen gedanklich vermischt, ist unklar, ob ein Problem beim Edge-Einstieg, bei der Transportverbindung oder bei der Anwendungsroute liegt.\u003c/p\u003e\n\u003cp\u003eAuch Backend Cloaking folgt diesem Prinzip. Das Backend muss nicht als öffentlich erreichbares Routingziel auftreten, wenn der öffentliche Eingang durch die Edge bereitgestellt wird. Die Edge kann Verbindungen annehmen, TLS terminieren, Regeln anwenden und den Traffic anschließend zu einem geschützten Backend weiterleiten. Layer-7-Regeln entscheiden dabei über die Zielanwendung; Netzwerk- und Transportmechanismen stellen die Verbindung dorthin bereit.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb sollten Metriken und Logs diese Ebenen getrennt abbilden: Erreichbarkeit des Anycast-Einstiegs, Verbindungsfehler auf Layer 4, Regelentscheidungen auf Layer 7 und Zustand der Backends. Health Checks und Failover müssen ebenfalls zum jeweiligen Modell passen. Ein erreichbarer TCP-Port beweist beispielsweise nicht, dass ein bestimmter API-Pfad korrekt arbeitet.\u003c/p\u003e\n\u003ch2 id=\"4-die-trennung-erleichtert-multi-cloud--und-kubernetes-architekturen\"\u003e4. Die Trennung erleichtert Multi-Cloud- und Kubernetes-Architekturen\u003c/h2\u003e\n\u003cp\u003eIn verteilten Umgebungen ändern sich Backends häufiger als der öffentliche Einstieg. Kubernetes-Services können verschoben, neue Cluster angebunden oder Workloads bei unterschiedlichen Providern betrieben werden. Wenn öffentliche IPs, Transportports und anwendungsbezogene Routen eng an einen einzelnen Cluster gekoppelt sind, werden solche Änderungen operativ aufwendig.\u003c/p\u003e\n\u003cp\u003eEin separates Application-Routing-Modell hält den öffentlichen Zugang stabiler. Hostnames und Pfade können an Backend-Pools oder Services gebunden werden, während sich deren konkrete Infrastruktur im Hintergrund ändert. Das ist besonders relevant, wenn mehrere \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Cluster oder Provider beteiligt sind. Die Kubernetes-native Integration der ayedo Edge Cloud kann dabei mit ayedo Managed Kubernetes ebenso genutzt werden wie mit eigenen oder bei anderen Providern betriebenen Clustern.\u003c/p\u003e\n\u003cp\u003eDie Plattform bleibt damit vom Compute-Ort getrennt: Die Edge übernimmt öffentlichen Traffic-Eingang, Routing, Schutz und Lastverteilung; die Compute-Infrastruktur führt die Workloads aus. Eigene Netzwerk-Infrastruktur, eigenes Autonomous System und eine Aktiv-Aktiv-Architektur sind in diesem Zusammenhang relevant, weil sie den Edge-Einstieg und dessen Betrieb als eigenständige Verantwortungsdomäne verankern. Sie machen Layer-7-Regeln jedoch nicht überflüssig.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung und eine API in zwei Kubernetes-Clusters. Beide nutzen einen gemeinsamen öffentlichen HTTPS-Einstieg. Anycast führt den Traffic zu einem erreichbaren Edge-PoP. Layer 4 nimmt TCP-Verbindungen auf Port 443 an. Erst nach der TLS-Terminierung entscheidet Layer 7: \u003ccode\u003ewww.example.com\u003c/code\u003e wird zur Webanwendung geleitet, \u003ccode\u003eapi.example.com/v1\u003c/code\u003e zur API.\u003c/p\u003e\n\u003cp\u003eFällt ein API-Backend aus, greift ein Health Check auf Pool- oder Serviceebene. Der Anycast-Einstieg muss deshalb nicht geändert werden. Würde die gesamte Logik nur über Netzwerkadressen modelliert, wären getrennte öffentliche Endpunkte oder manuelle Umschaltungen wahrscheinlicher. Das Beispiel zeigt: Der Transportpfad kann stabil bleiben, während sich das anwendungsbezogene Ziel verändert.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-bereits-application-routing\"\u003eIst Anycast bereits Application-Routing?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast bestimmt den erreichbaren Netzwerk-Einstieg anhand der Routinglogik des Internets. Application-Routing wertet anschließend anwendungsbezogene Informationen wie Hostnames oder Pfade aus.\u003c/p\u003e\n\u003ch3 id=\"wann-reicht-layer-4-aus\"\u003eWann reicht Layer 4 aus?\u003c/h3\u003e\n\u003cp\u003eLayer 4 reicht, wenn eine Weiterleitung anhand von IP, Port und Transportprotokoll genügt. Das ist beispielsweise bei nicht-HTTP-basierten Services oder bei TCP-Passthrough relevant.\u003c/p\u003e\n\u003ch3 id=\"warum-sollte-tls-an-der-edge-terminiert-werden\"\u003eWarum sollte TLS an der Edge terminiert werden?\u003c/h3\u003e\n\u003cp\u003eTLS-Terminierung an der Edge ermöglicht die Auswertung von HTTP-Informationen für Layer-7-Routing und Web Application Firewall. Ohne Terminierung bleiben solche Entscheidungen am öffentlichen Eingang eingeschränkt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eNetzwerk-Routing und Application-Routing sollten als getrennte, aber aufeinander aufbauende Steuerungsebenen modelliert werden. Anycast und Layer 4 sichern den Transportpfad zum Edge-Einstieg; Layer 7 ordnet Anfragen anschließend konkreten Anwendungen oder Services zu. Die ayedo Edge Cloud ist in diesem Modell keine reine Weiterleitungsschicht, sondern eine eigenständige Edge-Plattform vor wechselnden Backends und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Umgebungen.\u003c/p\u003e\n", "summary": "\nTL;DR Netzwerk-Routing und Application-Routing lösen unterschiedliche Probleme. Anycast und Layer 4 bestimmen, wie Traffic einen Edge-Einstieg erreicht und zu welchem Transportziel weiterläuft. Layer 7 entscheidet dagegen anhand von Hostnames, Pfaden oder HTTP-Eigenschaften, welcher Service die Anfrage verarbeitet. Diese Ebenen müssen getrennt modelliert werden, damit Architektur, Betrieb und Fehlersuche beherrschbar bleiben.\nEinleitung Ein häufiger Architekturfehler besteht darin, eine Anfrage vom öffentlichen Netzwerkpfad bis zum Backend als eine einzige Routingentscheidung zu betrachten. Dadurch werden Anycast, Layer-4-Weiterleitung und anwendungsbezogene Regeln vermischt. Das erschwert nicht nur die Fehlersuche: Auch Sicherheitsregeln, Health Checks und Failover greifen dann an Stellen, an denen sie ihre Wirkung nicht zuverlässig entfalten.\n", "image": "https://ayedo.de/netzwerk-routing-und-application-routing-trennen.png", "date_published": "2026-09-08T17:04:58Z", "date_modified": "2026-09-08T17:04:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","security","kubernetes","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/proxy-protocol-im-backend-pool-korrekt-einsetzen/", "url": "https://ayedo.de/posts/proxy-protocol-im-backend-pool-korrekt-einsetzen/", "title": "Proxy Protocol im Backend-Pool korrekt einsetzen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/proxy-protocol-im-backend-pool-korrekt-einsetzen/proxy-protocol-im-backend-pool-korrekt-einsetzen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProxy Protocol überträgt Verbindungsinformationen aus einem Proxy- oder Loadbalancing-Layer an das Backend. Damit können Anwendungen die ursprüngliche Client-IP und weitere Transportdaten auswerten. Voraussetzung sind ein abgestimmtes Protokoll, kompatible Listener und eine konsistente Konfiguration im gesamten Backend-Pool.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eProxy Protocol ist kein optionales Detail im Loadbalancing, sondern ein Integrationsvertrag zwischen Edge und Backend. Wird es an der ayedo Edge Cloud aktiviert, erwartet jedes Zielsystem im entsprechenden Backend-Pool die zusätzliche Protokollzeile vor der eigentlichen Anwendungskommunikation. Ein gewöhnlicher TCP- oder HTTP-Listener kann diese Daten nicht automatisch interpretieren. Die Folge sind abgewiesene Verbindungen, fehlerhafte Client-IP-Auswertung oder schwer nachvollziehbare Unterschiede zwischen einzelnen Backends. Entscheidend ist daher nicht nur, ob Proxy Protocol grundsätzlich unterstützt wird. Entscheidend ist, ob Edge, Protokolltyp, Listener und Anwendung dieselbe Annahme über den Verbindungsaufbau teilen.\u003c/p\u003e\n\u003ch2 id=\"1-welche-informationen-proxy-protocol-weitergibt\"\u003e1. Welche Informationen Proxy Protocol weitergibt\u003c/h2\u003e\n\u003cp\u003eEin Proxy beendet die ursprüngliche TCP-Verbindung des Clients und baut zum Backend eine neue Verbindung auf. Ohne zusätzliche Metadaten sieht das Backend deshalb zunächst die Quelladresse des Edge-Systems. Für Zugriffskontrollen, Rate Limits, Audit-Logs oder forensische Analysen kann diese Information unzureichend sein.\u003c/p\u003e\n\u003cp\u003eProxy Protocol ergänzt die neue Verbindung um Verbindungsinformationen der ursprünglichen Sitzung. Dazu gehören typischerweise Quell- und Zieladresse sowie die verwendeten Ports. Das Backend kann dadurch zwischen Edge-Verbindung und ursprünglichem Client unterscheiden, ohne diese Informationen aus anwendungsspezifischen Headern ableiten zu müssen.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Abgrenzung zu HTTP-Headern wie \u003ccode\u003eX-Forwarded-For\u003c/code\u003e: Proxy Protocol arbeitet auf der Transportebene und ist deshalb auch für TCP-Dienste relevant. Es ersetzt jedoch keine Authentisierung und beweist nicht, dass die übermittelten Daten aus einer vertrauenswürdigen Quelle stammen. Das Backend muss Proxy Protocol nur auf dem dafür vorgesehenen, kontrollierten Eingang akzeptieren.\u003c/p\u003e\n\u003ch2 id=\"2-der-backend-pool-als-protokollvertrag\"\u003e2. Der Backend-Pool als Protokollvertrag\u003c/h2\u003e\n\u003cp\u003eDie Aktivierung von Proxy Protocol ist eine Eigenschaft des Zusammenspiels aus Edge und Backend-Pool. Die ayedo Edge Cloud kann Verbindungen per Proxy Protocol an Backends weitergeben. Ob diese Verbindungen erfolgreich verarbeitet werden, hängt anschließend vom Listener des jeweiligen Zielsystems ab.\u003c/p\u003e\n\u003cp\u003eEin Backend-Pool sollte deshalb nicht nur nach Erreichbarkeit, Port und Health Check modelliert werden. Auch die erwartete Verbindungsform gehört zur Pool-Definition. Alle Ziele eines Pools müssen denselben Protokollvertrag erfüllen: Sie müssen Proxy Protocol am verwendeten Listener akzeptieren und die nachfolgenden Daten korrekt an den Dienst weiterreichen.\u003c/p\u003e\n\u003cp\u003eEin häufiger Fehler ist die Mischung inkompatibler Ziele. Ein Pool enthält beispielsweise einen für Proxy Protocol konfigurierten Ingress und zusätzlich einen direkten TCP-Dienst. Der Loadbalancer kann beide Ziele technisch erreichen, aber nur eines versteht den Verbindungsbeginn. Health Checks können dabei irreführend sein, wenn sie einen anderen Listener oder eine andere Prüfmethodik verwenden als der reale Traffic. Protokollkompatibilität muss daher ausdrücklich getestet werden.\u003c/p\u003e\n\u003ch2 id=\"3-protokollkompatibilität-entlang-der-verbindung\"\u003e3. Protokollkompatibilität entlang der Verbindung\u003c/h2\u003e\n\u003cp\u003eProxy Protocol wird vor der eigentlichen Nutzlast übertragen. Der empfangende Listener muss diese Information erkennen, verarbeiten und anschließend den ursprünglichen Datenstrom an die Anwendung weitergeben. Ist der Listener ausschließlich für unveränderte TLS-, HTTP- oder proprietäre TCP-Daten ausgelegt, interpretiert er den Proxy-Header als ungültige Nutzlast.\u003c/p\u003e\n\u003cp\u003eDas betrifft mehrere Schichten: den externen Listener des Ingress, einen möglichen Sidecar oder Reverse Proxy und den eigentlichen Anwendungsprozess. Bereits eine nicht kompatible Zwischenkomponente kann die Verbindung abbrechen. Bei TLS ist besonders wichtig, dass Proxy Protocol vor dem TLS-Handshake ankommt und der TLS-Listener diese Reihenfolge unterstützt. Proxy Protocol verschlüsselt die Metadaten nicht selbst.\u003c/p\u003e\n\u003cp\u003eAuch die eingesetzte Variante muss zusammenpassen. Die textbasierte und die binäre Variante unterscheiden sich in Aufbau und Parser-Verhalten. Wird am Edge eine Variante erwartet, die der Listener nicht unterstützt, entsteht kein belastbarer Fallback. Deshalb gehören Protokollvariante, Transporttyp und Listener-Verhalten in die technische Schnittstellenbeschreibung des Dienstes.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsfehler-systematisch-vermeiden\"\u003e4. Betriebsfehler systematisch vermeiden\u003c/h2\u003e\n\u003cp\u003eDie häufigsten Fehler entstehen durch Konfigurationsänderungen ohne Pool-weite Betrachtung. Wird Proxy Protocol am Edge aktiviert, aber nur ein Teil der Backends angepasst, erscheinen Ausfälle zunächst wie zufällige Health- oder Netzwerkprobleme. Tatsächlich hängt die Verfügbarkeit dann davon ab, welches Ziel der Loadbalancer auswählt.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb sind getrennte Pools mit eindeutigem Protokollverhalten meist robuster als ein gemischter Pool. Migrationen sollten schrittweise erfolgen: zunächst einen kompatiblen Listener bereitstellen, anschließend mit realistischen Verbindungen testen und erst danach weitere Ziele aufnehmen. Logs müssen den Verbindungsaufbau am Listener, die erkannte Client-Adresse und mögliche Parserfehler sichtbar machen.\u003c/p\u003e\n\u003cp\u003eBesondere Aufmerksamkeit verdient die Vertrauensgrenze. Ein Backend darf die im Proxy Protocol enthaltene Quelladresse nur dann für Sicherheitsentscheidungen verwenden, wenn ausschließlich bekannte Edge-Pfade diesen Listener erreichen können. Wird derselbe Port direkt aus dem Internet oder aus unkontrollierten Netzen zugänglich, kann ein Angreifer falsche Verbindungsinformationen einspeisen. Proxy Protocol verbessert damit die Transparenz, ersetzt aber keine Netzwerksegmentierung und keine Zugriffskontrolle.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen HTTPS-Service auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und einen TCP-basierten Legacy-Dienst auf virtuellen Maschinen. Beide sollen über die ayedo Edge Cloud erreichbar sein. Für den HTTPS-Service wird ein Ingress eingesetzt, dessen Listener Proxy Protocol versteht. Der Legacy-Dienst verwendet dagegen weiterhin einen Standard-TCP-Listener.\u003c/p\u003e\n\u003cp\u003eBeide Zielsysteme in einem gemeinsamen Backend-Pool zu führen, wäre falsch: Die ayedo Edge Cloud würde denselben Verbindungsaufbau an unterschiedliche Listener liefern. Stattdessen werden getrennte Pools mit jeweils passender Protokollvereinbarung definiert. Der HTTPS-Pool verarbeitet Proxy Protocol bis zum kompatiblen Ingress; der Legacy-Pool erhält nur Verbindungen, deren Zielsystem den vereinbarten Transport tatsächlich unterstützt. Ein eigener Health Check pro Pool prüft zusätzlich den richtigen Listener und nicht nur die Erreichbarkeit des Hosts.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-proxy-protocol-nur-für-http-dienste-relevant\"\u003eIst Proxy Protocol nur für HTTP-Dienste relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Proxy Protocol arbeitet auf der Transportebene und kann auch TCP-Dienste mit ursprünglichen Verbindungsinformationen versorgen. Der jeweilige Listener muss das Protokoll jedoch explizit unterstützen.\u003c/p\u003e\n\u003ch3 id=\"kann-proxy-protocol-durch-http-header-ersetzt-werden\"\u003eKann Proxy Protocol durch HTTP-Header ersetzt werden?\u003c/h3\u003e\n\u003cp\u003eBei HTTP können Forwarding-Header Clientinformationen übertragen. Das ist aber nicht gleichwertig für TCP-Dienste und erfordert Vertrauen in die Header-Kette. Proxy Protocol liegt unterhalb der Anwendungsschicht.\u003c/p\u003e\n\u003ch3 id=\"warum-funktionieren-health-checks-trotz-fehlerhaftem-proxy-protocol\"\u003eWarum funktionieren Health Checks trotz fehlerhaftem Proxy Protocol?\u003c/h3\u003e\n\u003cp\u003eEin Health Check kann einen anderen Port, Listener oder Verbindungsaufbau verwenden als der produktive Traffic. Erreichbarkeit allein bestätigt daher nicht, dass der Backend-Dienst Proxy Protocol korrekt verarbeitet.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProxy Protocol ist ein klar zu definierender Integrationspunkt zwischen Edge-Proxy und Backend-Dienst. Die technische Frage lautet nicht nur, ob Client-IP-Informationen benötigt werden, sondern welcher Listener sie in welcher Form und unter welcher Vertrauensgrenze verarbeitet. In der ayedo Edge Cloud gehört diese Entscheidung zur Abstimmung des Backend-Pools. Sauber getrennte Pools, kompatible Listener und passende Health Checks verhindern, dass aus einer kleinen Protokollabweichung ein intermittierendes Betriebsproblem wird.\u003c/p\u003e\n", "summary": "\nTL;DR Proxy Protocol überträgt Verbindungsinformationen aus einem Proxy- oder Loadbalancing-Layer an das Backend. Damit können Anwendungen die ursprüngliche Client-IP und weitere Transportdaten auswerten. Voraussetzung sind ein abgestimmtes Protokoll, kompatible Listener und eine konsistente Konfiguration im gesamten Backend-Pool.\nEinleitung Proxy Protocol ist kein optionales Detail im Loadbalancing, sondern ein Integrationsvertrag zwischen Edge und Backend. Wird es an der ayedo Edge Cloud aktiviert, erwartet jedes Zielsystem im entsprechenden Backend-Pool die zusätzliche Protokollzeile vor der eigentlichen Anwendungskommunikation. Ein gewöhnlicher TCP- oder HTTP-Listener kann diese Daten nicht automatisch interpretieren. Die Folge sind abgewiesene Verbindungen, fehlerhafte Client-IP-Auswertung oder schwer nachvollziehbare Unterschiede zwischen einzelnen Backends. Entscheidend ist daher nicht nur, ob Proxy Protocol grundsätzlich unterstützt wird. Entscheidend ist, ob Edge, Protokolltyp, Listener und Anwendung dieselbe Annahme über den Verbindungsaufbau teilen.\n", "image": "https://ayedo.de/proxy-protocol-im-backend-pool-korrekt-einsetzen.png", "date_published": "2026-09-08T17:04:58Z", "date_modified": "2026-09-08T17:04:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","compliance","kubernetes","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/tls-termination-an-der-edge-routing-sicher-gestalten/", "url": "https://ayedo.de/posts/tls-termination-an-der-edge-routing-sicher-gestalten/", "title": "TLS Termination an der Edge: Routing sicher gestalten", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-termination-an-der-edge-routing-sicher-gestalten/tls-termination-an-der-edge-routing-sicher-gestalten.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eTLS Termination beendet die äußere HTTPS-Verbindung an der Edge und schafft den technischen Übergabepunkt für anwendungsbezogenes Routing. Damit werden Host-, Pfad- und Header-Regeln möglich. Die Architektur muss jedoch klar festlegen, welche Sicherheits- und Routingaufgaben die Edge übernimmt und welche Kontrolle beim Backend verbleibt.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eTLS Termination ist keine reine Performance- oder Komfortfunktion. Sie verändert den Punkt, an dem verschlüsselter Client-Traffic sichtbar, geprüft und anhand von Layer-7-Merkmalen verteilt werden kann. Ein typischer Architekturfehler besteht darin, HTTPS an der Edge zu beenden, danach aber keine klare Trennung zwischen Edge-Routing und Backend-Verantwortung zu definieren. Dann entstehen unklare Vertrauensgrenzen, widersprüchliche Routingregeln oder unnötige Abhängigkeiten von einzelnen Infrastrukturen. Entscheidend ist deshalb nicht nur, \u003cem\u003ewo\u003c/em\u003e TLS endet, sondern auch, welche Informationen dort ausgewertet werden und wie der Traffic anschließend kontrolliert an Anwendungen und APIs übergeben wird.\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-schafft-einen-kontrollierten-übergabepunkt\"\u003e1. TLS Termination schafft einen kontrollierten Übergabepunkt\u003c/h2\u003e\n\u003cp\u003eBei einer TLS-Verbindung verschlüsselt der Client den HTTP-Traffic bis zum Terminierungspunkt. Erfolgt die TLS Termination an der Edge, wird die äußere Verbindung dort angenommen, der TLS-Handshake durchgeführt und die Anfrage für die weitere Verarbeitung zugänglich gemacht. Erst dadurch lassen sich HTTP-Attribute wie Hostname, Pfad, Methode oder bestimmte Header für Layer-7-Routing verwenden.\u003c/p\u003e\n\u003cp\u003eArchitektonisch entsteht damit eine klare Übergabe: Die Edge verantwortet den öffentlichen Zugang, die TLS-Verarbeitung und die erste Traffic-Steuerung. Das Backend muss nicht selbst den gesamten öffentlichen HTTPS-Eingang abbilden. Diese Trennung reduziert die Zahl direkt exponierter Komponenten und unterstützt Backend Cloaking, weil interne Zielsysteme nicht als öffentliche Endpunkte auftreten müssen.\u003c/p\u003e\n\u003cp\u003eDie Edge wird dadurch allerdings zu einer sicherheitsrelevanten Vertrauensgrenze. Zertifikatsverwaltung, erlaubte Protokolle, Routingregeln und der Umgang mit weitergereichten Anfrageinformationen müssen zusammen betrachtet werden. TLS Termination ist daher eine Architekturentscheidung über Zuständigkeiten, nicht nur eine Einstellung am Loadbalancer.\u003c/p\u003e\n\u003ch2 id=\"2-layer-7-routing-braucht-belastbare-entscheidungsregeln\"\u003e2. Layer-7-Routing braucht belastbare Entscheidungsregeln\u003c/h2\u003e\n\u003cp\u003eNach der TLS Termination kann die Edge HTTPS Routing auf Anwendungsebene umsetzen. Typische Regeln unterscheiden beispielsweise zwischen mehreren Hostnames, API-Pfaden oder Versionen eines Dienstes. So kann \u003ccode\u003eapi.example.de\u003c/code\u003e zu einem anderen Backend führen als \u003ccode\u003eapp.example.de\u003c/code\u003e; ebenso kann \u003ccode\u003e/v1\u003c/code\u003e getrennt von \u003ccode\u003e/v2\u003c/code\u003e behandelt werden. Layer-7-Regeln verbinden damit den öffentlichen Einstiegspunkt mit der logischen Struktur der Anwendungen.\u003c/p\u003e\n\u003cp\u003eDiese Flexibilität erhöht aber die Komplexität. Routing sollte nicht auf zufällig variierenden Headern, impliziten Reihenfolgen oder schwer nachvollziehbaren Ausnahmen beruhen. Sinnvoll sind deterministische Regeln mit klarer Priorität, dokumentierten Fallbacks und einem definierten Verhalten bei unbekannten Hosts oder Pfaden. Andernfalls können neue Services versehentlich über bestehende Regeln erreichbar werden.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist außerdem wichtig, dass die Edge den Zustand der Backends berücksichtigt. Health Checks und Failover verhindern, dass Traffic dauerhaft an nicht verfügbare Ziele geleitet wird. Die ayedo Edge Cloud verbindet TLS Termination mit Layer-4- und Layer-7-Loadbalancing sowie Backend Health Checks. Damit wird Routing nicht als statische Weiterleitung, sondern als kontrollierter Teil des öffentlichen Traffic-Eingangs behandelt.\u003c/p\u003e\n\u003ch2 id=\"3-die-tls-strecke-zum-backend-muss-bewusst-definiert-werden\"\u003e3. Die TLS-Strecke zum Backend muss bewusst definiert werden\u003c/h2\u003e\n\u003cp\u003eMit dem Ende der Client-TLS-Verbindung ist die Kommunikation nicht automatisch auf jedem Abschnitt gleich geschützt. Zwischen Edge und Backend kann abhängig von der Zielarchitektur eine neue verschlüsselte Verbindung oder eine andere abgesicherte Transportstrecke erforderlich sein. Diese Entscheidung hängt von Schutzbedarf, Netzwerksegmentierung, Compliance-Vorgaben und den Fähigkeiten der nachgelagerten Plattform ab.\u003c/p\u003e\n\u003cp\u003eWichtig ist, die externe und die interne Identität einer Anfrage sauber auseinanderzuhalten. Das Backend muss erkennen können, ob eine Anfrage ursprünglich über HTTPS eingegangen ist, welchen Hostnamen sie adressierte und unter welchem Pfad sie geroutet wurde. Solche Informationen dürfen nicht unkontrolliert aus beliebigen Client-Headern übernommen werden. Sie müssen an der Vertrauensgrenze konsistent gesetzt, validiert und im Backend entsprechend ausgewertet werden.\u003c/p\u003e\n\u003cp\u003eAuch die Quelladresse verdient Aufmerksamkeit. Für Logging, Rate Limiting oder Sicherheitsanalysen kann die ursprüngliche Client-IP relevant sein. Verfahren wie Proxy Protocol können diese Information transportieren, sofern die Backend-Seite sie sicher und korrekt verarbeitet. Entscheidend bleibt: Die Edge definiert die Übergabe, das Backend muss die übergebenen Metadaten in seiner Vertrauenszone korrekt behandeln.\u003c/p\u003e\n\u003ch2 id=\"4-edge-und-backend-brauchen-getrennte-verantwortlichkeiten\"\u003e4. Edge und Backend brauchen getrennte Verantwortlichkeiten\u003c/h2\u003e\n\u003cp\u003eDie Edge sollte den öffentlichen Traffic-Eingang steuern, aber nicht die fachliche Logik der Anwendung ersetzen. Sie entscheidet, welches Backend eine Anfrage erreicht, kann den Zugang absichern und fehlerhafte oder unerwünschte Muster bereits vor der Anwendung abweisen. Das Backend bleibt für Authentisierung, Autorisierung, Geschäftslogik und die fachliche Validierung zuständig.\u003c/p\u003e\n\u003cp\u003eDiese Trennung wirkt sich direkt auf den Betrieb aus. Routingänderungen, Failover und die Verteilung eingehender Last können unabhängig vom Deployment einzelner Anwendungen organisiert werden. Gleichzeitig dürfen Edge-Regeln nicht zum zweiten, unkoordinierten Konfigurationssystem neben Ingress- oder Gateway-Konfigurationen im Cluster werden. Zuständigkeiten, Änderungsprozesse und Rollback-Verfahren müssen deshalb festgelegt sein.\u003c/p\u003e\n\u003cp\u003eDas gilt auch bei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n: Die Integration der Edge kann mit ayedo Managed Kubernetes erfolgen, aber ebenso mit eigenen oder bei anderen Providern betriebenen Clustern. Die Edge bleibt dabei eine eigenständige Plattform für öffentlichen Zugang, TLS Termination und Traffic-Steuerung. Diese providerunabhängige Nutzung verhindert, dass HTTPS Routing automatisch an den Lebenszyklus eines bestimmten Compute-Clusters gekoppelt wird.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-zwei-anwendungen-ein-öffentlicher-einstieg\"\u003ePraxisszenario: Zwei Anwendungen, ein öffentlicher Einstieg\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung und eine API in getrennten Kubernetes-Clustern. Beide sollen unter einer gemeinsamen Domain erreichbar sein. TLS wird an der Edge terminiert. Eine Layer-7-Regel leitet \u003ccode\u003e/api\u003c/code\u003e an das API-Backend, alle übrigen Pfade an die Webanwendung. Fällt das API-Backend aus, greifen dessen Health Checks und Failover-Regeln, ohne das Routing der Webanwendung zu verändern.\u003c/p\u003e\n\u003cp\u003eDie Backends bleiben nicht direkt öffentlich adressierbar. Für die Auswertung von Logs und Zugriffskontrollen werden die relevanten Ursprungsinformationen kontrolliert übergeben. Die Cluster können unabhängig voneinander betrieben oder ersetzt werden, während der öffentliche TLS-Endpunkt und die grundlegende Routingstruktur an der Edge bestehen bleiben.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-tls-immer-bis-zum-backend-durchgehend-bestehen\"\u003eMuss TLS immer bis zum Backend durchgehend bestehen?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Die passende Transportabsicherung zwischen Edge und Backend hängt von Schutzbedarf, Netzwerkarchitektur und Vertrauensgrenzen ab. Sie muss ausdrücklich festgelegt und technisch umgesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"welche-informationen-eignen-sich-für-layer-7-routing\"\u003eWelche Informationen eignen sich für Layer-7-Routing?\u003c/h3\u003e\n\u003cp\u003eTypische Kriterien sind Hostname, Pfad und HTTP-Methode. Regeln sollten stabil, nachvollziehbar und priorisiert sein. Zufällige oder ungeprüfte Header sind als Routinggrundlage problematisch.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-tls-termination-die-anwendungssicherheit\"\u003eErsetzt TLS Termination die Anwendungssicherheit?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge schützt und steuert den öffentlichen Zugang. Authentisierung, Autorisierung, Eingabevalidierung und Geschäftslogik bleiben Verantwortlichkeiten der Anwendung beziehungsweise ihrer Backend-Dienste.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eTLS Termination an der Edge ist ein architektonischer Übergabepunkt: Von der verschlüsselten öffentlichen Verbindung führt der Weg zu kontrolliertem Layer-7-Routing und definierten Backend-Zuständigkeiten. Wer diese Grenze sauber gestaltet, kann öffentliche Erreichbarkeit, Backend Cloaking und providerunabhängigen Betrieb miteinander verbinden. Die ayedo Edge Cloud ist in diesem Modell nicht lediglich ein vorgeschalteter Loadbalancer, sondern die Plattform für TLS-Verarbeitung, Traffic-Eingang und die strukturierte Übergabe an unterschiedliche Compute-Umgebungen.\u003c/p\u003e\n", "summary": "\nTL;DR TLS Termination beendet die äußere HTTPS-Verbindung an der Edge und schafft den technischen Übergabepunkt für anwendungsbezogenes Routing. Damit werden Host-, Pfad- und Header-Regeln möglich. Die Architektur muss jedoch klar festlegen, welche Sicherheits- und Routingaufgaben die Edge übernimmt und welche Kontrolle beim Backend verbleibt.\nEinleitung TLS Termination ist keine reine Performance- oder Komfortfunktion. Sie verändert den Punkt, an dem verschlüsselter Client-Traffic sichtbar, geprüft und anhand von Layer-7-Merkmalen verteilt werden kann. Ein typischer Architekturfehler besteht darin, HTTPS an der Edge zu beenden, danach aber keine klare Trennung zwischen Edge-Routing und Backend-Verantwortung zu definieren. Dann entstehen unklare Vertrauensgrenzen, widersprüchliche Routingregeln oder unnötige Abhängigkeiten von einzelnen Infrastrukturen. Entscheidend ist deshalb nicht nur, wo TLS endet, sondern auch, welche Informationen dort ausgewertet werden und wie der Traffic anschließend kontrolliert an Anwendungen und APIs übergeben wird.\n", "image": "https://ayedo.de/tls-termination-an-der-edge-routing-sicher-gestalten.png", "date_published": "2026-09-08T17:04:58Z", "date_modified": "2026-09-08T17:04:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","kubernetes","cloud-native","development"], "language": "de" },{ "id": "https://ayedo.de/posts/anycast-im-traffic-management-routing-bis-zum-backend/", "url": "https://ayedo.de/posts/anycast-im-traffic-management-routing-bis-zum-backend/", "title": "Anycast im Traffic-Management: Routing bis zum Backend", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-im-traffic-management-routing-bis-zum-backend/anycast-im-traffic-management-routing-bis-zum-backend.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAnycast Traffic Management beginnt mit einem global erreichbaren Einstiegspunkt, endet aber nicht am nächstgelegenen Edge-Standort. Anycast \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n führt den Traffic zu einer Edge-Instanz; dort entscheiden Layer-4- und Layer-7-Regeln über Backend-Pools, Health Status und gegebenenfalls Application-Routing. Erst diese Trennung schafft einen kontrollierbaren Pfad bis zur Anwendung.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eAnycast wird häufig als Antwort auf die Frage verstanden, welcher Standort eine Anfrage entgegennimmt. Für belastbares Traffic-Management greift diese Sicht zu kurz. Das Netzwerk bestimmt zunächst, an welchem Edge-Punkt ein Paket verarbeitet wird. Erst danach entstehen Entscheidungen über Protokoll, Hostname, Pfad, Port, Backend-Pool und Failover. Wer Anycast \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n direkt mit Application-Routing gleichsetzt, vermischt zwei unterschiedliche Steuerungsebenen und erschwert Betrieb sowie Fehlersuche. Eine Edge-Architektur muss daher den Weg vom öffentlichen Einstiegspunkt bis zum konkreten Backend nachvollziehbar machen. Genau dort liegt der technische Wert von Anycast in der ayedo Edge Cloud: als Eingang in eine verteilte, aktiv-aktive Traffic-Management-Plattform.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-ist-der-globale-netzwerk-einstieg\"\u003e1. Anycast ist der globale Netzwerk-Einstieg\u003c/h2\u003e\n\u003cp\u003eBei Anycast kündigen mehrere Edge-Standorte dieselbe IP-Adresse über das Routing an. Ein Client adressiert damit keinen einzelnen Server, sondern einen verteilten Dienst. Das Internet-Routing führt den Traffic zu einem aus Netzwerksicht geeigneten Ankündigungspunkt. Diese Auswahl basiert auf Routinginformationen und Netzwerktopologie, nicht automatisch auf der physisch kürzesten Entfernung oder der aktuell besten Anwendungslatenz.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist diese Unterscheidung wichtig. Anycast \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n legt fest, wo eine Verbindung in die Edge eintritt. Es entscheidet noch nicht, welches Backend die Anfrage verarbeitet. Fällt ein Edge-Standort oder eine Route aus, können andere Ankündigungspunkte den öffentlichen Dienst weiter erreichbar machen. Dafür braucht es eine konsistente Adress- und Routingarchitektur. Die ayedo Edge Cloud nutzt dafür ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur in einer verteilten Multi-PoP-Architektur. Das Aktiv-Aktiv-Prinzip vermeidet, dass ein einzelner Standort zum impliziten zentralen Eingang wird.\u003c/p\u003e\n\u003ch2 id=\"2-von-der-edge-annahme-zum-kontrollierten-pfad\"\u003e2. Von der Edge-Annahme zum kontrollierten Pfad\u003c/h2\u003e\n\u003cp\u003eNach dem Eintritt in die Edge wird der Traffic nicht einfach an irgendeinen verfügbaren Server weitergeleitet. Die Edge übernimmt zunächst die Verarbeitung auf der passenden Ebene: Layer 4 für verbindungsorientiertes Traffic-Management oder Layer 7 für HTTP- und HTTPS-Anfragen. Abhängig vom Dienst können dabei TLS Termination, WAF-Prüfungen oder weitere Routingbedingungen relevant sein. Diese Funktionen verändern den Charakter des öffentlichen Einstiegs: Die Edge ist nicht nur Transitpunkt, sondern kontrollierte Verarbeitungsschicht.\u003c/p\u003e\n\u003cp\u003eDer Pfad zum Backend wird dadurch von der öffentlichen Netzwerktopologie entkoppelt. Backends müssen nicht selbst global angekündigt werden und können gegenüber dem Internet verborgen bleiben. Backend Cloaking reduziert die direkte Angriffs- und Abhängigkeitfläche, ersetzt aber keine saubere Segmentierung oder Anwendungssicherheit. Für die Weitergabe von Verbindungsinformationen kann Proxy Protocol eingesetzt werden, sofern das Backend diese Übergabe unterstützt. Die Edge Cloud bündelt damit Netzwerk-Einstieg, Schutz und Weiterleitung, während die Anwendung weiterhin in einer getrennten Compute-Infrastruktur betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"3-backend-pools-verbinden-routing-mit-betriebszustand\"\u003e3. Backend-Pools verbinden Routing mit Betriebszustand\u003c/h2\u003e\n\u003cp\u003eDie Zuordnung zu einem Backend entsteht typischerweise über Pools. Ein Pool fasst geeignete Backends für einen Dienst zusammen; Health Checks liefern den Betriebszustand, auf dessen Basis die Edge verfügbare Ziele berücksichtigt. So wird aus dem globalen Anycast-Einstieg ein konkreter Weiterleitungspfad. Fällt ein Backend aus, kann Traffic innerhalb des Pools neu verteilt oder auf einen anderen Pool beziehungsweise Failover-Pfad gelenkt werden.\u003c/p\u003e\n\u003cp\u003eDiese Logik ist von Anycast \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n zu unterscheiden. Anycast entscheidet über den Edge-Einstieg, Health Checks und Pool-Regeln über die Weiterleitung dahinter. Beide Ebenen müssen dennoch zusammenpassen: Ein erreichbarer Edge-Punkt kann sonst Traffic an einen vollständig ausgefallenen Backend-Pool senden. Für SRE- und Plattformteams bedeutet das, Routing, Pool-Zustand und Backend-Fehler getrennt zu beobachten. Traffic- und Usage-Statistiken helfen dabei, die tatsächlich genutzten Pfade zu prüfen und Fehlannahmen über Erreichbarkeit oder Auslastung zu vermeiden.\u003c/p\u003e\n\u003ch2 id=\"4-application-routing-beginnt-erst-hinter-dem-netzwerk\"\u003e4. Application-Routing beginnt erst hinter dem Netzwerk\u003c/h2\u003e\n\u003cp\u003eApplication-Routing arbeitet auf einer anderen Abstraktionsebene als Anycast. Ein DNS-Name oder eine Anycast-IP bringt die Anfrage zur Edge. Erst dort können HTTP-Attribute wie Hostname, URL-Pfad oder weitere anwendungsnahe Kriterien die Auswahl eines Backend-Pools beeinflussen. Bei Layer-4-Diensten stehen dagegen Verbindungsparameter wie IP-Adresse und Port im Vordergrund. Die konkrete Routinglogik muss deshalb zum Protokoll und zur Anwendung passen.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist auch bei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n relevant. Ein Cluster kann bei ayedo Managed Kubernetes, in einer eigenen Umgebung oder bei einem anderen Provider betrieben werden. Die Edge Cloud bleibt dabei der öffentliche Eingang und ordnet Traffic geeigneten Backend-Pools zu; der Kubernetes-Service bleibt Teil der Compute- und Anwendungsebene. Das verhindert, dass Application-Routing an einen einzelnen Cluster oder Provider gekoppelt wird. Gleichzeitig müssen Zuständigkeiten klar dokumentiert sein: Die Edge entscheidet über den externen Pfad, die Anwendung über interne Service- und Requestlogik.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei Kubernetes-Clustern bei unterschiedlichen Providern. Beide Cluster werden über dieselbe Anycast-IP veröffentlicht. Das Anycast \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n führt Clientverbindungen zu einem Edge-Punkt. Nach TLS Termination und einer Layer-7-Regel für den API-Host wählt die Edge den passenden Backend-Pool. Health Checks markieren fehlerhafte Ziele; bei einem Ausfall kann der Traffic auf den verfügbaren Pool des zweiten Clusters wechseln.\u003c/p\u003e\n\u003cp\u003eIn diesem Modell bleibt die öffentliche Adresse stabil, obwohl sich die Compute-Zuordnung ändert. Ein reines DNS-basiertes Verfahren würde zusätzlich von Cachezeiten und Resolververhalten abhängen. Ein direkter Backend-Zugriff würde dagegen die Cluster und ihre Provider öffentlich exponieren. Anycast, Pool-Auswahl und Application-Routing erfüllen hier jeweils eine klar getrennte Aufgabe.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-automatisch-der-schnellste-weg-zum-backend\"\u003eIst Anycast automatisch der schnellste Weg zum Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast bestimmt den Edge-Einstieg anhand des Internet-Routings. Die Backend-Zuordnung erfolgt anschließend durch Edge-Regeln, Pool-Logik und Health Checks.\u003c/p\u003e\n\u003ch3 id=\"kann-anycast-application-routing-ersetzen\"\u003eKann Anycast Application-Routing ersetzen?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast arbeitet auf Netzwerkebene. Application-Routing wertet beispielsweise Hostnamen oder URL-Pfade aus und erfolgt typischerweise erst an der Layer-7-fähigen Edge.\u003c/p\u003e\n\u003ch3 id=\"müssen-alle-backends-am-selben-standort-betrieben-werden\"\u003eMüssen alle Backends am selben Standort betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Backend-Pools können geeignete Ziele in unterschiedlichen Compute-Umgebungen zusammenfassen. Entscheidend sind Erreichbarkeit, Protokollkompatibilität und der konfigurierte Betriebszustand.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAnycast Traffic Management ist kein einzelner Routingentscheid, sondern eine Kette klar getrennter Ebenen: Das Netzwerk führt zur Edge, die Edge verarbeitet und schützt den Traffic, und Pool- sowie Application-Routing bestimmen das konkrete Backend. Diese Trennung verbessert Fehlersuche, Failover und Providerunabhängigkeit. Die ayedo Edge Cloud bildet dafür den öffentlichen, aktiv-aktiven Einstieg vor unterschiedlichen Compute-Umgebungen – nicht als Ersatz für die Anwendung, sondern als kontrollierte Vermittlung bis zu ihr.\u003c/p\u003e\n", "summary": "\nTL;DR Anycast Traffic Management beginnt mit einem global erreichbaren Einstiegspunkt, endet aber nicht am nächstgelegenen Edge-Standort. Anycast Routing führt den Traffic zu einer Edge-Instanz; dort entscheiden Layer-4- und Layer-7-Regeln über Backend-Pools, Health Status und gegebenenfalls Application-Routing. Erst diese Trennung schafft einen kontrollierbaren Pfad bis zur Anwendung.\nEinleitung Anycast wird häufig als Antwort auf die Frage verstanden, welcher Standort eine Anfrage entgegennimmt. Für belastbares Traffic-Management greift diese Sicht zu kurz. Das Netzwerk bestimmt zunächst, an welchem Edge-Punkt ein Paket verarbeitet wird. Erst danach entstehen Entscheidungen über Protokoll, Hostname, Pfad, Port, Backend-Pool und Failover. Wer Anycast Routing direkt mit Application-Routing gleichsetzt, vermischt zwei unterschiedliche Steuerungsebenen und erschwert Betrieb sowie Fehlersuche. Eine Edge-Architektur muss daher den Weg vom öffentlichen Einstiegspunkt bis zum konkreten Backend nachvollziehbar machen. Genau dort liegt der technische Wert von Anycast in der ayedo Edge Cloud: als Eingang in eine verteilte, aktiv-aktive Traffic-Management-Plattform.\n", "image": "https://ayedo.de/anycast-im-traffic-management-routing-bis-zum-backend.png", "date_published": "2026-09-08T17:04:57Z", "date_modified": "2026-09-08T17:04:57Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/backend-pools-planen-health-checks-und-failover/", "url": "https://ayedo.de/posts/backend-pools-planen-health-checks-und-failover/", "title": "Backend-Pools planen: Health Checks und Failover", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-pools-planen-health-checks-und-failover/backend-pools-planen-health-checks-und-failover.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend-Pools sind keine bloßen Listen von Zielsystemen. Ihre Zusammensetzung bestimmt, welche Backends Traffic erhalten, wie Ausfälle erkannt werden und wann Failover greift. Aussagekräftige Health Checks, klare Pool-Grenzen und ein definierter Rückfallpfad verhindern, dass die Edge Traffic an technisch erreichbare, aber nicht funktionsfähige Systeme verteilt.\u003c/p\u003e\n\u003cp\u003eEin Backend-Pool verbindet öffentliche Erreichbarkeit mit konkreten internen Zielen. In der Praxis entscheidet deshalb nicht allein der Loadbalancer über Verfügbarkeit, sondern bereits die Planung der Backend-Gruppen. Werden unterschiedliche Anwendungen, Betriebszustände oder Fehlerdomänen unkontrolliert in einem Pool zusammengefasst, kann ein Ausfall zu unvorhersehbaren Umschaltungen führen.\u003c/p\u003e\n\u003cp\u003eDie zentrale Architekturentscheidung lautet: Welche Ziele dürfen im Fehlerfall denselben Traffic übernehmen? Diese Frage ist wichtiger als die reine Anzahl verfügbarer Backends. Ein Pool sollte nur Systeme enthalten, die aus Sicht der Anwendung tatsächlich austauschbar sind. Unterschiedliche Versionen, Datenstände, Regionen oder Sicherheitszonen benötigen häufig getrennte Pools oder einen bewusst definierten Failover-Pfad.\u003c/p\u003e\n\u003ch2 id=\"1-backend-pools-nach-austauschbarkeit-schneiden\"\u003e1. Backend-Pools nach Austauschbarkeit schneiden\u003c/h2\u003e\n\u003cp\u003eEin Pool sollte fachlich und technisch zusammengehörige Ziele enthalten. Dazu gehören beispielsweise mehrere Instanzen desselben Services mit vergleichbarer Konfiguration, identischem Protokoll und kompatiblem Datenzugriff. Ein zweiter Pool kann für eine andere Region, ein separates Rechenzentrum oder eine bewusst nachgelagerte Notfallumgebung vorgesehen werden.\u003c/p\u003e\n\u003cp\u003eDie wichtigste Grenze ist die Austauschbarkeit: Kann jedes Ziel dieselbe Anfrage korrekt verarbeiten, ohne dass Session-Zustand, Datenversion oder Berechtigungen verletzt werden? Wenn nicht, ist ein gemeinsamer Pool meist problematisch. Ein Backend kann zwar auf TCP-Ebene erreichbar sein, aber fachlich nicht als Ersatz dienen.\u003c/p\u003e\n\u003cp\u003eDiese Struktur wirkt sich direkt auf den Betrieb aus. Kleinere, klar abgegrenzte Pools erleichtern die Fehlersuche und machen Failover-Entscheidungen nachvollziehbar. Zu stark fragmentierte Pools erhöhen dagegen den Konfigurationsaufwand und können verfügbare Kapazität unnötig isolieren. Die Pool-Grenzen sollten deshalb an Fehlerdomänen und Betriebsmodellen ausgerichtet werden, nicht ausschließlich an der Topologie.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-müssen-den-dienstzustand-abbilden\"\u003e2. Health Checks müssen den Dienstzustand abbilden\u003c/h2\u003e\n\u003cp\u003eHealth Checks steuern, ob ein Backend für die Zielauswahl als verfügbar gilt. Ein einfacher Verbindungsaufbau prüft jedoch nur, ob ein Netzwerkpfad und ein Listener existieren. Für HTTP- und HTTPS-Services ist ein anwendungsspezifischer Check meist aussagekräftiger: Er kann Statuscode, Antwortverhalten oder einen definierten Bereitschaftsendpunkt prüfen.\u003c/p\u003e\n\u003cp\u003eDer Check muss dabei genau die Voraussetzung messen, die für die Traffic-Verarbeitung relevant ist. Ein Service kann den Prüfpfad erfolgreich beantworten, während Datenbankzugriff, Abhängigkeiten oder relevante Geschäftslogik gestört sind. Umgekehrt kann ein zu komplexer Check temporäre Störungen überbewerten und ein funktionierendes Backend unnötig aus dem Pool entfernen.\u003c/p\u003e\n\u003cp\u003eWichtig sind außerdem Auswerteparameter wie Prüfintervall, Timeout und die Anzahl aufeinanderfolgender Fehlversuche. Sie beeinflussen die Reaktionsgeschwindigkeit und die Stabilität der Zielauswahl. Zu aggressive Werte können zwischen verfügbar und nicht verfügbar flappen; zu konservative Werte verlängern die Zeit, in der Traffic an ein gestörtes Ziel gelangt. Health Checks sind damit ein Betriebsmechanismus, kein rein technisches Kontrollkästchen.\u003c/p\u003e\n\u003ch2 id=\"3-failover-als-kontrollierten-traffic-pfad-modellieren\"\u003e3. Failover als kontrollierten Traffic-Pfad modellieren\u003c/h2\u003e\n\u003cp\u003eFailover sollte vorab beschreiben, welches Zielverhalten bei einem Ausfall erwartet wird. Eine mögliche Strategie verteilt Traffic zunächst auf mehrere primäre Backends und nutzt einen separaten Pool nur dann, wenn die primäre Gruppe nicht ausreichend verfügbar ist. Alternativ kann ein Backup-Ziel dauerhaft einen begrenzten Anteil übernehmen, um seine Betriebsbereitschaft zu verifizieren.\u003c/p\u003e\n\u003cp\u003eEntscheidend ist die Unterscheidung zwischen dem Ausfall eines einzelnen Backends und dem Ausfall eines gesamten Pools. Fällt eine Instanz aus, sollte der Traffic möglichst innerhalb derselben Gruppe neu verteilt werden. Wird dagegen eine gemeinsame Fehlerdomäne unzugänglich, muss der Rückfallpfad eine andere Domäne erreichen. Ohne diese Trennung kann ein scheinbares Failover lediglich Traffic zwischen gleich betroffenen Systemen verschieben.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud werden Backend Health Checks und Failover am öffentlichen Eingang der Anwendungen berücksichtigt. Die Edge Cloud kann dadurch die Zielauswahl vor dem Backend-Zugriff steuern. Das ersetzt jedoch keine Kapazitäts- und Abhängigkeitsplanung: Ein Failover-Ziel muss Anfragen tatsächlich verarbeiten können, und seine Daten- oder Betriebsgrenzen müssen bekannt sein.\u003c/p\u003e\n\u003ch2 id=\"4-verfügbarkeit-security-und-betrieb-gemeinsam-bewerten\"\u003e4. Verfügbarkeit, Security und Betrieb gemeinsam bewerten\u003c/h2\u003e\n\u003cp\u003eBackend-Pools beeinflussen nicht nur Routing und Verfügbarkeit. Die Wahl der Ziele bestimmt auch, welche Systeme vom öffentlichen Eingang aus erreichbar sein müssen. Backend Cloaking kann dabei helfen, interne Strukturen nicht direkt nach außen sichtbar zu machen. Der Edge-Zugriff wird auf definierte Ziele gelenkt, während die eigentlichen Backend-Adressen nicht zum öffentlichen Adressierungsmodell werden.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb müssen Zustandswechsel nachvollziehbar sein. Traffic- und Usage-Statistiken unterstützen dabei, ungewöhnliche Verteilungen, steigende Fehlerraten oder einen ausgelösten Failover zu erkennen. Besonders relevant ist die Frage, ob ein Backup-Pool unerwartet dauerhaft Traffic übernimmt und dadurch seine eigene Reserve verliert.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud ist dabei nicht an ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n gebunden. Backend-Pools können auch für eigene oder bei anderen Providern betriebene Kubernetes-Cluster genutzt werden. Kubernetes-native Integration erleichtert die Einbindung wechselnder Workloads, ersetzt aber nicht die fachliche Entscheidung, welche Services gemeinsam failovern dürfen. Providerunabhängigkeit erweitert den Architekturspielraum; sie macht Pool- und Abhängigkeitsgrenzen nicht automatisch korrekt.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-primärpool-mit-separatem-notfallziel\"\u003eBetriebsszenario: Primärpool mit separatem Notfallziel\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei Umgebungen. Drei Backends im primären Pool bedienen den regulären Traffic. Eine getrennte Umgebung enthält zwei weitere Backends und wird als Failover-Pool genutzt. Der Health Check prüft nicht nur den Port, sondern einen dedizierten Bereitschaftsendpunkt mit den für die API notwendigen Abhängigkeiten.\u003c/p\u003e\n\u003cp\u003eFällt eine primäre Instanz aus, verteilt die Edge den Traffic auf die verbleibenden Ziele. Erst wenn der primäre Pool nicht mehr verfügbar ist, greift der Failover-Pfad. Vor der Aktivierung muss geprüft sein, dass die Notfallumgebung kompatible Daten verarbeitet und ausreichend Kapazität besitzt. Andernfalls würde das Routing zwar technisch funktionieren, aber die Störung nur verlagern.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"wie-viele-backends-sollte-ein-pool-enthalten\"\u003eWie viele Backends sollte ein Pool enthalten?\u003c/h3\u003e\n\u003cp\u003eSo viele, wie für gemeinsame Verarbeitung und gewünschte Redundanz sinnvoll sind. Maßgeblich sind Austauschbarkeit, Kapazität und gemeinsame Fehlerdomänen – nicht eine pauschale Zielanzahl.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-ein-eigener-failover-pool-sinnvoll\"\u003eWann ist ein eigener Failover-Pool sinnvoll?\u003c/h3\u003e\n\u003cp\u003eWenn Ersatzsysteme in einer anderen Fehlerdomäne, Region oder Betriebsumgebung liegen oder bewusst anders priorisiert werden. Ein eigener Pool macht diesen Rückfallpfad explizit steuerbar.\u003c/p\u003e\n\u003ch3 id=\"was-sollte-ein-health-check-nicht-prüfen\"\u003eWas sollte ein Health Check nicht prüfen?\u003c/h3\u003e\n\u003cp\u003eKeine unnötig umfangreiche Geschäftslogik. Der Check sollte den für Traffic relevanten Bereitschaftszustand zuverlässig abbilden, ohne durch entfernte oder volatile Abhängigkeiten instabil zu werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eGut geplante Backend-Pools bilden Verfügbarkeit nicht nur ab, sondern steuern sie. Entscheidend sind klare Austauschbarkeitsregeln, realistische Health Checks und ein Failover-Pfad, dessen technische und betriebliche Grenzen bekannt sind. Die ayedo Edge Cloud ordnet diese Entscheidungen am öffentlichen Eingang ein und verteilt Traffic auf verfügbare Ziele – unabhängig davon, ob die Backends in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, eigenen Clustern oder bei anderen Providern betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR Backend-Pools sind keine bloßen Listen von Zielsystemen. Ihre Zusammensetzung bestimmt, welche Backends Traffic erhalten, wie Ausfälle erkannt werden und wann Failover greift. Aussagekräftige Health Checks, klare Pool-Grenzen und ein definierter Rückfallpfad verhindern, dass die Edge Traffic an technisch erreichbare, aber nicht funktionsfähige Systeme verteilt.\nEin Backend-Pool verbindet öffentliche Erreichbarkeit mit konkreten internen Zielen. In der Praxis entscheidet deshalb nicht allein der Loadbalancer über Verfügbarkeit, sondern bereits die Planung der Backend-Gruppen. Werden unterschiedliche Anwendungen, Betriebszustände oder Fehlerdomänen unkontrolliert in einem Pool zusammengefasst, kann ein Ausfall zu unvorhersehbaren Umschaltungen führen.\n", "image": "https://ayedo.de/backend-pools-planen-health-checks-und-failover.png", "date_published": "2026-09-08T17:04:57Z", "date_modified": "2026-09-08T17:04:57Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","kubernetes","cloud-native","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/l4-oder-l7-traffic-management-in-der-edge-cloud/", "url": "https://ayedo.de/posts/l4-oder-l7-traffic-management-in-der-edge-cloud/", "title": "L4 oder L7: Traffic-Management in der Edge Cloud", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/l4-oder-l7-traffic-management-in-der-edge-cloud/l4-oder-l7-traffic-management-in-der-edge-cloud.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eL4- und L7-Loadbalancing lösen unterschiedliche Aufgaben. Layer 4 vermittelt Verbindungen anhand von IP, Port und Transportprotokoll, ohne den Anwendungsinhalt auszuwerten. Layer 7 versteht HTTP oder HTTPS und ermöglicht Routing nach Hostname, Pfad oder weiteren Request-Merkmalen. Die Entscheidung bestimmt TLS-Verarbeitung, Backend-Pools und Betriebsaufwand.\u003c/p\u003e\n\u003cp\u003eEine häufige Fehlentscheidung besteht darin, jede Anwendung mit Layer-7-Regeln zu betreiben. Das erhöht die Protokollkomplexität und verlagert zusätzliche Verantwortung an die Edge, obwohl für viele TCP- oder UDP-Dienste lediglich eine zuverlässige Transportvermittlung erforderlich ist. Umgekehrt bleibt ein reines Layer-4-Modell unzureichend, wenn mehrere Anwendungen eine gemeinsame öffentliche Adresse nutzen oder Requests abhängig von HTTP-Merkmalen unterschiedliche Backends erreichen müssen.\u003c/p\u003e\n\u003ch2 id=\"1-layer-4-transportvermittlung-ohne-anwendungskenntnis\"\u003e1. Layer 4: Transportvermittlung ohne Anwendungskenntnis\u003c/h2\u003e\n\u003cp\u003eLayer-4-Routing arbeitet auf Ebene von IP und Transportprotokoll. Die Edge kennt dabei beispielsweise Zielport und Verbindungszustand, nicht jedoch HTTP-Methode, URL-Pfad oder Header. Sie verteilt TCP- oder UDP-Verbindungen an einen passenden Backend-Pool und lässt die Anwendung die eigentliche Protokollverarbeitung übernehmen.\u003c/p\u003e\n\u003cp\u003eDieser Ansatz eignet sich für Dienste, bei denen die Verbindung als Ganzes weitergeleitet werden soll: etwa für nicht HTTP-basierte Protokolle, TLS-Passthrough oder Anwendungen, deren Routing bereits im Backend erfolgt. Auch wenn alle Anfragen eines Dienstes in denselben Pool gehören, ist zusätzliche Protokollkenntnis nicht erforderlich.\u003c/p\u003e\n\u003cp\u003eDer betriebliche Vorteil liegt in der geringeren Kopplung zwischen Edge und Anwendung. Änderungen an URL-Strukturen oder HTTP-Headern beeinflussen das Traffic-Management nicht. Gleichzeitig bleiben Möglichkeiten wie WAF-Prüfung oder inhaltsbezogene Weiterleitung außen vor. Layer 4 ist deshalb nicht „weniger professionell“, sondern ein passender Abstraktionsgrad für Transportvermittlung.\u003c/p\u003e\n\u003ch2 id=\"2-layer-7-routing-auf-basis-der-anwendung\"\u003e2. Layer 7: Routing auf Basis der Anwendung\u003c/h2\u003e\n\u003cp\u003eLayer-7-Routing setzt voraus, dass die Edge das verwendete Anwendungsprotokoll versteht. Bei HTTP und HTTPS können Regeln beispielsweise Hostnamen, Pfade oder weitere Request-Eigenschaften berücksichtigen. Dadurch lassen sich mehrere Anwendungen hinter einer öffentlichen Adresse betreiben oder unterschiedliche API-Versionen gezielt an getrennte Backend-Pools verteilen.\u003c/p\u003e\n\u003cp\u003eDiese Flexibilität verändert jedoch die Verantwortungsverteilung. Die Edge wird Teil der HTTP-Verarbeitung und muss Requests korrekt terminieren, prüfen und weiterleiten. Bei HTTPS ist insbesondere die TLS-Verarbeitung relevant: Für inhaltsbezogene Regeln muss der verschlüsselte Verkehr an der Edge entschlüsselt werden. Die ayedo Edge Cloud unterstützt TLS Termination an der Edge und kann HTTP-/HTTPS-Services zusätzlich mit einer Web Application Firewall schützen.\u003c/p\u003e\n\u003cp\u003eLayer 7 schafft damit mehr Steuerungsmöglichkeiten, aber auch mehr Abhängigkeiten. Änderungen an Routingregeln, Zertifikaten oder Sicherheitsrichtlinien können den öffentlichen Zugriff unmittelbar beeinflussen. Regelwerke sollten deshalb versioniert, getestet und klar den verantwortlichen Teams zugeordnet werden.\u003c/p\u003e\n\u003ch2 id=\"3-tls-bestimmt-die-grenze-zwischen-l4-und-l7\"\u003e3. TLS bestimmt die Grenze zwischen L4 und L7\u003c/h2\u003e\n\u003cp\u003eDie Entscheidung zwischen Layer 4 und Layer 7 ist eng mit dem Umgang mit TLS verbunden. Bei TLS-Passthrough vermittelt die Edge verschlüsselte Verbindungen, ohne den HTTP-Inhalt zu lesen. Das Backend bleibt für Zertifikat, Entschlüsselung und anwendungsbezogene Verarbeitung verantwortlich. Für einfache Weiterleitung oder spezielle Protokollanforderungen kann das die sauberere Architektur sein.\u003c/p\u003e\n\u003cp\u003eSoll die Edge dagegen nach HTTP-Pfaden oder anderen Request-Merkmalen routen, muss sie den Inhalt verarbeiten können. TLS Termination an der Edge beendet die externe TLS-Verbindung dort; anschließend wird der Request innerhalb der definierten Backend-Kommunikation weitergeleitet. Damit verschiebt sich die Sicherheits- und Betriebsgrenze: Zertifikatsverwaltung, Verschlüsselung und Schutzmechanismen liegen zumindest teilweise vor dem Backend.\u003c/p\u003e\n\u003cp\u003eDas ist nicht automatisch besser. TLS Termination zentralisiert Funktionen und ermöglicht konsistente L7-Regeln, erhöht aber die Bedeutung der Edge als vertrauenswürdige Kontrollinstanz. Unternehmen müssen festlegen, welche Daten dort verarbeitet werden dürfen und wie die Verbindung zur Anwendung abgesichert bleibt.\u003c/p\u003e\n\u003ch2 id=\"4-backend-pools-health-checks-und-betriebsfolgen\"\u003e4. Backend-Pools, Health Checks und Betriebsfolgen\u003c/h2\u003e\n\u003cp\u003eDie Wahl der Schicht beeinflusst, wie Backend-Pools gebildet und überwacht werden. Bei Layer 4 steht typischerweise die Erreichbarkeit eines Dienstes oder Ports im Vordergrund. Layer 7 kann zusätzlich anwendungsnahe Health Checks und unterschiedliche Pools für Hosts, Pfade oder API-Bereiche abbilden. Dadurch lassen sich Ausfälle gezielter behandeln, sofern die Routinglogik tatsächlich zur Anwendung passt.\u003c/p\u003e\n\u003cp\u003eMit mehreren L7-Pools steigt allerdings die Zahl der Zustände, die im Betrieb nachvollziehbar bleiben müssen: Routingregeln, Zertifikate, Health Checks, Failover-Verhalten und die Zuordnung zu den jeweiligen Deployments. Ein fehlerhafter Pfad-Match kann dann einen Teil der Anwendung unerreichbar machen, obwohl alle Backends technisch gesund sind.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit Backend Health Checks und Failover. Damit kann die öffentliche Traffic-Verteilung unabhängig von der Compute-Plattform organisiert werden – auch bei eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n. Backend Cloaking trennt dabei die öffentliche Zugriffsebene von den intern betriebenen Endpunkten. Entscheidend bleibt, Pools und Regeln nach der tatsächlichen Anwendungstopologie zu modellieren.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePraxis- und Entscheidungsszenario\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eEin Unternehmen betreibt einen TCP-basierten Dienst und eine HTTP-API. Der TCP-Dienst soll verschlüsselte Verbindungen unverändert an einen Pool weiterleiten; die TLS-Verarbeitung bleibt im Backend. Hier ist Layer 4 ausreichend und vermeidet unnötige Anwendungsabhängigkeit. Die API nutzt dagegen \u003ccode\u003e/v1\u003c/code\u003e und \u003ccode\u003e/v2\u003c/code\u003e mit getrennten Backend-Pools sowie unterschiedlichen Rollout-Zyklen. Dafür ist Layer 7 sinnvoll: Die Edge terminiert TLS, wertet den HTTP-Pfad aus und leitet Requests gezielt weiter. Beide Modelle können parallel in einer Edge-Plattform betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-layer-7-grundsätzlich-sicherer-als-layer-4\"\u003eIst Layer 7 grundsätzlich sicherer als Layer 4?\u003c/h3\u003e\n\u003cp\u003eNein. Layer 7 ermöglicht anwendungsbezogene Prüfungen wie HTTP-Regeln oder WAF-Schutz. Layer 4 reduziert dagegen die Verarbeitungstiefe. Sicherheit hängt von Bedrohungsmodell, Protokoll und korrekter Konfiguration ab.\u003c/p\u003e\n\u003ch3 id=\"kann-https-immer-mit-layer-4-betrieben-werden\"\u003eKann HTTPS immer mit Layer 4 betrieben werden?\u003c/h3\u003e\n\u003cp\u003eJa, als TLS-Passthrough. Die Edge vermittelt die Verbindung, wertet den HTTP-Inhalt aber nicht aus. Für pfad- oder hostbasiertes Routing ist TLS Termination an der Edge erforderlich.\u003c/p\u003e\n\u003ch3 id=\"wann-sollte-ein-backend-pool-aufgeteilt-werden\"\u003eWann sollte ein Backend-Pool aufgeteilt werden?\u003c/h3\u003e\n\u003cp\u003eWenn Anwendungen unterschiedliche Skalierungs-, Release-, Health-Check- oder Failover-Anforderungen haben. Eine Aufteilung nur aus organisatorischen Gründen erhöht dagegen die Routingkomplexität ohne technischen Nutzen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eL4- und L7-Loadbalancing sind keine konkurrierenden Produktvarianten, sondern unterschiedliche Architekturgrenzen. Layer 4 hält die Edge von der Anwendung fern und eignet sich für transparente Transportvermittlung. Layer 7 schafft Kontrolle über HTTP-Traffic, verlangt aber bewusste Entscheidungen zu TLS, Regeln und Backend-Pools. Eine Edge Cloud wie ayedo ist dann sinnvoll eingesetzt, wenn diese Ebenen pro Dienst gezielt kombiniert werden – statt jede Anwendung demselben Routingmodell zu unterwerfen.\u003c/p\u003e\n", "summary": "\nTL;DR L4- und L7-Loadbalancing lösen unterschiedliche Aufgaben. Layer 4 vermittelt Verbindungen anhand von IP, Port und Transportprotokoll, ohne den Anwendungsinhalt auszuwerten. Layer 7 versteht HTTP oder HTTPS und ermöglicht Routing nach Hostname, Pfad oder weiteren Request-Merkmalen. Die Entscheidung bestimmt TLS-Verarbeitung, Backend-Pools und Betriebsaufwand.\nEine häufige Fehlentscheidung besteht darin, jede Anwendung mit Layer-7-Regeln zu betreiben. Das erhöht die Protokollkomplexität und verlagert zusätzliche Verantwortung an die Edge, obwohl für viele TCP- oder UDP-Dienste lediglich eine zuverlässige Transportvermittlung erforderlich ist. Umgekehrt bleibt ein reines Layer-4-Modell unzureichend, wenn mehrere Anwendungen eine gemeinsame öffentliche Adresse nutzen oder Requests abhängig von HTTP-Merkmalen unterschiedliche Backends erreichen müssen.\n", "image": "https://ayedo.de/l4-oder-l7-traffic-management-in-der-edge-cloud.png", "date_published": "2026-09-08T17:04:57Z", "date_modified": "2026-09-08T17:04:57Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","kubernetes","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/failover-uber-mehrere-provider-mit-der-edge-cloud/", "url": "https://ayedo.de/posts/failover-uber-mehrere-provider-mit-der-edge-cloud/", "title": "Failover über mehrere Provider mit der Edge Cloud", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-uber-mehrere-provider-mit-der-edge-cloud/failover-uber-mehrere-provider-mit-der-edge-cloud.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProviderunabhä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 \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei unterschiedlichen Providern betrieben werden. Backend Cloaking verhindert dabei, dass Failover-Architekturen durch öffentlich erreichbare Ursprungsdienste unnötig exponiert werden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin 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.\u003c/p\u003e\n\u003ch2 id=\"1-providerunabhängigkeit-beginnt-am-öffentlichen-eingang\"\u003e1. Providerunabhängigkeit beginnt am öffentlichen Eingang\u003c/h2\u003e\n\u003cp\u003eEin 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.\u003c/p\u003e\n\u003cp\u003eAnycast 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.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003ch2 id=\"2-backend-cloaking-trennt-erreichbarkeit-von-sichtbarkeit\"\u003e2. Backend Cloaking trennt Erreichbarkeit von Sichtbarkeit\u003c/h2\u003e\n\u003cp\u003eProviderunabhä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.\u003c/p\u003e\n\u003cp\u003eBackend 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 \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n: Ein Cluster kann bei ayedo Managed Kubernetes oder bei einem anderen Provider betrieben werden, ohne dass seine öffentliche Erreichbarkeit zum Architekturprinzip werden muss.\u003c/p\u003e\n\u003cp\u003eDamit 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.\u003c/p\u003e\n\u003ch2 id=\"3-failover-braucht-belastbare-signale-und-klare-zustände\"\u003e3. Failover braucht belastbare Signale und klare Zustände\u003c/h2\u003e\n\u003cp\u003eAnycast 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.\u003c/p\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003cp\u003eBetrieblich 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.\u003c/p\u003e\n\u003ch2 id=\"4-zentrale-edge-funktionen-reduzieren-organisatorische-kopplung\"\u003e4. Zentrale Edge-Funktionen reduzieren organisatorische Kopplung\u003c/h2\u003e\n\u003cp\u003eWenn 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.\u003c/p\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003cp\u003eIm 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.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-allein-ein-multi-cloud-failover\"\u003eIst Anycast allein ein Multi-Cloud-Failover?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast bringt den Traffic zur Edge. Erst Health Checks, Backend-Auswahl und eine geeignete Anwendungskonfiguration ermöglichen die Weiterleitung zu einem alternativen Provider.\u003c/p\u003e\n\u003ch3 id=\"verhindert-backend-cloaking-jeden-direkten-angriff-auf-ein-backend\"\u003eVerhindert Backend Cloaking jeden direkten Angriff auf ein Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert die öffentliche Sichtbarkeit und verhindert, dass der normale Client-Traffic die Edge umgeht. Backends benötigen weiterhin eigene Zugriffs- und Sicherheitskontrollen.\u003c/p\u003e\n\u003ch3 id=\"muss-kubernetes-bei-ayedo-betrieben-werden\"\u003eMuss \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud kann auch \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n anbinden, die selbst betrieben oder bei anderen Providern ausgeführt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderunabhä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.\u003c/p\u003e\n", "summary": "\nTL;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.\nEinleitung 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.\n", "image": "https://ayedo.de/failover-uber-mehrere-provider-mit-der-edge-cloud.png", "date_published": "2026-09-07T13:54:41Z", "date_modified": "2026-09-07T13:54:41Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","security","cloud","operations"], "language": "de" },{ "id": "https://ayedo.de/posts/aktiv-aktiv-failover-lastverteilung-und-konsistenz/", "url": "https://ayedo.de/posts/aktiv-aktiv-failover-lastverteilung-und-konsistenz/", "title": "Aktiv-Aktiv-Failover: Lastverteilung und Konsistenz", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-failover-lastverteilung-und-konsistenz/aktiv-aktiv-failover-lastverteilung-und-konsistenz.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv-Failover verteilt produktiven Traffic gleichzeitig auf mehrere Backends. Dadurch bleiben einzelne Ausfälle für Nutzer und Clients oft transparent. Der Preis ist zusätzlicher Aufwand: Sitzungen, Datenänderungen und Nebenwirkungen müssen über die beteiligten Instanzen hinweg konsistent oder bewusst fehlertolerant gestaltet werden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv ist keine reine Redundanzentscheidung, sondern eine Architekturentscheidung für den gesamten Request- und Datenpfad. Mehrere Backends gleichzeitig produktiv zu nutzen, reduziert die Abhängigkeit von einer einzelnen Failure Domain. Es beseitigt jedoch nicht automatisch Ausfallrisiken: Ein Backend kann erreichbar sein, aber veraltete Daten liefern, Sitzungen verlieren oder widersprüchliche Änderungen erzeugen. Die zentrale Frage lautet deshalb nicht nur, wie Traffic verteilt wird, sondern welche Zustände verteilt werden müssen. Für öffentlich erreichbare Anwendungen und APIs entscheidet diese Trennung darüber, ob Aktiv-Aktiv-Failover tatsächlich kontinuierliche Nutzung ermöglicht oder lediglich einen komplexeren Betriebsmodus schafft.\u003c/p\u003e\n\u003ch2 id=\"1-traffic-verteilung-über-mehrere-failure-domains\"\u003e1. Traffic-Verteilung über mehrere Failure Domains\u003c/h2\u003e\n\u003cp\u003eIn einer Aktiv-Aktiv-Architektur verarbeiten mehrere Backends gleichzeitig produktive Anfragen. Ein Ausfall führt nicht zwingend zu einem vollständigen Wechsel auf ein passives System; die Traffic-Verteilung kann den Anteil eines betroffenen Backends reduzieren oder es vollständig aus dem Pool entfernen. Dadurch werden Failure Domains entkoppelt, etwa einzelne Cluster, Rechenzonen, Provider oder Netzwerkpfade.\u003c/p\u003e\n\u003cp\u003eTechnisch benötigt dieser Ansatz einen öffentlichen Eingang, der Erreichbarkeit und Backend-Zustand laufend bewertet. Anycast-basiertes Layer-4- und Layer-7-Loadbalancing kann Anfragen über eine verteilte Edge-Infrastruktur an verfügbare Backends leiten. Health Checks sind dabei keine Konsistenzprüfung: Sie zeigen, ob ein Dienst erreichbar und funktionsfähig genug ist, nicht ob seine Daten aktuell sind.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud übernimmt genau diese Edge-Aufgaben mit Anycast, Backend Health Checks und Failover. Sie kann damit mehrere eigene oder providerübergreifend betriebene Backends anbinden. Die eigentliche Anwendungskonsistenz bleibt jedoch Aufgabe der Backend- und Datenarchitektur.\u003c/p\u003e\n\u003ch2 id=\"2-sitzungen-und-zustände-im-request-pfad\"\u003e2. Sitzungen und Zustände im Request-Pfad\u003c/h2\u003e\n\u003cp\u003eDer einfachste Aktiv-Aktiv-Fall ist eine zustandslose Anwendung. Jeder Request enthält alle Informationen, die das Backend benötigt, oder greift auf einen gemeinsam verfügbaren Zustand zu. Dann kann Traffic ohne feste Bindung an eine Instanz verteilt werden. Das verbessert die Ausfalltoleranz und erleichtert Skalierung, setzt aber eine konsequente Trennung von Request-Verarbeitung und Sitzungszustand voraus.\u003c/p\u003e\n\u003cp\u003eProblematisch wird es, wenn Sessions im lokalen Speicher eines Backends liegen. Wird der nächste Request an eine andere Instanz verteilt, fehlen Authentifizierungs-, Warenkorb- oder Workflow-Daten. Sticky Sessions können dieses Problem begrenzen, verschlechtern aber die Lastverteilung und machen einen Backend-Ausfall spürbarer. Außerdem lösen sie keine Datenkonsistenz zwischen Instanzen.\u003c/p\u003e\n\u003cp\u003eFür öffentlich erreichbare APIs sind kurzlebige Tokens, idempotente Operationen und ein klar definierter gemeinsamer Zustand häufig robuster. TLS Termination an der Edge, Proxy Protocol oder Backend Cloaking können den Netzwerkpfad strukturieren und die Backends schützen. Sie ersetzen jedoch keine Entscheidung darüber, wo Sitzungsdaten liegen und wie deren Ausfall behandelt wird.\u003c/p\u003e\n\u003ch2 id=\"3-datenkonsistenz-als-eigentliche-komplexitätsgrenze\"\u003e3. Datenkonsistenz als eigentliche Komplexitätsgrenze\u003c/h2\u003e\n\u003cp\u003eBei mehreren aktiven Backends ist die Datenhaltung meist der anspruchsvollste Teil. Lesen zwei Instanzen unterschiedliche Replikationsstände, entstehen sichtbare Abweichungen: Ein gerade angelegtes Objekt erscheint noch nicht, ein Statuswechsel wird überschrieben oder eine API liefert widersprüchliche Antworten. Je nach Geschäftsprozess kann das tolerierbar, fachlich kritisch oder unzulässig sein.\u003c/p\u003e\n\u003cp\u003eVor einer Aktiv-Aktiv-Entscheidung müssen daher Konsistenzmodell und Fehlerverhalten festgelegt werden. Denkbare Anforderungen reichen von eventual consistency bis zu stärker koordinierter Verarbeitung. Schreibzugriffe können partitioniert, über definierte Leader geführt oder durch Idempotency Keys gegen Wiederholung abgesichert werden. Konfliktauflösung darf nicht implizit dem Loadbalancer überlassen werden.\u003c/p\u003e\n\u003cp\u003eDas erzeugt organisatorische und wirtschaftliche Folgen. Entwicklungsteams müssen Zustandsübergänge, Retries und Nebenläufigkeit spezifizieren; Betriebsteams benötigen Metriken für Replikationsverzug und fehlgeschlagene Synchronisation. Aktiv-Aktiv reduziert zwar die Abhängigkeit von einzelnen Infrastrukturkomponenten, kann aber den Aufwand für Datenbetrieb und Tests deutlich erhöhen.\u003c/p\u003e\n\u003ch2 id=\"4-failover-braucht-anwendungswissen\"\u003e4. Failover braucht Anwendungswissen\u003c/h2\u003e\n\u003cp\u003eEin Backend gilt nicht automatisch als gesund, nur weil ein Port antwortet. Ein oberflächlicher Health Check kann einen Prozess als verfügbar melden, obwohl Datenbankzugriffe fehlschlagen, Abhängigkeiten nicht erreichbar sind oder das Backend keine neuen Schreibvorgänge sicher verarbeiten kann. Zu aggressive Checks erzeugen dagegen unnötige Umschaltungen und zusätzliche Last.\u003c/p\u003e\n\u003cp\u003eSinnvoll sind abgestufte Zustände: Ein Backend kann weiterhin lesen, aber keine Schreibvorgänge annehmen; es kann aus dem Traffic-Pool entfernt werden, während laufende Verbindungen auslaufen. Layer-7-Checks können anwendungsnahe Verfügbarkeit prüfen, müssen aber fachlich sorgfältig definiert sein. Failover sollte außerdem mit Retries, Timeouts und Idempotenz abgestimmt werden, damit ein erneut gesendeter Request keine doppelten Nebenwirkungen erzeugt.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann verfügbare Backends über Health Checks bewerten und Traffic entsprechend verteilen oder umleiten. Das schafft eine technische Grundlage für Aktiv-Aktiv-Failover, entscheidet aber nicht, ob ein Dienst fachlich sicher weiterbetrieben werden kann. Diese Verantwortung liegt bei Anwendung, Datenhaltung und Betriebsprozessen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEine API läuft in zwei unabhängigen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. Beide Cluster sind aktiv und werden über die ayedo Edge Cloud veröffentlicht. Leseanfragen können auf beide Backends verteilt werden. Für Schreibvorgänge verwendet die Anwendung Idempotency Keys und ein Datenmodell, das Replikationsverzug berücksichtigt. Ein Health Check entfernt ein Backend aus dem Pool, wenn die API zwar erreichbar ist, aber keine gültigen Datenbankoperationen ausführen kann.\u003c/p\u003e\n\u003cp\u003eOhne diese Maßnahmen würde ein reines Traffic-Failover lediglich Requests umleiten. Nutzer könnten dann zwischen unterschiedlichen Zuständen wechseln oder Schreibvorgänge mehrfach auslösen. Die Aktiv-Aktiv-Architektur reduziert also die Auswirkung eines Cluster- oder Provider-Ausfalls, verlangt aber bewusst modellierte Zustände und überprüfbare Betriebsabläufe.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-failover-für-jede-anwendung-geeignet\"\u003eIst Aktiv-Aktiv-Failover für jede Anwendung geeignet?\u003c/h3\u003e\n\u003cp\u003eNein. Anwendungen mit strikt zentraler, nicht replizierbarer Zustandslogik profitieren möglicherweise stärker von einem kontrollierten Aktiv-Passiv-Modell.\u003c/p\u003e\n\u003ch3 id=\"sind-sticky-sessions-eine-ausreichende-lösung\"\u003eSind Sticky Sessions eine ausreichende Lösung?\u003c/h3\u003e\n\u003cp\u003eNein. Sie stabilisieren Sitzungszuordnung, lösen aber weder Datenreplikation noch den Ausfall des gebundenen Backends.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-anycast-dabei\"\u003eWelche Rolle spielt Anycast dabei?\u003c/h3\u003e\n\u003cp\u003eAnycast stellt einen verteilten öffentlichen Eingang bereit. Die konkrete Backend-Auswahl und deren Konsistenz bleiben davon getrennte Architekturaufgaben.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv-Failover ist dann sinnvoll, wenn mehrere Backends kontinuierlich produktiv arbeiten sollen und Failure Domains bewusst entkoppelt werden müssen. Die entscheidende Grenze verläuft nicht beim Loadbalancing, sondern bei Sessions, Schreibvorgängen und \u003ca href=\"/kubernetes/\"\u003eDatenkonsistenz\u003c/a\u003e\n. Eine Edge-Plattform wie die ayedo Edge Cloud kann öffentlichen Traffic über Anycast verteilen, Backends prüfen und Failover auslösen. Ob dieser Mechanismus fachlich sicher ist, bestimmt jedoch die Architektur hinter der Edge.\u003c/p\u003e\n", "summary": "\nTL;DR Aktiv-Aktiv-Failover verteilt produktiven Traffic gleichzeitig auf mehrere Backends. Dadurch bleiben einzelne Ausfälle für Nutzer und Clients oft transparent. Der Preis ist zusätzlicher Aufwand: Sitzungen, Datenänderungen und Nebenwirkungen müssen über die beteiligten Instanzen hinweg konsistent oder bewusst fehlertolerant gestaltet werden.\nEinleitung Aktiv-Aktiv ist keine reine Redundanzentscheidung, sondern eine Architekturentscheidung für den gesamten Request- und Datenpfad. Mehrere Backends gleichzeitig produktiv zu nutzen, reduziert die Abhängigkeit von einer einzelnen Failure Domain. Es beseitigt jedoch nicht automatisch Ausfallrisiken: Ein Backend kann erreichbar sein, aber veraltete Daten liefern, Sitzungen verlieren oder widersprüchliche Änderungen erzeugen. Die zentrale Frage lautet deshalb nicht nur, wie Traffic verteilt wird, sondern welche Zustände verteilt werden müssen. Für öffentlich erreichbare Anwendungen und APIs entscheidet diese Trennung darüber, ob Aktiv-Aktiv-Failover tatsächlich kontinuierliche Nutzung ermöglicht oder lediglich einen komplexeren Betriebsmodus schafft.\n", "image": "https://ayedo.de/aktiv-aktiv-failover-lastverteilung-und-konsistenz.png", "date_published": "2026-09-07T13:54:40Z", "date_modified": "2026-09-07T13:54:40Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["development","operations","kubernetes","hosting","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen/", "url": "https://ayedo.de/posts/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen/", "title": "Aktiv/passiv oder Aktiv-Aktiv: Failover richtig wählen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAktiv-passiv Failover ist nicht grundsätzlich einfacher, Aktiv-Aktiv nicht automatisch überlegen. Entscheidend sind Umschaltzeit, Datenkonsistenz, Wartungsanforderungen und die Fähigkeit der Anwendung, parallele Verarbeitung zu unterstützen. Die \u003ca href=\"/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n verteilt öffentlichen Traffic unabhängig davon, welches Modell im Backend verwendet wird, und muss Health Checks, Routing und Failover zuverlässig abbilden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Hochverfügbarkeitskonzepte scheitern nicht an fehlender Infrastruktur, sondern an einer unpassenden Failover-Strategie. Ein passiver Standort kann zwar klare Zuständigkeiten und kontrollierte Datenflüsse bieten, verursacht aber ungenutzte Kapazität und verlängert den Wiederanlauf. Aktiv-Aktiv reduziert diese Nachteile, stellt dafür höhere Anforderungen an Anwendung, Datenhaltung und Betrieb. Die Entscheidung sollte deshalb nicht mit der Frage beginnen, welches Modell moderner wirkt. Maßgeblich sind die Betriebsbedingungen: Wie schnell muss ein Ausfall abgefangen werden? Welche Daten dürfen divergieren? Kann die Anwendung Anfragen an mehreren Standorten gleichzeitig verarbeiten?\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-passiv-kontrolliertes-failover-mit-klaren-zuständigkeiten\"\u003e1. Aktiv-passiv: kontrolliertes Failover mit klaren Zuständigkeiten\u003c/h2\u003e\n\u003cp\u003eBei einer Aktiv-passiv-Architektur verarbeitet ein primäres Backend den regulären Traffic. Das sekundäre System bleibt entweder vollständig bereit oder wird nur teilweise betrieben. Im Fehlerfall muss der Traffic auf das passive Ziel umgeschaltet werden. Dieses Modell vereinfacht die Zuständigkeit: Es gibt normalerweise einen führenden Datenbestand und einen definierten Produktionsstandort.\u003c/p\u003e\n\u003cp\u003eDer Preis dafür ist eine potenziell geringere Kapazitätsauslastung. Das passive System muss für den Ausfall ausreichend dimensioniert sein, bleibt im Normalbetrieb aber weitgehend ungenutzt. Zusätzlich entsteht eine Umschaltkette aus Fehlererkennung, Routing-Änderung, Anwendungsstart und gegebenenfalls Datenbank-Recovery. Health Checks erkennen dabei nur, ob ein Ziel erreichbar und funktional genug ist. Sie ersetzen keine fachliche Prüfung der Datenkonsistenz.\u003c/p\u003e\n\u003cp\u003eAktiv-passiv Failover passt daher besonders zu Anwendungen mit strikt kontrolliertem Schreibpfad, begrenzter Parallelisierung oder hohen Anforderungen an einen eindeutigen Primärstandort.\u003c/p\u003e\n\u003ch2 id=\"2-aktiv-aktiv-kapazität-nutzen-komplexität-verteilen\"\u003e2. Aktiv-Aktiv: Kapazität nutzen, Komplexität verteilen\u003c/h2\u003e\n\u003cp\u003eIn einer Aktiv-Aktiv-Architektur verarbeiten mehrere Standorte oder Instanzen gleichzeitig produktiven Traffic. Die vorhandene Kapazität wird dadurch besser genutzt, und Wartungsarbeiten können unter Umständen ohne vollständige Umschaltung erfolgen. Fällt ein Standort aus, muss der Traffic nicht erst auf ein bislang ungenutztes System aktiviert werden.\u003c/p\u003e\n\u003cp\u003eDiese Vorteile entstehen jedoch nicht allein durch zusätzliches Routing. Die Anwendung muss parallele Requests, verteilte Sessions und gegebenenfalls mehrere Schreibpfade unterstützen. Besonders anspruchsvoll ist die Datenhaltung: Replikation kann Verzögerungen erzeugen, konkurrierende Änderungen müssen aufgelöst werden, und nicht jede Transaktion lässt sich ohne zentralen Koordinationspunkt verteilen.\u003c/p\u003e\n\u003cp\u003eAktiv-Aktiv reduziert somit den infrastrukturellen Wiederanlauf, verlagert aber Komplexität in Applikationsdesign, Datenmodell und Betrieb. Ohne klare Konsistenzanforderungen wird aus höherer Verfügbarkeit schnell ein schwer nachvollziehbares Fehlerbild.\u003c/p\u003e\n\u003ch2 id=\"3-die-edge-cloud-als-umschalt--und-verteilungsebene\"\u003e3. Die \u003ca href=\"/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n als Umschalt- und Verteilungsebene\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud entscheidet nicht, ob ein Backend intern aktiv-passiv oder aktiv-aktiv arbeitet. Sie bildet den öffentlichen Eingang und kann eingehenden Traffic über Anycast-Layer-4- und Layer-7-Loadbalancing an geeignete Backends verteilen. Backend Health Checks und Failover entfernen nicht erreichbare oder fehlerhafte Ziele aus der Verteilung. Damit wird die Umschaltlogik vom Backend-Zustand abhängig, nicht nur von einer manuellen DNS-Änderung.\u003c/p\u003e\n\u003cp\u003eBei Aktiv-Aktiv kann die Edge Cloud Traffic gleichzeitig auf mehrere verfügbare Backends verteilen. Bei Aktiv-passiv wird das passive Ziel nur im Fehlerfall relevant. In beiden Fällen bleiben Session-Verhalten, Schreibkonsistenz und Recovery-Aufgaben Sache der Anwendung und ihrer Datenhaltung.\u003c/p\u003e\n\u003cp\u003eDie verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip der ayedo Edge Cloud adressieren dabei die öffentliche Traffic-Ebene. Durch eigenes Autonomous System und eigene Netzwerk-Infrastruktur liegt diese Ebene nicht ausschließlich in der Kontrolle eines einzelnen Compute-Providers. Das ersetzt kein hochverfügbares Backend, schafft aber eine unabhängige Steuerung für Routing, Schutz und Failover.\u003c/p\u003e\n\u003ch2 id=\"4-wartung-wiederanlauf-und-wirtschaftliche-folgen\"\u003e4. Wartung, Wiederanlauf und wirtschaftliche Folgen\u003c/h2\u003e\n\u003cp\u003eDie Wahl des Modells zeigt sich besonders während Wartungsfenstern. Aktiv-passiv erlaubt einen klaren Wechsel vom primären zum sekundären System. Dieser Wechsel muss jedoch regelmäßig getestet werden; ein passives System, das nur im Notfall aktiviert wird, kann veraltete Konfigurationen, fehlende Kapazität oder unerkannte Fehler enthalten. Failover-Tests sind deshalb ein Bestandteil des Betriebsmodells und kein einmaliges Projekt.\u003c/p\u003e\n\u003cp\u003eAktiv-Aktiv verteilt die laufende Last und kann Wartung ohne vollständigen Kapazitätsverlust ermöglichen. Dafür müssen Deployments, Konfigurationen und Datenänderungen zwischen den aktiven Einheiten kontrolliert synchronisiert werden. Der organisatorische Aufwand steigt, weil mehrere Betriebszustände gleichzeitig beobachtet und bewertet werden müssen.\u003c/p\u003e\n\u003cp\u003eWirtschaftlich stehen sich ungenutzte Reservekapazität und höhere Betriebs- sowie Entwicklungskomplexität gegenüber. Eine Aktiv-Aktiv-Architektur lohnt sich nicht automatisch bei jeder Anwendung. Wenn Konsistenzanforderungen hoch und Ausfallzeiten tolerierbar sind, kann Aktiv-passiv die robustere und transparentere Entscheidung sein.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin API-Dienst verarbeitet Bestellungen mit zentraler Transaktionslogik. Die Datenbank unterstützt keinen konfliktfreien Multi-Master-Betrieb. Aktiv-Aktiv auf Anwendungsebene würde deshalb zusätzliche Koordination und komplexe Fehlerbehandlung erfordern. Ein Aktiv-passiv-Modell mit repliziertem Standby ist hier plausibler: Ein Standort schreibt, der zweite übernimmt nach definierten Prüfungen.\u003c/p\u003e\n\u003cp\u003eEin statelesses Lese-API mit replizierten Daten kann dagegen an mehreren Standorten aktiv betrieben werden. Die \u003ca href=\"/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n verteilt den öffentlichen Traffic auf gesunde Backends. Fällt ein Ziel aus, wird es über Health Checks aus der Verteilung genommen. Die Entscheidung basiert damit auf den Eigenschaften von Anwendung und Datenmodell, nicht auf einem pauschalen Vorrang von Aktiv-Aktiv.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-immer-hochverfügbarer-als-aktiv-passiv\"\u003eIst Aktiv-Aktiv immer hochverfügbarer als Aktiv-passiv?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv vermeidet bestimmte Umschaltzeiten, erhöht aber die Anforderungen an Datenkonsistenz und Betrieb. Eine fehlerhaft verteilte Aktiv-Aktiv-Anwendung kann weniger zuverlässig sein als ein gut getestetes Aktiv-passiv-System.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielen-health-checks-beim-failover\"\u003eWelche Rolle spielen Health Checks beim Failover?\u003c/h3\u003e\n\u003cp\u003eHealth Checks prüfen die Erreichbarkeit und definierte Funktionsfähigkeit eines Backends. Sie erkennen nicht automatisch fachlich falsche Daten, Replikationsfehler oder inkonsistente Transaktionen.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-cloud-eine-aktiv-passiv-architektur-vollständig-ersetzen\"\u003eKann die \u003ca href=\"/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n eine Aktiv-passiv-Architektur vollständig ersetzen?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud verteilt und schützt den öffentlichen Traffic. Wiederanlauf, Datenreplikation, Konsistenz und die Aktivierung eines passiven Backends bleiben Aufgaben der Compute- und Anwendungsebene.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDie richtige Failover-Strategie folgt aus den Betriebsbedingungen: Konsistenzmodell, tolerierbare Umschaltzeit, Wartungsanforderungen und verfügbare Betriebskompetenz. Aktiv-passiv bietet klare Kontrolle, Aktiv-Aktiv bessere Ressourcennutzung und potenziell geringere Umschaltabhängigkeit. Eine Edge-Plattform wie die ayedo Edge Cloud verbindet beide Modelle mit einer unabhängigen Ebene für Traffic-Verteilung, Health Checks und Failover, ohne die Verantwortung der Backends zu verschleiern.\u003c/p\u003e\n", "summary": "\nTL;DR Aktiv-passiv Failover ist nicht grundsätzlich einfacher, Aktiv-Aktiv nicht automatisch überlegen. Entscheidend sind Umschaltzeit, Datenkonsistenz, Wartungsanforderungen und die Fähigkeit der Anwendung, parallele Verarbeitung zu unterstützen. Die Edge Cloud verteilt öffentlichen Traffic unabhängig davon, welches Modell im Backend verwendet wird, und muss Health Checks, Routing und Failover zuverlässig abbilden.\nEinleitung Viele Hochverfügbarkeitskonzepte scheitern nicht an fehlender Infrastruktur, sondern an einer unpassenden Failover-Strategie. Ein passiver Standort kann zwar klare Zuständigkeiten und kontrollierte Datenflüsse bieten, verursacht aber ungenutzte Kapazität und verlängert den Wiederanlauf. Aktiv-Aktiv reduziert diese Nachteile, stellt dafür höhere Anforderungen an Anwendung, Datenhaltung und Betrieb. Die Entscheidung sollte deshalb nicht mit der Frage beginnen, welches Modell moderner wirkt. Maßgeblich sind die Betriebsbedingungen: Wie schnell muss ein Ausfall abgefangen werden? Welche Daten dürfen divergieren? Kann die Anwendung Anfragen an mehreren Standorten gleichzeitig verarbeiten?\n", "image": "https://ayedo.de/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen.png", "date_published": "2026-09-07T13:54:40Z", "date_modified": "2026-09-07T13:54:40Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/failover-testen-runbooks-zustande-und-ruckfallpfade/", "url": "https://ayedo.de/posts/failover-testen-runbooks-zustande-und-ruckfallpfade/", "title": "Failover testen: Runbooks, Zustände und Rückfallpfade", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-testen-runbooks-zustande-und-ruckfallpfade/failover-testen-runbooks-zustande-und-ruckfallpfade.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eFailover ist erst belastbar, wenn Ausfall, Umschaltung und Rückkehr reproduzierbar getestet werden. Ein gutes Failover-Runbook beschreibt erwartete Health-Check-Zustände, Routing- und DNS-Verhalten, Beobachtungspunkte sowie einen kontrollierten Rückfallpfad. Entscheidend ist nicht die konfigurierte Regel, sondern das nachweisbare Betriebsverhalten.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Failover-Architekturen werden einmal konfiguriert, aber nie unter realistischen Bedingungen geprüft. Genau darin liegt ein betrieblicher Fehler: Ein Backend kann zwar aus dem Loadbalancing entfernt werden, während DNS-Caches, bestehende Verbindungen, Health-Check-Intervalle oder unklare Rückschaltlogik weiterhin ein anderes Verhalten erzeugen. Failover testen bedeutet deshalb nicht nur, einen Server abzuschalten. Es bedeutet, Zustände, Zeitabläufe und Verantwortlichkeiten zu validieren. Für öffentlich erreichbare Services müssen insbesondere Routing, DNS, Health Checks und die Rückkehr zum Primärsystem gemeinsam betrachtet werden.\u003c/p\u003e\n\u003ch2 id=\"1-das-failover-runbook-beschreibt-zustände-nicht-nur-befehle\"\u003e1. Das Failover-Runbook beschreibt Zustände, nicht nur Befehle\u003c/h2\u003e\n\u003cp\u003eEin brauchbares Failover-Runbook beginnt mit dem erwarteten Zustandsmodell. Es sollte zwischen „healthy“, „degraded“, „unhealthy“, „failed over“ und „recovered“ unterscheiden. Für jeden Zustand gehören Auslöser, technische Auswirkungen und zulässige nächste Schritte in die Dokumentation.\u003c/p\u003e\n\u003cp\u003eBei einem Backend-Ausfall muss beispielsweise festgelegt sein, wann ein Health Check als fehlgeschlagen gilt, wie viele aufeinanderfolgende Fehler die Umschaltung auslösen und welches Ziel anschließend Traffic übernimmt. Ebenso wichtig ist die Frage, was mit bestehenden Verbindungen geschieht. Layer-4- und Layer-7-Verhalten können sich dabei unterscheiden: Neue Requests lassen sich anders behandeln als bereits etablierte Sessions.\u003c/p\u003e\n\u003cp\u003eDas Runbook sollte außerdem Rollen und Freigaben definieren. Wer startet den Test? Wer beobachtet Metriken und Logs? Wer entscheidet über Abbruch oder Rückschaltung? Klare Zuständigkeiten reduzieren die Zeit zwischen technischer Erkenntnis und operativer Entscheidung. Ein Runbook, das nur eine Kommandoabfolge enthält, ist für komplexe Ausfälle unvollständig.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-müssen-als-zustandsautomat-beobachtet-werden\"\u003e2. Health Checks müssen als Zustandsautomat beobachtet werden\u003c/h2\u003e\n\u003cp\u003eHealth Checks sind keine neutrale Ja-nein-Prüfung. Ihr Verhalten hängt von Endpoint, Timeout, Intervall, Fehlergrenzen und Wiederanlaufbedingungen ab. Ein Test muss deshalb dokumentieren, wann ein Backend erstmals als fehlerhaft erkannt wird, wann es aus dem Traffic genommen wird und wann es wieder als verfügbar gilt.\u003c/p\u003e\n\u003cp\u003eWährend des Tests sollten mindestens Backend-Zustand, Request-Verteilung, Fehlerraten, Antwortzeiten und aktive Verbindungen beobachtet werden. Zusätzlich ist zu prüfen, ob das erwartete Ersatz-Backend tatsächlich Anfragen übernimmt. Ein grüner Health Check allein beweist nicht, dass der gesamte Failover-Pfad funktioniert.\u003c/p\u003e\n\u003cp\u003eBesonders kritisch ist der Übergang von „unhealthy“ zu „healthy“. Ein Backend kann technisch wieder erreichbar sein, aber noch nicht stabil genug für vollständigen Traffic. Deshalb braucht ein Failover-Runbook Kriterien für eine kontrollierte Wiederaufnahme. Im Kontext einer Edge-Plattform wie der ayedo Edge Cloud sind diese Zustandsübergänge relevant, weil Backend Health Checks und Failover direkt das öffentliche Routing beeinflussen.\u003c/p\u003e\n\u003ch2 id=\"3-routing-und-dns-getrennt-aber-gemeinsam-testen\"\u003e3. Routing und DNS getrennt, aber gemeinsam testen\u003c/h2\u003e\n\u003cp\u003eRouting-Failover und DNS-Failover lösen unterschiedliche Probleme. Ein Anycast-Layer-4- oder Layer-7-Routing kann Traffic an der Edge auf ein anderes Backend lenken, ohne dass sich der öffentliche DNS-Eintrag ändert. DNS-Failover verändert dagegen die Auflösung und unterliegt Caches, TTLs und Resolver-Verhalten. Wer beide Mechanismen kombiniert, muss ihre zeitlichen Effekte getrennt messen.\u003c/p\u003e\n\u003cp\u003eEin Test sollte daher zunächst klären, welcher Pfad tatsächlich ausfällt. Wird ein einzelnes Backend entfernt, darf sich die DNS-Auflösung nicht unnötig verändern. Fällt dagegen ein gesamter Edge- oder Routing-Pfad aus, muss geprüft werden, ob Anycast DNS oder Multi-Provider-DNS wie vorgesehen reagieren. Dabei sind Messungen aus mehreren Netzen sinnvoll, weil rekursive Resolver und lokale Caches unterschiedliche Ergebnisse liefern können.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bündelt Anycast DNS, Multi-Provider-DNS sowie Layer-4- und Layer-7-Loadbalancing in einer Edge-Plattform. Für Tests bleibt trotzdem die Trennung der Verantwortlichkeiten wichtig: DNS-Auflösung, Edge-Routing und Backend-Erreichbarkeit müssen jeweils einzeln validiert und anschließend im Zusammenspiel bewertet werden.\u003c/p\u003e\n\u003ch2 id=\"4-rückschaltung-kontrollieren-und-beweise-sichern\"\u003e4. Rückschaltung kontrollieren und Beweise sichern\u003c/h2\u003e\n\u003cp\u003eDie Rückschaltung ist kein automatischer Nachlauf des Failovers, sondern ein eigener Betriebszustand. Ein zuvor ausgefallenes Backend sollte erst dann wieder Traffic erhalten, wenn Ursache, Stabilität und Kapazität geprüft sind. Andernfalls kann ein instabiles System sofort erneut Fehler erzeugen oder durch einen plötzlichen Traffic-Anstieg überlastet werden.\u003c/p\u003e\n\u003cp\u003eDas Runbook sollte deshalb eine gestufte Rückkehr vorsehen: Wiederherstellung prüfen, Health-Check-Zustand beobachten, Traffic kontrolliert erhöhen und Fehlerraten vergleichen. Falls keine stufenweise Verteilung möglich ist, braucht es zumindest ein definiertes Zeitfenster und klare Abbruchkriterien. Die Rückschaltung muss außerdem dokumentieren, ob Sessions, Caches oder Verbindungen beeinflusst werden.\u003c/p\u003e\n\u003cp\u003eEin Disaster-Recovery-Test ist erst aussagekräftig, wenn Belege gesichert werden: Zeitstempel der Zustandswechsel, Routing-Entscheidungen, DNS-Antworten, Metriken und relevante Logs. Daraus lässt sich erkennen, ob die Architektur wie geplant reagiert hat oder nur scheinbar verfügbar blieb. Diese Nachweise sind auch für spätere Verbesserungen am Runbook entscheidend.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-backend-ausfall-mit-kontrollierter-rückkehr\"\u003ePraxisszenario: Backend-Ausfall mit kontrollierter Rückkehr\u003c/h2\u003e\n\u003cp\u003eEin öffentlich erreichbarer API-Service läuft auf zwei Backends. Im Test wird das primäre Backend so deaktiviert, dass Health Checks fehlschlagen. Das Team misst zunächst die Zeit bis zur Erkennung und prüft, ob neue Requests auf das sekundäre Backend verteilt werden. DNS bleibt unverändert; damit lässt sich der Routing-Failover isoliert bewerten.\u003c/p\u003e\n\u003cp\u003eNach der Wiederherstellung des primären Backends bleibt dieses zunächst aus dem produktiven Traffic. Das Team prüft Logs, Antwortzeiten und Health-Check-Stabilität. Erst danach wird die Rückschaltung freigegeben. Tritt dabei erneut eine erhöhte Fehlerrate auf, greift der dokumentierte Rückfallpfad: Das primäre Backend wird wieder ausgeschlossen und der Betrieb auf dem sekundären Ziel fortgesetzt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"wie-oft-sollte-man-failover-testen\"\u003eWie oft sollte man Failover testen?\u003c/h3\u003e\n\u003cp\u003eNach relevanten Architektur- oder Konfigurationsänderungen und regelmäßig im Betrieb. Die Frequenz hängt von Kritikalität, Änderungsrate und Wiederanlaufanforderungen des Services ab.\u003c/p\u003e\n\u003ch3 id=\"was-gehört-in-ein-failover-runbook\"\u003eWas gehört in ein Failover-Runbook?\u003c/h3\u003e\n\u003cp\u003eAuslöser, erwartete Zustände, Beobachtungspunkte, Zuständigkeiten, Abbruchkriterien, Umschaltlogik, Rückschaltung und die erforderlichen Nachweise.\u003c/p\u003e\n\u003ch3 id=\"warum-reicht-ein-erfolgreicher-umschalttest-nicht-aus\"\u003eWarum reicht ein erfolgreicher Umschalttest nicht aus?\u003c/h3\u003e\n\u003cp\u003eWeil ein Service zwar auf das Ersatz-Backend wechseln kann, aber die Rückschaltung, DNS-Caches, Sessions oder die Stabilität des ursprünglichen Backends weiterhin fehlerhaft sein können.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eFailover-Qualität entsteht nicht durch eine einzelne Konfiguration, sondern durch wiederholbare Abläufe. Wer Health-Check-Zustände, Routing, DNS und Rückschaltung als zusammenhängenden Betriebsprozess testet, erkennt Abweichungen, bevor sie im Störungsfall kritisch werden. Die ayedo Edge Cloud bietet dafür eine gemeinsame Edge-Ebene mit Anycast-Routing, DNS, Health Checks und Failover. Ihre Wirksamkeit muss jedoch im konkreten Betriebsmodell durch Runbooks und Tests nachgewiesen werden.\u003c/p\u003e\n", "summary": "\nTL;DR Failover ist erst belastbar, wenn Ausfall, Umschaltung und Rückkehr reproduzierbar getestet werden. Ein gutes Failover-Runbook beschreibt erwartete Health-Check-Zustände, Routing- und DNS-Verhalten, Beobachtungspunkte sowie einen kontrollierten Rückfallpfad. Entscheidend ist nicht die konfigurierte Regel, sondern das nachweisbare Betriebsverhalten.\nEinleitung Viele Failover-Architekturen werden einmal konfiguriert, aber nie unter realistischen Bedingungen geprüft. Genau darin liegt ein betrieblicher Fehler: Ein Backend kann zwar aus dem Loadbalancing entfernt werden, während DNS-Caches, bestehende Verbindungen, Health-Check-Intervalle oder unklare Rückschaltlogik weiterhin ein anderes Verhalten erzeugen. Failover testen bedeutet deshalb nicht nur, einen Server abzuschalten. Es bedeutet, Zustände, Zeitabläufe und Verantwortlichkeiten zu validieren. Für öffentlich erreichbare Services müssen insbesondere Routing, DNS, Health Checks und die Rückkehr zum Primärsystem gemeinsam betrachtet werden.\n", "image": "https://ayedo.de/failover-testen-runbooks-zustande-und-ruckfallpfade.png", "date_published": "2026-09-07T13:54:40Z", "date_modified": "2026-09-07T13:54:40Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/failover-reaktionswege-zwischen-edge-dns-und-backend/", "url": "https://ayedo.de/posts/failover-reaktionswege-zwischen-edge-dns-und-backend/", "title": "Failover-Reaktionswege zwischen Edge, DNS und Backend", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-reaktionswege-zwischen-edge-dns-und-backend/failover-reaktionswege-zwischen-edge-dns-und-backend.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003e\u003cstrong\u003eTL;DR:\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eFailover ist keine einzelne Umschaltfunktion, sondern eine Kette aus Erkennung, Entscheidung, Weiterleitung und Stabilisierung. Edge-Routing reagiert typischerweise näher am laufenden Traffic, während DNS-Failover durch TTLs, Resolver- und Client-Caches verzögert wird. Bestehende Verbindungen folgen dabei anderen Regeln als neue Requests.\u003c/p\u003e\n\u003cp\u003eEin Failover wird häufig als Zustandswechsel beschrieben: Ein Backend fällt aus, ein alternatives Backend übernimmt. Technisch liegen dazwischen jedoch mehrere voneinander abhängige Schritte. Ein Health Check muss den Ausfall erkennen, eine Routing-Instanz muss die Information bewerten, neue Verbindungen müssen einen anderen Pfad erhalten und der Traffic muss sich stabilisieren. Wird stattdessen DNS geändert, kommen zusätzlich TTLs, Resolver-Caches und lokale Client-Caches hinzu.\u003c/p\u003e\n\u003cp\u003eDer entscheidende Unterschied liegt deshalb nicht nur in der Erkennungszeit. Relevant sind auch der Umschaltpfad, die Sichtbarkeit für bestehende Verbindungen und die Frage, an welcher Stelle der Architektur die Entscheidung getroffen wird. Failover-Reaktionswege sollten daher als Ablauf analysiert werden – nicht als Schalter mit einer pauschalen Umschaltzeit.\u003c/p\u003e\n\u003ch2 id=\"1-backend-health-checks-bestimmen-den-ersten-reaktionspunkt\"\u003e1. Backend Health Checks bestimmen den ersten Reaktionspunkt\u003c/h2\u003e\n\u003cp\u003eJeder Failover beginnt mit einer Beobachtung. Ein Backend Health Check prüft beispielsweise, ob ein Dienst erreichbar ist und eine erwartete Antwort liefert. Dabei ist zwischen Netzwerk-Erreichbarkeit und Anwendungszustand zu unterscheiden: Ein erreichbarer Server kann weiterhin keine funktionsfähigen Requests verarbeiten.\u003c/p\u003e\n\u003cp\u003eErst aus mehreren Prüfergebnissen entsteht ein belastbarer Zustandswechsel. Zu aggressive Prüfungen können kurzfristige Netz- oder Lastprobleme als Ausfall interpretieren. Zu konservative Prüfungen verlängern dagegen die Zeit, in der Traffic an ein nicht funktionsfähiges Ziel geleitet wird. Prüfintervall, Timeout und die erforderliche Anzahl aufeinanderfolgender Fehler beeinflussen damit direkt die Reaktionscharakteristik.\u003c/p\u003e\n\u003cp\u003eBei einer Edge-Plattform werden solche Health Checks vor der Weiterleitung an das Backend ausgewertet. Die Edge kann daraufhin ein Ziel aus dem aktiven Routing nehmen oder einen alternativen Pfad verwenden. Der Health Check ist aber noch kein Failover: Er liefert nur die Information, auf deren Grundlage die Routing-Entscheidung getroffen wird.\u003c/p\u003e\n\u003ch2 id=\"2-edge-routing-schaltet-neue-weiterleitungen-gezielt-um\"\u003e2. Edge-Routing schaltet neue Weiterleitungen gezielt um\u003c/h2\u003e\n\u003cp\u003eBeim Edge-Failover bleibt der öffentliche Einstiegspunkt unverändert. Die Edge empfängt den Traffic weiterhin über die bestehende Adresse und entscheidet anhand des aktuellen Backend-Zustands, wohin neue Verbindungen oder Requests weitergeleitet werden. Dadurch entfällt die Abhängigkeit von einer erneuten DNS-Auflösung für jeden Umschaltvorgang.\u003c/p\u003e\n\u003cp\u003eDer Reaktionsweg lautet vereinfacht: Health Check erkennt einen Fehler, die Edge aktualisiert den verfügbaren Backend-Pool, anschließend werden neue Weiterleitungen auf ein alternatives Ziel gelenkt. Bei Layer 7 kann die Entscheidung auf Request-Ebene erfolgen; bei Layer 4 ist die Lebensdauer der Verbindung stärker durch TCP- oder UDP-Zustände geprägt. Ein bereits aufgebauter TCP-Kanal wird nicht automatisch zu einer anderen Gegenstelle verschoben.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet solche Backend Health Checks mit Edge-Routing in einer verteilten Multi-PoP- und Aktiv-Aktiv-Architektur. Das ist vor allem dann relevant, wenn der öffentliche Einstiegspunkt stabil bleiben soll, während Backends in unterschiedlichen Umgebungen betrieben werden – etwa in eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n. Die Edge bleibt dabei für Eingang, Schutz und Weiterleitung zuständig; die Compute-Infrastruktur bleibt der Ort der Anwendung.\u003c/p\u003e\n\u003ch2 id=\"3-dns-failover-verlagert-die-entscheidung-zu-resolvern-und-clients\"\u003e3. DNS-Failover verlagert die Entscheidung zu Resolvern und Clients\u003c/h2\u003e\n\u003cp\u003eBeim DNS-Failover wird nicht primär die Weiterleitung an der Edge verändert, sondern die Antwort auf eine Namensauflösung. Ein Health Check kann feststellen, dass ein Ziel nicht verfügbar ist, woraufhin DNS eine alternative Adresse liefert. Der weitere Traffic erreicht dieses Ziel jedoch erst, wenn eine neue DNS-Auflösung stattfindet.\u003c/p\u003e\n\u003cp\u003eDie konfigurierte TTL begrenzt die Gültigkeit einer Antwort, garantiert aber keine exakte Umschaltzeit. Rekursive Resolver, Betriebssysteme, Anwendungen und lokale Netzkomponenten können Antworten unterschiedlich lange zwischenspeichern oder eigene Wiederverwendungslogiken anwenden. Dadurch entsteht zwischen Zustandswechsel und tatsächlicher Nutzung des neuen Ziels eine verteilte Übergangsphase.\u003c/p\u003e\n\u003cp\u003eDNS-Failover ist sinnvoll, wenn der öffentliche Einstieg selbst zwischen unabhängigen Endpunkten wechseln soll oder wenn eine Änderung außerhalb einer einzelnen Edge-Routing-Domäne erforderlich ist. Anycast DNS und Multi-Provider-DNS können dabei die DNS-Ebene resilienter gestalten, beseitigen aber nicht die Wirkung von Caches. Bei der ayedo Edge Cloud ist DNS daher ein eigener Reaktionsweg neben dem Edge-Routing, nicht dessen Ersatz.\u003c/p\u003e\n\u003ch2 id=\"4-bestehende-verbindungen-machen-den-unterschied-sichtbar\"\u003e4. Bestehende Verbindungen machen den Unterschied sichtbar\u003c/h2\u003e\n\u003cp\u003eFailover betrifft neue und bestehende Verbindungen unterschiedlich. Eine neue Verbindung kann nach der Routing-Entscheidung ein gesundes Backend erreichen. Eine bereits etablierte Verbindung bleibt dagegen zunächst an ihren bisherigen Netzwerkpfad gebunden. Fällt das Backend aus, muss der Client, ein Proxy oder die Anwendung die Verbindung beenden, erneut aufbauen oder einen Request wiederholen.\u003c/p\u003e\n\u003cp\u003eBei HTTP über eine Edge kann die öffentliche Adresse für den Client stabil bleiben, während die interne Weiterleitung wechselt. Das vereinfacht die Wiederherstellung neuer Requests, ersetzt aber keine Transaktionslogik. Wiederholungen sind nur dann sicher, wenn die Anwendung sie verkraftet, etwa durch Idempotenz oder geeignete Request-IDs. Bei lang laufenden WebSockets, Streaming-Verbindungen oder zustandsbehafteten Sessions ist die Unterbrechung deutlich sichtbarer.\u003c/p\u003e\n\u003cp\u003eBeim DNS-Failover bleibt eine bestehende Verbindung ebenfalls auf ihrem ursprünglichen Ziel. Zusätzlich können neue Verbindungen noch die alte Adresse verwenden, solange die DNS-Antwort gecacht ist. Die Stabilisierung besteht deshalb nicht nur aus dem Umschalten, sondern auch aus Retry-Verhalten, Session-Handling, Connection Draining und der Überwachung von Fehlerraten nach der Entscheidung.\u003c/p\u003e\n\u003ch2 id=\"szenario-edge-umschaltung-oder-dns-änderung\"\u003eSzenario: Edge-Umschaltung oder DNS-Änderung?\u003c/h2\u003e\n\u003cp\u003eAngenommen, ein API-Cluster ist nicht erreichbar, während ein zweiter Cluster betriebsbereit bleibt. Beim Edge-Failover erkennt der Health Check den Fehler, nimmt das erste Backend aus der Weiterleitung und sendet neue Requests an den zweiten Cluster. Clients behalten den bekannten öffentlichen Endpunkt; bestehende Verbindungen müssen dennoch je nach Protokoll neu aufgebaut werden.\u003c/p\u003e\n\u003cp\u003eBeim DNS-Failover wird stattdessen eine neue Zieladresse veröffentlicht. Resolver und Clients übernehmen diese Information zeitversetzt. Während der Übergangsphase erreicht ein Teil der neuen Verbindungen weiterhin das ausgefallene Ziel. Der Edge-Weg reduziert damit den Einfluss von DNS-Caches, während der DNS-Weg die Entscheidung weiter nach außen verlagert. Welche Variante passt, hängt vom gewünschten Kontrollpunkt und von der Verbindungstypik ab.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-edge-failover-immer-schneller-als-dns-failover\"\u003eIst Edge-Failover immer schneller als DNS-Failover?\u003c/h3\u003e\n\u003cp\u003eNicht automatisch. Entscheidend sind Health-Check-Parameter, Routing-Aktualisierung und Protokollverhalten. DNS-Failover ist zusätzlich von TTLs und Caches abhängig, wodurch die Nutzung des neuen Ziels zeitlich stärker auseinanderlaufen kann.\u003c/p\u003e\n\u003ch3 id=\"werden-bestehende-tcp-verbindungen-beim-failover-verschoben\"\u003eWerden bestehende TCP-Verbindungen beim Failover verschoben?\u003c/h3\u003e\n\u003cp\u003eNein. Eine bestehende Verbindung ist an ihren ursprünglichen Pfad gebunden. Fällt dieser aus, sind Verbindungsabbruch, erneuter Aufbau oder ein anwendungsseitiger Retry erforderlich.\u003c/p\u003e\n\u003ch3 id=\"braucht-dns-failover-zusätzlich-edge-routing\"\u003eBraucht DNS-Failover zusätzlich Edge-Routing?\u003c/h3\u003e\n\u003cp\u003eNicht grundsätzlich. DNS kann zwischen eigenständigen Endpunkten umschalten. Edge-Routing ist jedoch geeigneter, wenn der öffentliche Einstieg stabil bleiben und die Weiterleitungsentscheidung zentral an der Edge erfolgen soll.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eFailover sollte als zeitlicher Ablauf modelliert werden: Erkennung durch Health Checks, Entscheidung an Edge oder DNS, Weiterleitung neuer Verbindungen und Stabilisierung der laufenden Kommunikation. Edge-Routing reduziert die Abhängigkeit von DNS-Caches, während DNS-Failover einen breiteren, aber weniger unmittelbar kontrollierbaren Umschaltpfad nutzt. Die ayedo Edge Cloud ordnet diese Mechanismen in einer Plattform für öffentlichen Traffic-Eingang, Schutz und Weiterleitung ein – unabhängig davon, wo die Backends betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR: Failover ist keine einzelne Umschaltfunktion, sondern eine Kette aus Erkennung, Entscheidung, Weiterleitung und Stabilisierung. Edge-Routing reagiert typischerweise näher am laufenden Traffic, während DNS-Failover durch TTLs, Resolver- und Client-Caches verzögert wird. Bestehende Verbindungen folgen dabei anderen Regeln als neue Requests.\nEin Failover wird häufig als Zustandswechsel beschrieben: Ein Backend fällt aus, ein alternatives Backend übernimmt. Technisch liegen dazwischen jedoch mehrere voneinander abhängige Schritte. Ein Health Check muss den Ausfall erkennen, eine Routing-Instanz muss die Information bewerten, neue Verbindungen müssen einen anderen Pfad erhalten und der Traffic muss sich stabilisieren. Wird stattdessen DNS geändert, kommen zusätzlich TTLs, Resolver-Caches und lokale Client-Caches hinzu.\n", "image": "https://ayedo.de/failover-reaktionswege-zwischen-edge-dns-und-backend.png", "date_published": "2026-09-07T13:54:40Z", "date_modified": "2026-09-07T13:54:40Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","kubernetes","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/failure-domains-im-edge-design-fur-offentliche-dienste/", "url": "https://ayedo.de/posts/failure-domains-im-edge-design-fur-offentliche-dienste/", "title": "Failure Domains im Edge-Design für öffentliche Dienste", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failure-domains-im-edge-design-fur-offentliche-dienste/failure-domains-im-edge-design-fur-offentliche-dienste.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eFailover ist nur dann belastbar, wenn Ersatzpfade nicht von derselben Ausfallgrenze abhängen wie der Primärpfad. Backend, Cluster, Provider, Netzwerk und Edge müssen deshalb getrennt bewertet werden. Eine Multi-PoP-Architektur mit eigenem \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und Aktiv-Aktiv-Betrieb erweitert den Designraum für Hochverfügbarkeit, ersetzt aber keine saubere Abhängigkeitenanalyse.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin zweites Backend macht einen öffentlichen Dienst nicht automatisch hochverfügbar. Wenn beide Backends im selben Cluster, beim selben Provider oder hinter derselben Netzwerkabhängigkeit betrieben werden, bleibt die relevante Failure Domain unverändert. Genau deshalb muss Failover im Edge-Design von außen nach innen betrachtet werden: Welche Komponente fällt aus, welche Route bleibt erreichbar und welche Abhängigkeiten werden dabei nicht mitgerissen? Für öffentliche Services entscheidet sich Hochverfügbarkeit nicht erst in der Anwendung. DNS, Edge, Transitnetz, Provider, Cluster und Backend bilden eine Kette. Fällt ein gemeinsamer Abschnitt dieser Kette aus, versagen auch scheinbar redundante Systeme gemeinsam.\u003c/p\u003e\n\u003ch2 id=\"1-failure-domains-entlang-des-request-pfads\"\u003e1. Failure Domains entlang des Request-Pfads\u003c/h2\u003e\n\u003cp\u003eEin Request durchläuft mehrere potenzielle Ausfallgrenzen. Auf Backend-Ebene können einzelne Instanzen, ein Service oder eine Datenbank betroffen sein. Auf Cluster-Ebene kommen Control-Plane-, Netzwerk- oder Storage-Probleme hinzu. Die Provider-Domain umfasst dagegen Infrastruktur, Stromversorgung, Routing und Betriebsprozesse eines einzelnen Cloud- oder Hosting-Anbieters.\u003c/p\u003e\n\u003cp\u003eDarüber liegt die Netzwerk-Domain: Transit, BGP-Erreichbarkeit, DNS-Auflösung oder ein zentraler Internet-Uplink können mehrere Providerpfade gleichzeitig beeinflussen. Die Edge selbst ist wiederum eine eigene Failure Domain. Ein einzelner Ingress, Loadbalancer oder PoP kann ausfallen, ohne dass Backend oder Provider gestört sind.\u003c/p\u003e\n\u003cp\u003eDiese Ebenen dürfen nicht nur als Liste dokumentiert werden. Entscheidend ist die Korrelation: Liegen mehrere Komponenten in derselben Failure Domain, ist ihre Redundanz im gemeinsamen Ausfallfall wirkungslos. Hochverfügbarkeitsdesign beginnt daher mit einer Abhängigkeitskarte, nicht mit der Anzahl bereitgestellter Backends.\u003c/p\u003e\n\u003ch2 id=\"2-warum-ein-ersatz-backend-oft-nicht-ausreicht\"\u003e2. Warum ein Ersatz-Backend oft nicht ausreicht\u003c/h2\u003e\n\u003cp\u003eEin klassischer Failover-Aufbau verteilt einen Dienst auf zwei Backends und aktiviert das zweite, wenn Health Checks beim ersten fehlschlagen. Das ist sinnvoll, deckt aber nur einen Teil des Fehlerbilds ab. Beide Backends können denselben Cluster, dieselbe Region, denselben Provider oder denselben Netzwerkpfad nutzen. Ein Ausfall oberhalb der Anwendung erreicht dann beide Ziele.\u003c/p\u003e\n\u003cp\u003eAuch die Umschaltung selbst benötigt eine funktionsfähige Steuerung. DNS-Caching, TTLs, BGP-Konvergenz, Session-Zustände und die Erreichbarkeit des Failover-Mechanismus bestimmen, wie schnell ein alternativer Pfad wirksam wird. Ein technisch vorhandenes Ersatz-Backend ist deshalb nicht gleichbedeutend mit einem nutzbaren Failover-Pfad.\u003c/p\u003e\n\u003cp\u003eDie Edge sollte Gesundheitszustände bewerten und Traffic gezielt verteilen, ohne den Fehler des Primärsystems zu vergrößern. Backend Health Checks, Failover und Backend Cloaking helfen dabei, den öffentlichen Zugang von den internen Zielsystemen zu entkoppeln. Die eigentliche Unabhängigkeit entsteht jedoch erst, wenn die Ziele und ihre vorgelagerten Abhängigkeiten bewusst über Failure Domains hinweg verteilt sind.\u003c/p\u003e\n\u003ch2 id=\"3-multi-pop-autonomous-system-und-aktiv-aktiv\"\u003e3. Multi-PoP, Autonomous System und Aktiv-Aktiv\u003c/h2\u003e\n\u003cp\u003eEine verteilte Multi-PoP-Architektur reduziert die Abhängigkeit von einem einzelnen Edge-Standort. Fällt ein PoP aus oder ist ein Teil des Netzes dort nicht erreichbar, können andere PoPs weiterhin Requests annehmen. Das ist architektonisch etwas anderes als ein zweiter Loadbalancer im selben Standort: Die Edge selbst wird über mehrere Betriebs- und Netzwerkbereiche verteilt.\u003c/p\u003e\n\u003cp\u003eFür die Bewertung der Netzwerk-Failure-Domain ist außerdem relevant, wer das Routing kontrolliert. Die ayedo Edge Cloud nutzt ein eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und eigene Netzwerk-Infrastruktur. Dadurch lässt sich die Edge als eigenständige Routing- und Schutzschicht betrachten, statt sie ausschließlich als Funktion eines einzelnen Compute-Providers zu modellieren. Das beseitigt keine externen Internetstörungen, reduziert aber die direkte Kopplung an eine einzelne Provider-Netzwerkarchitektur.\u003c/p\u003e\n\u003cp\u003eDas Aktiv-Aktiv-Prinzip verschiebt die Betriebslogik ebenfalls: Mehrere Edge-Pfade sind grundsätzlich gleichzeitig nutzbar, statt dass ein vollständig passiver Standby erst aktiviert werden muss. Failover wird damit zu einer Frage der Traffic-Verteilung und Gesundheitsbewertung, nicht nur zu einem manuellen Umschaltvorgang.\u003c/p\u003e\n\u003ch2 id=\"4-failure-domains-als-betriebs--und-kostenentscheidung\"\u003e4. Failure Domains als Betriebs- und Kostenentscheidung\u003c/h2\u003e\n\u003cp\u003eDie technische Trennung von Failure Domains hat betriebliche Konsequenzen. Werden Backends über Provider oder Cluster verteilt, steigen Integrations-, Monitoring- und Netzwerkaufwand. Werden sie dagegen nur innerhalb eines Systems repliziert, bleibt der Betrieb einfacher, aber die Resilienz gegen Provider- oder Cluster-Ausfälle begrenzt. Es gibt daher keinen universellen Redundanzgrad.\u003c/p\u003e\n\u003cp\u003eEine belastbare Entscheidung braucht konkrete Ausfallannahmen: Soll ein einzelner Pod, ein kompletter Cluster, ein Provider oder auch die Edge selbst toleriert werden? Welche Daten dürfen zwischen Standorten verzögert synchronisiert werden? Welche Abhängigkeiten wie Identity, Datenbank oder DNS bleiben zentral? Erst daraus ergeben sich sinnvolle Failover-Pfade.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud kann zentrale Funktionen wie Anycast DNS, Layer-4- und Layer-7-Loadbalancing, TLS-Termination, DDoS-Schutz und Health-basierte Weiterleitung über eine verteilte Plattform bündeln. Für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist dabei nicht entscheidend, ob der Cluster von ayedo oder einem anderen Provider betrieben wird. Relevant ist, dass die öffentliche Eintrittsschicht unabhängig vom jeweiligen Compute-Betrieb geplant werden kann.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-drei-ebenen-statt-ein-zweites-backend\"\u003ePraxisszenario: Drei Ebenen statt ein zweites Backend\u003c/h2\u003e\n\u003cp\u003eEin öffentlicher API-Dienst läuft zunächst in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster bei einem Provider. Ein zweites Deployment im selben Cluster erhöht die Verfügbarkeit auf Workload-Ebene, schützt aber nicht vor einem Cluster- oder Provider-Ausfall. In einer erweiterten Architektur wird ein zweiter Cluster bei einem anderen Provider betrieben. Beide Cluster werden über die Edge veröffentlicht und durch Health Checks überwacht.\u003c/p\u003e\n\u003cp\u003eDie Edge verteilt den Traffic über mehrere PoPs und hält die Backends gegenüber dem Internet verborgen. Fällt eine Anwendung aus, wird der betroffene Pfad aus der Verteilung genommen. Bei einem Cluster- oder Provider-Ausfall bleiben Ziele in der anderen Umgebung verfügbar. Fällt ein einzelner Edge-PoP aus, übernehmen andere PoPs den Eingang. Der Mehrwert entsteht nicht durch eine einzelne Komponente, sondern durch die Trennung der Ausfallgrenzen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-multi-provider-betrieb-automatisch-hochverfügbar\"\u003eIst Multi-Provider-Betrieb automatisch hochverfügbar?\u003c/h3\u003e\n\u003cp\u003eNein. Gemeinsame DNS-, Identity-, Datenbank- oder Netzwerkabhängigkeiten können weiterhin eine gemeinsame Failure Domain bilden. Multi-Provider-Betrieb ist nur dann wirksam, wenn diese Kopplungen ebenfalls bewertet werden.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-das-autonomous-system\"\u003eWelche Rolle spielt das Autonomous System?\u003c/h3\u003e\n\u003cp\u003eEs bildet eine eigenständige Routing-Domäne der Edge. Dadurch wird der öffentliche Zugang weniger eng an die Netzwerkinfrastruktur eines einzelnen Compute-Providers gekoppelt.\u003c/p\u003e\n\u003ch3 id=\"muss-jedes-backend-aktiv-genutzt-werden\"\u003eMuss jedes Backend aktiv genutzt werden?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Ein passiver Standby kann betrieblich sinnvoll sein. Aktiv-Aktiv reduziert jedoch die Abhängigkeit von einem Umschaltvorgang und ermöglicht die gleichzeitige Nutzung mehrerer Edge-Pfade.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eFailure Domains sind die entscheidende Perspektive für belastbares Failover. Ein Ersatz-Backend genügt nicht, wenn Cluster, Provider, Netzwerk oder Edge dieselbe Ausfallgrenze teilen. Die Multi-PoP-Architektur, das eigene \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und der Aktiv-Aktiv-Betrieb der ayedo Edge Cloud schaffen eine eigenständige Edge-Schicht für diese Planung. Ihre Wirkung hängt jedoch davon ab, ob Unternehmen auch Compute-, Daten- und Betriebsabhängigkeiten konsequent entkoppeln.\u003c/p\u003e\n", "summary": "\nTL;DR Failover ist nur dann belastbar, wenn Ersatzpfade nicht von derselben Ausfallgrenze abhängen wie der Primärpfad. Backend, Cluster, Provider, Netzwerk und Edge müssen deshalb getrennt bewertet werden. Eine Multi-PoP-Architektur mit eigenem Autonomous System und Aktiv-Aktiv-Betrieb erweitert den Designraum für Hochverfügbarkeit, ersetzt aber keine saubere Abhängigkeitenanalyse.\nEinleitung Ein zweites Backend macht einen öffentlichen Dienst nicht automatisch hochverfügbar. Wenn beide Backends im selben Cluster, beim selben Provider oder hinter derselben Netzwerkabhängigkeit betrieben werden, bleibt die relevante Failure Domain unverändert. Genau deshalb muss Failover im Edge-Design von außen nach innen betrachtet werden: Welche Komponente fällt aus, welche Route bleibt erreichbar und welche Abhängigkeiten werden dabei nicht mitgerissen? Für öffentliche Services entscheidet sich Hochverfügbarkeit nicht erst in der Anwendung. DNS, Edge, Transitnetz, Provider, Cluster und Backend bilden eine Kette. Fällt ein gemeinsamer Abschnitt dieser Kette aus, versagen auch scheinbar redundante Systeme gemeinsam.\n", "image": "https://ayedo.de/failure-domains-im-edge-design-fur-offentliche-dienste.png", "date_published": "2026-09-07T13:54:40Z", "date_modified": "2026-09-07T13:54:40Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["hosting","kubernetes","cloud-native","operations","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/backend-health-checks-als-grundlage-fur-belastbares-failover/", "url": "https://ayedo.de/posts/backend-health-checks-als-grundlage-fur-belastbares-failover/", "title": "Backend Health Checks als Grundlage für belastbares Failover", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-health-checks-als-grundlage-fur-belastbares-failover/backend-health-checks-als-grundlage-fur-belastbares-failover.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks liefern die Signale, anhand derer eine Edge-Plattform erreichbare und nicht erreichbare Ziele unterscheidet. Ihre Aussagekraft hängt jedoch vom Prüfpunkt ab: Netzwerkverbindung, Prozesszustand und tatsächlich nutzbarer Service sind unterschiedliche Failure Domains. Belastbares Failover entsteht deshalb erst durch passende Prüfsignale und kontrollierten Wiederanlauf.\u003c/p\u003e\n\u003cp\u003eEin Failover kann nur so zuverlässig sein wie das Signal, auf dem es basiert. Ein erreichbarer TCP-Port beweist nicht, dass eine Anwendung Requests korrekt verarbeitet. Umgekehrt kann ein einzelnes fehlerhaftes Anwendungssignal einen gesunden Backend-Pool fälschlich aus dem Routing nehmen. Health Checks sind daher keine reine Verfügbarkeitsanzeige, sondern eine betriebliche Entscheidungslogik: Sie beeinflussen, welches Ziel Traffic erhält und wann ein Backend als wieder einsatzbereit gilt.\u003c/p\u003e\n\u003cp\u003eIn einer verteilten Edge-Architektur wird diese Entscheidung vor dem eigentlichen Backend getroffen. Das reduziert die Abhängigkeit von einzelnen Zielen, erhöht aber die Verantwortung für die Qualität der Prüfsignale. Unpräzise Checks können Ausfälle verlängern, gesunde Kapazität aus dem Betrieb nehmen oder einen Fehlerzustand durch vorschnellen Wiederanlauf wieder in den Traffic bringen.\u003c/p\u003e\n\u003ch2 id=\"1-was-ein-health-check-tatsächlich-misst\"\u003e1. Was ein Health Check tatsächlich misst\u003c/h2\u003e\n\u003cp\u003eEin Health Check beantwortet immer nur eine begrenzte Frage. Ein Netzwerk- oder Layer-4-Check kann zeigen, dass eine Verbindung zu einem Ziel aufgebaut werden kann. Das sagt etwas über Erreichbarkeit und einen erreichbaren Listener aus, nicht jedoch über Datenbankverbindungen, Anwendungsthreads oder die Verarbeitung eines realistischen Requests.\u003c/p\u003e\n\u003cp\u003eEin HTTP-basierter Check kann die Anwendungsebene besser abbilden, sofern Status und Antwortinhalt aussagekräftig sind. Auch dann bleibt der geprüfte Pfad ein Ausschnitt des Gesamtsystems. Ein Health Endpoint kann beispielsweise unabhängig von einer gestörten Fachfunktion antworten oder nur den lokalen Prozesszustand melden.\u003c/p\u003e\n\u003cp\u003eFür die Failover-Entscheidung ist deshalb entscheidend, welche Failure Domain der Check abdeckt: Netzwerk, Host, Prozess, Anwendung oder abhängige Komponente. In der ayedo Edge Cloud bilden Backend Health Checks die Grundlage dafür, einzelne Ziele oder Backend-Pools zu bewerten und Routing- sowie Failover-Entscheidungen daran auszurichten. Die technische Frage lautet nicht nur, ob ein Check fehlschlägt, sondern ob sein Fehler die Nutzbarkeit des Services ausreichend repräsentiert.\u003c/p\u003e\n\u003ch2 id=\"2-fehlklassifikationen-entstehen-an-den-grenzen\"\u003e2. Fehlklassifikationen entstehen an den Grenzen\u003c/h2\u003e\n\u003cp\u003eEin Backend-Ausfall wird häufig als binärer Zustand modelliert: gesund oder nicht gesund. In der Praxis gibt es Zwischenzustände. Ein Ziel kann nur bestimmte Requests ablehnen, unter hoher Last zu spät antworten oder von einem Edge-Standort aus erreichbar sein, während eine Abhängigkeit regional gestört ist.\u003c/p\u003e\n\u003cp\u003eDadurch entstehen False Positives und False Negatives. Ein False Positive nimmt ein funktionierendes Backend aus dem Routing. Das reduziert die verfügbare Kapazität und kann weitere Ziele durch zusätzliche Last destabilisieren. Ein False Negative hält ein tatsächlich nicht nutzbares Ziel im Pool. Clients erhalten dann Fehler oder Timeouts, obwohl andere Backends verfügbar wären.\u003c/p\u003e\n\u003cp\u003eAuch der Prüfstandort ist relevant. Ein Check aus der Edge kann einen anderen Netzwerkpfad sehen als ein interner Monitoring-Agent. Routing, Firewall-Regeln oder asymmetrische Erreichbarkeit können deshalb zu unterschiedlichen Einschätzungen führen. Health Monitoring muss diese Perspektive berücksichtigen. Ein globaler Service ist nicht automatisch gesund, nur weil ein einzelnes Ziel von einem einzelnen Prüfpunkt aus antwortet.\u003c/p\u003e\n\u003ch2 id=\"3-prüfsignale-müssen-zur-failover-entscheidung-passen\"\u003e3. Prüfsignale müssen zur Failover-Entscheidung passen\u003c/h2\u003e\n\u003cp\u003eDie Auswahl des Signals ist eine Architekturentscheidung. Für einen TCP-Service kann die Transport-Erreichbarkeit ein sinnvoller Minimaltest sein. Bei HTTP- oder HTTPS-Anwendungen sollte dagegen geprüft werden, ob der Service auf Anwendungsebene erwartbar reagiert. Welche Antwort als gesund gilt, muss zum Betriebsmodell passen und darf nicht lediglich einen technischen Endpoint abbilden, der mit der Nutzerfunktion wenig zu tun hat.\u003c/p\u003e\n\u003cp\u003eGleichzeitig darf ein Check nicht alle Abhängigkeiten des Systems unkritisch einschließen. Wenn der Health Endpoint bei jeder vorübergehenden Störung einer nachgelagerten Komponente fehlschlägt, kann ein lokales Problem den gesamten Backend-Pool aus dem Routing nehmen. Wird die Abhängigkeit dagegen nicht berücksichtigt, bleibt ein formal erreichbarer, aber praktisch unbrauchbarer Service aktiv.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud wirken diese Bewertungen auf die Verteilung eingehender Requests. Das macht die Semantik des Checks betriebsrelevant: Sie entscheidet nicht nur über Monitoring-Sichtbarkeit, sondern darüber, ob ein einzelnes Ziel weiter Traffic erhält oder ein Failover auf andere Ziele beziehungsweise Pools erfolgt. Ein Health Check sollte deshalb die kleinste sinnvolle Failure Domain abbilden, die für die Routing-Entscheidung relevant ist.\u003c/p\u003e\n\u003ch2 id=\"4-wiederanlauf-braucht-kontrollierte-zustandswechsel\"\u003e4. Wiederanlauf braucht kontrollierte Zustandswechsel\u003c/h2\u003e\n\u003cp\u003eFailover ist nicht abgeschlossen, sobald ein Ziel als fehlerhaft erkannt wurde. Ebenso kritisch ist der Wiederanlauf. Ein Backend, das nach einer kurzen Störung wieder antwortet, ist nicht zwingend stabil genug, um sofort die volle Last zu übernehmen. Einzelne erfolgreiche Prüfungen können durch einen transienten Zustand entstehen.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb müssen daher zwei Richtungen betrachtet werden: der Übergang von gesund zu fehlerhaft und die Rückkehr in den aktiven Pool. Aufeinanderfolgende Prüfergebnisse, tolerierte Fehler und eine kontrollierte Wiederaufnahme reduzieren Zustandsflattern. Ohne solche Regeln kann ein Backend wiederholt aus- und eingeschlossen werden. Das erschwert die Analyse und erzeugt zusätzliche Last durch wechselnde Verbindungen oder Wiederholungen.\u003c/p\u003e\n\u003cp\u003eDie Edge-Plattform liefert dafür die Routing- und Failover-Ebene; die konkrete Prüflogik muss jedoch zum Service passen. Teams sollten festlegen, welche Fehler als temporär gelten, wann ein Pool als erschöpft betrachtet wird und wie ein wiederhergestelltes Ziel validiert wird. Health Monitoring und Traffic-Steuerung gehören dabei zusammen, dürfen aber nicht verwechselt werden: Monitoring erklärt den Zustand, Failover verändert den Datenpfad.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-erreichbar-aber-nicht-nutzbar\"\u003eBetriebsszenario: Erreichbar, aber nicht nutzbar\u003c/h2\u003e\n\u003cp\u003eEin Backend-Pool besteht aus mehreren Anwendungszielen. Der Prozess läuft auf allen Zielen, und ein einfacher Netzwerk-Check bleibt erfolgreich. Nach einer Störung der gemeinsamen Datenbank beantworten die Anwendungen Verbindungen weiterhin, liefern aber für produktive Requests Fehler oder Timeouts.\u003c/p\u003e\n\u003cp\u003eEin reiner Erreichbarkeitscheck erkennt den Serviceausfall nicht. Ein anwendungsspezifischer Check, der die relevante Verarbeitung validiert, könnte die betroffenen Ziele aus dem Routing nehmen. Gleichzeitig darf dieser Check nicht bei jeder kurzen Datenbankverzögerung den gesamten Pool deaktivieren. Die Entscheidung hängt deshalb von der Failure Domain und der gewünschten Betriebsreaktion ab: lokales Failover, Pool-Failover oder bewusste Fehlersichtbarkeit für den Bereitschaftsdienst.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sind-erfolgreiche-tcp-verbindungen-ein-ausreichender-health-check\"\u003eSind erfolgreiche TCP-Verbindungen ein ausreichender Health Check?\u003c/h3\u003e\n\u003cp\u003eNein. Sie belegen primär Netzwerk- und Listener-Erreichbarkeit. Für Anwendungen muss zusätzlich bewertet werden, ob Requests auf der relevanten Protokoll- und Funktionsebene verarbeitet werden.\u003c/p\u003e\n\u003ch3 id=\"warum-kann-ein-zu-umfassender-health-check-problematisch-sein\"\u003eWarum kann ein zu umfassender Health Check problematisch sein?\u003c/h3\u003e\n\u003cp\u003eEr kann eine lokale oder abhängige Störung auf den gesamten Backend-Pool übertragen. Dadurch wird mehr Kapazität aus dem Routing genommen, als der tatsächliche Fehler erfordert.\u003c/p\u003e\n\u003ch3 id=\"was-sollte-beim-wiederanlauf-eines-backends-geprüft-werden\"\u003eWas sollte beim Wiederanlauf eines Backends geprüft werden?\u003c/h3\u003e\n\u003cp\u003eNicht nur die erste erfolgreiche Antwort. Entscheidend sind stabile Prüfergebnisse und eine kontrollierte Rückkehr in den aktiven Pool, damit ein instabiles Ziel keinen erneuten Fehlerzyklus auslöst.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks sind keine neutrale Statusanzeige. Sie übersetzen technische Beobachtungen in Routing- und Failover-Entscheidungen und müssen deshalb die relevante Failure Domain möglichst genau abbilden. Netzwerk-Erreichbarkeit, Anwendungsgesundheit und Abhängigkeiten sind getrennt zu bewerten. Die ayedo Edge Cloud ordnet diese Backend-Bewertungen in eine verteilte Edge-Plattform ein, die Traffic vor den Backends steuert. Belastbares Failover entsteht dabei nicht durch möglichst viele Checks, sondern durch passende Signale und kontrollierte Zustandswechsel.\u003c/p\u003e\n", "summary": "\nTL;DR Backend Health Checks liefern die Signale, anhand derer eine Edge-Plattform erreichbare und nicht erreichbare Ziele unterscheidet. Ihre Aussagekraft hängt jedoch vom Prüfpunkt ab: Netzwerkverbindung, Prozesszustand und tatsächlich nutzbarer Service sind unterschiedliche Failure Domains. Belastbares Failover entsteht deshalb erst durch passende Prüfsignale und kontrollierten Wiederanlauf.\nEin Failover kann nur so zuverlässig sein wie das Signal, auf dem es basiert. Ein erreichbarer TCP-Port beweist nicht, dass eine Anwendung Requests korrekt verarbeitet. Umgekehrt kann ein einzelnes fehlerhaftes Anwendungssignal einen gesunden Backend-Pool fälschlich aus dem Routing nehmen. Health Checks sind daher keine reine Verfügbarkeitsanzeige, sondern eine betriebliche Entscheidungslogik: Sie beeinflussen, welches Ziel Traffic erhält und wann ein Backend als wieder einsatzbereit gilt.\n", "image": "https://ayedo.de/backend-health-checks-als-grundlage-fur-belastbares-failover.png", "date_published": "2026-09-07T13:54:39Z", "date_modified": "2026-09-07T13:54:39Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/posts/backend-pools-im-failover-zustande-routing-und-recovery/", "url": "https://ayedo.de/posts/backend-pools-im-failover-zustande-routing-und-recovery/", "title": "Backend-Pools im Failover: Zustände, Routing und Recovery", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-pools-im-failover-zustande-routing-und-recovery/backend-pools-im-failover-zustande-routing-und-recovery.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend-Pools sind kein statisches Verzeichnis von Zielsystemen, sondern ein Betriebsmodell für Lastverteilung, Zustandsbewertung und kontrolliertes Recovery. Failover beginnt mit Health Checks, endet aber erst, wenn Rückfall, Konsistenz und erneute Belastbarkeit des Primärpools geprüft sind. Ohne definierte Zustandsübergänge kann die Rückkehr zum Regelbetrieb neue Ausfälle erzeugen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Backend-Failover ist nicht erfolgreich, nur weil Traffic kurzfristig auf ein Ersatzziel umgeleitet wurde. Entscheidend ist, wie der Backend-Pool Zustände bewertet, Routing-Entscheidungen ableitet und nach einer Störung wieder in den Regelbetrieb zurückkehrt. Ein häufiger Architekturfehler besteht darin, den Sekundärpool lediglich als technische Reserve zu betrachten. Dadurch bleiben Fragen zu Datenkonsistenz, Rückfall, Kapazität und zur kontrollierten Wiederaufnahme des Primärziels ungeklärt. Ein belastbares Modell behandelt Primär- und Ersatzziele als Teile eines zusammenhängenden Betriebsprozesses. Die Edge übernimmt dabei die öffentliche Verkehrssteuerung; die Compute-Infrastruktur bleibt für Anwendungen, Daten und deren Wiederanlauf verantwortlich.\u003c/p\u003e\n\u003ch2 id=\"1-der-backend-pool-als-zustandsmodell\"\u003e1. Der Backend-Pool als Zustandsmodell\u003c/h2\u003e\n\u003cp\u003eEin Backend-Pool beschreibt nicht nur eine Gruppe von Servern, Services oder Endpunkten. Er bildet ab, welche Ziele grundsätzlich verfügbar sind, welche Priorität sie besitzen und unter welchen Bedingungen Traffic zu ihnen geroutet werden darf. Health Checks liefern dafür technische Signale: Erreichbarkeit, Antwortverhalten oder die Verfügbarkeit eines definierten Service-Endpunkts.\u003c/p\u003e\n\u003cp\u003eAus diesen Signalen entstehen Zustände wie „bereit“, „beeinträchtigt“, „nicht verfügbar“ oder „wird wiederhergestellt“. Wichtig ist die Trennung zwischen einem einzelnen fehlerhaften Backend und dem Ausfall eines gesamten Pools. Ein einzelnes Ziel kann aus der Lastverteilung entfernt werden, während der Pool weiterhin aktiv bleibt. Erst wenn keine ausreichende Kapazität mehr verfügbar ist oder definierte Fehlerbedingungen eintreten, wird ein Backend-Failover ausgelöst.\u003c/p\u003e\n\u003cp\u003eIn einer Edge-Plattform wie der ayedo Edge Cloud verbinden sich Health Checks und Lastverteilung zu einer Routing-Entscheidung. Der Pool ist damit eine betriebliche Abstraktion: Er legt fest, welche Backends Traffic erhalten und wann ein kontrollierter Wechsel auf Ersatzziele notwendig wird.\u003c/p\u003e\n\u003ch2 id=\"2-failover-ist-eine-routing--und-kapazitätsentscheidung\"\u003e2. Failover ist eine Routing- und Kapazitätsentscheidung\u003c/h2\u003e\n\u003cp\u003eBeim Failover wird Traffic nicht einfach „irgendwohin“ verschoben. Die Edge muss ein Ziel auswählen, das technisch erreichbar und für die erwartete Last geeignet ist. Ein Ersatzziel kann zwar verfügbar sein, aber nur einen Teil des normalen Verkehrs aufnehmen. Deshalb gehören Prioritäten, Pool-Grenzen und Kapazitätsannahmen zusammen.\u003c/p\u003e\n\u003cp\u003eEin sinnvoller Ablauf entfernt zunächst einzelne fehlerhafte Backends aus der aktiven Lastverteilung. Dadurch kann ein Pool degradiert weiterarbeiten, ohne sofort den gesamten Traffic umzuschalten. Erst bei einem Pool-Ausfall oder einer definierten Mindestverfügbarkeit wird der Ersatzpool aktiviert. Diese Abstufung verhindert unnötige Wechsel und reduziert Zustandsflattern.\u003c/p\u003e\n\u003cp\u003eDie Konsequenzen sind auch organisatorisch relevant. Teams müssen vorab festlegen, ob der Ersatzpool dieselbe Anwendung vollständig bedienen kann, ob er nur einen eingeschränkten Funktionsumfang bereitstellt oder ob die Umschaltung lediglich die Erreichbarkeit einer statischen Fehlerseite sicherstellt. Die ayedo Edge Cloud unterstützt diesen Prozess durch Backend Health Checks, Failover und Lastverteilung am öffentlichen Eingang. Die fachliche Eignung und Kapazität der Backends bleibt jedoch eine Verantwortung der jeweiligen Anwendung und Compute-Umgebung.\u003c/p\u003e\n\u003ch2 id=\"3-rückfall-braucht-kontrollierte-zustandsübergänge\"\u003e3. Rückfall braucht kontrollierte Zustandsübergänge\u003c/h2\u003e\n\u003cp\u003eDer schwierigste Teil eines Failovers beginnt häufig nach der Stabilisierung. Sobald der Primärpool wieder erreichbar ist, darf er nicht automatisch sofort die gesamte Last übernehmen. Ein erfolgreicher Health Check belegt zunächst nur, dass ein Prüfpunkt antwortet. Er sagt nicht zwingend aus, dass Initialisierung, Datenbestand, Abhängigkeiten und Skalierung abgeschlossen sind.\u003c/p\u003e\n\u003cp\u003eEin kontrollierter Recovery-Prozess unterscheidet daher mindestens zwischen „wieder erreichbar“, „bereit für begrenzten Traffic“ und „für Regelbetrieb freigegeben“. Während dieser Phase kann der Primärpool schrittweise in die Lastverteilung zurückkehren. Parallel muss beobachtet werden, ob Fehlerquoten, Antwortzeiten und abhängige Systeme stabil bleiben. Erst danach sollte der Ersatzpool entlastet oder deaktiviert werden.\u003c/p\u003e\n\u003cp\u003eBesonders relevant ist die Zustandskonsistenz. Wenn während des Failovers schreibende Anfragen verarbeitet wurden, muss geklärt sein, wie der Primärpool diesen Zustand übernimmt. Die Edge kann Routing und Rückfall steuern, aber keine fachliche Datenreplikation ersetzen. Bei der ayedo Edge Cloud ist Recovery deshalb als Zusammenspiel von Backend-Zustand, Health Checks, Lastverteilung und den Betriebsmechanismen der Compute-Plattform zu verstehen.\u003c/p\u003e\n\u003ch2 id=\"4-zustandskonsistenz-und-betrieb-im-aktiv-aktiv-modell\"\u003e4. Zustandskonsistenz und Betrieb im Aktiv-Aktiv-Modell\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv-Architekturen verändern die Failover-Logik. Mehrere Backends oder Standorte können gleichzeitig Traffic verarbeiten; ein Ausfall führt dann nicht zwingend zu einem vollständigen Wechsel zwischen „primär“ und „sekundär“. Stattdessen werden fehlerhafte Ziele aus der Verteilung entfernt, während verfügbare Ziele den Traffic übernehmen. Das kann die Wiederherstellung vereinfachen, erhöht aber die Anforderungen an Konsistenz und Kapazitätsplanung.\u003c/p\u003e\n\u003cp\u003eEin Backend-Pool benötigt deshalb klare Regeln für Eintritt, Ausschluss und Wiederaufnahme von Zielen. Dazu gehören geeignete Health-Check-Endpunkte, definierte Schwellenwerte und ein Verfahren gegen kurzfristige Zustandswechsel. Ebenso wichtig ist die Beobachtbarkeit: Traffic- und Usage-Statistiken helfen, die Auswirkungen eines Pool-Ausfalls und die Belastung während des Recovery zu beurteilen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist als verteilte, Aktiv-Aktiv arbeitende Edge-Plattform mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System auf kontinuierliche Verkehrssteuerung ausgelegt. Das ersetzt keine redundante Anwendung, schafft aber einen zentralen Ort für Routing, Schutz und Lastverteilung. Backend-Pools werden dadurch unabhängig davon steuerbar, ob die eigentlichen Workloads bei ayedo, im eigenen Rechenzentrum oder bei einem anderen Provider betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem primären \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster und hält einen zweiten Cluster bei einem anderen Provider vor. Der Primärpool verliert zunächst einzelne Backends. Health Checks entfernen diese Ziele, die verbleibenden Instanzen übernehmen die Last. Fällt der Pool vollständig aus, routet die Edge auf den Ersatzpool.\u003c/p\u003e\n\u003cp\u003eNach der Reparatur meldet der Primärpool wieder erfolgreiche Checks. Ein automatischer Vollrückfall wäre riskant, wenn Migrationen, Cache-Aufbau oder Skalierung noch laufen. Stattdessen wird der Primärpool zunächst begrenzt zugelassen und anhand der Betriebsdaten bewertet. Erst bei stabiler Verarbeitung übernimmt er wieder die reguläre Last. Der Ersatzpool bleibt so lange aktiv, bis der Recovery-Prozess abgeschlossen ist.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"wann-sollte-ein-einzelnes-backend-aus-dem-pool-entfernt-werden\"\u003eWann sollte ein einzelnes Backend aus dem Pool entfernt werden?\u003c/h3\u003e\n\u003cp\u003eWenn Health Checks oder definierte Fehlerbedingungen zeigen, dass dieses Ziel Anfragen nicht zuverlässig verarbeitet. Der gesamte Pool sollte erst bei unzureichender Restkapazität ausfallen.\u003c/p\u003e\n\u003ch3 id=\"muss-ein-ersatzpool-dieselbe-kapazität-wie-der-primärpool-haben\"\u003eMuss ein Ersatzpool dieselbe Kapazität wie der Primärpool haben?\u003c/h3\u003e\n\u003cp\u003eNein. Er kann auch einen eingeschränkten Betrieb ermöglichen. Diese Begrenzung muss jedoch bekannt sein und in Routing, Kommunikation und Lastplanung berücksichtigt werden.\u003c/p\u003e\n\u003ch3 id=\"warum-reicht-ein-erfolgreicher-health-check-für-den-rückfall-nicht-aus\"\u003eWarum reicht ein erfolgreicher Health Check für den Rückfall nicht aus?\u003c/h3\u003e\n\u003cp\u003eWeil Erreichbarkeit nicht automatisch Anwendungsbereitschaft, Datenkonsistenz oder ausreichende Kapazität bedeutet. Recovery benötigt zusätzliche Betriebsprüfungen und eine kontrollierte Wiederaufnahme.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eBackend-Failover ist ein Zustands- und Betriebsmodell, kein einzelner Routing-Schalter. Health Checks, Pool-Ausfall, Ersatzrouting und Rückfall müssen dieselben Zustände und Verantwortlichkeiten abbilden. Wer den Recovery-Prozess nicht definiert, verlagert das Ausfallrisiko lediglich auf den Wiederanlauf. Eine Edge-Plattform wie die ayedo Edge Cloud kann diese Verkehrssteuerung providerunabhängig bündeln. Die Stabilität des Gesamtsystems entsteht jedoch erst durch das Zusammenspiel von Edge, Backends, Datenkonsistenz und Betrieb.\u003c/p\u003e\n", "summary": "\nTL;DR Backend-Pools sind kein statisches Verzeichnis von Zielsystemen, sondern ein Betriebsmodell für Lastverteilung, Zustandsbewertung und kontrolliertes Recovery. Failover beginnt mit Health Checks, endet aber erst, wenn Rückfall, Konsistenz und erneute Belastbarkeit des Primärpools geprüft sind. Ohne definierte Zustandsübergänge kann die Rückkehr zum Regelbetrieb neue Ausfälle erzeugen.\nEinleitung Ein Backend-Failover ist nicht erfolgreich, nur weil Traffic kurzfristig auf ein Ersatzziel umgeleitet wurde. Entscheidend ist, wie der Backend-Pool Zustände bewertet, Routing-Entscheidungen ableitet und nach einer Störung wieder in den Regelbetrieb zurückkehrt. Ein häufiger Architekturfehler besteht darin, den Sekundärpool lediglich als technische Reserve zu betrachten. Dadurch bleiben Fragen zu Datenkonsistenz, Rückfall, Kapazität und zur kontrollierten Wiederaufnahme des Primärziels ungeklärt. Ein belastbares Modell behandelt Primär- und Ersatzziele als Teile eines zusammenhängenden Betriebsprozesses. Die Edge übernimmt dabei die öffentliche Verkehrssteuerung; die Compute-Infrastruktur bleibt für Anwendungen, Daten und deren Wiederanlauf verantwortlich.\n", "image": "https://ayedo.de/backend-pools-im-failover-zustande-routing-und-recovery.png", "date_published": "2026-09-07T13:54:39Z", "date_modified": "2026-09-07T13:54:39Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/dns-basiertes-failover-ttl-caching-und-ausfallzeiten/", "url": "https://ayedo.de/posts/dns-basiertes-failover-ttl-caching-und-ausfallzeiten/", "title": "DNS-basiertes Failover: TTL, Caching und Ausfallzeiten", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-basiertes-failover-ttl-caching-und-ausfallzeiten/dns-basiertes-failover-ttl-caching-und-ausfallzeiten.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS-basiertes Failover verteilt Anfragen auf erreichbare Ziele, kann bestehende Verbindungen aber nicht umleiten und wirkt wegen Caching nicht sofort überall. TTL, rekursive Resolver, Betriebssysteme und Anwendungen beeinflussen die Umschaltzeit. Anycast DNS und Multi-Provider-DNS erhöhen die Steuerbarkeit und Resilienz, beseitigen diese Unsicherheit jedoch nicht vollständig.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNS-basiertes Failover wird häufig mit einer schnellen Umschaltung gleichgesetzt: Ein Ziel ist nicht erreichbar, der DNS-Eintrag ändert sich, und Clients verwenden automatisch ein alternatives Backend. Diese Annahme ist technisch zu einfach. DNS verteilt Namensauflösungen, nicht bereits etablierte Verbindungen. Außerdem bestimmen TTL, rekursive Resolver, lokale DNS-Caches und anwendungsspezifische Zwischenspeicher, wann eine Änderung tatsächlich wirksam wird. Dadurch entsteht ein zentraler Trade-off: DNS bietet eine breite Steuerungsmöglichkeit über viele Clients und Provider hinweg, aber keine präzise Kontrolle über den Zeitpunkt jeder einzelnen Umschaltung.\u003c/p\u003e\n\u003ch2 id=\"1-dns-steuert-neue-auflösungen-nicht-bestehende-verbindungen\"\u003e1. DNS steuert neue Auflösungen, nicht bestehende Verbindungen\u003c/h2\u003e\n\u003cp\u003eBei einem DNS-basierten Failover wird die Antwort auf eine Namensauflösung verändert. Ein Resolver kann statt der bisherigen IP-Adresse künftig ein alternatives Ziel zurückgeben. Das hilft bei neuen Verbindungen, erreicht aber keine bereits laufenden TCP- oder TLS-Sessions. Diese bleiben bestehen, bis sie regulär beendet werden oder wegen eines Fehlers abbrechen.\u003c/p\u003e\n\u003cp\u003eDie tatsächliche Umschaltzeit hängt deshalb nicht nur von der Erkennung des Ausfalls ab. Auch die Dauer der bestehenden Verbindungen, Retries auf Anwendungsebene und das Verhalten von Clients beeinflussen die Unterbrechung. Ein kurzlebiger HTTP-Request reagiert anders als eine langlebige API-Verbindung oder ein Streaming-Kanal.\u003c/p\u003e\n\u003cp\u003eFür die Betriebsplanung ist diese Unterscheidung entscheidend: DNS-Failover ist ein Mechanismus für neue Verbindungsaufnahmen. Es ersetzt weder Session-Management noch Applikations-Failover. Anwendungen müssen mit temporär nicht erreichbaren Zielen umgehen können, etwa durch Timeouts, Wiederholungslogik und idempotente Requests.\u003c/p\u003e\n\u003ch2 id=\"2-ttl-ist-eine-obergrenze-kein-umschaltversprechen\"\u003e2. TTL ist eine Obergrenze, kein Umschaltversprechen\u003c/h2\u003e\n\u003cp\u003eDie TTL legt fest, wie lange eine DNS-Antwort grundsätzlich zwischengespeichert werden darf. Eine niedrige TTL kann die Zeit bis zur erneuten Abfrage verkürzen. Sie garantiert jedoch nicht, dass alle Clients nach Ablauf exakt zu diesem Zeitpunkt eine neue Antwort erhalten. Resolver können Abfragen zeitlich versetzt durchführen, und Endgeräte oder Anwendungen können zusätzliche Caches verwenden.\u003c/p\u003e\n\u003cp\u003eEine hohe TTL reduziert normalerweise DNS-Abfragen und kann die Infrastruktur entlasten. Im Fehlerfall verlängert sie aber die Bindung an ein nicht erreichbares Ziel. Eine sehr niedrige TTL verbessert die Reaktionsfähigkeit, erhöht jedoch die Abhängigkeit von DNS-Erreichbarkeit und die Anzahl der Auflösungen. Außerdem bleibt die TTL wirkungslos, wenn eine Anwendung die Adresse selbst länger zwischenspeichert.\u003c/p\u003e\n\u003cp\u003eDer sinnvolle Wert ergibt sich daher aus dem Ausfallmodell, nicht aus dem Wunsch nach möglichst schneller Umschaltung. Für kritische Services sollte getestet werden, wie rekursive Resolver, Betriebssysteme, Libraries und Clients tatsächlich reagieren. Erst diese Beobachtung macht aus einer konfigurierten TTL eine belastbare Betriebserwartung.\u003c/p\u003e\n\u003ch2 id=\"3-anycast-dns-und-multi-provider-dns-erweitern-die-resilienz\"\u003e3. Anycast DNS und Multi-Provider-DNS erweitern die Resilienz\u003c/h2\u003e\n\u003cp\u003eAnycast DNS verteilt DNS-Anfragen über mehrere erreichbare Netzwerkknoten und nutzt Routing, damit Resolver einen geeigneten Antwortpunkt erreichen. Das kann die Erreichbarkeit des DNS-Dienstes verbessern und die Abhängigkeit von einem einzelnen Standort reduzieren. Die nachgelagerte Failover-Entscheidung bleibt davon getrennt: Auch ein global erreichbarer DNS-Dienst kann weiterhin Antworten liefern, die bei einzelnen Clients noch aus dem Cache stammen.\u003c/p\u003e\n\u003cp\u003eMulti-Provider-DNS verteilt den autoritativen DNS-Betrieb über mehrere Anbieter. Dadurch entsteht eine zusätzliche Ausfallgrenze, beispielsweise wenn ein DNS-Provider selbst nicht erreichbar ist. Gleichzeitig steigen die Anforderungen an Konfiguration, Monitoring, Änderungsprozesse und Konsistenz. Ein zweiter Provider ist kein automatisches Failover, wenn Zonen, Health Checks oder Delegationen nicht abgestimmt betrieben werden.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform wie die ayedo Edge Cloud verbindet Anycast DNS und Multi-Provider-DNS mit einer eigenen Netzwerk-Infrastruktur und einem eigenen Autonomous System. Das stärkt die Unabhängigkeit im öffentlichen Eingangspfad. Die grundsätzliche Cache-Latenz von DNS bleibt jedoch bestehen und muss in der Architektur berücksichtigt werden.\u003c/p\u003e\n\u003ch2 id=\"4-health-checks-erkennen-zustände-aber-nicht-jede-nutzerwirkung\"\u003e4. Health Checks erkennen Zustände, aber nicht jede Nutzerwirkung\u003c/h2\u003e\n\u003cp\u003eHealth Checks können prüfen, ob ein Ziel erreichbar ist oder auf definierte Anfragen korrekt reagiert. Auf dieser Grundlage lässt sich die DNS-Antwort anpassen und Traffic zu einem anderen Ziel lenken. Zwischen erkannter Störung und wirksamer Umschaltung liegen jedoch mehrere Schritte: Der Check muss auslösen, die autoritative Antwort muss aktualisiert werden, Resolver müssen neu abfragen, und Clients müssen die neue Adresse verwenden.\u003c/p\u003e\n\u003cp\u003eDabei ist die Wahl des Prüfpunktes wichtig. Ein Check aus einer einzelnen Netzwerkposition kann regionale Routing- oder Providerprobleme übersehen. Ein Ziel kann für den Health Check erreichbar sein, während eine Anwendung funktional gestört ist. Umgekehrt kann ein temporärer Fehler zu unnötigen Umschaltungen führen. Schwellenwerte, Wiederholungen und Rückkehrlogik beeinflussen deshalb die Stabilität des Failovers.\u003c/p\u003e\n\u003cp\u003eBetrieblich braucht DNS-Failover nachvollziehbare Telemetrie: Welche Ziele gelten als gesund, welche Antworten werden aktuell autoritativ ausgegeben, und wie lange halten Resolver alte Daten? Die ayedo Edge Cloud stellt Backend Health Checks und Failover als Teil ihrer Edge-Funktionen bereit. Für die Bewertung der Ausfallzeit müssen Betreiber dennoch DNS-Caching und Clientverhalten separat betrachten.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API an zwei Standorten und veröffentlicht sie unter einem gemeinsamen DNS-Namen. Ein Health Check erkennt, dass Standort A keine gültigen Antworten mehr liefert. Die autoritative DNS-Konfiguration verweist daraufhin auf Standort B. Neue Clients, deren Resolver keine alte Antwort mehr verwenden, erreichen B. Andere Clients erhalten weiterhin A, solange ihre Resolver- oder Anwendungscaches gültig sind. Bereits bestehende Verbindungen zu A schlagen zusätzlich fehl, bis die Anwendung einen Retry ausführt oder die Verbindung neu aufbaut.\u003c/p\u003e\n\u003cp\u003eEin niedriger TTL-Wert reduziert die erwartete Verzögerung, eliminiert sie aber nicht. Ein Anycast-DNS- und Multi-Provider-Ansatz erhöht die Verfügbarkeit der DNS-Steuerung, ersetzt jedoch kein Applikationsverhalten für Timeouts, Retries und Sessions.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-ttl-von-wenigen-sekunden-gleichbedeutend-mit-einem-sofortigen-failover\"\u003eIst eine TTL von wenigen Sekunden gleichbedeutend mit einem sofortigen Failover?\u003c/h3\u003e\n\u003cp\u003eNein. Sie begrenzt die vorgesehene Cache-Dauer, garantiert aber keine exakte Wirksamkeit. Resolver, Betriebssysteme und Anwendungen können die Umschaltung unterschiedlich schnell übernehmen.\u003c/p\u003e\n\u003ch3 id=\"kann-dns-failover-bestehende-verbindungen-auf-ein-anderes-backend-verschieben\"\u003eKann DNS-Failover bestehende Verbindungen auf ein anderes Backend verschieben?\u003c/h3\u003e\n\u003cp\u003eNein. DNS beeinflusst neue Auflösungen. Bestehende TCP-, TLS- oder Anwendungssitzungen müssen auslaufen, fehlschlagen oder durch die Anwendung neu aufgebaut werden.\u003c/p\u003e\n\u003ch3 id=\"was-leistet-anycast-dns-zusätzlich\"\u003eWas leistet Anycast DNS zusätzlich?\u003c/h3\u003e\n\u003cp\u003eAnycast DNS verbessert die Erreichbarkeit des DNS-Eingangspunkts über verteilte Netzwerkpfade. Es beseitigt jedoch weder alte DNS-Antworten in Caches noch Fehler in den Backends.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS-basiertes Failover ist ein wirksames Steuerungsinstrument für neue Verbindungen, aber kein präziser Schalter für den gesamten Datenverkehr. TTL und DNS-Caching bestimmen, wie schnell Änderungen sichtbar werden; Health Checks bestimmen, wann ein Problem erkannt wird. Anycast DNS und Multi-Provider-DNS erhöhen die Resilienz des Steuerungspfads. Die ayedo Edge Cloud ordnet diese Mechanismen in eine verteilte Edge-Plattform ein. Für belastbare Ausfallzeiten müssen Unternehmen zusätzlich Sessions, Retries und Anwendungscaches planen.\u003c/p\u003e\n", "summary": "\nTL;DR DNS-basiertes Failover verteilt Anfragen auf erreichbare Ziele, kann bestehende Verbindungen aber nicht umleiten und wirkt wegen Caching nicht sofort überall. TTL, rekursive Resolver, Betriebssysteme und Anwendungen beeinflussen die Umschaltzeit. Anycast DNS und Multi-Provider-DNS erhöhen die Steuerbarkeit und Resilienz, beseitigen diese Unsicherheit jedoch nicht vollständig.\nEinleitung DNS-basiertes Failover wird häufig mit einer schnellen Umschaltung gleichgesetzt: Ein Ziel ist nicht erreichbar, der DNS-Eintrag ändert sich, und Clients verwenden automatisch ein alternatives Backend. Diese Annahme ist technisch zu einfach. DNS verteilt Namensauflösungen, nicht bereits etablierte Verbindungen. Außerdem bestimmen TTL, rekursive Resolver, lokale DNS-Caches und anwendungsspezifische Zwischenspeicher, wann eine Änderung tatsächlich wirksam wird. Dadurch entsteht ein zentraler Trade-off: DNS bietet eine breite Steuerungsmöglichkeit über viele Clients und Provider hinweg, aber keine präzise Kontrolle über den Zeitpunkt jeder einzelnen Umschaltung.\n", "image": "https://ayedo.de/dns-basiertes-failover-ttl-caching-und-ausfallzeiten.png", "date_published": "2026-09-07T13:54:39Z", "date_modified": "2026-09-07T13:54:39Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","development","kubernetes","hosting","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/routing-basiertes-failover-fur-apis-und-webanwendungen/", "url": "https://ayedo.de/posts/routing-basiertes-failover-fur-apis-und-webanwendungen/", "title": "Routing-basiertes Failover für APIs und Webanwendungen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/routing-basiertes-failover-fur-apis-und-webanwendungen/routing-basiertes-failover-fur-apis-und-webanwendungen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eRouting-basiertes Failover entscheidet an der Edge, welcher erreichbare Backend-Pool eine Anfrage oder Verbindung erhält. Im Gegensatz zu DNS-Failover muss der Client nicht erst einen neuen Zielnamen auflösen. Das verkürzt den Reaktionsweg, macht Gesundheitszustände unmittelbar nutzbar und trennt öffentlichen Zugang von der eigentlichen Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin DNS-Eintrag kann nicht zuverlässig abbilden, ob ein konkreter Backend-Pool gerade Requests verarbeitet. DNS verteilt Namen und Adressen, während die eigentliche Verfügbarkeitsentscheidung erst beim Verbindungsaufbau und bei der Anfrage sichtbar wird. Wird Failover ausschließlich über DNS umgesetzt, hängen Reaktionszeit und Wirksamkeit zusätzlich von TTLs, Resolvern, Caches und bestehenden Verbindungen ab. Routing-basiertes Failover setzt deshalb an einer anderen Stelle an: Die Edge nimmt den Traffic entgegen, prüft die Erreichbarkeit konfigurierter Backends und wählt den verfügbaren Pool direkt für die Weiterleitung. Das ist besonders relevant für APIs und Webanwendungen mit mehreren Betriebsstandorten oder Providern.\u003c/p\u003e\n\u003ch2 id=\"1-die-failover-entscheidung-gehört-an-den-traffic-eingang\"\u003e1. Die Failover-Entscheidung gehört an den Traffic-Eingang\u003c/h2\u003e\n\u003cp\u003eBei routing-basiertem Failover liegt die zentrale Entscheidung zwischen Client und Backend. Die Anfrage erreicht zunächst einen öffentlichen Edge-Endpunkt. Dort wird anhand des Protokolls, des Dienstes und des Zustands der Backend-Pools bestimmt, wohin der Traffic weitergeleitet wird. Fällt der primäre Pool aus oder ist er nicht erreichbar, kann die Edge auf einen alternativen Pool routen.\u003c/p\u003e\n\u003cp\u003eBei Layer 4 erfolgt diese Entscheidung auf Ebene von Verbindungen und Transportdaten. Das eignet sich für TCP-basierte Dienste, bei denen die Edge den Inhalt der Anwendung nicht auswerten muss. Layer 7 kann zusätzlich HTTP- beziehungsweise HTTPS-Traffic verarbeiten und den jeweiligen Web- oder API-Dienst auf Anwendungsebene verteilen. Entscheidend ist in beiden Fällen: Der Client bleibt am öffentlichen Endpunkt, während sich das interne Ziel ändern kann.\u003c/p\u003e\n\u003ch2 id=\"2-backend-health-checks-liefern-die-entscheidungsgrundlage\"\u003e2. Backend Health Checks liefern die Entscheidungsgrundlage\u003c/h2\u003e\n\u003cp\u003eFailover ist nur belastbar, wenn die Edge den Zustand der Backends systematisch bewertet. Health Checks prüfen, ob ein Backend oder ein Backend-Pool erreichbar und für die Weiterleitung geeignet ist. Dabei ist zwischen Netzwerk-Erreichbarkeit und tatsächlicher Dienstverfügbarkeit zu unterscheiden: Eine offene TCP-Verbindung bedeutet nicht automatisch, dass eine API korrekte Antworten liefert.\u003c/p\u003e\n\u003cp\u003eDie Routing-Entscheidung muss außerdem mit dem Pool-Modell übereinstimmen. Ein Pool kann mehrere Backends enthalten, während ein weiterer Pool als Ausweichziel dient. Wird der primäre Pool als nicht verfügbar bewertet, routet die Edge neue Verbindungen oder Requests zum alternativen Pool. Für den Betrieb ist dabei wichtig, Zustandswechsel nachvollziehbar zu machen. Traffic- und Usage-Statistiken helfen, Auswirkungen eines Failovers zu erkennen und zwischen Backend-Problem, Routing-Ereignis und normaler Lastverteilung zu unterscheiden.\u003c/p\u003e\n\u003ch2 id=\"3-direkte-edge-entscheidung-versus-dns-failover\"\u003e3. Direkte Edge-Entscheidung versus DNS-Failover\u003c/h2\u003e\n\u003cp\u003eDNS-Failover verändert die Antwort auf eine Namensauflösung. Resolver und Clients erhalten anschließend eine andere Adresse oder ein anderes Ziel. Dieser Ansatz kann funktionieren, ist aber an den DNS-Auflösungsweg gebunden. TTLs werden nicht immer exakt eingehalten, Resolver können Antworten zwischenspeichern, und bereits bestehende Verbindungen wechseln nicht automatisch das Ziel. Zudem verteilt DNS primär Adressen; die eigentliche Backend-Gesundheit muss in die DNS-Logik integriert werden.\u003c/p\u003e\n\u003cp\u003eRouting-basiertes Failover entscheidet dagegen beim Eingang des Traffics an der Edge. Die Namensauflösung verweist weiterhin auf den öffentlichen Dienst, während die Edge den erreichbaren Backend-Pool auswählt. Dadurch bleibt die öffentliche Adresse stabil und der Failover-Pfad wird nicht durch zusätzliche DNS-Caches verlängert. DNS bleibt für Anycast DNS und Multi-Provider-DNS relevant, ersetzt aber nicht die nachgelagerte Routing-Entscheidung für konkrete Anwendungen.\u003c/p\u003e\n\u003ch2 id=\"4-failover-verändert-auch-die-betriebsarchitektur\"\u003e4. Failover verändert auch die Betriebsarchitektur\u003c/h2\u003e\n\u003cp\u003eEin alternativer Backend-Pool ist kein rein technischer Schalter. Anwendungen müssen Zustände, Sessions, Datenhaltung und Abhängigkeiten über beide Ziele hinweg berücksichtigen. Ein stateless API-Service lässt sich meist einfacher umleiten als eine Anwendung, deren Sessions oder Schreibzugriffe an einen einzelnen Standort gebunden sind. Routing kann den Traffic verschieben, aber keine inkonsistenten Datenbestände korrigieren.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud trennt dabei den öffentlichen Zugang von der Compute-Infrastruktur. Backends können bei ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern oder bei anderen Providern betrieben werden. Backend Cloaking verhindert, dass interne Zielstrukturen zum öffentlichen Adressraum werden. Eine verteilte Multi-PoP-Architektur mit Aktiv-Aktiv-Prinzip reduziert zudem die Abhängigkeit von einem einzelnen Edge-Standort. Failover wird damit als Zusammenspiel aus Erreichbarkeit, Routing und Anwendungsdesign behandelt – nicht als isolierte DNS-Konfiguration.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEine API läuft parallel in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. Beide Cluster sind über einen gemeinsamen öffentlichen Dienst erreichbar; ein Pool ist primär, der andere dient als Ausweichziel. Die Edge prüft die Backends und routet neue API-Anfragen zunächst zum erreichbaren primären Pool. Fällt dessen API-Service aus, übernimmt der alternative Pool, ohne dass Clients einen neuen DNS-Eintrag auflösen müssen.\u003c/p\u003e\n\u003cp\u003eBei einem DNS-basierten Ansatz müsste zunächst eine andere Adresse veröffentlicht werden. Caches und bestehende Verbindungen können dazu führen, dass ein Teil des Traffics weiterhin das ausgefallene Ziel erreicht. Beim Edge-Routing bleibt der öffentliche Endpunkt unverändert. Die Anwendung muss dennoch für parallele Zustände, Datenzugriff und mögliche Wiederholungen von Requests ausgelegt sein.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-routing-basiertes-failover-dns-vollständig\"\u003eErsetzt routing-basiertes Failover DNS vollständig?\u003c/h3\u003e\n\u003cp\u003eNein. DNS bleibt für die Namensauflösung sowie für Anycast- und Multi-Provider-Szenarien relevant. Routing-basiertes Failover übernimmt die Entscheidung, welcher Backend-Pool den bereits eingehenden Traffic verarbeitet.\u003c/p\u003e\n\u003ch3 id=\"gilt-failover-gleichermaßen-für-layer-4-und-layer-7\"\u003eGilt Failover gleichermaßen für Layer 4 und Layer 7?\u003c/h3\u003e\n\u003cp\u003eDas Grundprinzip gilt für beide Ebenen. Layer 4 arbeitet verbindungsorientiert, Layer 7 verarbeitet HTTP- beziehungsweise HTTPS-Traffic und kann Anwendungsdienste differenzierter behandeln.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-mit-bestehenden-verbindungen\"\u003eWas passiert mit bestehenden Verbindungen?\u003c/h3\u003e\n\u003cp\u003eFailover wirkt primär auf neue Verbindungen oder Requests. Bereits bestehende Sessions können zum ausgefallenen Backend bestehen bleiben oder fehlschlagen und müssen von Protokoll und Anwendung behandelt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eRouting-basiertes Failover verschiebt die Verfügbarkeitsentscheidung an den Ort, an dem der Traffic tatsächlich verarbeitet wird. Das verkürzt den Reaktionsweg gegenüber einer reinen DNS-Umleitung und hält den öffentlichen Endpunkt stabil. Für APIs und Webanwendungen ist entscheidend, Health Checks, Backend-Pools und Anwendungszustände gemeinsam zu planen. Die ayedo Edge Cloud bildet dafür die vorgelagerte Routing- und Schutzebene – unabhängig davon, wo die eigentlichen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder Compute-Workloads betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR Routing-basiertes Failover entscheidet an der Edge, welcher erreichbare Backend-Pool eine Anfrage oder Verbindung erhält. Im Gegensatz zu DNS-Failover muss der Client nicht erst einen neuen Zielnamen auflösen. Das verkürzt den Reaktionsweg, macht Gesundheitszustände unmittelbar nutzbar und trennt öffentlichen Zugang von der eigentlichen Compute-Infrastruktur.\nEinleitung Ein DNS-Eintrag kann nicht zuverlässig abbilden, ob ein konkreter Backend-Pool gerade Requests verarbeitet. DNS verteilt Namen und Adressen, während die eigentliche Verfügbarkeitsentscheidung erst beim Verbindungsaufbau und bei der Anfrage sichtbar wird. Wird Failover ausschließlich über DNS umgesetzt, hängen Reaktionszeit und Wirksamkeit zusätzlich von TTLs, Resolvern, Caches und bestehenden Verbindungen ab. Routing-basiertes Failover setzt deshalb an einer anderen Stelle an: Die Edge nimmt den Traffic entgegen, prüft die Erreichbarkeit konfigurierter Backends und wählt den verfügbaren Pool direkt für die Weiterleitung. Das ist besonders relevant für APIs und Webanwendungen mit mehreren Betriebsstandorten oder Providern.\n", "image": "https://ayedo.de/routing-basiertes-failover-fur-apis-und-webanwendungen.png", "date_published": "2026-09-07T13:54:39Z", "date_modified": "2026-09-07T13:54:39Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","development","operations","kubernetes","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen/", "url": "https://ayedo.de/posts/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen/", "title": "Aktiv-Aktiv-Architektur für hochverfügbare Plattformen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur verteilt Edge-Funktionen über mehrere PoPs, statt einen Standort als passiven Ersatz vorzuhalten. Dadurch werden Failover und Wartung zu laufenden Betriebsprozessen. Für interne Plattformdienste bedeutet das: Der öffentliche Zugang, Schutzfunktionen und Routing müssen selbst ausfallsfähig sein – unabhängig davon, wo die Backends betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit endet nicht am Cluster- oder Rechenzentrumsrand. Ein Plattformdienst kann über mehrere Backends verfügen und trotzdem ausfallen, wenn sein zentraler Einstiegspunkt an einem einzelnen Standort, Loadbalancer oder DNS-System hängt. Genau dort entsteht ein häufig übersehener Single Point of Failure: die vorgelagerte Edge-Schicht.\u003c/p\u003e\n\u003cp\u003eDie Architekturentscheidung zwischen Aktiv-Passiv und Aktiv-Aktiv betrifft deshalb nicht nur Compute-Ressourcen. Sie bestimmt auch, wie Traffic angenommen, verteilt, geschützt und bei Störungen umgeleitet wird. Eine verteilte Multi-PoP-Architektur mit aktiv betriebenen Standorten behandelt die Edge als gemeinsamen Plattformbaustein – nicht als passiven Notfallstandort, der nur im Krisenfall relevant wird.\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-aktiv-beginnt-vor-dem-backend\"\u003e1. Aktiv-Aktiv beginnt vor dem Backend\u003c/h2\u003e\n\u003cp\u003eBei Aktiv-Passiv-Modellen verarbeitet normalerweise ein primärer Standort den Traffic. Ein zweiter Standort hält Ressourcen vor, übernimmt aber erst nach einer Störung. Dieses Modell kann funktionieren, wenn der Umschaltprozess zuverlässig, schnell und regelmäßig getestet ist. Es erzeugt jedoch eine zusätzliche Betriebsabhängigkeit: Der passive Pfad muss im Fehlerfall korrekt aktiviert, erreichbar und ausreichend dimensioniert sein.\u003c/p\u003e\n\u003cp\u003eAktiv-Aktiv verteilt die Verarbeitung dagegen auf mehrere gleichzeitig genutzte PoPs. Jeder Standort ist Teil des regulären Betriebs. Fällt ein PoP oder ein Teil seines Pfads aus, kann Traffic über andere aktive Standorte verarbeitet werden. Das reduziert die Abhängigkeit von einem einzelnen Umschaltereignis.\u003c/p\u003e\n\u003cp\u003eFür Plattformdienste ist diese Unterscheidung relevant, weil der Edge-Einstieg häufig mehrere Funktionen bündelt: Anycast-L4- und L7-Loadbalancing, TLS-Terminierung, WAF, DDoS-Schutz und Routing zum Backend. Werden diese Funktionen an einem einzelnen Standort konzentriert, bleibt die Plattform trotz redundanter Backends ausfallsensibel.\u003c/p\u003e\n\u003ch2 id=\"2-multi-pop-verändert-das-failover-modell\"\u003e2. Multi-PoP verändert das Failover-Modell\u003c/h2\u003e\n\u003cp\u003eFailover ist nicht nur die Frage, wohin Traffic nach einem Ausfall geleitet wird. Entscheidend ist, wer den Ausfall erkennt, auf welcher Ebene er erkannt wird und wie der verbleibende Pfad bewertet wird. Ein DNS-Failover kann andere Fehlerbilder abdecken als ein Anycast-basiertes Routing oder ein Backend-Health-Check.\u003c/p\u003e\n\u003cp\u003eIn einer Multi-PoP-Aktiv-Aktiv-Architektur greifen diese Ebenen zusammen. Die Edge nimmt Traffic verteilt an, prüft die Erreichbarkeit der Backends und kann fehlerhafte Ziele aus der Verteilung nehmen. Dadurch lässt sich zwischen einem Ausfall des PoPs, des Netzpfads und des eigentlichen Plattformdienstes unterscheiden.\u003c/p\u003e\n\u003cp\u003eDas verändert auch die Betriebsprozesse. Failover ist kein seltenes Notfallverfahren, sondern Bestandteil des Normalbetriebs. Wartungsarbeiten, Routingänderungen und Backend-Wechsel müssen so geplant werden, dass aktive Pfade kontrolliert verändert werden können. Regelmäßige Tests sind weiterhin notwendig, aber sie prüfen nicht nur einen ungenutzten Ersatzpfad, sondern das Verhalten eines kontinuierlich verteilten Systems.\u003c/p\u003e\n\u003ch2 id=\"3-die-edge-bleibt-vom-compute-getrennt\"\u003e3. Die Edge bleibt vom Compute getrennt\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv auf der Edge bedeutet nicht automatisch, dass auch die Backends aktiv-aktiv betrieben werden. Ein Dienst kann hinter der Edge weiterhin in einem einzelnen Cluster, einer Region oder einem anderen Provider laufen. Die Edge erhöht in diesem Fall die Ausfallsicherheit des öffentlichen Zugangs, beseitigt aber keine Ausfälle im Backend.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist architektonisch wichtig. Edge-Funktionen übernehmen öffentlichen Traffic-Eingang, Schutz, Termination und Lastverteilung. Die Compute-Infrastruktur führt Anwendungen und Plattformkomponenten aus. Für ein belastbares Failover-Modell müssen beide Ebenen separat betrachtet werden: Was passiert bei einem PoP-Ausfall? Was bei einem nicht erreichbaren Cluster? Und welche Zustände darf ein Backend-Health-Check als funktionsfähig bewerten?\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist für diese Trennung als verteilte Multi-PoP-Plattform ausgelegt. Ihr eigenes Autonomous System und die eigene Netzwerk-Infrastruktur bilden dabei den Rahmen für den Edge-Betrieb. Die Backends können in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in eigenen Clustern oder bei anderen Providern betrieben werden. Damit bleibt die Edge-Architektur vom gewählten Compute-Standort entkoppelt.\u003c/p\u003e\n\u003ch2 id=\"4-hochverfügbarkeit-erzeugt-betriebliche-pflichten\"\u003e4. Hochverfügbarkeit erzeugt betriebliche Pflichten\u003c/h2\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur reduziert einzelne Ausfallrisiken, macht den Betrieb aber nicht automatisch einfacher. Mehrere aktive Pfade bedeuten mehr Zustände, die beobachtet und bewertet werden müssen. Routing, Health Checks, TLS-Konfigurationen, WAF-Regeln und Backend-Zuordnungen müssen konsistent gepflegt werden.\u003c/p\u003e\n\u003cp\u003eBesonders kritisch ist die Definition von „gesund“. Ein erreichbarer Port beweist nicht, dass ein Plattformdienst nutzbar ist. Health Checks müssen zur jeweiligen Service-Semantik passen und dürfen bei kurzzeitigen Fehlern nicht zu instabilen Umschaltungen führen. Gleichzeitig muss ein tatsächlich fehlerhaftes Backend schnell aus dem Traffic genommen werden.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen entstehen daraus organisatorische Konsequenzen: Netzwerk-, Plattform- und Anwendungsteams müssen gemeinsame Fehlerbilder definieren. Runbooks sollten nicht nur den Ausfall eines Clusters, sondern auch PoP-, DNS- und Routing-Szenarien abdecken. Die Aktiv-Aktiv-Architektur ist somit weniger ein einzelnes Feature als ein Betriebsmodell, das technische Zuständigkeiten und Tests über mehrere Ebenen hinweg verbindet.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine interne Entwicklerplattform mit API-Zugang, Benutzeroberfläche und Automatisierungsdiensten. Die Workloads laufen in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. In einem Aktiv-Passiv-Modell führt ein zentraler Standort den gesamten Edge-Traffic; der Ersatzpfad wird nur bei einem größeren Ausfall aktiviert.\u003c/p\u003e\n\u003cp\u003eBei einer Aktiv-Aktiv-Architektur wird der Traffic über mehrere Edge-PoPs angenommen. Ein Backend-Health-Check erkennt, dass ein Cluster den Plattformdienst nicht mehr zuverlässig bereitstellt, und nimmt dieses Ziel aus der Verteilung. Fällt zusätzlich ein Edge-PoP aus, bleibt der Zugang über andere aktive PoPs bestehen. Die Anwendung muss dafür nicht am selben Ort wie die Edge betrieben werden. Das Failover verteilt sich auf mehrere Ebenen, statt an einer einzelnen Umschaltung zu hängen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-dasselbe-wie-zwei-aktive-kubernetes-cluster\"\u003eIst Aktiv-Aktiv dasselbe wie zwei aktive Kubernetes-Cluster?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv kann zunächst die Edge betreffen. Ob mehrere Backends gleichzeitig produktiv genutzt werden, hängt von Anwendung, Datenmodell und Betriebsstrategie ab.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-anycast-jeden-failover-mechanismus\"\u003eErsetzt Anycast jeden Failover-Mechanismus?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast verteilt den Zugang, ersetzt aber weder Backend-Health-Checks noch anwendungsspezifische Fehlererkennung und geeignete Routingregeln.\u003c/p\u003e\n\u003ch3 id=\"wann-reicht-aktiv-passiv-aus\"\u003eWann reicht Aktiv-Passiv aus?\u003c/h3\u003e\n\u003cp\u003eAktiv-Passiv kann genügen, wenn Umschaltung, Kapazität und Datenkonsistenz beherrscht sowie regelmäßig getestet werden. Die Edge bleibt dabei dennoch ein eigener Ausfallbereich.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit ist unvollständig, wenn nur die Compute-Ebene redundant ausgelegt wird. Ein einzelner Edge-Standort kann trotz mehrerer Cluster zum gemeinsamen Ausfallpunkt werden. Die Aktiv-Aktiv- und Multi-PoP-Architektur der ayedo Edge Cloud ordnet den öffentlichen Zugang, Schutz und das Failover als eigenständige Plattformschicht ein. Entscheidend bleibt, Edge und Compute getrennt zu planen und ihre Fehler- und Betriebsmodelle bewusst miteinander zu verbinden.\u003c/p\u003e\n", "summary": "\nTL;DR Eine Aktiv-Aktiv-Architektur verteilt Edge-Funktionen über mehrere PoPs, statt einen Standort als passiven Ersatz vorzuhalten. Dadurch werden Failover und Wartung zu laufenden Betriebsprozessen. Für interne Plattformdienste bedeutet das: Der öffentliche Zugang, Schutzfunktionen und Routing müssen selbst ausfallsfähig sein – unabhängig davon, wo die Backends betrieben werden.\nEinleitung Hochverfügbarkeit endet nicht am Cluster- oder Rechenzentrumsrand. Ein Plattformdienst kann über mehrere Backends verfügen und trotzdem ausfallen, wenn sein zentraler Einstiegspunkt an einem einzelnen Standort, Loadbalancer oder DNS-System hängt. Genau dort entsteht ein häufig übersehener Single Point of Failure: die vorgelagerte Edge-Schicht.\n", "image": "https://ayedo.de/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen.png", "date_published": "2026-09-07T13:49:18Z", "date_modified": "2026-09-07T13:49:18Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","kubernetes","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/backend-cloaking-als-plattformstandard-fur-services/", "url": "https://ayedo.de/posts/backend-cloaking-als-plattformstandard-fur-services/", "title": "Backend Cloaking als Plattformstandard für Services", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-cloaking-als-plattformstandard-fur-services/backend-cloaking-als-plattformstandard-fur-services.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking trennt den öffentlichen Service-Endpunkt von den tatsächlichen Backend-Adressen. Als Plattformstandard reduziert es die sichtbare Angriffsfläche, erleichtert Netzwerksegmentierung und entkoppelt Service-Veröffentlichung von internen Infrastrukturdetails. Die ayedo Edge Cloud setzt diese Trennung an der Edge um – auch für \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n außerhalb von ayedo Managed Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin öffentlicher Service sollte nicht automatisch die Adresse seines Backends preisgeben. Trotzdem entstehen in gewachsenen Plattformen häufig direkte Abhängigkeiten: DNS-Einträge zeigen auf Ingress-Adressen, Firewall-Regeln erlauben öffentlich erreichbare Backend-Netze oder Teams veröffentlichen Services mit individuellen Ausnahmen. Das erschwert Rotation, Migration und Incident Response. Backend Cloaking setzt an dieser Stelle eine klare Grenze: Clients erreichen einen öffentlichen Endpunkt an der Edge, während interne Backend-Adressen außerhalb des öffentlichen Sichtbarkeitsbereichs bleiben. Für eine interne Plattform ist entscheidend, diese Trennung nicht als optionale Sonderkonfiguration, sondern als Standard für Service Exposure zu etablieren.\u003c/p\u003e\n\u003ch2 id=\"1-öffentlicher-endpunkt-und-backend-sind-unterschiedliche-rollen\"\u003e1. Öffentlicher Endpunkt und Backend sind unterschiedliche Rollen\u003c/h2\u003e\n\u003cp\u003eEin öffentlicher Endpunkt ist die Adresse, unter der ein Service für Clients erreichbar ist. Das Backend ist dagegen die technische Zielinstanz, die Anfragen verarbeitet. Beide Rollen müssen weder dieselbe IP-Adresse noch dieselbe Netzgrenze haben. Backend Cloaking macht diese Unterscheidung im Datenpfad konsequent sichtbar.\u003c/p\u003e\n\u003cp\u003eDer Client verbindet sich mit der Edge. Dort können Routing, TLS Termination, Web Application Firewall, DDoS Protection und Lastverteilung erfolgen, bevor der Traffic zum Backend weitergeleitet wird. Für den Client bleibt die interne Zieladresse unsichtbar. Sichtbar ist nur der öffentliche Service-Endpunkt und die dafür vorgesehenen Eigenschaften.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist mehr als eine kosmetische DNS-Abstraktion. Backend-Adressen können geändert, migriert oder ausgetauscht werden, ohne den öffentlichen Endpunkt neu zu veröffentlichen. Auch die interne Topologie muss nicht Bestandteil externer Dokumentation oder Clientkonfiguration sein. Die ayedo Edge Cloud bildet dafür den öffentlichen Eingang vor Anwendungen und APIs und hält die Backend-Zielstruktur von diesem Eingang getrennt.\u003c/p\u003e\n\u003ch2 id=\"2-weniger-sichtbarkeit-verbessert-segmentierung-und-security\"\u003e2. Weniger Sichtbarkeit verbessert Segmentierung und Security\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking ersetzt keine Zugriffskontrollen. Ein Backend muss weiterhin so abgesichert sein, dass nur der vorgesehene Traffic es erreicht. Die reduzierte Sichtbarkeit senkt jedoch die Zahl der direkt adressierbaren Komponenten und unterstützt dadurch eine klarere Netzwerksegmentierung.\u003c/p\u003e\n\u003cp\u003eOhne diese Trennung können öffentliche DNS-Einträge, Fehlkonfigurationen oder geleakte Konfigurationsdaten interne Adressen sichtbar machen. Das bedeutet nicht automatisch, dass ein Backend erreichbar ist. Es vergrößert aber die Angriffsfläche für Scans, Fehlzugriffe und gezielte Angriffe. Wenn nur die Edge als öffentlicher Eingang dient, lassen sich Netzregeln und Monitoring auf diesen Datenpfad konzentrieren.\u003c/p\u003e\n\u003cp\u003eBetrieblich entsteht ein weiterer Vorteil: Backends müssen nicht für beliebige externe Netze ausgelegt werden. Sie können in privaten Segmenten oder innerhalb eines \u003ca href=\"/kubernetes/\"\u003eKubernetes-Netzwerks\u003c/a\u003e\n verbleiben, während die Edge die externe Erreichbarkeit übernimmt. Die ayedo Edge Cloud unterstützt dieses Modell mit Backend Cloaking, Health Checks und Failover. Die konkrete Absicherung der Backend-Strecke bleibt dabei Teil der jeweiligen Netzwerk- und Plattformarchitektur.\u003c/p\u003e\n\u003ch2 id=\"3-der-plattformstandard-reduziert-individuelle-service-exposure\"\u003e3. Der Plattformstandard reduziert individuelle Service Exposure\u003c/h2\u003e\n\u003cp\u003eFür Anwendungsteams wird die Veröffentlichung eines Services unnötig kompliziert, wenn sie selbst öffentliche IPs, DNS, Zertifikate, Firewall-Regeln und Backend-Erreichbarkeit koordinieren müssen. Gleichzeitig entstehen bei vollständig manuellen Verfahren unterschiedliche Sicherheitsniveaus. Ein Plattformstandard verschiebt diese Verantwortung an die zentrale Plattform, ohne die Teams von einer klaren Service-Schnittstelle abzuschneiden.\u003c/p\u003e\n\u003cp\u003eDas grundlegende Muster kann verbindlich definiert werden: Ein Service erhält einen öffentlichen Endpunkt an der Edge; das Backend bleibt intern und wird über eine kontrollierte Zielkonfiguration angebunden. Teams müssen dann nicht entscheiden, ob ihre interne Adresse direkt veröffentlicht werden darf. Sie deklarieren vielmehr, welcher Service extern erreichbar sein soll und welche Backends den Traffic verarbeiten.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes-native\u003c/a\u003e\n Integration ist dafür besonders relevant, weil Services und Workloads dynamisch entstehen. Der Ansatz ist jedoch nicht auf ayedo Managed Kubernetes begrenzt. Die ayedo Edge Cloud kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden. Damit bleibt das Veröffentlichungsmuster über unterschiedliche Compute-Umgebungen hinweg konsistent.\u003c/p\u003e\n\u003ch2 id=\"4-cloaking-schafft-entkopplung-aber-keine-unsichtbare-infrastruktur\"\u003e4. Cloaking schafft Entkopplung, aber keine unsichtbare Infrastruktur\u003c/h2\u003e\n\u003cp\u003eDie zentrale Architekturentscheidung lautet nicht „Edge statt Backend“, sondern „öffentlicher Eingang getrennt von interner Verarbeitung“. Diese Entkopplung bringt allerdings Anforderungen mit sich. Routing, Health Checks, Failover, Namensauflösung und die Erreichbarkeit zwischen Edge und Backend müssen eindeutig betrieben werden. Ein verborgenes Backend ist nicht automatisch verfügbar oder korrekt segmentiert.\u003c/p\u003e\n\u003cp\u003eAuch Observability muss die zwei Perspektiven abbilden: den Client-Traffic am öffentlichen Endpunkt und die Weiterleitung zum internen Ziel. Traffic- und Usage-Statistiken an der Edge helfen dabei, externe Nutzung und Weiterleitungsverhalten getrennt zu betrachten. Für Fehleranalysen müssen Plattformteams zusätzlich den Übergang zum Backend und die Anwendung selbst einbeziehen.\u003c/p\u003e\n\u003cp\u003eWirtschaftlich reduziert ein Standard die Zahl individueller Integrationen und Ausnahmen. Das senkt langfristig den Betriebsaufwand, weil Service Exposure wiederholbar wird. Der Nutzen entsteht aber nur, wenn Cloaking verbindlich in Onboarding, Freigaben und Betriebsprozesse integriert ist. Eine Option, die jedes Team selbst aktivieren muss, bleibt ein Sonderfall und erzielt nicht die Wirkung eines Plattformstandards.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-service-über-mehrere-cluster\"\u003ePraxisszenario: Ein Service über mehrere Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n und migriert sie später in einen Cluster eines anderen Providers. In beiden Fällen soll derselbe öffentliche Endpunkt bestehen bleiben. Ohne Cloaking müssten DNS, Firewall-Regeln und Clientkonfiguration an die jeweils neue Backend-Adresse angepasst werden.\u003c/p\u003e\n\u003cp\u003eMit einer Edge vor beiden Compute-Umgebungen bleibt der öffentliche Endpunkt unverändert. Die Plattform tauscht das interne Ziel aus, prüft dessen Verfügbarkeit über Health Checks und leitet Requests nur an ein gültiges Backend weiter. Für Clients ändert sich die Adresse nicht; für die Plattform bleibt die interne Topologie austauschbar. Die Migration wird dadurch nicht automatisch risikofrei, aber sie verliert die direkte Kopplung zwischen Service Exposure und Backend-Adresse.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"verhindert-backend-cloaking-jeden-direkten-zugriff-auf-das-backend\"\u003eVerhindert Backend Cloaking jeden direkten Zugriff auf das Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Cloaking reduziert die öffentliche Sichtbarkeit. Netzwerkregeln, Authentisierung und Backend-Policies müssen zusätzlich sicherstellen, dass nur vorgesehener Traffic akzeptiert wird.\u003c/p\u003e\n\u003ch3 id=\"ist-backend-cloaking-nur-für-kubernetes-relevant\"\u003eIst Backend Cloaking nur für Kubernetes relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Das Prinzip gilt für APIs, Webanwendungen und andere Services. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n erleichtert die Standardisierung, weil Workloads und Service-Ziele dynamisch verwaltet werden.\u003c/p\u003e\n\u003ch3 id=\"muss-ein-öffentlicher-endpunkt-dauerhaft-an-dasselbe-backend-zeigen\"\u003eMuss ein öffentlicher Endpunkt dauerhaft an dasselbe Backend zeigen?\u003c/h3\u003e\n\u003cp\u003eNein. Eine zentrale Edge kann Ziele wechseln oder mehrere Backends über Health Checks und Failover berücksichtigen, während der öffentliche Endpunkt bestehen bleibt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking sollte in einer internen Plattform nicht als optionale Sicherheitsfunktion behandelt werden, sondern als Standard für Service Exposure. Die Trennung zwischen öffentlichem Endpunkt und internem Backend reduziert Sichtbarkeit, unterstützt Segmentierung und erleichtert Migrationen über Compute-Grenzen hinweg. Die ayedo Edge Cloud setzt diese Trennung als Teil ihrer Edge-Funktionalität um – unabhängig davon, ob das Backend in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, einem eigenen oder einem fremden Kubernetes-Cluster betrieben wird.\u003c/p\u003e\n", "summary": "\nTL;DR Backend Cloaking trennt den öffentlichen Service-Endpunkt von den tatsächlichen Backend-Adressen. Als Plattformstandard reduziert es die sichtbare Angriffsfläche, erleichtert Netzwerksegmentierung und entkoppelt Service-Veröffentlichung von internen Infrastrukturdetails. Die ayedo Edge Cloud setzt diese Trennung an der Edge um – auch für Kubernetes-Cluster außerhalb von ayedo Managed Kubernetes.\nEinleitung Ein öffentlicher Service sollte nicht automatisch die Adresse seines Backends preisgeben. Trotzdem entstehen in gewachsenen Plattformen häufig direkte Abhängigkeiten: DNS-Einträge zeigen auf Ingress-Adressen, Firewall-Regeln erlauben öffentlich erreichbare Backend-Netze oder Teams veröffentlichen Services mit individuellen Ausnahmen. Das erschwert Rotation, Migration und Incident Response. Backend Cloaking setzt an dieser Stelle eine klare Grenze: Clients erreichen einen öffentlichen Endpunkt an der Edge, während interne Backend-Adressen außerhalb des öffentlichen Sichtbarkeitsbereichs bleiben. Für eine interne Plattform ist entscheidend, diese Trennung nicht als optionale Sonderkonfiguration, sondern als Standard für Service Exposure zu etablieren.\n", "image": "https://ayedo.de/backend-cloaking-als-plattformstandard-fur-services.png", "date_published": "2026-09-07T13:49:18Z", "date_modified": "2026-09-07T13:49:18Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","operations","security","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/digitale-souveranitat-durch-getrennte-edge-verantwortung/", "url": "https://ayedo.de/posts/digitale-souveranitat-durch-getrennte-edge-verantwortung/", "title": "Digitale Souveränität durch getrennte Edge-Verantwortung", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/digitale-souveranitat-durch-getrennte-edge-verantwortung/digitale-souveranitat-durch-getrennte-edge-verantwortung.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität entsteht nicht durch den Verzicht auf Cloud- oder Plattformanbieter, sondern durch kontrollierbare Architekturgrenzen. Wer öffentlichen Zugang, Routing und Schutzfunktionen von der Compute-Infrastruktur trennt, kann \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n unabhängiger betreiben, Provider wechseln und Sicherheitsentscheidungen zentral durchsetzen. Die ayedo Edge Cloud unterstützt dieses Modell vor eigenen oder fremden Clustern.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n sollte nicht automatisch auch die Verantwortung für seinen öffentlichen Zugang übernehmen. Werden DNS, TLS, DDoS-Schutz, WAF und Traffic-Verteilung eng an einen einzelnen Cluster oder Cloud-Provider gekoppelt, wird ein Plattformwechsel technisch und organisatorisch aufwendig. Die Ursache liegt nicht in Kubernetes selbst, sondern in einer vermischten Zuständigkeit: Compute, Netzwerkzugang und Schutzfunktionen werden als eine Einheit betrieben. Eine getrennte Edge-Verantwortung schafft hier eine überprüfbare Architekturgrenze. Sie definiert, welche Komponenten den öffentlichen Traffic kontrollieren und welche Infrastruktur die Anwendungen ausführt. Digitale Souveränität wird damit zu einer Frage von Abhängigkeiten, Betriebsprozessen und technischer Portabilität.\u003c/p\u003e\n\u003ch2 id=\"1-digitale-souveränität-beginnt-an-der-öffentlichen-schnittstelle\"\u003e1. Digitale Souveränität beginnt an der öffentlichen Schnittstelle\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität wird häufig auf die Wahl eines Cloud- oder Infrastrukturproviders reduziert. Für den Betrieb digitaler Dienste ist jedoch eine andere Frage entscheidend: Wer kontrolliert den Weg vom Internet bis zum Backend? Dazu gehören DNS-Auflösung, IP-Adressierung, TLS-Terminierung, Routing, Lastverteilung und die Durchsetzung von Sicherheitsrichtlinien.\u003c/p\u003e\n\u003cp\u003eLiegt diese Verantwortung vollständig beim Compute-Provider, sind öffentliche Endpunkte oft eng mit dessen Netzwerk, Loadbalancing und Sicherheitsdiensten verbunden. Ein Wechsel des Clusters kann dann auch Änderungen an DNS-Zonen, Zertifikatsprozessen, IP-Adressen und Zugriffskontrollen erfordern. Das erhöht nicht nur die technische Komplexität, sondern erschwert auch Audits und standardisierte Betriebsprozesse.\u003c/p\u003e\n\u003cp\u003eEine souveränere Architektur trennt deshalb die Kontrollpunkte. Die Edge verarbeitet den öffentlichen Traffic, während die Compute-Infrastruktur Anwendungen und Workloads ausführt. Diese Trennung macht Zuständigkeiten prüfbar: Policies für den externen Zugang werden unabhängig von den internen Deployment-Prozessen betrieben.\u003c/p\u003e\n\u003ch2 id=\"2-edge-und-compute-als-getrennte-verantwortungsbereiche\"\u003e2. Edge und Compute als getrennte Verantwortungsbereiche\u003c/h2\u003e\n\u003cp\u003eEdge und Compute erfüllen unterschiedliche Aufgaben. Die Edge Cloud nimmt eingehenden Traffic entgegen, verteilt ihn auf gesunde Backends und schützt die nachgelagerte Infrastruktur. Dazu zählen beispielsweise Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, Anycast DNS, Multi-Provider-DNS, WAF, DDoS Protection und TLS Termination. Die Compute-Infrastruktur stellt dagegen die Services bereit und verarbeitet Geschäftslogik.\u003c/p\u003e\n\u003cp\u003eDiese Trennung verändert die Architekturgrenze eines Systems. Backends müssen nicht direkt öffentlich erreichbar sein, wenn Backend Cloaking den öffentlichen Zugang auf die Edge konzentriert. Health Checks und Failover können die Erreichbarkeit der Anwendungen bewerten, ohne den gesamten Traffic-Einstieg in den Cluster zu verlagern. Proxy Protocol kann dabei relevante Verbindungsinformationen an nachgelagerte Systeme übergeben, sofern dies für die Anwendung oder Auswertung erforderlich ist.\u003c/p\u003e\n\u003cp\u003eBetrieblich entsteht ein klareres Verantwortungsmodell: Edge-Policies können zentral angepasst werden, während Teams ihre Cluster unabhängig deployen. Das reduziert Kopplungen, ersetzt sie aber nicht vollständig. Routing, Backend-Erreichbarkeit und Sicherheitsregeln müssen dokumentiert, getestet und zwischen den Verantwortlichen abgestimmt werden.\u003c/p\u003e\n\u003ch2 id=\"3-providerunabhängigkeit-braucht-technische-portabilität\"\u003e3. Providerunabhängigkeit braucht technische Portabilität\u003c/h2\u003e\n\u003cp\u003eEine getrennte Edge ist besonders relevant, wenn \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n nicht an einen einzigen Betreiber gebunden sein soll. Ein Cluster kann bei ayedo Managed Kubernetes, in einer eigenen Infrastruktur oder bei einem anderen Provider betrieben werden. Der öffentliche Zugang bleibt dabei an derselben Edge-Schicht verankert, anstatt mit jedem Clusterwechsel neu entworfen zu werden.\u003c/p\u003e\n\u003cp\u003eDas ist mehr als eine Frage des Deployments. Ein standardisierter Edge-Einstieg kann Migrationspfade vereinfachen: Ein neuer Cluster wird als Backend eingebunden, seine Erreichbarkeit über Health Checks geprüft und der Traffic anschließend kontrolliert umgeschaltet. Die Anwendung muss dabei nicht zwangsläufig ihre öffentliche Identität ändern. BYOIP kann zusätzlich relevant sein, wenn IP-Adressräume Teil von Governance, Allowlisting oder organisatorischen Vorgaben sind.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist für diese Nutzung nicht auf Managed Kubernetes beschränkt. Ihre Kubernetes-native Integration kann auch mit eigenen oder bei anderen Providern betriebenen Clustern eingesetzt werden. Damit wird Providerunabhängigkeit zu einer konkreten Betriebsoption, nicht zu einer abstrakten Vertragsklausel.\u003c/p\u003e\n\u003ch2 id=\"4-kontrolle-muss-auch-im-betrieb-nachweisbar-sein\"\u003e4. Kontrolle muss auch im Betrieb nachweisbar sein\u003c/h2\u003e\n\u003cp\u003eArchitekturdiagramme allein belegen keine digitale Souveränität. Entscheidend ist, ob ein Unternehmen Zuständigkeiten, Änderungen und Ausfälle im Betrieb kontrollieren kann. Dazu gehören definierte Verfahren für DNS-Änderungen, Zertifikatsverwaltung, Backend-Failover, Sicherheitsregeln und die Rücknahme von Traffic-Routen. Auch die Frage, welche Systeme öffentlich sichtbar sind, muss regelmäßig überprüfbar sein.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System schafft dafür eine klar abgegrenzte technische Domäne. Die verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip adressieren zugleich die Verfügbarkeit der öffentlichen Zugangsschicht. Das ersetzt keine vollständige Resilienzstrategie: Backends, Datenhaltung und Abhängigkeiten müssen separat bewertet werden.\u003c/p\u003e\n\u003cp\u003eTraffic- und Usage-Statistiken unterstützen die operative Kontrolle, weil sie Veränderungen am eingehenden Verkehr sichtbar machen. Für Cloud Governance ist wichtig, dass diese Informationen in Betriebsprozesse einfließen: Wer darf Routing ändern? Wie wird ein Providerwechsel getestet? Welche Sicherheitsanforderungen gelten für jedes Backend? Souveränität zeigt sich in diesen überprüfbaren Abläufen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei einem externen Provider und plant parallel eine zweite Umgebung in eigener Infrastruktur. Ohne getrennte Edge müssen DNS, TLS, WAF und Loadbalancing für beide Umgebungen unterschiedlich aufgebaut und betrieben werden. Das erschwert einen kontrollierten Wechsel.\u003c/p\u003e\n\u003cp\u003eMit einer vorgelagerten ayedo Edge Cloud bleiben öffentlicher Einstieg und Schutzfunktionen an einer zentralen Stelle. Beide Cluster werden als Backends angebunden, über Health Checks bewertet und zunächst parallel für Tests genutzt. Der Traffic kann anschließend schrittweise auf die neue Umgebung verteilt werden. Fällt ein Backend aus, kann die Edge auf die verfügbare Umgebung reagieren. Die Compute-Anbieter bleiben austauschbar; die Edge-Verantwortung bleibt als eigenständige Betriebsschicht bestehen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-digitale-souveränität-ohne-eigene-cloud-möglich\"\u003eIst digitale Souveränität ohne eigene Cloud möglich?\u003c/h3\u003e\n\u003cp\u003eJa. Entscheidend ist nicht der vollständige Eigenbetrieb, sondern die Kontrolle kritischer Architektur- und Betriebsentscheidungen. Eine getrennte Edge kann Abhängigkeiten vom Compute-Provider reduzieren.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-cloud-die-verantwortung-des-kubernetes-teams\"\u003eErsetzt die Edge Cloud die Verantwortung des Kubernetes-Teams?\u003c/h3\u003e\n\u003cp\u003eNein. Sie übernimmt den öffentlichen Zugang, Routing und Schutzfunktionen. Das Kubernetes-Team bleibt für Workloads, interne Services und die Betriebsfähigkeit der Anwendungen verantwortlich.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-byoip\"\u003eWelche Rolle spielt BYOIP?\u003c/h3\u003e\n\u003cp\u003eBYOIP kann helfen, bestehende IP-Adressräume unabhängig von der Compute-Umgebung weiterzuführen. Das ist relevant für Allowlisting, Governance und kontrollierte Providerwechsel.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität Edge bedeutet, technische Abhängigkeiten sichtbar und veränderbar zu machen. Die Trennung von Edge und Compute schafft dafür eine belastbare Grenze: Öffentlicher Zugang, Routing und Schutzfunktionen werden unabhängig von der Ausführung der Workloads betrieben. Die ayedo Edge Cloud unterstützt dieses Modell mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System und providerunabhängiger \u003ca href=\"/kubernetes/\"\u003eKubernetes-Nutzung\u003c/a\u003e\n. Souveränität entsteht dabei nicht durch Abgrenzung, sondern durch klare Zuständigkeiten und kontrollierbare Betriebsprozesse.\u003c/p\u003e\n", "summary": "\nTL;DR Digitale Souveränität entsteht nicht durch den Verzicht auf Cloud- oder Plattformanbieter, sondern durch kontrollierbare Architekturgrenzen. Wer öffentlichen Zugang, Routing und Schutzfunktionen von der Compute-Infrastruktur trennt, kann Kubernetes-Cluster unabhängiger betreiben, Provider wechseln und Sicherheitsentscheidungen zentral durchsetzen. Die ayedo Edge Cloud unterstützt dieses Modell vor eigenen oder fremden Clustern.\nEinleitung Ein Kubernetes-Cluster sollte nicht automatisch auch die Verantwortung für seinen öffentlichen Zugang übernehmen. Werden DNS, TLS, DDoS-Schutz, WAF und Traffic-Verteilung eng an einen einzelnen Cluster oder Cloud-Provider gekoppelt, wird ein Plattformwechsel technisch und organisatorisch aufwendig. Die Ursache liegt nicht in Kubernetes selbst, sondern in einer vermischten Zuständigkeit: Compute, Netzwerkzugang und Schutzfunktionen werden als eine Einheit betrieben. Eine getrennte Edge-Verantwortung schafft hier eine überprüfbare Architekturgrenze. Sie definiert, welche Komponenten den öffentlichen Traffic kontrollieren und welche Infrastruktur die Anwendungen ausführt. Digitale Souveränität wird damit zu einer Frage von Abhängigkeiten, Betriebsprozessen und technischer Portabilität.\n", "image": "https://ayedo.de/digitale-souveranitat-durch-getrennte-edge-verantwortung.png", "date_published": "2026-09-07T13:49:18Z", "date_modified": "2026-09-07T13:49:18Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","digital-sovereignty","security","cloud-native","politics"], "language": "de" },{ "id": "https://ayedo.de/posts/eine-edge-schicht-fur-heterogene-kubernetes-cluster/", "url": "https://ayedo.de/posts/eine-edge-schicht-fur-heterogene-kubernetes-cluster/", "title": "Eine Edge-Schicht für heterogene Kubernetes-Cluster", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/eine-edge-schicht-fur-heterogene-kubernetes-cluster/eine-edge-schicht-fur-heterogene-kubernetes-cluster.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHeterogene \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n erhöhen die Flexibilität, verteilen aber auch Routing, TLS, Security und Failover über mehrere Implementierungen. Eine gemeinsame Edge-Schicht entkoppelt den öffentlichen Eingang von Cluster-Technologien und Compute-Providern. Die ayedo Edge Cloud übernimmt diese Funktionen providerunabhängig und ermöglicht konsistentes Backend Cloaking über Multi-Cluster-Architekturen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eBei Multi-Cluster-Architekturen wird der öffentliche Traffic häufig direkt an die jeweiligen Ingress-Controller der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Umgebungen\u003c/a\u003e\n adressiert. Das wirkt zunächst einfach, koppelt DNS, TLS, Schutzmechanismen und Failover jedoch an konkrete Cluster und Provider. Ändert sich die zugrunde liegende Infrastruktur, müssen auch externe Routing- und Sicherheitskonfigurationen angepasst werden. Der zentrale Architekturfehler besteht darin, den Cluster als öffentlichen Einstiegspunkt zu behandeln. Sinnvoller ist eine getrennte Edge-Schicht: Sie bildet den stabilen öffentlichen Eingang, während Kubernetes-Cluster und andere Workloads als austauschbare Backends dahinter betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"öffentlicher-eingang-und-compute-müssen-getrennt-werden\"\u003eÖffentlicher Eingang und Compute müssen getrennt werden\u003c/h2\u003e\n\u003cp\u003eKubernetes orchestriert Workloads, Services und interne Netzwerkpfade. Der öffentliche Eingang einer Anwendung ist jedoch eine übergreifende Infrastrukturaufgabe. Dazu gehören Anycast DNS, Routing, TLS Termination, DDoS Protection, Web Application Firewall, Health Checks und die Verteilung von Anfragen auf verfügbare Backends.\u003c/p\u003e\n\u003cp\u003eWer diese Funktionen in jedem Cluster separat implementiert, erzeugt mehrere Betriebsmodelle. Jeder Cluster kann eigene Ingress-Regeln, Zertifikatsprozesse, Sicherheitsrichtlinien und Failover-Mechanismen verwenden. Das erschwert Standards und erhöht die Zahl der Konfigurationspunkte. Außerdem wird ein Providerwechsel schnell zu einer Routingmigration.\u003c/p\u003e\n\u003cp\u003eEine gemeinsame Edge-Schicht entkoppelt diese Verantwortungsbereiche. Die ayedo Edge Cloud verarbeitet den öffentlichen Traffic vor den eigentlichen Backends. Diese Backends können in unterschiedlichen Kubernetes-Umgebungen, bei verschiedenen Providern oder außerhalb von Kubernetes betrieben werden. Der Cluster bleibt für die Ausführung der Anwendung verantwortlich; die Edge übernimmt den kontrollierten Zugang dorthin.\u003c/p\u003e\n\u003ch2 id=\"multi-cluster-ohne-providergebundenes-public-routing\"\u003eMulti-Cluster ohne providergebundenes Public Routing\u003c/h2\u003e\n\u003cp\u003eHeterogene Kubernetes-Cluster entstehen aus unterschiedlichen Anforderungen: Ein Cluster kann von ayedo Managed Kubernetes betrieben werden, ein weiterer in der eigenen Infrastruktur oder bei einem anderen Cloud-Provider. Auch verschiedene Kubernetes-Versionen, Netzwerkmodelle und Ingress-Implementierungen sind möglich. Für die Anwendung sollten diese Unterschiede nicht automatisch zu unterschiedlichen öffentlichen Endpunkten führen.\u003c/p\u003e\n\u003cp\u003eMit einem gemeinsamen Anycast-basierten Layer-4- und Layer-7-Loadbalancing lässt sich der öffentliche Service vor den Clustern adressieren. Die Edge entscheidet anhand der konfigurierten Backend-Struktur, wohin der Traffic weitergeleitet wird. Backend Health Checks ermöglichen, nicht verfügbare Ziele aus dem Routing zu nehmen. Failover kann dadurch an der Edge statt in jeder einzelnen Cluster-Implementierung abgebildet werden.\u003c/p\u003e\n\u003cp\u003eDas reduziert die Abhängigkeit von einzelnen Ingress-Controllern und Providern. Gleichzeitig bleibt die interne Clusterwahl eine Architekturentscheidung: aktiv-aktiv über mehrere Backends, priorisiertes Failover oder eine getrennte Verteilung nach Service. Die Edge Cloud bringt dafür die öffentliche Erreichbarkeit, nicht jedoch eine einheitliche interne Clustertechnologie voraus.\u003c/p\u003e\n\u003ch2 id=\"backend-cloaking-als-schutz--und-entkopplungsprinzip\"\u003eBackend Cloaking als Schutz- und Entkopplungsprinzip\u003c/h2\u003e\n\u003cp\u003eEine öffentliche Anwendung sollte nicht zwingend die Adressen ihrer Kubernetes-Services, Nodes oder Provider-Netze sichtbar machen. Backend Cloaking trennt die öffentliche Identität eines Services von seinen tatsächlichen Ursprungszielen. Clients kommunizieren mit dem Edge-Endpunkt, während die Backends hinter der Edge verborgen bleiben.\u003c/p\u003e\n\u003cp\u003eDas hat zwei technische Konsequenzen. Erstens werden Änderungen an Cluster-Adressen, Providern oder internen Routingpfaden nicht automatisch zu Änderungen am öffentlichen DNS. Zweitens wird die Angriffsfläche reduziert, weil die eigentlichen Backend-Endpunkte nicht als reguläre öffentliche Einstiegspunkte fungieren müssen. Backend Cloaking ersetzt keine Zugriffskontrollen im Cluster, verhindert aber, dass die Edge-Architektur die Backend-Struktur nach außen abbildet.\u003c/p\u003e\n\u003cp\u003eFür heterogene Kubernetes-Cluster ist diese Trennung besonders relevant. TLS kann an der Edge terminiert werden, während die Weiterleitung über definierte Backend-Pfade erfolgt. Proxy Protocol kann dabei Informationen zur ursprünglichen Verbindung an Backends weitergeben, sofern die nachgelagerte Infrastruktur dies unterstützt. Damit bleiben Logging, Routing und Sicherheitskontrollen zwischen Edge und Cluster technisch abgestimmt.\u003c/p\u003e\n\u003ch2 id=\"einheitlicher-betrieb-statt-identischer-cluster\"\u003eEinheitlicher Betrieb statt identischer Cluster\u003c/h2\u003e\n\u003cp\u003eEine gemeinsame Edge-Schicht bedeutet nicht, dass alle Kubernetes-Cluster gleich betrieben werden müssen. Sie schafft vielmehr eine gemeinsame Kontrollfläche für den öffentlichen Traffic. DNS, WAF-Regeln, DDoS Protection, TLS Termination, Backend-Status und Traffic-Statistiken können zentral vor den unterschiedlichen Compute-Umgebungen organisiert werden.\u003c/p\u003e\n\u003cp\u003eDas verändert auch die Verantwortlichkeiten. Das Plattformteam definiert den externen Service und seine Erreichbarkeitsregeln. Die Teams für die jeweiligen Cluster verantworten Deployment, Service-Discovery und interne Resilienz. Dadurch lassen sich organisatorische Grenzen sauberer abbilden, ohne dass jedes Team die vollständige öffentliche Routing- und Schutzarchitektur neu aufbauen muss.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist dabei nicht auf ayedo Managed Kubernetes beschränkt. Sie kann auch vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden. Grundlage sind die eigene Netzwerk-Infrastruktur, das eigene Autonomous System und eine verteilte Multi-PoP-Architektur im Aktiv-Aktiv-Prinzip. Entscheidend ist nicht die Vereinheitlichung des Compute, sondern die Entkopplung seines öffentlichen Zugangs.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-service-über-drei-cluster\"\u003ePraxisszenario: Ein Service über drei Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in drei Umgebungen: in einem ayedo Managed Kubernetes Cluster, in einem eigenen Kubernetes-Cluster und bei einem weiteren Provider. Ohne gemeinsame Edge-Schicht besitzt jede Umgebung einen eigenen öffentlichen Endpunkt. DNS, TLS, WAF und Failover müssen je nach Ingress-Implementierung unterschiedlich gepflegt werden.\u003c/p\u003e\n\u003cp\u003eAlternativ wird die API über einen gemeinsamen Edge-Endpunkt veröffentlicht. Die ayedo Edge Cloud führt Health Checks auf die drei Backends aus und verteilt den Traffic nach einem definierten Aktiv-Aktiv- oder Failover-Modell. Die Clients sehen weder Cluster-Adressen noch Providerwechsel. Fällt ein Backend aus, kann es aus dem Routing genommen werden, ohne die öffentliche Service-Adresse zu verändern. Die Cluster bleiben technisch unterschiedlich, erfüllen gegenüber der Edge aber dieselbe Backend-Rolle.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-jeder-cluster-denselben-ingress-controller-verwenden\"\u003eMuss jeder Cluster denselben Ingress-Controller verwenden?\u003c/h3\u003e\n\u003cp\u003eNein. Eine gemeinsame Edge-Schicht entkoppelt das öffentliche Routing von der konkreten Ingress-Implementierung. Wichtig sind erreichbare Backends und ein konsistentes Zielmodell für Health Checks und Weiterleitung.\u003c/p\u003e\n\u003ch3 id=\"ist-backend-cloaking-nur-für-security-relevant\"\u003eIst Backend Cloaking nur für Security relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert auch die Kopplung zwischen öffentlichem DNS und internen Backend-Adressen. Dadurch lassen sich Cluster, Provider und Routingpfade ändern, ohne den externen Service zwangsläufig umzubauen.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-auch-nicht-kubernetes-backends-bedienen\"\u003eKann die Edge auch Nicht-Kubernetes-Backends bedienen?\u003c/h3\u003e\n\u003cp\u003eJa. Die Edge Cloud kann \u003ca href=\"/kubernetes/\"\u003eKubernetes-Backends\u003c/a\u003e\n mit anderen Workloads kombinieren. Entscheidend ist die Backend-Erreichbarkeit, nicht die Verwendung einer bestimmten Compute-Plattform.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eHeterogene Kubernetes-Cluster sind kein Problem, das durch identische Clusterimplementierungen gelöst werden muss. Die robustere Architektur trennt den öffentlichen Eingang von der Compute-Ausführung. Eine gemeinsame Edge-Schicht bündelt Routing, Schutz, TLS und Failover, während Cluster und Provider austauschbare Backend-Umgebungen bleiben. Die ayedo Edge Cloud unterstützt dieses Modell providerunabhängig und macht Backend Cloaking sowie Multi-Cluster-Routing zu Bestandteilen einer konsistenten öffentlichen Infrastruktur.\u003c/p\u003e\n", "summary": "\nTL;DR Heterogene Kubernetes-Cluster erhöhen die Flexibilität, verteilen aber auch Routing, TLS, Security und Failover über mehrere Implementierungen. Eine gemeinsame Edge-Schicht entkoppelt den öffentlichen Eingang von Cluster-Technologien und Compute-Providern. Die ayedo Edge Cloud übernimmt diese Funktionen providerunabhängig und ermöglicht konsistentes Backend Cloaking über Multi-Cluster-Architekturen.\nEinleitung Bei Multi-Cluster-Architekturen wird der öffentliche Traffic häufig direkt an die jeweiligen Ingress-Controller der Kubernetes-Umgebungen adressiert. Das wirkt zunächst einfach, koppelt DNS, TLS, Schutzmechanismen und Failover jedoch an konkrete Cluster und Provider. Ändert sich die zugrunde liegende Infrastruktur, müssen auch externe Routing- und Sicherheitskonfigurationen angepasst werden. Der zentrale Architekturfehler besteht darin, den Cluster als öffentlichen Einstiegspunkt zu behandeln. Sinnvoller ist eine getrennte Edge-Schicht: Sie bildet den stabilen öffentlichen Eingang, während Kubernetes-Cluster und andere Workloads als austauschbare Backends dahinter betrieben werden.\n", "image": "https://ayedo.de/eine-edge-schicht-fur-heterogene-kubernetes-cluster.png", "date_published": "2026-09-07T13:49:17Z", "date_modified": "2026-09-07T13:49:17Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","cloud-native","operations","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/providerunabhangige-edge-architektur-im-plattformbetrieb/", "url": "https://ayedo.de/posts/providerunabhangige-edge-architektur-im-plattformbetrieb/", "title": "Providerunabhängige Edge-Architektur im Plattformbetrieb", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/providerunabhangige-edge-architektur-im-plattformbetrieb/providerunabhangige-edge-architektur-im-plattformbetrieb.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine providerunabhängige Edge entsteht nicht allein durch mehrere Cloudanbieter. Entscheidend ist, wer öffentliche Erreichbarkeit, Routing, Schutz und Failover kontrolliert. Eigenes Netzwerk, \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und eine zentral betriebene Edge-Plattform entkoppeln diese Funktionen von einzelnen Compute- oder Kubernetes-Providern. Dadurch werden Migrationsfähigkeit und Betriebsverantwortung architektonisch planbar.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eMehrere \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei unterschiedlichen Providern ergeben noch keine providerunabhängige Edge. Wenn DNS, öffentliche IP-Adressen, DDoS-Schutz, TLS-Terminierung und Traffic-Verteilung weiterhin an einen einzelnen Anbieter gebunden sind, bleibt der kritische Eingangspfad abhängig. Der typische Architekturfehler besteht darin, nur die Compute-Schicht zu diversifizieren, während Routing und Schutz zentral beim Provider verbleiben. Eine belastbare providerunabhängige Edge trennt deshalb zwei Verantwortungsbereiche: Die Compute-Infrastruktur führt Anwendungen aus, die Edge steuert ihren öffentlichen Zugang. Diese Trennung ist keine organisatorische Formalität, sondern eine Entscheidung über Routing, Sicherheitsgrenzen und die langfristige Betriebsfähigkeit einer Plattform.\u003c/p\u003e\n\u003ch2 id=\"1-providerunabhängigkeit-beginnt-beim-netzwerk\"\u003e1. Providerunabhängigkeit beginnt beim Netzwerk\u003c/h2\u003e\n\u003cp\u003eEin eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und eigene Netzwerk-Infrastruktur schaffen eine eigenständige technische Identität außerhalb einzelner Cloud- oder Kubernetes-Provider. Das ist relevant, weil öffentliche Erreichbarkeit nicht mehr vollständig an das Netzwerkmodell eines Compute-Anbieters gekoppelt ist. IP-Adressierung, Routing und der Zugang zu den Backends können als eigene Plattformverantwortung betrachtet werden.\u003c/p\u003e\n\u003cp\u003eDabei bedeutet ein eigenes Autonomous System nicht automatisch Unabhängigkeit von jeder externen Infrastruktur. Die Edge benötigt weiterhin Konnektivität und muss mit den Netzwerken kommunizieren, in denen die Backends betrieben werden. Der Unterschied liegt in der Kontrolle über den öffentlichen Eingang und dessen Architektur. Mit Bring Your Own IP kann die Adressierung zusätzlich an die eigene Plattformstrategie angepasst werden, statt bei jedem Providerwechsel die externe Adresse als Migrationsproblem neu zu behandeln.\u003c/p\u003e\n\u003cp\u003eFür ein Multi-Cloud Netzwerk ist diese Trennung entscheidend: Provider werden zu möglichen Ausführungsorten der Workloads, nicht zu Eigentümern des gesamten Traffic-Pfads.\u003c/p\u003e\n\u003ch2 id=\"2-routing-und-schutz-gehören-in-eine-gemeinsame-edge-schicht\"\u003e2. Routing und Schutz gehören in eine gemeinsame Edge-Schicht\u003c/h2\u003e\n\u003cp\u003eRouting allein löst keine Providerabhängigkeit. Ein neuer Compute-Provider kann zwar als Backend angebunden werden, aber ohne zentrale Schutz- und Termination-Funktionen entstehen pro Provider unterschiedliche Betriebsmodelle. TLS, WAF-Regeln, DDoS Protection, Health Checks und Failover müssten dann jeweils separat konfiguriert und überwacht werden.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform bündelt diese Funktionen vor den Backends. Die ayedo Edge Cloud verarbeitet eingehenden Traffic über Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, kann TLS an der Edge terminieren und bietet WAF sowie DDoS Protection mit Scrubbing an der Edge. Backend Cloaking reduziert dabei die direkte Sichtbarkeit der Ursprungsinfrastruktur. Die konkrete Compute-Umgebung bleibt hinter der Edge austauschbar, ohne dass der öffentliche Zugang für jede Umgebung neu entworfen werden muss.\u003c/p\u003e\n\u003cp\u003eDas ist eine Architekturentscheidung: Routing und Schutz werden als unabhängige Plattformdienste betrieben, nicht als Nebenprodukt eines bestimmten Kubernetes-Clusters.\u003c/p\u003e\n\u003ch2 id=\"3-betriebsverantwortung-verschiebt-sich-bewusst\"\u003e3. Betriebsverantwortung verschiebt sich bewusst\u003c/h2\u003e\n\u003cp\u003eProviderunabhängigkeit reduziert nicht automatisch den Betriebsaufwand. Sie verschiebt Verantwortung. Wer die Edge als eigene Plattformschicht definiert, muss Zuständigkeiten für DNS, IP-Adressierung, Zertifikate, Routingregeln, Backend-Anbindung und Incident Response klar festlegen. Ohne diese Verantwortungsgrenzen entsteht lediglich eine zusätzliche Abstraktion mit unklarer Ownership.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt diese Trennung mit Anycast DNS und Multi-Provider-DNS, Backend Health Checks und Failover sowie einer verteilten Multi-PoP-Architektur nach dem Aktiv-Aktiv-Prinzip. Traffic- und Usage-Statistiken helfen dabei, die Auswirkungen von Routing- und Betriebsentscheidungen sichtbar zu machen. \u003ca href=\"/kubernetes/\"\u003eKubernetes-native Integration\u003c/a\u003e\n ermöglicht die Nutzung sowohl mit ayedo Managed Kubernetes als auch mit eigenen oder bei anderen Providern betriebenen Clustern.\u003c/p\u003e\n\u003cp\u003eDamit wird die Edge nicht an ein bestimmtes Cluster gebunden. Die Plattformverantwortung umfasst den öffentlichen Traffic-Eingang; die Teams der Compute-Schicht verantworten weiterhin Anwendungen, Cluster und Workloads.\u003c/p\u003e\n\u003ch2 id=\"4-vendor-lock-in-wird-an-schnittstellen-sichtbar\"\u003e4. Vendor Lock-in wird an Schnittstellen sichtbar\u003c/h2\u003e\n\u003cp\u003eVendor Lock-in zeigt sich selten in einer einzelnen Funktion. Er entsteht an den Schnittstellen: proprietäre IP-Modelle, providergebundene DNS-Konfigurationen, fest integrierte Loadbalancer, unterschiedliche Sicherheitsrichtlinien und fehlende Portabilität der Backend-Anbindung. Je mehr dieser Funktionen pro Cloud separat umgesetzt werden, desto höher werden Migrationsrisiko und Betriebsaufwand.\u003c/p\u003e\n\u003cp\u003eEine providerunabhängige Edge begrenzt diesen Lock-in, indem sie stabile externe Schnittstellen definiert. Anwendungen müssen öffentlich nicht wissen, bei welchem Provider ihr Backend läuft. Die Edge kann Traffic anhand zentraler Regeln verteilen, Backends prüfen und bei Ausfällen auf alternative Ziele umschalten. Proxy Protocol kann dabei relevante Verbindungsinformationen für die Backend-Seite transportieren, ohne die gesamte Edge-Funktion in den Cluster zu verlagern.\u003c/p\u003e\n\u003cp\u003eWichtig bleibt die technische Ehrlichkeit: Datenbanken, Storage, Cluster-APIs oder providerabhängige Managed Services werden dadurch nicht automatisch portabel. Die Edge entkoppelt den öffentlichen Zugang und die Schutzfunktionen. Sie ersetzt keine Strategie für die Portabilität der Workloads selbst.\u003c/p\u003e\n\u003ch2 id=\"architektur--und-betriebsszenario\"\u003eArchitektur- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei Kubernetes-Clustern: ein Cluster läuft bei ayedo, ein weiteres bei einem anderen Provider. Beide Cluster sind über die ayedo Edge Cloud als Backends angebunden. Der öffentliche DNS-Eintrag, TLS-Terminierung, WAF-Regeln und DDoS-Schutz liegen an der Edge. Health Checks erkennen, ob ein Backend verfügbar ist; bei einem Ausfall kann der Traffic auf das verbleibende Ziel gelenkt werden.\u003c/p\u003e\n\u003cp\u003eBei einem Providerwechsel bleibt der öffentliche Zugang unverändert. Das neue Backend wird an die Edge angebunden und schrittweise in die Verteilung aufgenommen. Die Anwendungsteams migrieren ihre Workloads, während die Verantwortlichen für Netzwerk und Edge die externe Erreichbarkeit kontrollieren. Genau diese Trennung reduziert das Risiko, dass ein Compute-Wechsel gleichzeitig eine Änderung des gesamten Sicherheits- und Routingmodells erzwingt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-multi-cloud-automatisch-providerunabhängig\"\u003eIst Multi-Cloud automatisch providerunabhängig?\u003c/h3\u003e\n\u003cp\u003eNein. Mehrere Computeanbieter helfen nur, wenn DNS, IP-Adressierung, Routing, Schutz und Failover nicht weiterhin an einen einzelnen Provider gebunden sind.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-das-autonomous-system\"\u003eWelche Rolle spielt das Autonomous System?\u003c/h3\u003e\n\u003cp\u003eEs bildet eine eigenständige Netzwerkidentität und unterstützt die Kontrolle über den öffentlichen Traffic-Pfad. Es ersetzt jedoch keine Konnektivität oder Portabilitätsstrategie für die Backends.\u003c/p\u003e\n\u003ch3 id=\"ist-die-edge-nur-für-ayedo-managed-kubernetes-gedacht\"\u003eIst die Edge nur für ayedo Managed Kubernetes gedacht?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderunabhängige Edge ist eine Architekturentscheidung über den öffentlichen Traffic-Pfad und die dazugehörige Betriebsverantwortung. Eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n, eigene Netzwerk-Infrastruktur und eine zentral betriebene Edge-Schicht entkoppeln Routing, Schutz und Failover von einzelnen Compute-Providern. Die ayedo Edge Cloud ordnet diese Funktionen unabhängig von der konkreten Kubernetes- oder Cloud-Umgebung ein. Das beseitigt nicht jeden Vendor Lock-in, schafft aber eine klar abgegrenzte und portierbare Plattformgrenze.\u003c/p\u003e\n", "summary": "\nTL;DR Eine providerunabhängige Edge entsteht nicht allein durch mehrere Cloudanbieter. Entscheidend ist, wer öffentliche Erreichbarkeit, Routing, Schutz und Failover kontrolliert. Eigenes Netzwerk, Autonomous System und eine zentral betriebene Edge-Plattform entkoppeln diese Funktionen von einzelnen Compute- oder Kubernetes-Providern. Dadurch werden Migrationsfähigkeit und Betriebsverantwortung architektonisch planbar.\nEinleitung Mehrere Kubernetes-Cluster bei unterschiedlichen Providern ergeben noch keine providerunabhängige Edge. Wenn DNS, öffentliche IP-Adressen, DDoS-Schutz, TLS-Terminierung und Traffic-Verteilung weiterhin an einen einzelnen Anbieter gebunden sind, bleibt der kritische Eingangspfad abhängig. Der typische Architekturfehler besteht darin, nur die Compute-Schicht zu diversifizieren, während Routing und Schutz zentral beim Provider verbleiben. Eine belastbare providerunabhängige Edge trennt deshalb zwei Verantwortungsbereiche: Die Compute-Infrastruktur führt Anwendungen aus, die Edge steuert ihren öffentlichen Zugang. Diese Trennung ist keine organisatorische Formalität, sondern eine Entscheidung über Routing, Sicherheitsgrenzen und die langfristige Betriebsfähigkeit einer Plattform.\n", "image": "https://ayedo.de/providerunabhangige-edge-architektur-im-plattformbetrieb.png", "date_published": "2026-09-07T13:49:17Z", "date_modified": "2026-09-07T13:49:17Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","cloud-native","operations","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/self-service-fur-dns-und-traffic-am-anwendungseingang/", "url": "https://ayedo.de/posts/self-service-fur-dns-und-traffic-am-anwendungseingang/", "title": "Self-Service für DNS und Traffic am Anwendungseingang", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/self-service-fur-dns-und-traffic-am-anwendungseingang/self-service-fur-dns-und-traffic-am-anwendungseingang.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eSelf-Service DNS darf nicht bedeuten, dass Anwendungsteams DNS-Zonen, Routing und Sicherheitsentscheidungen vollständig selbst verwalten. Eine interne Plattform sollte standardisierte Bausteine, feste Policies und nachvollziehbare Freigaben anbieten. So werden Services schneller veröffentlicht, während Betrieb, Security und Netzwerkverantwortung zentral steuerbar bleiben.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Plattformen behandeln die Veröffentlichung eines Services noch immer als Ticket an Netzwerk- oder Infrastrukturteams. Das verlangsamt Releases, erzeugt manuelle Fehler und führt zu uneinheitlichen DNS- und Routing-Konfigurationen. Die Gegenposition ist jedoch ebenso problematisch: Vollständig freie Änderungen durch Anwendungsteams verlagern kritische Verantwortung lediglich an die falsche Stelle. DNS-Ausfälle, unkontrollierte Zieländerungen oder fehlende Schutzmechanismen betreffen schließlich nicht nur die jeweilige Anwendung. Sinnvoller ist ein Self-Service-Modell mit klaren Abstraktionen. Teams beantragen und verwalten den öffentlichen Anwendungseingang über standardisierte Schnittstellen, während zentrale Plattformverantwortliche Policies, Sicherheitsgrenzen und Betriebsfähigkeit kontrollieren.\u003c/p\u003e\n\u003ch2 id=\"1-self-service-beginnt-mit-standardisierten-service-bausteinen\"\u003e1. Self-Service beginnt mit standardisierten Service-Bausteinen\u003c/h2\u003e\n\u003cp\u003eEin brauchbarer Self-Service für DNS und Traffic Management stellt nicht einzelne technische Parameter bereit, sondern vollständige, verständliche Bausteine. Ein Anwendungsteam sollte beispielsweise einen öffentlichen Service mit DNS-Namen, TLS-Anforderung, Backend-Zielen, Health Checks und einem definierten Routing-Modell anlegen können. Die Plattform übersetzt diese Angaben in die erforderlichen Konfigurationen.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Trennung zwischen Nutzerabsicht und Implementierungsdetails. Das Team beschreibt: „Dieser Service soll unter einer bestimmten Domain erreichbar sein und bei Ausfall des primären Backends auf ein alternatives Ziel wechseln.“ Es muss dafür nicht selbst Nameserver, Anycast-Routen oder Proxy-Einstellungen konfigurieren.\u003c/p\u003e\n\u003cp\u003eFür Self-Service DNS eignen sich versionierte Vorlagen, deklarative Konfigurationen und klar definierte Serviceklassen. Eine einfache Klasse kann einen einzelnen Service mit Standard-Health-Checks veröffentlichen. Eine höhere Klasse kann Multi-Provider-DNS, Failover oder besondere Routing-Anforderungen abbilden. Jede Klasse braucht nachvollziehbare Grenzen: erlaubte Domains, Zieltypen, Änderungsumfang und Verantwortlichkeiten.\u003c/p\u003e\n\u003ch2 id=\"2-dns--und-routing-verantwortung-sinnvoll-aufteilen\"\u003e2. DNS- und Routing-Verantwortung sinnvoll aufteilen\u003c/h2\u003e\n\u003cp\u003eDNS ist nicht nur ein Eintrag im Zonefile. TTLs, Delegation, Failover-Verhalten, Caching und Providerabhängigkeiten beeinflussen direkt die Wiederherstellungszeit und die Änderbarkeit eines Services. Deshalb sollten Anwendungsteams die fachlich notwendigen Entscheidungen treffen können, ohne die gesamte DNS-Architektur zu besitzen.\u003c/p\u003e\n\u003cp\u003eEine interne Plattform kann dafür Profile anbieten. Ein Profil legt etwa fest, ob ein Service über \u003ca href=\"/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n veröffentlicht wird, ob mehrere DNS-Provider verwendet werden und welche Failover-Logik gilt. Die Teams wählen das passende Profil und liefern die servicebezogenen Parameter. Die zentrale Plattform verantwortet Providerkonfiguration, Konsistenz, Berechtigungen und Überwachung.\u003c/p\u003e\n\u003cp\u003eBeim Traffic-Routing gilt derselbe Grundsatz. Gewünschte Verteilungen wie primäres und sekundäres Backend, geografische Aufteilung oder kontrollierte Migrationen können als standardisierte Routing-Modelle bereitgestellt werden. Freie Gewichtungen oder beliebige Zieländerungen sind dagegen häufig zu riskant. Ein Plattformteam sollte prüfen, ob ein Ziel technisch erreichbar, autorisiert und durch Health Checks abgesichert ist. So bleibt Self-Service DNS schnell, ohne zentrale Betriebsverantwortung aufzulösen.\u003c/p\u003e\n\u003ch2 id=\"3-sicherheitsgrenzen-müssen-teil-des-self-service-sein\"\u003e3. Sicherheitsgrenzen müssen Teil des Self-Service sein\u003c/h2\u003e\n\u003cp\u003eDer öffentliche Anwendungseingang ist eine Sicherheits- und Betriebsgrenze. Deshalb darf eine Plattform für DNS und Traffic nicht nur Erreichbarkeit automatisieren. Sie muss auch festlegen, welche Services veröffentlicht werden dürfen, welche Backends erreichbar sind und welche Schutzfunktionen verpflichtend sind.\u003c/p\u003e\n\u003cp\u003eBei einer Edge-Plattform wie der ayedo Edge Cloud können solche Bausteine mit \u003ca href=\"/kubernetes/\"\u003eAnycast-basiertem Layer-4- und Layer-7-Loadbalancing\u003c/a\u003e\n, TLS Termination, Web Application Firewall, DDoS Protection und Backend Cloaking verbunden werden. Das Anwendungsteam beantragt einen Service und erhält ein definiertes Schutzprofil, statt einzelne Sicherheitskomponenten selbst zusammensetzen zu müssen. Backend Cloaking verhindert dabei, dass interne Zielstrukturen zum Bestandteil des öffentlichen Designs werden.\u003c/p\u003e\n\u003cp\u003eAuch Berechtigungen und Änderungen gehören in das Modell. Teams sollten nur Domains und Backends ihrer Zuständigkeit verwalten können. Änderungen müssen nachvollziehbar, validierbar und möglichst reversibel sein. Für kritische Routingänderungen können zusätzliche Freigaben oder zeitlich begrenzte Berechtigungen erforderlich sein. Self-Service reduziert dann nicht die Governance, sondern verlagert sie in überprüfbare Plattformregeln.\u003c/p\u003e\n\u003ch2 id=\"4-die-plattform-muss-den-gesamten-lebenszyklus-abbilden\"\u003e4. Die Plattform muss den gesamten Lebenszyklus abbilden\u003c/h2\u003e\n\u003cp\u003eEin DNS-Eintrag ist nur dann erfolgreich bereitgestellt, wenn der dahinterliegende Service auch betrieben werden kann. Deshalb sollte der Self-Service den Lebenszyklus von der Veröffentlichung bis zur Stilllegung abbilden. Dazu gehören Besitzinformationen, Ablaufregeln, Health-Check-Status, Änderungsverlauf und die eindeutige Zuordnung zu Anwendung oder Team.\u003c/p\u003e\n\u003cp\u003eFür \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Umgebungen ist eine deklarative Integration besonders sinnvoll. Die Veröffentlichung kann aus der Service- oder Ingress-Konfiguration heraus angestoßen werden, ohne dass der Cluster selbst zum öffentlichen DNS- und Traffic-Verantwortlichen wird. Das gilt sowohl für ayedo Managed Kubernetes als auch für eigene oder bei anderen Providern betriebene Kubernetes-Cluster. Die Edge Cloud bleibt dabei die zentrale Plattform für den öffentlichen Eingang, während Compute und Workload-Betrieb getrennt bleiben.\u003c/p\u003e\n\u003cp\u003eBetriebsdaten müssen ebenfalls verfügbar sein. Traffic- und Usage-Statistiken helfen Teams, Fehlkonfigurationen und unerwartete Nutzung zu erkennen. Plattformverantwortliche benötigen zusätzlich eine übergreifende Sicht auf Failover, Routingänderungen und Ressourcenverbrauch. Diese Trennung schafft klare Zuständigkeiten: Teams verantworten ihre Services, die Plattform verantwortet die Funktionsfähigkeit und Regeln des öffentlichen Eingangs.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt mehrere Kubernetes-Cluster bei unterschiedlichen Providern. Ein Team veröffentlicht einen API-Service über ein Self-Service-Portal oder eine deklarative Plattformdefinition. Es wählt eine Serviceklasse mit \u003ca href=\"/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n, TLS Termination, Standard-Health-Checks und einem primären sowie sekundären Backend. Die Plattform prüft Domain- und Zielberechtigungen, erzeugt die notwendige Konfiguration und bindet den Service an das vorgegebene Schutzprofil.\u003c/p\u003e\n\u003cp\u003eFällt das primäre Backend aus, greift das definierte Failover. Das Team muss weder DNS-Provider einzeln konfigurieren noch öffentliche Backend-Adressen verwalten. Bei einer Migration kann das Routing kontrolliert angepasst werden. Die zentrale Plattform behält dabei Policies, Auditierbarkeit und Sicherheitsgrenzen unter Kontrolle.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-self-service-dns-für-jedes-team-vollständig-offen\"\u003eIst Self-Service DNS für jedes Team vollständig offen?\u003c/h3\u003e\n\u003cp\u003eNein. Teams sollten servicebezogene Einstellungen verwalten können. Domainräume, Routingmodelle, Zieltypen und Sicherheitsprofile müssen durch zentrale Policies begrenzt werden.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-multi-provider-dns-sinnvoll\"\u003eWann ist Multi-Provider-DNS sinnvoll?\u003c/h3\u003e\n\u003cp\u003eWenn DNS-Verfügbarkeit und Providerunabhängigkeit wichtige Anforderungen sind. Die zusätzliche Komplexität bei Synchronisation, Tests und Betrieb muss jedoch bewusst übernommen werden.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-cloud-mit-externen-kubernetes-clustern-genutzt-werden\"\u003eKann die Edge Cloud mit externen Kubernetes-Clustern genutzt werden?\u003c/h3\u003e\n\u003cp\u003eJa. Die ayedo Edge Cloud kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eGuter Self-Service für DNS und Traffic Management ist ein Plattformprodukt, kein freier Zugriff auf Infrastrukturparameter. Anwendungsteams erhalten standardisierte Wege zur Veröffentlichung und Änderung ihrer Services. Netzwerk-, Routing- und Sicherheitsverantwortung bleibt dort, wo sie fachlich hingehört: bei der Plattformorganisation. Die ayedo Edge Cloud unterstützt dieses Modell als providerunabhängiger öffentlicher Eingang mit \u003ca href=\"/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n, Traffic-Steuerung und integrierten Schutzfunktionen.\u003c/p\u003e\n", "summary": "\nTL;DR Self-Service DNS darf nicht bedeuten, dass Anwendungsteams DNS-Zonen, Routing und Sicherheitsentscheidungen vollständig selbst verwalten. Eine interne Plattform sollte standardisierte Bausteine, feste Policies und nachvollziehbare Freigaben anbieten. So werden Services schneller veröffentlicht, während Betrieb, Security und Netzwerkverantwortung zentral steuerbar bleiben.\nEinleitung Viele Plattformen behandeln die Veröffentlichung eines Services noch immer als Ticket an Netzwerk- oder Infrastrukturteams. Das verlangsamt Releases, erzeugt manuelle Fehler und führt zu uneinheitlichen DNS- und Routing-Konfigurationen. Die Gegenposition ist jedoch ebenso problematisch: Vollständig freie Änderungen durch Anwendungsteams verlagern kritische Verantwortung lediglich an die falsche Stelle. DNS-Ausfälle, unkontrollierte Zieländerungen oder fehlende Schutzmechanismen betreffen schließlich nicht nur die jeweilige Anwendung. Sinnvoller ist ein Self-Service-Modell mit klaren Abstraktionen. Teams beantragen und verwalten den öffentlichen Anwendungseingang über standardisierte Schnittstellen, während zentrale Plattformverantwortliche Policies, Sicherheitsgrenzen und Betriebsfähigkeit kontrollieren.\n", "image": "https://ayedo.de/self-service-fur-dns-und-traffic-am-anwendungseingang.png", "date_published": "2026-09-07T13:49:17Z", "date_modified": "2026-09-07T13:49:17Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","software-delivery","operations","kubernetes","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/verantwortungsgrenzen-zwischen-plattform-und-anwendung/", "url": "https://ayedo.de/posts/verantwortungsgrenzen-zwischen-plattform-und-anwendung/", "title": "Verantwortungsgrenzen zwischen Plattform und Anwendung", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/verantwortungsgrenzen-zwischen-plattform-und-anwendung/verantwortungsgrenzen-zwischen-plattform-und-anwendung.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin belastbares Betriebsmodell für die Edge trennt zentrale Schutz- und Netzwerkfunktionen von anwendungsspezifischer Konfiguration. Das Plattformteam verantwortet DNS, TLS, DDoS Protection und technische Erreichbarkeit. Das Anwendungsteam liefert fachliche Anforderungen, WAF-Regeln und belastbare Health-Check-Endpunkte. Shared Responsibility verhindert dabei blinde Zuständigkeitslücken.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Störungen an der Edge entstehen nicht durch fehlende Funktionen, sondern durch unklare Verantwortlichkeiten. Wenn niemand eindeutig für DNS-Einträge, Zertifikate, WAF-Ausnahmen oder Backend Health Checks zuständig ist, werden Änderungen entweder zu langsam umgesetzt oder ohne ausreichende Prüfung vorgenommen. Besonders problematisch ist die Annahme, das Plattformteam müsse jede Anwendung bis ins Detail verstehen oder das Anwendungsteam könne Netzwerk- und Schutzfunktionen selbstständig verwalten. Ein tragfähiges Modell definiert deshalb nicht nur Zuständigkeiten, sondern auch Übergaben, Freigaben und technische Schnittstellen. Platform Engineering schafft dabei den Rahmen; die Anwendung liefert den Kontext.\u003c/p\u003e\n\u003ch2 id=\"1-dns-und-tls-gehören-in-eine-zentrale-betriebsverantwortung\"\u003e1. DNS und TLS gehören in eine zentrale Betriebsverantwortung\u003c/h2\u003e\n\u003cp\u003eDNS und TLS-Termination sind zentrale Edge-Funktionen mit Auswirkungen auf Erreichbarkeit, Sicherheit und Änderungsprozesse. Das Plattformteam sollte deshalb die DNS-Zonen, Anycast DNS beziehungsweise Multi-Provider-DNS, Zertifikatsbereitstellung und TLS-Parameter betreiben. Es verantwortet damit auch die technische Konsistenz über mehrere Anwendungen und Umgebungen hinweg.\u003c/p\u003e\n\u003cp\u003eDas Anwendungsteam muss jedoch festlegen, welche Hostnames benötigt werden, welche Umgebungen erreichbar sein sollen und welche fachlichen Abhängigkeiten bestehen. Eine Anwendung kann beispielsweise zusätzliche Subdomains oder getrennte Endpunkte für APIs erfordern. Diese Anforderungen gehören nicht in die zentrale Plattformlogik.\u003c/p\u003e\n\u003cp\u003eDie Trennung reduziert operative Risiken: Zertifikats- und DNS-Änderungen folgen standardisierten Prozessen, während anwendungsspezifische Entscheidungen beim verantwortlichen Team bleiben. Wichtig ist eine klare Eskalation für Ablauf, Fehlkonfiguration und Rollback. Die Edge kann TLS terminieren, aber sie kann nicht entscheiden, ob ein bestimmter Hostname fachlich noch benötigt wird.\u003c/p\u003e\n\u003ch2 id=\"2-waf-und-ddos-protection-brauchen-unterschiedliche-zuständigkeiten\"\u003e2. WAF und DDoS Protection brauchen unterschiedliche Zuständigkeiten\u003c/h2\u003e\n\u003cp\u003eDDoS Protection ist eine plattformweite Schutzfunktion. Das Plattformteam verantwortet Aktivierung, Grundkonfiguration, Monitoring und den technischen Betrieb der Schutzmechanismen an der Edge. Diese Verantwortung sollte nicht bei einzelnen Anwendungsteams liegen, weil Angriffe mehrere Services gleichzeitig betreffen können und Schutzmaßnahmen möglichst unabhängig vom Backend greifen müssen.\u003c/p\u003e\n\u003cp\u003eEine WAF erfordert dagegen eine geteilte Verantwortung. Das Plattformteam stellt die WAF als zentralen Dienst bereit, pflegt Baseline-Regeln und definiert den sicheren Rahmen für Änderungen. Das Anwendungsteam kennt die konkreten HTTP- und API-Muster: erlaubte Methoden, spezielle Payloads, Uploads oder bewusst notwendige Ausnahmen. Es muss diese Anforderungen dokumentieren und testen.\u003c/p\u003e\n\u003cp\u003eWAF-Ausnahmen dürfen nicht als dauerhafte Abkürzung für unklare Anwendungsfehler dienen. Jede Ausnahme benötigt einen fachlichen Eigentümer, eine Begründung und eine Prüfung ihrer Reichweite. So bleibt der Schutz zentral steuerbar, ohne legitime Anwendungsmuster pauschal zu blockieren. DDoS Protection bleibt dabei infrastrukturell, WAF-Konfiguration wird zum Shared-Responsibility-Thema.\u003c/p\u003e\n\u003ch2 id=\"3-health-checks-trennen-infrastrukturstatus-und-anwendungssicht\"\u003e3. Health Checks trennen Infrastrukturstatus und Anwendungssicht\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks sind nur dann verlässlich, wenn Plattform- und Anwendungsteam unterschiedliche Fragen beantworten. Das Plattformteam prüft, ob ein Backend technisch erreichbar ist: Ist der Dienst über das erwartete Protokoll und den erwarteten Port erreichbar? Funktioniert die Verbindung aus Sicht der Edge? Werden Timeouts, Statuscodes und Failover korrekt verarbeitet?\u003c/p\u003e\n\u003cp\u003eDas Anwendungsteam verantwortet den Health-Check-Endpunkt und seine Semantik. Dieser Endpunkt sollte den tatsächlichen Zustand der Anwendung geeignet abbilden, ohne unnötig von abhängigen Systemen abzuhängen. Ein Prozess, der zwar läuft, aber keine Requests verarbeiten kann, darf nicht fälschlich als gesund gelten. Umgekehrt sollte ein temporär nicht benötigtes Nebensystem nicht automatisch das gesamte Backend aus dem Routing nehmen.\u003c/p\u003e\n\u003cp\u003eDiese Grenze ist betrieblich entscheidend. Die Plattform kann bei fehlerhaften Checks Traffic umverteilen oder Backends aus dem Pool entfernen. Sie kann aber nicht beurteilen, ob ein fachlicher Zustand akzeptabel ist. Dafür braucht sie definierte Kriterien vom Anwendungsteam. Werden diese nicht vereinbart, entstehen entweder unnötige Failover oder Traffic zu nicht funktionsfähigen Instanzen.\u003c/p\u003e\n\u003ch2 id=\"4-backend-erreichbarkeit-ist-kein-reines-plattformproblem\"\u003e4. Backend-Erreichbarkeit ist kein reines Plattformproblem\u003c/h2\u003e\n\u003cp\u003eDie Edge kann Traffic terminieren, schützen und zu Backends verteilen. Die tatsächliche Erreichbarkeit hängt jedoch von mehreren Ebenen ab: Routing, Firewall-Regeln, Listenern, Ports, Proxy Protocol, Namensauflösung, Rückwegen und der Konfiguration des Dienstes. Das Plattformteam verantwortet die Edge-seitige Verbindung und dokumentiert die technischen Anforderungen an ein Backend.\u003c/p\u003e\n\u003cp\u003eDas Anwendungsteam muss sicherstellen, dass der Service auf dem vereinbarten Interface lauscht, die erwarteten Header verarbeitet und Verbindungen aus dem vorgesehenen Netzwerk akzeptiert. Dazu gehört auch, Besonderheiten wie Proxy Protocol oder TLS zwischen Edge und Backend bewusst zu konfigurieren. Backend Cloaking kann den öffentlichen Zugriff auf interne Ziele reduzieren, ersetzt aber keine korrekte Segmentierung und keine funktionierenden Rückwege.\u003c/p\u003e\n\u003cp\u003eFür die Zusammenarbeit eignet sich eine verbindliche Schnittstelle: Service-Adresse, Port, Protokoll, Health-Check, Timeout-Verhalten, erlaubte Quellinformationen und Verantwortlicher. So wird aus „Backend nicht erreichbar“ eine prüfbare Fehlerkette. Die Edge Cloud kann dabei mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder mit \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern eigener oder anderer Provider eingesetzt werden. Die Zuständigkeitsgrenze bleibt unabhängig vom Compute-Betreiber bestehen.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-eine-neue-api-wird-veröffentlicht\"\u003eBetriebsszenario: Eine neue API wird veröffentlicht\u003c/h2\u003e\n\u003cp\u003eEin Anwendungsteam möchte eine API unter \u003ccode\u003eapi.example.de\u003c/code\u003e veröffentlichen. Das Plattformteam legt den DNS-Eintrag an, stellt TLS an der Edge bereit und aktiviert die zentrale DDoS Protection. Gemeinsam wird festgelegt, welche WAF-Baseline gilt und ob die API spezielle Methoden oder Payloads benötigt.\u003c/p\u003e\n\u003cp\u003eDas Anwendungsteam stellt einen Health-Check-Endpunkt bereit und dokumentiert Port, Protokoll, Timeout und erwartetes Verhalten. Das Plattformteam prüft die technische Erreichbarkeit und konfiguriert Failover. Wenn Requests blockiert werden, analysiert das Anwendungsteam zunächst das API-Muster; das Plattformteam bewertet Regel, Logik und Reichweite der WAF-Anpassung. Kein Team verändert die Zuständigkeit des anderen, beide verantworten aber die Übergabe.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"wer-sollte-dns--und-zertifikatsänderungen-freigeben\"\u003eWer sollte DNS- und Zertifikatsänderungen freigeben?\u003c/h3\u003e\n\u003cp\u003eDas Plattformteam betreibt DNS und TLS. Das Anwendungsteam bestätigt Hostnames, Gültigkeitsbedarf und fachliche Auswirkungen. Für kritische Änderungen empfiehlt sich eine dokumentierte gemeinsame Freigabe.\u003c/p\u003e\n\u003ch3 id=\"wer-ist-für-eine-waf-ausnahme-verantwortlich\"\u003eWer ist für eine WAF-Ausnahme verantwortlich?\u003c/h3\u003e\n\u003cp\u003eDas Anwendungsteam begründet die Ausnahme und beschreibt das benötigte Verhalten. Das Plattformteam prüft technische Umsetzung, Reichweite und verbleibendes Risiko.\u003c/p\u003e\n\u003ch3 id=\"reicht-ein-tcp-health-check-für-ein-backend\"\u003eReicht ein TCP-Health-Check für ein Backend?\u003c/h3\u003e\n\u003cp\u003eNur für die technische Erreichbarkeit. Ob die Anwendung Requests verarbeiten kann, muss ein anwendungsspezifischer Health Check mit klarer Semantik prüfen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eVerantwortungsgrenzen zwischen Plattformteam und Anwendungsteam sind eine technische Schnittstelle, keine reine Organisationsfrage. Zentrale Funktionen wie DNS, TLS-Termination und DDoS Protection brauchen konsistenten Plattformbetrieb. WAF-Regeln, Health-Check-Semantik und Backend-Anforderungen benötigen dagegen Anwendungskontext. Die ayedo Edge Cloud unterstützt dieses Modell als eigenständige Edge-Plattform vor unterschiedlichen Backends und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen. Entscheidend bleibt eine präzise Shared-Responsibility-Vereinbarung.\u003c/p\u003e\n", "summary": "\nTL;DR Ein belastbares Betriebsmodell für die Edge trennt zentrale Schutz- und Netzwerkfunktionen von anwendungsspezifischer Konfiguration. Das Plattformteam verantwortet DNS, TLS, DDoS Protection und technische Erreichbarkeit. Das Anwendungsteam liefert fachliche Anforderungen, WAF-Regeln und belastbare Health-Check-Endpunkte. Shared Responsibility verhindert dabei blinde Zuständigkeitslücken.\nEinleitung Viele Störungen an der Edge entstehen nicht durch fehlende Funktionen, sondern durch unklare Verantwortlichkeiten. Wenn niemand eindeutig für DNS-Einträge, Zertifikate, WAF-Ausnahmen oder Backend Health Checks zuständig ist, werden Änderungen entweder zu langsam umgesetzt oder ohne ausreichende Prüfung vorgenommen. Besonders problematisch ist die Annahme, das Plattformteam müsse jede Anwendung bis ins Detail verstehen oder das Anwendungsteam könne Netzwerk- und Schutzfunktionen selbstständig verwalten. Ein tragfähiges Modell definiert deshalb nicht nur Zuständigkeiten, sondern auch Übergaben, Freigaben und technische Schnittstellen. Platform Engineering schafft dabei den Rahmen; die Anwendung liefert den Kontext.\n", "image": "https://ayedo.de/verantwortungsgrenzen-zwischen-plattform-und-anwendung.png", "date_published": "2026-09-07T13:49:17Z", "date_modified": "2026-09-07T13:49:17Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["platform","security","operations","cloud-native","development"], "language": "de" },{ "id": "https://ayedo.de/posts/edge-funktionen-als-produkt-der-internen-plattform/", "url": "https://ayedo.de/posts/edge-funktionen-als-produkt-der-internen-plattform/", "title": "Edge-Funktionen als Produkt der internen Plattform", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-funktionen-als-produkt-der-internen-plattform/edge-funktionen-als-produkt-der-internen-plattform.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine interne Entwicklerplattform sollte Edge-Funktionen nicht als individuelle Infrastrukturaufgabe behandeln. TLS-Terminierung, DNS, Loadbalancing und Backend Health Checks werden als standardisierte Plattformdienste mit klaren Schnittstellen, Zuständigkeiten und Betriebsmodellen bereitgestellt. So entsteht ein wiederverwendbares Plattformprodukt für unterschiedliche Anwendungsteams und Laufzeitumgebungen.\u003c/p\u003e\n\u003cp\u003eDie Edge wird in vielen Unternehmen noch wie eine einmalig konfigurierte Infrastrukturkomponente betrieben: Ein Team richtet DNS, Zertifikate, Loadbalancing und Health Checks für eine Anwendung ein, dokumentiert die Konfiguration und übergibt sie anschließend an den Betrieb. Dieses Modell funktioniert, solange wenige Services mit ähnlichen Anforderungen existieren. Mit wachsender Anzahl von Anwendungen entstehen jedoch individuelle Sonderfälle, uneinheitliche Betriebsprozesse und unklare Verantwortlichkeiten.\u003c/p\u003e\n\u003cp\u003eDer entscheidende Perspektivwechsel lautet: Edge Services sind keine Ansammlung einzelner Konfigurationsaufgaben, sondern ein Plattformprodukt. Eine interne Plattform stellt sie über definierte Schnittstellen bereit, beschreibt ihre Nutzung in verständlichen Betriebsmodellen und grenzt Zuständigkeiten zwischen Plattform- und Anwendungsteams ab. Damit wird Platform Engineering Edge zu einer Frage von Produktdesign und nicht nur von Netzwerkautomatisierung.\u003c/p\u003e\n\u003ch2 id=\"1-plattformdienste-beginnen-mit-klaren-nutzergruppen\"\u003e1. Plattformdienste beginnen mit klaren Nutzergruppen\u003c/h2\u003e\n\u003cp\u003eEin Plattformprodukt braucht zunächst eine definierte Zielgruppe. Für Edge Services können das Teams sein, die öffentliche HTTP- oder HTTPS-Anwendungen betreiben, API-Verantwortliche, Plattformteams mit \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder Betreiber von Workloads außerhalb der zentralen Compute-Umgebung. Diese Gruppen benötigen nicht zwingend dieselbe technische Tiefe oder dieselben Betriebsoptionen.\u003c/p\u003e\n\u003cp\u003eDie interne Plattform sollte deshalb nicht primär technische Einzelparameter anbieten, sondern nutzerorientierte Services. Ein Team könnte beispielsweise einen öffentlichen HTTPS-Endpunkt mit TLS-Terminierung, einem L7-Loadbalancer und Backend Health Checks anfordern. Ein anderes benötigt möglicherweise Layer-4-Loadbalancing für einen nicht HTTP-basierten Dienst. DNS, Backend-Ziele und Failover werden dabei über eine konsistente Schnittstelle beschrieben.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Trennung zwischen Wunsch und Implementierung. Anwendungsteams müssen nicht wissen, an welchem Edge-Standort eine Anfrage verarbeitet wird oder wie Routing intern umgesetzt wird. Sie müssen jedoch wissen, welche Eigenschaften garantiert sind, welche Eingaben erforderlich sind und welche Auswirkungen eine Konfigurationsänderung hat. Die Plattform abstrahiert Komplexität, ohne die betrieblichen Konsequenzen zu verbergen.\u003c/p\u003e\n\u003ch2 id=\"2-schnittstellen-machen-edge-funktionen-wiederverwendbar\"\u003e2. Schnittstellen machen Edge-Funktionen wiederverwendbar\u003c/h2\u003e\n\u003cp\u003eDie Wiederverwendbarkeit entsteht nicht allein durch Automatisierung. Sie hängt an stabilen Schnittstellen und standardisierten Lebenszyklen. Eine Plattform muss festlegen, wie ein Dienst angelegt, geändert, geprüft und entfernt wird. Dazu gehören auch Validierungen für DNS-Namen, Backend-Ziele, TLS-Konfigurationen und Health-Check-Parameter.\u003c/p\u003e\n\u003cp\u003eFür Anwendungsteams ist außerdem relevant, welche Teile selbstständig geändert werden dürfen. Eine Plattform kann etwa eine Standardklasse für öffentliche HTTPS-Services anbieten und daneben Varianten für besondere Anforderungen definieren. Entscheidend ist, dass diese Varianten als nachvollziehbare Produkte beschrieben werden und nicht als frei kombinierbare Sammlung schwer verständlicher Optionen.\u003c/p\u003e\n\u003cp\u003eIm \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umfeld kann die Bereitstellung in deklarative Workflows integriert werden. Das gilt nicht nur für ayedo Managed Kubernetes, sondern auch für eigene Cluster oder Kubernetes-Umgebungen bei anderen Providern. Die Edge bleibt dabei ein eigenständiger Verantwortungsbereich: Kubernetes beschreibt den Workload und dessen Erreichbarkeit, während die Edge den öffentlichen Eingang, TLS-Terminierung, Routing und die Verteilung zum Backend übernimmt.\u003c/p\u003e\n\u003ch2 id=\"3-betriebsmodelle-definieren-verantwortung-und-risiko\"\u003e3. Betriebsmodelle definieren Verantwortung und Risiko\u003c/h2\u003e\n\u003cp\u003eEin Plattformprodukt ist erst dann belastbar, wenn sein Betriebsmodell eindeutig ist. Das Anwendungsteam verantwortet typischerweise die Erreichbarkeit und Funktion seiner Anwendung. Das Plattformteam verantwortet dagegen die bereitgestellten Edge Services, ihre Schnittstellen und die technische Umsetzung des öffentlichen Eingangs. Ohne diese Trennung werden Störungen schnell zu Zuständigkeitsfragen.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks zeigen, warum diese Abgrenzung notwendig ist. Ein Check ist nicht automatisch sinnvoll, nur weil ein Endpoint technisch erreichbar ist. Anwendungsteams müssen festlegen, welche Abhängigkeiten für die Annahme von Traffic relevant sind. Das Plattformteam muss sicherstellen, dass Fehlzustände erkannt und bei Bedarf Failover-Mechanismen genutzt werden können. Beide Seiten benötigen dafür gemeinsame Vorgaben und sichtbare Betriebsinformationen.\u003c/p\u003e\n\u003cp\u003eAuch Security gehört in das Produktmodell. TLS-Terminierung an der Edge verlagert einen sicherheitsrelevanten Verarbeitungsschritt aus dem Backend in eine zentral betriebene Plattform. Ergänzende Edge-Funktionen wie WAF, DDoS Protection oder Backend Cloaking können dabei als definierte Servicevarianten eingeordnet werden. Die Frage ist nicht, ob jede Anwendung alle Funktionen erhält, sondern welche Schutz- und Betriebsprofile angeboten werden.\u003c/p\u003e\n\u003ch2 id=\"4-ein-plattformprodukt-braucht-messbare-qualität\"\u003e4. Ein Plattformprodukt braucht messbare Qualität\u003c/h2\u003e\n\u003cp\u003eDie Qualität einer internen Plattform zeigt sich nicht nur daran, ob ein neuer Endpoint schnell angelegt wird. Entscheidend ist, ob Teams den Service zuverlässig verstehen, nutzen und betreiben können. Dazu gehören dokumentierte Schnittstellen, nachvollziehbare Zustände, klare Änderungsprozesse und Traffic- sowie Usage-Statistiken für die betroffenen Services.\u003c/p\u003e\n\u003cp\u003eFür die Plattformorganisation bedeutet das, Edge Services wie ein internes Produkt zu behandeln. Nutzerfeedback, wiederkehrende Betriebsprobleme und Änderungsanforderungen fließen in die Weiterentwicklung ein. Gleichzeitig müssen Standards konsequent genug sein, damit die Plattform nicht zu einer Sammlung individueller Ausnahmen wird. Jede neue Option erhöht die Komplexität der Schnittstelle und des Betriebs.\u003c/p\u003e\n\u003cp\u003eArchitektonisch ist die ayedo Edge Cloud dafür als zusammenhängende Plattform relevant: Sie verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, Anycast DNS beziehungsweise Multi-Provider-DNS, TLS-Terminierung und Backend Health Checks. Die zugrunde liegende eigene Netzwerk-Infrastruktur, das Autonomous System und die Aktiv-Aktiv-Architektur sind dabei keine Produktdetails für Anwendungsteams, aber wichtige Grundlagen für das Betriebsmodell der Plattformorganisation.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt mehrere \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster bei unterschiedlichen Providern sowie einzelne Legacy-Anwendungen außerhalb von Kubernetes. Ohne Plattformprodukt konfiguriert jedes Team DNS, Zertifikate und Loadbalancing auf eigene Weise. Im Störungsfall ist unklar, welche Health Checks aktiv sind und wer Failover-Entscheidungen verantwortet.\u003c/p\u003e\n\u003cp\u003eAls Gegenmodell bietet die interne Plattform drei standardisierte Profile an: HTTPS-Service mit TLS-Terminierung und L7-Routing, TCP-Service mit L4-Loadbalancing sowie einen Service mit erweiterten Schutzfunktionen. Alle Profile verwenden dieselben grundlegenden Schnittstellen für DNS, Backends und Health Checks. Die Anwendungsteams bleiben für ihre Backends verantwortlich; die Plattform betreibt den öffentlichen Eingang. ayedo Edge Cloud kann dabei unabhängig vom jeweiligen Kubernetes- oder Cloud-Provider als Edge-Schicht genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-die-edge-dann-nur-ein-kubernetes-service\"\u003eIst die Edge dann nur ein Kubernetes-Service?\u003c/h3\u003e\n\u003cp\u003eNein. Kubernetes kann die Bereitstellung integrieren, ist aber nicht Voraussetzung. Die Edge Cloud kann auch vor eigenen Clustern, Provider-übergreifenden Umgebungen und nicht containerisierten Backends eingesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"welche-schnittstellen-sollte-ein-edge-plattformprodukt-anbieten\"\u003eWelche Schnittstellen sollte ein Edge-Plattformprodukt anbieten?\u003c/h3\u003e\n\u003cp\u003eMindestens Serviceprofil, DNS-Namen, TLS-Anforderungen, Backend-Ziele, Health-Check-Verhalten, Änderungsprozess und Verantwortlichkeiten. Entscheidend ist die verständliche Semantik, nicht die Anzahl technischer Optionen.\u003c/p\u003e\n\u003ch3 id=\"muss-jedes-anwendungsteam-edge-konfigurationen-selbst-verwalten\"\u003eMuss jedes Anwendungsteam Edge-Konfigurationen selbst verwalten?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Teams können deklarative Anforderungen einreichen, während die Plattform Umsetzung und Betrieb übernimmt. Selbstverwaltung ist sinnvoll, wenn Freigaben, Validierungen und Zuständigkeiten klar definiert sind.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEdge Services werden zum Plattformprodukt, wenn sie für definierte Nutzergruppen über stabile Schnittstellen mit klaren Betriebsmodellen bereitstehen. TLS-Terminierung, DNS, Loadbalancing und Health Checks sind dann keine individuellen Tickets mehr, sondern wiederverwendbare Bausteine der internen Entwicklerplattform. Die ayedo Edge Cloud unterstützt dieses Modell als eigenständige Edge-Schicht vor Anwendungen und APIs – unabhängig davon, wo die Compute-Workloads betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR Eine interne Entwicklerplattform sollte Edge-Funktionen nicht als individuelle Infrastrukturaufgabe behandeln. TLS-Terminierung, DNS, Loadbalancing und Backend Health Checks werden als standardisierte Plattformdienste mit klaren Schnittstellen, Zuständigkeiten und Betriebsmodellen bereitgestellt. So entsteht ein wiederverwendbares Plattformprodukt für unterschiedliche Anwendungsteams und Laufzeitumgebungen.\nDie Edge wird in vielen Unternehmen noch wie eine einmalig konfigurierte Infrastrukturkomponente betrieben: Ein Team richtet DNS, Zertifikate, Loadbalancing und Health Checks für eine Anwendung ein, dokumentiert die Konfiguration und übergibt sie anschließend an den Betrieb. Dieses Modell funktioniert, solange wenige Services mit ähnlichen Anforderungen existieren. Mit wachsender Anzahl von Anwendungen entstehen jedoch individuelle Sonderfälle, uneinheitliche Betriebsprozesse und unklare Verantwortlichkeiten.\n", "image": "https://ayedo.de/edge-funktionen-als-produkt-der-internen-plattform.png", "date_published": "2026-09-07T13:49:16Z", "date_modified": "2026-09-07T13:49:16Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","automation","platform","cloud-native","development"], "language": "de" },{ "id": "https://ayedo.de/posts/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze/", "url": "https://ayedo.de/posts/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze/", "title": "Kubernetes und Edge Cloud als gemeinsame Plattformgrenze", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine einheitliche Veröffentlichung mehrerer \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster beginnt nicht bei Ingress-Ressourcen, sondern bei einer klaren Plattformgrenze. Kubernetes steuert Workloads und interne Services; die providerunabhängige Edge übernimmt öffentlichen Traffic, Schutz, TLS, Routing und Failover. So entsteht eine gemeinsame Kubernetes Edge Integration für Managed- und externe Cluster.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Kubernetes-Architekturen behandeln jeden Cluster als vollständige Veröffentlichungseinheit: eigener Ingress, eigene öffentliche IPs, eigenes DNS und separate Schutzmechanismen. Das funktioniert, solange eine Anwendung nur in einer Umgebung betrieben wird. Mit ayedo Managed Kubernetes, eigenen Clustern oder Clustern bei mehreren Providern entstehen jedoch doppelte Eintrittspunkte und unterschiedliche Betriebsmodelle. Der zentrale Architekturfehler besteht darin, die Ingress-Schicht mit der öffentlichen Edge gleichzusetzen. Eine belastbare Plattform trennt deshalb zwei Verantwortungsbereiche: Kubernetes veröffentlicht Services innerhalb seiner Betriebsgrenzen, während eine gemeinsame Edge-Schicht den providerunabhängigen Zugang vor mehreren Clustern koordiniert.\u003c/p\u003e\n\u003ch2 id=\"1-die-plattformgrenze-zwischen-cluster-und-edge\"\u003e1. Die Plattformgrenze zwischen Cluster und Edge\u003c/h2\u003e\n\u003cp\u003eKubernetes ist für die Ausführung und Orchestrierung von Workloads zuständig. Dazu gehören Deployments, Services, Pods, interne Service-Erkennung und die Regelung, wie Traffic innerhalb eines Clusters zu einem Ziel gelangt. Ein Ingress oder Gateway kann zusätzlich HTTP-Routen abbilden und TLS-Verbindungen terminieren. Diese Funktionen beziehen sich jedoch zunächst auf einen einzelnen Cluster und dessen Netzwerkmodell.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud liegt eine Ebene davor. Sie bildet den öffentlichen Eingang für Anwendungen und APIs, nimmt Traffic über Anycast entgegen und verteilt ihn auf definierte Backends. Dabei kann sie Layer-4- und Layer-7-Loadbalancing, TLS Termination, WAF, DDoS Protection und Backend Health Checks kombinieren. Die Edge entscheidet damit nicht, welcher Pod innerhalb eines Clusters den Request verarbeitet. Sie entscheidet, welcher Cluster oder welches Backend den Request erhält.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist für eine Kubernetes Plattform entscheidend. Sie verhindert, dass öffentliche Erreichbarkeit, Anwendungsschutz und Failover in jedem Cluster separat modelliert werden müssen. Gleichzeitig bleiben clusterinterne Mechanismen dort, wo sie hingehören: im Verantwortungsbereich des jeweiligen Kubernetes-Teams.\u003c/p\u003e\n\u003ch2 id=\"2-einheitliches-routing-über-mehrere-cluster\"\u003e2. Einheitliches Routing über mehrere Cluster\u003c/h2\u003e\n\u003cp\u003eClusterübergreifendes Routing erfordert ein Routingmodell, das nicht von der Identität eines einzelnen Providers abhängt. Ein Hostname oder API-Endpunkt kann dabei auf mehrere Backends zeigen: etwa auf einen Cluster bei ayedo, auf eine eigene Kubernetes-Umgebung oder auf einen Cluster eines anderen Cloud-Providers. Die Edge bewertet die Erreichbarkeit dieser Backends und kann Traffic entsprechend verteilen oder bei Ausfällen umleiten.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Unterscheidung zwischen globalem und lokalem Routing. Die Edge bestimmt die grobe Zielumgebung. Der Ingress im Zielcluster übernimmt anschließend die konkrete Weiterleitung auf Services und Workloads. Ein Request kann also zunächst per Anycast an die Edge gelangen, anschließend an einen gesunden Cluster weitergeleitet und dort über Ingress-Regeln an einen Service zugestellt werden.\u003c/p\u003e\n\u003cp\u003eDamit diese Kette stabil funktioniert, müssen Zuständigkeiten und Identitäten klar definiert sein. Hostnames, Pfade, TLS-Zustände und Health-Check-Kriterien sollten nicht in mehreren Ebenen widersprüchlich modelliert werden. Backend Cloaking kann zusätzlich verhindern, dass die direkten Adressen der Cluster öffentlich sichtbar werden. Das reduziert die Kopplung zwischen externem Routing und der konkreten Netzwerktopologie.\u003c/p\u003e\n\u003ch2 id=\"3-gemeinsame-sicherheits--und-betriebsfunktionen\"\u003e3. Gemeinsame Sicherheits- und Betriebsfunktionen\u003c/h2\u003e\n\u003cp\u003eOhne zentrale Edge entstehen häufig Sicherheits- und Betriebsunterschiede zwischen Clustern. Ein Cluster nutzt beispielsweise eigene TLS-Regeln, ein anderer einen abweichenden WAF-Ansatz; DDoS-Schutz und Logging werden mehrfach konfiguriert. Technisch ist das möglich, organisatorisch erhöht es jedoch die Zahl der Kontrollpunkte und erschwert eine konsistente Änderung.\u003c/p\u003e\n\u003cp\u003eEine gemeinsame Edge-Schicht bündelt Funktionen, die vor dem Eintritt in Kubernetes ausgeführt werden sollten. Dazu zählen TLS Termination, Web Application Firewall und DDoS Protection. Die Backends können über Health Checks überwacht werden, während Failover-Regeln den Übergang zu einer alternativen Umgebung steuern. Traffic- und Usage-Statistiken schaffen dabei eine gemeinsame Sicht auf die externe Nutzung, unabhängig davon, in welchem Cluster die Anwendung läuft.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist für diesen Ansatz als verteilte Multi-PoP-Plattform mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System ausgelegt. Das Aktiv-Aktiv-Prinzip betrifft die Edge-Verfügbarkeit, nicht die automatische Hochverfügbarkeit jedes Kubernetes-Workloads. Anwendungen, Datenbanken und Zustandsmodelle müssen weiterhin auf Cluster- und Applikationsebene geplant werden.\u003c/p\u003e\n\u003ch2 id=\"4-kubernetes-native-integration-ohne-providerbindung\"\u003e4. Kubernetes-native Integration ohne Providerbindung\u003c/h2\u003e\n\u003cp\u003eEine Kubernetes-native Integration bedeutet nicht, dass die Edge ausschließlich mit ayedo Managed Kubernetes verbunden werden kann. Relevant ist vielmehr, dass Teams die Veröffentlichung aus ihren Kubernetes-Prozessen heraus konsistent beschreiben und betreiben können, ohne die öffentliche Eingangsschicht selbst als clusterlokale Infrastruktur zu implementieren.\u003c/p\u003e\n\u003cp\u003eDas ist besonders bei heterogenen Umgebungen wichtig. Ein Unternehmen kann Managed Kubernetes für bestimmte Workloads einsetzen, eigene Cluster betreiben oder Umgebungen bei unterschiedlichen Providern kombinieren. Die Edge bleibt dabei die gemeinsame Plattformgrenze, während jeder Cluster sein eigenes Lifecycle-, Netzwerk- und Release-Modell behält. Die \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Edge Integration muss somit Providerunterschiede nicht vollständig beseitigen; sie kapselt den externen Zugang und reduziert die Zahl der öffentlich zu betreibenden Eintrittspunkte.\u003c/p\u003e\n\u003cp\u003eFür Platform Engineers verschiebt sich die Aufgabe dadurch von der Pflege einzelner Ingress-Stacks zur Definition eines standardisierten Veröffentlichungsmodells. Zu klären sind unter anderem Ownership, Namenskonventionen, Health-Check-Verhalten, Zertifikatsprozesse und die Frage, welche Routen global oder clusterlokal gelten. Diese Standardisierung ist wichtiger als eine möglichst umfassende Abstraktion.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-api-endpunkt-drei-cluster\"\u003ePraxisszenario: Ein API-Endpunkt, drei Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in drei Umgebungen: produktiv in ayedo Managed Kubernetes, als Ausweichumgebung in einem eigenen Cluster und für bestimmte Regionen bei einem weiteren Provider. Alle drei Cluster besitzen einen lokalen Ingress. Öffentlich zeigt jedoch nur \u003ccode\u003eapi.example.com\u003c/code\u003e auf die Edge.\u003c/p\u003e\n\u003cp\u003eDie Edge terminiert TLS, prüft den Traffic und verwendet Health Checks, um erreichbare Backends zu erkennen. Im Normalbetrieb wird der Hauptanteil an den Managed-Kubernetes-Cluster geleitet. Fällt dieser aus, übernimmt die definierte Ausweichumgebung. Im Zielcluster entscheidet der lokale Ingress über Service und Version. Dadurch bleiben Deployments und interne Routingregeln clusterabhängig, während DNS, Schutzfunktionen und globales Failover nicht dreimal separat betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-die-edge-den-kubernetes-ingress\"\u003eErsetzt die Edge den Kubernetes-Ingress?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge wählt das Backend oder den Zielcluster. Der Ingress im Cluster routet anschließend zu Services und Workloads und bleibt für clusterinterne Regeln verantwortlich.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-die-integration-nur-mit-ayedo-managed-kubernetes\"\u003eFunktioniert die Integration nur mit ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud kann auch mit eigenen Kubernetes-Clustern sowie mit Clustern bei anderen Providern eingesetzt werden. Entscheidend ist die erreichbare und geprüfte Backend-Anbindung.\u003c/p\u003e\n\u003ch3 id=\"ist-damit-automatisch-multi-cluster-deployment-gelöst\"\u003eIst damit automatisch Multi-Cluster-Deployment gelöst?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge löst den öffentlichen Zugang, Routing und Failover. Deployment-Synchronisation, Datenkonsistenz und Applikationszustand bleiben Aufgaben der Plattform- und Anwendungsteams.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine belastbare \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Plattform endet nicht an der Clustergrenze, aber sie beginnt auch nicht mit einem weiteren Ingress-Controller. Die klare Trennung zwischen clusterinterner Zustellung und providerunabhängigem öffentlichem Eingang reduziert Betriebsaufwand und macht Multi-Cluster-Architekturen steuerbarer. Die ayedo Edge Cloud unterstützt dieses Modell als gemeinsame Edge-Schicht für Managed Kubernetes und externe Cluster – mit zentralem Routing, Schutz und Failover, ohne die Verantwortlichkeiten im Cluster aufzulösen.\u003c/p\u003e\n", "summary": "\nTL;DR Eine einheitliche Veröffentlichung mehrerer Kubernetes -Cluster beginnt nicht bei Ingress-Ressourcen, sondern bei einer klaren Plattformgrenze. Kubernetes steuert Workloads und interne Services; die providerunabhängige Edge übernimmt öffentlichen Traffic, Schutz, TLS, Routing und Failover. So entsteht eine gemeinsame Kubernetes Edge Integration für Managed- und externe Cluster.\nEinleitung Viele Kubernetes-Architekturen behandeln jeden Cluster als vollständige Veröffentlichungseinheit: eigener Ingress, eigene öffentliche IPs, eigenes DNS und separate Schutzmechanismen. Das funktioniert, solange eine Anwendung nur in einer Umgebung betrieben wird. Mit ayedo Managed Kubernetes, eigenen Clustern oder Clustern bei mehreren Providern entstehen jedoch doppelte Eintrittspunkte und unterschiedliche Betriebsmodelle. Der zentrale Architekturfehler besteht darin, die Ingress-Schicht mit der öffentlichen Edge gleichzusetzen. Eine belastbare Plattform trennt deshalb zwei Verantwortungsbereiche: Kubernetes veröffentlicht Services innerhalb seiner Betriebsgrenzen, während eine gemeinsame Edge-Schicht den providerunabhängigen Zugang vor mehreren Clustern koordiniert.\n", "image": "https://ayedo.de/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze.png", "date_published": "2026-09-07T13:49:16Z", "date_modified": "2026-09-07T13:49:16Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","platform","cloud-native","software-delivery","development"], "language": "de" },{ "id": "https://ayedo.de/posts/standardisiertes-loadbalancing-in-entwicklerplattformen/", "url": "https://ayedo.de/posts/standardisiertes-loadbalancing-in-entwicklerplattformen/", "title": "Standardisiertes Loadbalancing in Entwicklerplattformen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/standardisiertes-loadbalancing-in-entwicklerplattformen/standardisiertes-loadbalancing-in-entwicklerplattformen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eStandardisiertes Loadbalancing trennt zentrale Netzwerk- und Sicherheitsentscheidungen von teamnahen Serviceparametern. Layer-4- und Layer-7-Loadbalancing lassen sich in interne Plattformen integrieren, wenn Richtlinien, Defaults und Verantwortlichkeiten klar definiert sind. Die ayedo Edge Cloud stellt dafür eine providerunabhängige Edge-Schicht vor Anwendungen und APIs bereit.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Entwicklerplattformen behandeln Loadbalancing als lokale Konfiguration eines einzelnen Services. Das funktioniert, solange wenige Anwendungen existieren. Mit wachsender Anzahl von Teams entstehen jedoch unterschiedliche Routingregeln, uneinheitliche TLS-Vorgaben, unvollständige Health Checks und schwer nachvollziehbare Ausnahmen. Der zentrale Trade-off lautet deshalb nicht „zentral oder flexibel“, sondern: Welche Entscheidungen müssen als Plattformstandard gelten, und welche dürfen Teams selbst treffen? Eine belastbare Architektur standardisiert den öffentlichen Eingang, Schutzmechanismen und Betriebsgrundlagen, ohne die fachliche Bereitstellung neuer Services unnötig zu verlangsamen.\u003c/p\u003e\n\u003ch2 id=\"1-zentrale-standards-statt-individueller-netzwerkentscheidungen\"\u003e1. Zentrale Standards statt individueller Netzwerkentscheidungen\u003c/h2\u003e\n\u003cp\u003eEin internes Plattformteam sollte die invarianten Eigenschaften des Loadbalancings definieren. Dazu gehören etwa erlaubte Protokolle, TLS-Termination, Mindestanforderungen an Health Checks, Backend-Cloaking und der Umgang mit nicht erreichbaren Backends. Diese Vorgaben reduzieren die Zahl der Entscheidungen, die Anwendungsteams bei jeder Bereitstellung selbst treffen müssen.\u003c/p\u003e\n\u003cp\u003eLayer-4-Loadbalancing eignet sich für TCP- oder UDP-basierte Services, bei denen die Plattform den Traffic auf Backend-Ebene verteilen soll. Layer-7-Loadbalancing ergänzt diese Ebene um anwendungsbezogene Kriterien wie Hostnames, Pfade oder HTTP-Verhalten. Beide Varianten benötigen unterschiedliche Standards und Betriebsmodelle. Ein pauschales „Loadbalancing aktiviert“ reicht nicht aus.\u003c/p\u003e\n\u003cp\u003eDie Zentralisierung verbessert zudem Security und Auditierbarkeit. Schutzfunktionen wie eine Web Application Firewall oder DDoS Protection werden nicht abhängig davon, ob ein Team sie korrekt konfiguriert hat. Gleichzeitig muss dokumentiert sein, welche Parameter verbindlich sind und welche optional bleiben. Sonst wird aus Standardisierung lediglich eine schwer verständliche zentrale Sonderlogik.\u003c/p\u003e\n\u003ch2 id=\"2-teamnahe-konfiguration-mit-begrenztem-freiheitsgrad\"\u003e2. Teamnahe Konfiguration mit begrenztem Freiheitsgrad\u003c/h2\u003e\n\u003cp\u003eEine interne Plattform wird unbrauchbar, wenn jedes neue Routingdetail einen manuellen Vorgang beim Netzwerkteam auslöst. Teams sollten deshalb innerhalb eines kontrollierten Rahmens selbst angeben können, welcher Service erreichbar sein soll, welche Backends dazugehören und ob Layer 4 oder Layer 7 erforderlich ist. Die Plattform validiert diese Angaben und setzt sie in die zentrale Edge-Konfiguration um.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Trennung zwischen Intent und Implementierung. Ein Team beschreibt beispielsweise, dass ein HTTPS-Service unter einer bestimmten Domain erreichbar sein soll. Es muss nicht selbst entscheiden, welche Routingstruktur, welche Schutzregel oder welches Failover-Verfahren technisch dafür verwendet wird. Solche Entscheidungen bleiben bei der Plattform.\u003c/p\u003e\n\u003cp\u003eDieser Ansatz verhindert zugleich eine Überdehnung der Teamautonomie. Freie Konfiguration von TLS, Weiterleitungen oder Backend-Zielen kann Sicherheits- und Betriebsstandards unterlaufen. Besser sind definierte Profile: etwa ein Standardprofil für öffentliche HTTP-/HTTPS-Services und ein separates Profil für nicht-HTTP-basierte Protokolle. Ausnahmen benötigen eine nachvollziehbare Begründung und einen verantwortlichen Betreiber.\u003c/p\u003e\n\u003ch2 id=\"3-layer-4-und-layer-7-als-unterschiedliche-plattformpfade\"\u003e3. Layer 4 und Layer 7 als unterschiedliche Plattformpfade\u003c/h2\u003e\n\u003cp\u003eDie Unterscheidung zwischen Layer 4 und Layer 7 sollte im Bereitstellungsprozess sichtbar bleiben. Bei Layer 4 steht die Transportverbindung im Vordergrund. Die Plattform kann TCP-Verbindungen verteilen und Backend Health Checks ausführen, ohne den Inhalt der Anwendungskommunikation zu interpretieren. Das ist relevant für Protokolle, die nicht HTTP-basiert sind oder bei denen die Anwendungsebene außerhalb der Edge verarbeitet werden soll.\u003c/p\u003e\n\u003cp\u003eLayer 7 erlaubt dagegen routing- und sicherheitsbezogene Entscheidungen auf HTTP-Ebene. TLS kann an der Edge terminiert, Traffic anhand von Host oder Pfad verteilt und eine Web Application Firewall vorgeschaltet werden. Dafür müssen Header-Verhalten, Weiterleitungen und Backend-Erreichbarkeit eindeutig standardisiert sein. Proxy Protocol kann dabei die Weitergabe von Verbindungsinformationen an Backends unterstützen, sofern die Zielsysteme dafür ausgelegt sind.\u003c/p\u003e\n\u003cp\u003eFür die interne Plattform bedeutet das: Die Wahl des Profils ist teamnah, die Auswirkungen bleiben zentral kontrolliert. Die ayedo Edge Cloud kann dabei als öffentlicher Eingang vor Anwendungen und APIs sowohl Layer-4- als auch Layer-7-Loadbalancing bereitstellen. Die eigentlichen Workloads können in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder in eigenen beziehungsweise bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern laufen.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsmodell-ownership-und-ausnahmen\"\u003e4. Betriebsmodell, Ownership und Ausnahmen\u003c/h2\u003e\n\u003cp\u003eStandardisiertes Loadbalancing ist vor allem eine Frage klarer Verantwortlichkeiten. Das Plattformteam verantwortet die Edge-Standards, zentrale Schutzmechanismen, Failover-Logik und die technische Konsistenz der Bereitstellung. Anwendungsteams verantworten ihre Backends, deren Health-Endpunkte und die fachliche Bedeutung von Routingregeln. Ohne diese Aufteilung werden Fehler zwischen Netzwerk- und Anwendungsebene weitergereicht.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb sind beobachtbare Zustände entscheidend. Traffic- und Usage-Statistiken zeigen, ob ein Service tatsächlich erreicht wird und wie sich seine Nutzung entwickelt. Health Checks und Failover müssen so definiert sein, dass sie den Zustand der Anwendung sinnvoll abbilden, statt lediglich einen offenen Port zu testen. Andernfalls kann die Edge Traffic an ein formal erreichbares, aber fachlich nicht funktionsfähiges Backend senden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ordnet diese Aufgaben in eine verteilte, Aktiv-Aktiv ausgelegte Edge-Plattform mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System ein. Damit liegt der öffentliche Traffic-Eingang außerhalb einzelner Cluster. Das erleichtert eine providerunabhängige Nutzung, ersetzt aber nicht die Verantwortung der Teams für korrekte Backends und aussagekräftige Health Checks.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEine interne Plattform stellt zwei Profile bereit: ein Layer-7-Profil für öffentliche HTTPS-APIs und ein Layer-4-Profil für einen nicht HTTP-basierten Dienst. Das Team wählt nur das passende Profil, benennt Backend-Service und Zieladresse und hinterlegt den Health-Endpunkt, sofern erforderlich. TLS-Termination, WAF-Grundschutz, Backend-Cloaking und Failover folgen den zentralen Vorgaben.\u003c/p\u003e\n\u003cp\u003eBei einem individuell konfigurierten Loadbalancer müsste das Team dagegen Routing, Zertifikatsverhalten und Schutzregeln selbst zusammensetzen. Die Bereitstellung kann zunächst flexibel wirken, erzeugt aber unterschiedliche Betriebsstandards. Im standardisierten Modell bleibt die teamnahe Konfiguration erhalten, während sicherheits- und netzwerkrelevante Entscheidungen reproduzierbar ausgerollt werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"wann-ist-layer-4-loadbalancing-die-bessere-wahl\"\u003eWann ist Layer-4-Loadbalancing die bessere Wahl?\u003c/h3\u003e\n\u003cp\u003eWenn der Dienst nicht HTTP-basiert ist oder die Edge keine anwendungsbezogene Interpretation benötigt. Für TCP- und UDP-Dienste bleibt die Transportebene ausreichend.\u003c/p\u003e\n\u003ch3 id=\"muss-jedes-team-die-edge-konfiguration-verstehen\"\u003eMuss jedes Team die Edge-Konfiguration verstehen?\u003c/h3\u003e\n\u003cp\u003eNein. Teams benötigen ein Verständnis der verfügbaren Profile und ihrer Auswirkungen. Die konkrete Routing- und Schutzimplementierung sollte die Plattform standardisieren.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-der-ansatz-nur-mit-ayedo-managed-kubernetes\"\u003eFunktioniert der Ansatz nur mit ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. Die \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-native Integration der ayedo Edge Cloud kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eStandardisiertes Loadbalancing gelingt nicht durch maximale Zentralisierung und auch nicht durch vollständige Teamautonomie. Entscheidend ist eine klare Grenze: Die interne Plattform definiert Netzwerk-, Sicherheits- und Betriebsstandards, während Teams Services innerhalb dieser Leitplanken bereitstellen. Layer-4- und Layer-7-Profile machen diesen Rahmen praktisch nutzbar. Die ayedo Edge Cloud kann dafür als unabhängige Edge-Schicht vor unterschiedlichen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n- und Backend-Umgebungen eingesetzt werden.\u003c/p\u003e\n", "summary": "\nTL;DR Standardisiertes Loadbalancing trennt zentrale Netzwerk- und Sicherheitsentscheidungen von teamnahen Serviceparametern. Layer-4- und Layer-7-Loadbalancing lassen sich in interne Plattformen integrieren, wenn Richtlinien, Defaults und Verantwortlichkeiten klar definiert sind. Die ayedo Edge Cloud stellt dafür eine providerunabhängige Edge-Schicht vor Anwendungen und APIs bereit.\nEinleitung Viele Entwicklerplattformen behandeln Loadbalancing als lokale Konfiguration eines einzelnen Services. Das funktioniert, solange wenige Anwendungen existieren. Mit wachsender Anzahl von Teams entstehen jedoch unterschiedliche Routingregeln, uneinheitliche TLS-Vorgaben, unvollständige Health Checks und schwer nachvollziehbare Ausnahmen. Der zentrale Trade-off lautet deshalb nicht „zentral oder flexibel“, sondern: Welche Entscheidungen müssen als Plattformstandard gelten, und welche dürfen Teams selbst treffen? Eine belastbare Architektur standardisiert den öffentlichen Eingang, Schutzmechanismen und Betriebsgrundlagen, ohne die fachliche Bereitstellung neuer Services unnötig zu verlangsamen.\n", "image": "https://ayedo.de/standardisiertes-loadbalancing-in-entwicklerplattformen.png", "date_published": "2026-09-07T13:49:16Z", "date_modified": "2026-09-07T13:49:16Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","development","kubernetes","hosting","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/runbooks-fur-failover-und-wiederanlauf-an-der-edge/", "url": "https://ayedo.de/posts/runbooks-fur-failover-und-wiederanlauf-an-der-edge/", "title": "Runbooks für Failover und Wiederanlauf an der Edge", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/runbooks-fur-failover-und-wiederanlauf-an-der-edge/runbooks-fur-failover-und-wiederanlauf-an-der-edge.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eRunbooks für Edge Failover müssen mehr enthalten als eine Liste technischer Kommandos. Entscheidend sind eindeutige Symptome, Zuständigkeiten, Prüfreihenfolgen und Abbruchkriterien. Nur wenn Health Checks, Failover-Status, Backend-Zustand und Rückkehr zum Regelbetrieb gemeinsam bewertet werden, bleibt Incident Response auch unter Zeitdruck kontrollierbar.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Failover an der Edge ist nicht automatisch ein erfolgreicher Betrieb. Ein ausgefallenes Backend kann zwar aus dem Traffic genommen werden, während gleichzeitig ein fehlerhaftes Zielsystem, ein falscher Health Check oder eine unvollständige Zustandsänderung den Incident verlängert. Genau deshalb müssen Runbooks für Edge Failover die gesamte Entscheidungskette abbilden: vom ersten Symptom über die technische Bewertung bis zur kontrollierten Rückkehr in den Regelbetrieb. Ein belastbares Runbook reduziert dabei nicht nur Reaktionszeit. Es verhindert auch, dass mehrere Teams parallel widersprüchliche Änderungen vornehmen oder ein noch instabiles Backend zu früh wieder Traffic erhält.\u003c/p\u003e\n\u003ch2 id=\"1-symptome-und-zuständigkeiten-eindeutig-beschreiben\"\u003e1. Symptome und Zuständigkeiten eindeutig beschreiben\u003c/h2\u003e\n\u003cp\u003eDer erste Teil eines Runbooks muss klären, woran ein Edge-Incident erkannt wird. Relevante Symptome können erhöhte Fehlerquoten, Timeouts, fehlgeschlagene TLS-Verbindungen, DNS-Auffälligkeiten oder der Ausfall einzelner Backends sein. Entscheidend ist die Zuordnung: Ein HTTP-Fehlerbild weist auf andere Prüfungen hin als ein nicht erreichbarer Health-Check-Endpunkt oder ein Problem an einem einzelnen PoP.\u003c/p\u003e\n\u003cp\u003eFür jedes Symptom braucht das Runbook eine definierte Erstbewertung und eine Eskalationslogik. Wer übernimmt Incident Response? Wer darf Failover-Entscheidungen treffen? Wer bewertet die Anwendung im Backend? Wer informiert abhängige Teams und dokumentiert den Zeitverlauf? Diese Rollen müssen auch außerhalb der regulären Arbeitszeiten bekannt sein.\u003c/p\u003e\n\u003cp\u003eSinnvoll sind außerdem feste Angaben zu Beginn des Incidents, betroffenen Services, Zeitstempeln, Kommunikationskanälen und Freigaben. Dadurch wird aus einer Sammlung technischer Hinweise ein Betriebsprozess. Gerade bei einer verteilten Aktiv-Aktiv-Architektur verhindert diese Struktur, dass ein lokales Symptom vorschnell als globaler Ausfall interpretiert wird.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-nicht-mit-anwendungsgesundheit-verwechseln\"\u003e2. Health Checks nicht mit Anwendungsgesundheit verwechseln\u003c/h2\u003e\n\u003cp\u003eHealth Checks liefern ein technisches Signal, aber keine vollständige Aussage über die Betriebsfähigkeit einer Anwendung. Ein Endpunkt kann erreichbar sein, obwohl Datenbankzugriffe fehlschlagen, Abhängigkeiten nicht verfügbar sind oder nur ein Teil der Requests verarbeitet werden kann. Umgekehrt kann ein zu streng konfigurierter Check ein funktionsfähiges Backend unnötig aus dem Traffic nehmen.\u003c/p\u003e\n\u003cp\u003eDas Runbook sollte deshalb festlegen, welche Health-Check-Ergebnisse welche Handlung auslösen. Dazu gehören Prüfungen von Status, Antwortzeit, Erreichbarkeit, betroffenen Backends und gegebenenfalls mehreren Regionen oder Infrastruktursegmenten. Wichtig ist auch die zeitliche Einordnung: Ein einzelner Fehlversuch erfordert eine andere Reaktion als ein über mehrere Prüfintervalle bestätigter Ausfall.\u003c/p\u003e\n\u003cp\u003eVor einem Failover muss das Incident-Team prüfen, ob das Signal tatsächlich zum Fehlerbild passt. Nach einem Failover darf nicht nur der Status „healthy“ betrachtet werden. Entscheidend sind zusätzlich Traffic-Verteilung, Fehlerraten und die fachliche Funktionsfähigkeit der Anwendung. Die Edge Cloud kann mit Backend Health Checks und Failover-Mechanismen die öffentliche Erreichbarkeit steuern; die Bewertung der Anwendung bleibt jedoch eine gemeinsame Aufgabe von Edge- und Backend-Verantwortlichen.\u003c/p\u003e\n\u003ch2 id=\"3-failover-status-und-backend-bewertung-dokumentieren\"\u003e3. Failover-Status und Backend-Bewertung dokumentieren\u003c/h2\u003e\n\u003cp\u003eEin Runbook braucht einen expliziten Status für jede Phase: Normalbetrieb, degradierter Betrieb, Failover eingeleitet, Failover aktiv, Backend unter Prüfung und Wiederanlauf. Ohne diese Zustände entstehen Mehrdeutigkeiten. Ein Team kann sonst annehmen, der Traffic sei bereits umgestellt, während ein anderes noch von einer vorbereitenden Maßnahme ausgeht.\u003c/p\u003e\n\u003cp\u003eFür jedes betroffene Backend sollten Zustand, Ursache, letzte erfolgreiche Prüfung und aktuelle Erreichbarkeit dokumentiert werden. Ebenso wichtig ist die Frage, ob ein Zielsystem nur nicht erreichbar oder tatsächlich nicht belastbar ist. Ein Backend, das Verbindungen annimmt, aber Requests nicht zuverlässig verarbeitet, darf nicht allein aufgrund eines erfolgreichen Netzwerk-Checks wieder aktiviert werden.\u003c/p\u003e\n\u003cp\u003eDas Runbook sollte außerdem festlegen, wann ein Failover als abgeschlossen gilt. Dazu gehören beispielsweise bestätigte Traffic-Umleitung, stabile Health Checks am Ziel und die Prüfung relevanter Anwendungssignale. Bei einer Anycast-basierten, verteilten Edge müssen diese Kriterien über die betroffenen Traffic-Pfade hinweg betrachtet werden. Ein lokaler Erfolg reicht nicht zwingend als Nachweis für einen stabilen Gesamtbetrieb.\u003c/p\u003e\n\u003ch2 id=\"4-wiederanlauf-und-rückkehr-zum-regelbetrieb-steuern\"\u003e4. Wiederanlauf und Rückkehr zum Regelbetrieb steuern\u003c/h2\u003e\n\u003cp\u003eDer Wiederanlauf ist kein Rückgängigmachen des letzten Schritts, sondern ein eigener Betriebsprozess. Zuerst muss die Ursache des Ausfalls ausreichend verstanden oder zumindest eingegrenzt sein. Danach wird das Backend kontrolliert vorbereitet: Abhängigkeiten, Ressourcen, Konfiguration und Health-Check-Verhalten werden geprüft. Ein Dienst kann technisch erreichbar sein, aber unter realer Last weiterhin instabil reagieren.\u003c/p\u003e\n\u003cp\u003eDas Runbook sollte eine gestufte Rückführung vorsehen. Dazu gehören eine definierte Beobachtungsphase, klare Abbruchkriterien und eine verantwortliche Person für die Freigabe. Wird Traffic zu früh vollständig zurückgeführt, kann der Incident erneut auftreten oder sich auf weitere Komponenten ausweiten. Bleibt der Betrieb dauerhaft im Failover, entstehen dagegen Kapazitäts- und Betriebsrisiken am verbliebenen Ziel.\u003c/p\u003e\n\u003cp\u003eNach der Rückkehr müssen Failover-Status, Monitoring, Routing und Kommunikation wieder auf Normalbetrieb gesetzt werden. Erst danach ist der Incident abgeschlossen. Eine kurze Nachbereitung sollte prüfen, ob Symptome, Zuständigkeiten und Prüfschritte im Runbook noch korrekt sind. Betriebsprozesse werden belastbarer, wenn reale Abweichungen systematisch in die nächste Version einfließen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin API-Backend reagiert in einem Infrastruktursegment zunehmend mit Timeouts. Die Edge erkennt über Health Checks eine Verschlechterung und nimmt das Ziel gemäß der Failover-Logik aus der Verteilung. Das Runbook verpflichtet das Team zunächst, die betroffenen Traffic-Pfade und den Failover-Status zu bestätigen. Parallel bewertet das Backend-Team Datenbankverbindungen und Ressourcenverbrauch.\u003c/p\u003e\n\u003cp\u003eNach der Stabilisierung meldet der Health Check wieder Erfolg. Das Team aktiviert das Backend jedoch nicht sofort vollständig, sondern prüft zunächst fachliche Requests und beobachtet die Fehlerquote. Erst nach dokumentierter Freigabe wird der Regelbetrieb wiederhergestellt. So verhindert die Trennung von Edge-Entscheidung und Backend-Bewertung, dass ein formal erreichbares, aber praktisch instabiles System erneut Traffic erhält.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"welche-informationen-müssen-im-runbook-aktuell-gehalten-werden\"\u003eWelche Informationen müssen im Runbook aktuell gehalten werden?\u003c/h3\u003e\n\u003cp\u003eZuständigkeiten, Eskalationswege, Health-Check-Kriterien, Failover-Zustände, Freigaben und Abbruchkriterien. Technische Details sollten regelmäßig gegen die tatsächlich betriebene Konfiguration geprüft werden.\u003c/p\u003e\n\u003ch3 id=\"wer-entscheidet-über-die-rückkehr-zum-regelbetrieb\"\u003eWer entscheidet über die Rückkehr zum Regelbetrieb?\u003c/h3\u003e\n\u003cp\u003eDie Entscheidung sollte eine benannte Rolle treffen, nachdem Edge- und Backend-Signale gemeinsam bewertet wurden. Technische Erreichbarkeit allein ist kein ausreichendes Freigabekriterium.\u003c/p\u003e\n\u003ch3 id=\"wie-oft-sollten-edge-runbooks-getestet-werden\"\u003eWie oft sollten Edge-Runbooks getestet werden?\u003c/h3\u003e\n\u003cp\u003eNicht nur nach einem Incident. Geplante Reviews, Tabletop-Übungen und kontrollierte Tests zeigen, ob Zuständigkeiten, Prüfschritte und Kommunikationswege unter Zeitdruck funktionieren.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEin gutes Runbook für Edge Failover beschreibt nicht nur, welche technische Aktion möglich ist. Es definiert, wann sie gerechtfertigt ist, wer sie ausführt und woran Erfolg oder Abbruch erkannt werden. Diese Trennung von Symptom, Entscheidung, Backend-Bewertung und Wiederanlauf reduziert Fehlsteuerung im Incident. Eine Edge-Plattform wie die ayedo Edge Cloud bietet dafür den technischen Rahmen aus verteiltem Betrieb, Health Checks und Failover. Die betriebliche Stabilität entsteht jedoch erst durch standardisierte Prozesse, klare Verantwortlichkeiten und überprüfbare Freigaben.\u003c/p\u003e\n", "summary": "\nTL;DR Runbooks für Edge Failover müssen mehr enthalten als eine Liste technischer Kommandos. Entscheidend sind eindeutige Symptome, Zuständigkeiten, Prüfreihenfolgen und Abbruchkriterien. Nur wenn Health Checks, Failover-Status, Backend-Zustand und Rückkehr zum Regelbetrieb gemeinsam bewertet werden, bleibt Incident Response auch unter Zeitdruck kontrollierbar.\nEinleitung Ein Failover an der Edge ist nicht automatisch ein erfolgreicher Betrieb. Ein ausgefallenes Backend kann zwar aus dem Traffic genommen werden, während gleichzeitig ein fehlerhaftes Zielsystem, ein falscher Health Check oder eine unvollständige Zustandsänderung den Incident verlängert. Genau deshalb müssen Runbooks für Edge Failover die gesamte Entscheidungskette abbilden: vom ersten Symptom über die technische Bewertung bis zur kontrollierten Rückkehr in den Regelbetrieb. Ein belastbares Runbook reduziert dabei nicht nur Reaktionszeit. Es verhindert auch, dass mehrere Teams parallel widersprüchliche Änderungen vornehmen oder ein noch instabiles Backend zu früh wieder Traffic erhält.\n", "image": "https://ayedo.de/runbooks-fur-failover-und-wiederanlauf-an-der-edge.png", "date_published": "2026-09-07T13:44:06Z", "date_modified": "2026-09-07T13:44:06Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","operations","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/betriebsgrenzen-zwischen-edge-und-backend-erkennen/", "url": "https://ayedo.de/posts/betriebsgrenzen-zwischen-edge-und-backend-erkennen/", "title": "Betriebsgrenzen zwischen Edge und Backend erkennen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/betriebsgrenzen-zwischen-edge-und-backend-erkennen/betriebsgrenzen-zwischen-edge-und-backend-erkennen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine leistungsfähige Edge Cloud reduziert den öffentlichen Angriffs- und Ausfallpfad, beseitigt aber keine Fehler im Backend. Schutz, Routing, Health Checks und Failover können Traffic abweisen, umleiten oder verteilen. Backend-Sättigung, fehlerhafte Deployments und erschöpfte Datenbanken bleiben Aufgaben des Compute- und Anwendungsbetriebs.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEine robuste Edge wird häufig mit einer robusten Anwendung gleichgesetzt. Das ist ein Architekturfehler: Die Edge kontrolliert den Zugang zu Services, nicht deren interne Verarbeitungskapazität. Sie kann DDoS-Traffic scrubbing-seitig abfangen, fehlerhafte Backends aus dem Routing nehmen oder Anfragen auf verfügbare Ziele verteilen. Sie kann jedoch keine überlastete Datenbank reparieren, ein fehlerhaftes Deployment zurückrollen oder fehlende Anwendungskapazität erzeugen. Für den Betrieb ist deshalb eine klare Grenze entscheidend: Welche Störung endet an der Edge, und ab wann beginnt die Verantwortung von Compute-, Plattform- und Anwendungsteams?\u003c/p\u003e\n\u003ch2 id=\"1-die-edge-reduziert-den-öffentlichen-störpfad\"\u003e1. Die Edge reduziert den öffentlichen Störpfad\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud liegt vor Anwendungen und APIs. Dadurch können Schutzmechanismen dort greifen, wo unerwünschter oder schädlicher Traffic entsteht: am öffentlichen Eingang. DDoS Protection und Scrubbing reduzieren die Last, die überhaupt bis zu den Backends gelangt. Eine Web Application Firewall kann HTTP- und HTTPS-Anfragen anhand definierter Regeln prüfen und blockieren. TLS Termination an der Edge entkoppelt außerdem die öffentliche Verschlüsselung vom Backend-Betrieb.\u003c/p\u003e\n\u003cp\u003eDas verbessert Resilienz, aber nur innerhalb dieses Verantwortungsbereichs. Ein Angriff auf eine Anwendung, der gültige Requests erzeugt, kann die Edge passieren und trotzdem Anwendungsthreads, Caches oder Datenbanken auslasten. Ebenso schützt eine WAF nicht automatisch vor fachlich fehlerhaften Abfragen. Der Edge-Betrieb begrenzt also den externen Druck; die Fähigkeit der Anwendung, diesen Druck kontrolliert zu verarbeiten, bleibt eine Backend-Aufgabe.\u003c/p\u003e\n\u003ch2 id=\"2-routing-und-health-checks-lösen-keine-anwendungsfehler\"\u003e2. Routing und Health Checks lösen keine Anwendungsfehler\u003c/h2\u003e\n\u003cp\u003eAnycast-basiertes Layer-4- und Layer-7-Loadbalancing verteilt eingehenden Traffic über die verfügbare Edge-Infrastruktur und zu den konfigurierten Backends. Health Checks liefern dabei ein technisches Signal: Ein Backend ist erreichbar und antwortet gemäß der Prüfung – oder es wird als nicht verfügbar bewertet. Bei einem Ausfall können Routing und Failover Anfragen auf andere Ziele lenken.\u003c/p\u003e\n\u003cp\u003eDieses Modell hat Grenzen. Ein Backend kann formal gesund wirken, aber fachlich falsche Antworten liefern, zu langsam auf abhängige Systeme warten oder nur einen Teil seiner Funktionen korrekt ausführen. Ein oberflächlicher Health Check erkennt solche Zustände nicht zuverlässig. Auch Failover verschiebt Last auf verbleibende Systeme. Sind diese bereits nahe an ihrer Kapazitätsgrenze, wird aus einem lokalen Ausfall eine Kettenreaktion. Health Checks brauchen deshalb fachlich passende Prüfkriterien, und Failover muss mit realen Kapazitätsreserven geplant werden.\u003c/p\u003e\n\u003ch2 id=\"3-backend-sättigung-bleibt-im-compute-betrieb\"\u003e3. Backend-Sättigung bleibt im Compute-Betrieb\u003c/h2\u003e\n\u003cp\u003eSättigung entsteht typischerweise innerhalb des Systems: CPU- und Speicherdruck, erschöpfte Connection Pools, blockierte Worker, langsame Datenbanken oder überlastete abhängige Services. Die Edge kann den Zufluss kontrollieren, aber sie kennt nicht automatisch die interne Verarbeitungskapazität jedes Backends. Ein technisch erreichbarer Endpoint ist nicht zwangsläufig noch belastbar.\u003c/p\u003e\n\u003cp\u003eHier greifen Maßnahmen wie Autoscaling, Queueing, Rate Limiting auf Anwendungsebene, Caching, Lasttests und Kapazitätsplanung. Auch Timeouts und Circuit Breaker müssen zwischen Edge, Ingress und Anwendung abgestimmt werden. Andernfalls hält die Edge Verbindungen länger offen, während das Backend bereits keine Arbeit mehr annehmen kann. Wirtschaftlich relevant ist dabei nicht nur der Ausfall selbst: Überdimensionierte Reservekapazität kostet dauerhaft, während fehlende Reserve ungeplante Betriebs- und Umsatzrisiken erzeugt. Die Edge verbessert die Ausgangslage, ersetzt aber keine belastbare Compute-Architektur.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsverantwortung-muss-an-übergaben-sichtbar-sein\"\u003e4. Betriebsverantwortung muss an Übergaben sichtbar sein\u003c/h2\u003e\n\u003cp\u003eDie Grenze zwischen Edge und Backend sollte nicht nur technisch, sondern auch organisatorisch definiert werden. Für jede Störung muss klar sein, welche Signale das Edge-Team bewertet und welche Metriken den Compute- oder Anwendungsteams gehören. Dazu zählen beispielsweise Routing- und Health-Check-Status auf der einen sowie Fehlerraten, Latenzen, Queue-Tiefen und Ressourcenverbrauch auf der anderen Seite.\u003c/p\u003e\n\u003cp\u003eBei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n kann die Edge Cloud mit ayedo Managed Kubernetes oder mit eigenen beziehungsweise bei anderen Providern betriebenen Clustern genutzt werden. Diese providerunabhängige Nutzung trennt öffentlichen Traffic-Eingang und Backend-Betrieb bewusst. Backend Cloaking reduziert die direkte öffentliche Sichtbarkeit der Ursprungsziele; es macht deren Zustand jedoch nicht automatisch besser. Ein eigenes Autonomous System, eigene Netzwerkinfrastruktur und eine Aktiv-Aktiv-Architektur stärken die Verfügbarkeit der Edge. Die Betriebsverantwortung für Workloads, Abhängigkeiten und Kapazität bleibt davon getrennt.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin API-Service läuft in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern. Ein Ausfall eines Clusters wird durch Health Checks erkannt, und das Routing nimmt das betroffene Ziel aus dem Verkehr. Der Service bleibt erreichbar, solange das zweite Cluster die zusätzliche Last verarbeiten kann. Steigt dort jedoch die Datenbanklatenz stark an, meldet der Endpoint weiterhin „gesund“, während Requests anwachsen und Timeouts entstehen.\u003c/p\u003e\n\u003cp\u003eDie Edge hat den ersten Fehler korrekt umgeleitet, aber keinen zweiten Kapazitätsfehler verhindert. Eine belastbare Architektur kombiniert deshalb Edge-Failover mit reservierter Backend-Kapazität, aussagekräftigen Health Checks und einem kontrollierten Umgang mit Überlast – etwa durch Priorisierung, Rate Limits oder gezieltes Zurückweisen nicht kritischer Requests.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"kann-die-edge-ein-überlastetes-backend-entlasten\"\u003eKann die Edge ein überlastetes Backend entlasten?\u003c/h3\u003e\n\u003cp\u003eJa, durch Schutzregeln, Traffic-Steuerung und Weiterleitung. Sie erzeugt jedoch keine zusätzliche Anwendungskapazität und kann interne Engpässe wie Datenbanken oder Connection Pools nicht beheben.\u003c/p\u003e\n\u003ch3 id=\"was-muss-ein-health-check-prüfen\"\u003eWas muss ein Health Check prüfen?\u003c/h3\u003e\n\u003cp\u003eMindestens Erreichbarkeit und eine erwartbare Antwort. Für kritische Services sollten zusätzlich fachlich relevante Abhängigkeiten berücksichtigt werden, ohne der Prüfung selbst zu viele interne Komponenten unterzuordnen.\u003c/p\u003e\n\u003ch3 id=\"verhindert-backend-cloaking-ausfälle\"\u003eVerhindert Backend Cloaking Ausfälle?\u003c/h3\u003e\n\u003cp\u003eNein. Backend Cloaking reduziert die direkte öffentliche Sichtbarkeit der Ursprungsziele. Verfügbarkeit, Skalierung und Fehlerbehandlung der Backends bleiben Aufgabe des Compute- und Anwendungsbetriebs.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eResilienz entsteht nicht an einer einzelnen Schicht. Die Edge Cloud kann den öffentlichen Angriffs- und Ausfallpfad verkürzen, Traffic schützen, fehlerhafte Ziele aus dem Routing nehmen und Failover ermöglichen. Sie ersetzt jedoch weder Kapazitätsplanung noch Anwendungshärtung. Entscheidend ist eine explizite Betriebsgrenze: Die ayedo Edge Cloud schützt und steuert den Zugang, während Compute- und Anwendungsteams die Belastbarkeit hinter dieser Grenze verantworten.\u003c/p\u003e\n", "summary": "\nTL;DR Eine leistungsfähige Edge Cloud reduziert den öffentlichen Angriffs- und Ausfallpfad, beseitigt aber keine Fehler im Backend. Schutz, Routing, Health Checks und Failover können Traffic abweisen, umleiten oder verteilen. Backend-Sättigung, fehlerhafte Deployments und erschöpfte Datenbanken bleiben Aufgaben des Compute- und Anwendungsbetriebs.\nEinleitung Eine robuste Edge wird häufig mit einer robusten Anwendung gleichgesetzt. Das ist ein Architekturfehler: Die Edge kontrolliert den Zugang zu Services, nicht deren interne Verarbeitungskapazität. Sie kann DDoS-Traffic scrubbing-seitig abfangen, fehlerhafte Backends aus dem Routing nehmen oder Anfragen auf verfügbare Ziele verteilen. Sie kann jedoch keine überlastete Datenbank reparieren, ein fehlerhaftes Deployment zurückrollen oder fehlende Anwendungskapazität erzeugen. Für den Betrieb ist deshalb eine klare Grenze entscheidend: Welche Störung endet an der Edge, und ab wann beginnt die Verantwortung von Compute-, Plattform- und Anwendungsteams?\n", "image": "https://ayedo.de/betriebsgrenzen-zwischen-edge-und-backend-erkennen.png", "date_published": "2026-09-07T13:44:05Z", "date_modified": "2026-09-07T13:44:05Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","software-delivery","security","development","kubernetes"], "language": "de" }, ] }