L4 oder L7: Traffic-Management in der Edge Cloud

TL;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.

Eine 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.

1. Layer 4: Transportvermittlung ohne Anwendungskenntnis

Layer-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.

Dieser 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.

Der 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.

2. Layer 7: Routing auf Basis der Anwendung

Layer-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.

Diese 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.

Layer 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.

3. TLS bestimmt die Grenze zwischen L4 und L7

Die 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.

Soll 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.

Das 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.

4. Backend-Pools, Health Checks und Betriebsfolgen

Die 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.

Mit 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.

Die 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 Kubernetes-Clustern . Backend Cloaking trennt dabei die öffentliche Zugriffsebene von den intern betriebenen Endpunkten. Entscheidend bleibt, Pools und Regeln nach der tatsächlichen Anwendungstopologie zu modellieren.

Praxis- und Entscheidungsszenario

Ein 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 /v1 und /v2 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.

FAQ

Ist Layer 7 grundsätzlich sicherer als Layer 4?

Nein. 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.

Kann HTTPS immer mit Layer 4 betrieben werden?

Ja, 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.

Wann sollte ein Backend-Pool aufgeteilt werden?

Wenn 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.

Fazit

L4- 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.