TL;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.
Einleitung
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.
In 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.
1. Anycast und Layer 4 bestimmen den Transportpfad
Anycast 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?
Layer 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.
Diese 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.
2. Application-Routing beginnt mit dem Anwendungsprotokoll
Application-Routing wird erforderlich, sobald die Weiterleitung von Merkmalen der Anwendung abhängt. Bei HTTP und HTTPS können das Hostnames wie api.example.com, Pfade wie /checkout oder Eigenschaften einer Anfrage sein. Ein Layer-7-Router kann dadurch mehrere virtuelle Services über einen gemeinsamen öffentlichen Einstieg unterscheiden.
Der 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.
Diese 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.
3. Getrennte Ebenen verbessern Security und Fehlersuche
Die 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.
Auch 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.
Fü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.
4. Die Trennung erleichtert Multi-Cloud- und Kubernetes-Architekturen
In 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.
Ein 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 Kubernetes–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.
Die 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.
Praxis- und Betriebsszenario
Ein 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: www.example.com wird zur Webanwendung geleitet, api.example.com/v1 zur API.
Fä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.
FAQ
Ist Anycast bereits Application-Routing?
Nein. Anycast bestimmt den erreichbaren Netzwerk-Einstieg anhand der Routinglogik des Internets. Application-Routing wertet anschließend anwendungsbezogene Informationen wie Hostnames oder Pfade aus.
Wann reicht Layer 4 aus?
Layer 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.
Warum sollte TLS an der Edge terminiert werden?
TLS-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.
Fazit
Netzwerk-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 Kubernetes–Umgebungen.