HTTP-Routing mit L7-Loadbalancing für APIs und Apps

TL;DR

L7-Loadbalancing verteilt HTTP- und HTTPS-Anfragen nicht nur nach IP-Adresse und Port, sondern anhand von Hostname, URL-Pfad, Methode oder Headern. Dadurch lassen sich APIs, Webanwendungen und Versionen gezielt routen. Die ayedo Edge Cloud übernimmt diese Entscheidungen am öffentlichen Eingang und entkoppelt die Backends von direktem Internet-Traffic.

Einleitung

Ein TCP-Loadbalancer kann Verbindungen verteilen, kennt aber die Anwendung hinter diesen Verbindungen nicht. Für moderne APIs und Webanwendungen reicht diese Information oft nicht aus: /api/v1 kann zu einem anderen Backend gehören als /api/v2, und ein Hostname kann eine vollständig andere Anwendung repräsentieren. L7-Loadbalancing verschiebt die Routing-Entscheidung deshalb auf die HTTP-Ebene. Das schafft präzisere Steuerungsmöglichkeiten, erhöht aber auch die Verantwortung für TLS, Regelwerke, Health Checks und Fehlerszenarien. Wer HTTP-Routing nur als zusätzliche Weiterleitungsregel betrachtet, unterschätzt die Auswirkungen auf Architektur und Betrieb.

1. Was L7-Loadbalancing von TCP-Weiterleitung unterscheidet

L4-Loadbalancing arbeitet primär mit Netzwerk- und Transportinformationen: Ziel-IP, Port und Verbindungszustand. Die Nutzlast einer HTTP-Anfrage bleibt dabei in der Regel unberücksichtigt. Das Verfahren ist performant und universell, aber für anwendungsbezogene Entscheidungen begrenzt.

L7-Loadbalancing verarbeitet dagegen HTTP- oder HTTPS-Merkmale. Typische Kriterien sind der Hostname, der URL-Pfad, die HTTP-Methode oder bestimmte Header. Eine Regel kann beispielsweise Anfragen an api.example.com zu einem API-Backend und app.example.com zu einem Web-Backend leiten. Ebenso lassen sich /v1 und /v2 getrennten Backend-Pools zuordnen.

Diese zusätzliche Kontextinformation ermöglicht API Loadbalancing und differenziertes HTTP Routing. Sie bedeutet zugleich, dass der Loadbalancer HTTP verstehen und gegebenenfalls TLS terminieren muss. Damit wird er zu einem Bestandteil der Anwendungstopologie und nicht nur zu einer Netzwerkkomponente.

2. Routing-Regeln sind Teil der Anwendungsarchitektur

Ein L7-Regelwerk sollte aus der Struktur und den Betriebsanforderungen der Anwendung abgeleitet werden. Host-based Routing eignet sich, wenn mehrere Anwendungen oder API-Domains über einen gemeinsamen öffentlichen Eingang erreichbar sind. Path-based Routing ist sinnvoll, wenn ein Dienst in klar getrennte Funktionsbereiche aufgeteilt ist. Die HTTP-Methode kann zusätzliche Differenzierung ermöglichen, etwa bei unterschiedlichen Verarbeitungspfaden für Lese- und Schreibzugriffe.

Problematisch wird Routing, wenn Regeln implizite Abhängigkeiten enthalten. Eine neue API-Version, ein zusätzlicher Mandant oder ein geänderter Pfad kann unbeabsichtigt bestehende Anfragen umleiten. Deshalb gehören Reihenfolge, Priorität und Fallback-Verhalten zur Architekturentscheidung. Eine nicht gematchte Anfrage sollte nicht zufällig in einem allgemeinen Backend landen.

Auch Security-Anforderungen hängen am Routing. Unterschiedliche APIs können eigene Schutzregeln, Zugriffskontrollen oder Betriebsgrenzen benötigen. Das L7-Regelwerk ersetzt keine Authentifizierung, schafft aber die notwendige Trennung, damit Sicherheits- und Betriebsmaßnahmen gezielt angewendet werden können.

3. TLS Termination und Backend Cloaking verändern den Datenpfad

Bei HTTPS Traffic muss die Routing-Instanz die verschlüsselte Anfrage entweder selbst verstehen oder die Entscheidung an ein nachgelagertes System delegieren. TLS Termination an der Edge ermöglicht, Zertifikate und HTTP-Routing an einem öffentlichen Eingang zu bündeln. Danach kann die Anfrage anhand ihrer Anwendungseigenschaften an das passende Backend weitergeleitet werden. Die konkrete Verschlüsselung zwischen Edge und Backend bleibt eine separate Architekturentscheidung.

Diese Trennung reduziert die direkte Exponierung der Compute-Infrastruktur. Backend Cloaking sorgt dafür, dass interne Zielsysteme nicht als öffentliche Endpunkte auftreten müssen. Für das Backend sind damit nicht zwingend eigene öffentliche IP-Adressen oder öffentlich erreichbare Listener erforderlich. Das begrenzt die Angriffsfläche und vereinfacht die Kontrolle des eingehenden Datenverkehrs.

Der Preis ist eine zusätzliche Komponente im Request-Pfad. Zertifikatsverwaltung, Header-Weitergabe, Logging, Timeouts und die Behandlung von Client-IP-Adressen müssen eindeutig definiert sein. Proxy Protocol kann dabei relevant werden, wenn nachgelagerte Systeme Informationen über die ursprüngliche Verbindung benötigen. L7-Routing ist deshalb nur dann belastbar, wenn der gesamte Datenpfad dokumentiert und getestet wird.

4. Verfügbarkeit entsteht durch Routing plus Backend-Zustand

Ein korrektes Routing-Ziel ist nicht automatisch ein verfügbares Ziel. Backends können erreichbar sein, aber keine Anfragen mehr verarbeiten, oder nur einzelne Endpunkte können gestört sein. Health Checks müssen deshalb zur Anwendung passen. Ein TCP-Check bestätigt lediglich, dass ein Port antwortet; ein anwendungsnaher Check kann zusätzlich prüfen, ob ein definierter HTTP-Endpunkt funktional reagiert.

Bei mehreren Backend-Pools entscheidet das Verhalten im Fehlerfall über die tatsächliche Verfügbarkeit. Fällt ein Ziel aus, muss der Traffic kontrolliert auf gesunde Backends umgeleitet werden. Das betrifft nicht nur einzelne Instanzen, sondern auch Regionen, Cluster oder Provider. Ein Failover kann jedoch Nebenwirkungen haben, wenn Sessions, Datenhaltung oder Kapazitäten nicht darauf ausgelegt sind.

Die ayedo Edge Cloud bildet hierfür den öffentlichen Eingang vor Anwendungen und APIs. Sie verbindet Anycast-basiertes Layer-7-Loadbalancing mit Backend Health Checks und Failover. Ihre verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip ordnen die Verkehrsverteilung nicht einem einzelnen Standort zu. Die Backends können dabei in ayedo Managed Kubernetes , in eigenen Clustern oder bei anderen Providern betrieben werden.

Praxisszenario: Eine API mit zwei Versionen

Ein Unternehmen betreibt eine Webanwendung und zwei API-Versionen. Die Domains app.example.com und api.example.com werden über einen gemeinsamen öffentlichen Eingang veröffentlicht. Anfragen an /v1 gehen zunächst an den stabilen Backend-Pool, während /v2 einen separat betriebenen Pool erreicht. Ein Health Check prüft für beide Pools einen anwendungsspezifischen Endpunkt.

Bei einem Ausfall des /v2-Pools wird nicht die gesamte Domain als fehlerhaft betrachtet. Das Routing kann die betroffene Version gezielt auf ein definiertes alternatives Backend lenken oder kontrolliert einen Fehler zurückgeben. Die Webanwendung und /v1 bleiben davon getrennt. Entscheidend ist, dass die Pfadstruktur, Fallbacks und Kapazitätsgrenzen vorab festgelegt wurden.

FAQ

Ist L7-Loadbalancing nur für Kubernetes relevant?

Nein. L7-Loadbalancing ist unabhängig von der Compute-Plattform. Es kann Anwendungen und APIs vor Kubernetes-Clustern, virtuellen Maschinen oder anderen Backend-Umgebungen routen.

Wann reicht L4-Loadbalancing aus?

L4 genügt, wenn Verbindungen lediglich nach Netzwerkmerkmalen verteilt werden sollen und keine Entscheidungen anhand von Hostname, Pfad oder HTTP-Methode erforderlich sind.

Was passiert bei fehlerhaften Routing-Regeln?

Falsch priorisierte oder zu allgemeine Regeln können Anfragen an unpassende Backends senden. Deshalb sind Regeltests, eindeutige Fallbacks und Monitoring der tatsächlichen Traffic-Verteilung erforderlich.

Fazit

L7-Loadbalancing macht den öffentlichen Traffic-Eingang zu einer anwendungsbezogenen Steuerungsschicht. Hostnames, Pfade und weitere HTTP-Merkmale ermöglichen eine präzise Trennung von APIs und Apps, verlangen aber klare Regeln für TLS, Health Checks, Fallbacks und Backend-Sicherheit. Die ayedo Edge Cloud ordnet diese Funktionen vor den eigentlichen Backends ein und bleibt dabei unabhängig davon, wo die Anwendungen betrieben werden. Entscheidend ist nicht die Anzahl der Routing-Regeln, sondern ihre technische Beherrschbarkeit.