Ein Anwendungs-Load-Balancer verteilt HTTP- und HTTPS-Anfragen intelligent auf mehrere Backend-Server, indem er Anfrageinhalte auf der Anwendungsschicht analysiert. Diese Layer-7-Ger\u00e4te treffen Routing-Entscheidungen basierend auf URL-Pfaden, Host-Headern, Cookies oder anderen HTTP-Attributen. Unternehmen setzen sie ein, um Webanwendungen skalierbar, hochverf\u00fcgbar und performant zu halten.<\/p>\n
Anwendungs-Load-Balancer terminieren eingehende Client-Verbindungen und etablieren separate Verbindungen zu Backend-Servern, wodurch sie als Proxy zwischen Nutzern und Anwendungsinfrastruktur fungieren. Diese vollst\u00e4ndige Proxy-Architektur erm\u00f6glicht tiefgreifende Inspektion jeder HTTP-Anfrage, bevor Routing-Entscheidungen getroffen werden. Der Load-Balancer extrahiert relevante Merkmale wie den angeforderten URL-Pfad, Host-Header, Query-Parameter oder Cookie-Werte und vergleicht diese mit konfigurierten Routing-Regeln.<\/p>\n
Routing-Regeln werden typischerweise in einer Priorit\u00e4tsliste organisiert, wobei spezifischere Regeln vor allgemeineren Regeln gepr\u00fcft werden. Eine Regel k\u00f6nnte beispielsweise alle Anfragen mit dem Pfad Session-Persistenz stellt sicher, dass aufeinanderfolgende Anfragen eines Nutzers an denselben Backend-Server weitergeleitet werden, was f\u00fcr zustandsbehaftete Anwendungen kritisch ist. Anwendungs-Load-Balancer implementieren dies durch Cookie-Insertion, bei der ein spezielles Cookie mit einer Server-Kennung im ersten Response gesetzt wird, oder durch Analyse bestehender Session-Cookies der Anwendung. Bei Ausfall des zugewiesenen Servers leitet der Load-Balancer den Nutzer automatisch an einen funktionierenden Server um, wobei die Session-Daten gegebenenfalls neu etabliert werden m\u00fcssen.<\/p>\n Connection-Multiplexing reduziert die Anzahl gleichzeitiger Verbindungen zu Backend-Servern, indem mehrere Client-Anfragen \u00fcber wenige persistente Verbindungen geb\u00fcndelt werden. Ein Load-Balancer k\u00f6nnte Tausende Client-Verbindungen akzeptieren, aber nur Hunderte Keep-Alive-Verbindungen zu Backend-Servern aufrechterhalten. Diese Technik verringert den Overhead durch TCP-Handshakes und erm\u00f6glicht Servern, mit weniger Verbindungen mehr Anfragen zu verarbeiten.<\/p>\n Netzwerk-Load-Balancer operieren auf Layer 4 des OSI-Modells und treffen Entscheidungen ausschlie\u00dflich basierend auf IP-Adressen und TCP\/UDP-Ports, ohne Pakete zu inspizieren. Diese einfachere Verarbeitung erm\u00f6glicht h\u00f6here Durchsatzraten und niedrigere Latenzen, typischerweise im Bereich von Mikrosekunden statt Millisekunden. F\u00fcr Datenbanken, LDAP-Server, SMTP-Dienste oder andere Nicht-HTTP-Protokolle sind Netzwerk-Load-Balancer die einzige praktikable Option, da diese Protokolle keine HTTP-Semantik aufweisen.<\/p>\n Anwendungs-Load-Balancer bieten dagegen umfangreiche Funktionen, die nur durch HTTP-Inspektion m\u00f6glich sind. Sie k\u00f6nnen verschiedene Microservices unter einer Domain konsolidieren, indem sie Pfad-basiertes Routing nutzen \u2013 eine Architektur, die mit Netzwerk-Load-Balancern separate IP-Adressen f\u00fcr jeden Service erfordern w\u00fcrde. Die F\u00e4higkeit, Host-Header zu lesen, erm\u00f6glicht Virtual Hosting, bei dem ein einzelner Load-Balancer Hunderte verschiedener Domains bedient und jede an ihre spezifischen Backend-Server weiterleitet.<\/p>\n SSL\/TLS-Terminierung konzentriert die Zertifikatsverwaltung auf den Anwendungs-Load-Balancer, der verschl\u00fcsselte HTTPS-Verbindungen entschl\u00fcsselt und unverschl\u00fcsselte HTTP-Anfragen an Backend-Server weiterleitet. Dieser Ansatz reduziert die CPU-Last auf Anwendungsservern erheblich, da kryptografische Operationen ressourcenintensiv sind. Administratoren m\u00fcssen Zertifikate nur an einer Stelle erneuern statt auf Dutzenden Servern, was Ausfallrisiken durch abgelaufene Zertifikate minimiert.<\/p>\n End-to-End-Verschl\u00fcsselung bleibt m\u00f6glich, wenn der Load-Balancer HTTPS-Anfragen an Backend-Server sendet, was f\u00fcr Compliance-Anforderungen in hochsensiblen Umgebungen erforderlich sein kann. Diese Konfiguration erh\u00f6ht die Latenz und CPU-Nutzung, bietet aber Schutz gegen potenzielle Kompromittierung des internen Netzwerks. Einige Anwendungs-Load-Balancer unterst\u00fctzen unterschiedliche Verschl\u00fcsselungsstufen f\u00fcr externe und interne Verbindungen, sodass moderne TLS-Versionen gegen\u00fcber Clients verwendet werden, w\u00e4hrend \u00e4ltere Backend-Systeme mit \u00e4lteren Protokollen bedient werden.<\/p>\n Moderne Anwendungs-Load-Balancer enthalten h\u00e4ufig WAF-Regels\u00e4tze, die HTTP-Anfragen auf bekannte Angriffsmuster untersuchen, bevor diese Backend-Server erreichen. Diese Regeln erkennen SQL-Injection-Versuche durch Mustererkennung in URL-Parametern und POST-Daten oder blockieren Cross-Site-Scripting-Angriffe durch Filterung verd\u00e4chtiger JavaScript-Fragmente. Die zentrale Position des Load-Balancers macht ihn zum idealen Enforcement-Point f\u00fcr solche Sicherheitsrichtlinien.<\/p>\n Rate-Limiting-Mechanismen sch\u00fctzen Backend-Infrastruktur vor \u00dcberlastung durch fehlerhaft konfigurierte Clients oder Denial-of-Service-Versuche. Ein Anwendungs-Load-Balancer kann Anfragen pro IP-Adresse, pro API-Key oder pro Session begrenzen und \u00fcbersch\u00fcssige Anfragen mit HTTP 429-Statuscodes ablehnen. Diese Funktionalit\u00e4t operiert auf Anwendungsebene und kann zwischen legitimem Traffic-Burst und b\u00f6swilligen Angriffen differenzieren \u2013 eine F\u00e4higkeit, die Netzwerk-Load-Balancern fehlt.<\/p>\n Horizontale Skalierung von Webanwendungen wird durch Anwendungs-Load-Balancer transparent erm\u00f6glicht, da zus\u00e4tzliche Server bei Bedarf in den Pool aufgenommen werden k\u00f6nnen, ohne Client-Konfigurationen zu \u00e4ndern. Nutzer verbinden sich immer mit derselben Load-Balancer-IP, w\u00e4hrend die Backend-Infrastruktur dynamisch w\u00e4chst oder schrumpft. Diese Elastizit\u00e4t erlaubt automatisches Scaling basierend auf CPU-Auslastung, Anfrageraten oder anderen Metriken, wodurch Kosten bei niedriger Last gesenkt und Kapazit\u00e4t bei Spitzenlasten erh\u00f6ht wird.<\/p>\n Microservices-Architekturen profitieren besonders von URL-basiertem Routing, das verschiedene Dienste logisch unter einer Domain vereint. Ein API-Gateway-Pattern nutzt einen Anwendungs-Load-Balancer, um Blue-Green-Deployments nutzen Anwendungs-Load-Balancer, um Traffic schrittweise von einer Produktionsumgebung (Blue) zu einer neuen Version (Green) umzuschalten. Administratoren deployen die neue Version auf separate Server, f\u00fchren Tests durch und \u00e4ndern dann die Routing-Regeln, um 100% des Traffics auf die Green-Umgebung zu leiten. Bei Problemen erm\u00f6glicht ein einfacher Regelwechsel sofortiges Rollback zur vorherigen Version, ohne Code-\u00c4nderungen oder Server-Neustarts.<\/p>\n Canary-Releases verteilen einen kleinen Prozentsatz des Traffics \u2013 beispielsweise 5% \u2013 an Server mit der neuen Version, w\u00e4hrend 95% weiterhin die stabile Version erhalten. Anwendungs-Load-Balancer implementieren dies durch gewichtete Routing-Regeln, die Anfragen probabilistisch verteilen. Wenn Fehlerraten und Performance-Metriken der Canary-Version akzeptabel bleiben, wird der Prozentsatz schrittweise erh\u00f6ht, bis alle Nutzer die neue Version erhalten.<\/p>\n Health-Check-Konfiguration erfordert sorgf\u00e4ltige Abstimmung zwischen Erkennungsgeschwindigkeit und False-Positive-Vermeidung. Zu aggressive Health Checks \u2013 beispielsweise alle 5 Sekunden mit nur einem fehlgeschlagenen Check als Schwellenwert \u2013 k\u00f6nnen funktionierende Server bei kurzzeitigen Netzwerkst\u00f6rungen aus dem Pool entfernen. Konservativere Einstellungen wie Checks alle 30 Sekunden mit drei aufeinanderfolgenden Fehlern als Schwellenwert reduzieren False Positives, erh\u00f6hen aber die Zeit, bis tats\u00e4chlich fehlerhafte Server erkannt werden.<\/p>\n Health-Check-Endpunkte sollten kritische Anwendungsabh\u00e4ngigkeiten pr\u00fcfen, nicht nur HTTP-Erreichbarkeit best\u00e4tigen. Ein Single Point of Failure entsteht, wenn ein einzelner Anwendungs-Load-Balancer die gesamte Anwendung bedient \u2013 dessen Ausfall macht alle Backend-Server unerreichbar, unabh\u00e4ngig von deren Gesundheit. Produktionsumgebungen sollten mindestens zwei Load-Balancer in einer Aktiv-Aktiv- oder Aktiv-Passiv-Konfiguration betreiben, wobei DNS-Round-Robin, Floating-IPs oder ein vorgelagerter Netzwerk-Load-Balancer zwischen ihnen verteilt. Cloud-Provider bieten typischerweise automatisch redundante Load-Balancer-Instanzen, w\u00e4hrend On-Premises-Deployments explizite HA-Konfiguration erfordern.<\/p>\n Session-Drain-Probleme treten auf, wenn Server aus dem Pool entfernt werden, ohne aktive Verbindungen sauber zu beenden. Anwendungs-Load-Balancer sollten eine Drain-Period konfiguriert haben \u2013 typischerweise 30\u2013300 Sekunden \u2013, w\u00e4hrend derer der Server keine neuen Anfragen erh\u00e4lt, aber bestehende Verbindungen abschlie\u00dfen kann. Diese Verz\u00f6gerung verhindert unterbrochene Nutzer-Sessions bei Deployments oder Wartungsfenstern, verl\u00e4ngert aber die Zeit f\u00fcr vollst\u00e4ndige Server-Entfernung.<\/p>\n Bandwidth-Limitierungen des Load-Balancers selbst werden h\u00e4ufig \u00fcbersehen, bis sie bei Traffic-Spikes sichtbar werden. Ein Load-Balancer mit 1 Gbps Netzwerkkapazit\u00e4t kann maximal etwa 125 MB\/s Durchsatz liefern, was bei Video-Streaming oder gro\u00dfen Datei-Downloads schnell erreicht wird. Moderne Bereitstellungen nutzen mehrere Load-Balancer-Instanzen oder spezialisierte High-Throughput-Konfigurationen f\u00fcr solche Workloads.<\/p>\n SSL\/TLS-Performance wird zum Bottleneck, wenn der Load-Balancer Tausende Handshakes pro Sekunde verarbeiten muss, besonders mit Elliptic-Curve-Kryptografie. Hardware-Beschleunigung durch dedizierte Krypto-Prozessoren oder die Verwendung von TLS-Session-Resumption-Mechanismen (Session Tickets, Session IDs) reduziert diese Last erheblich. Bei extremen Anforderungen kann die Terminierung \u00fcber mehrere Load-Balancer verteilt oder selektiv nur f\u00fcr externe Verbindungen aktiviert werden.<\/p>\n HTTP\/2-Multiplexing kann paradoxerweise die Lastverteilung verschlechtern, da der Load-Balancer eingehende Requests \u00fcber wenige persistente Verbindungen empf\u00e4ngt und diese auf einzelne Backend-Server verteilen muss. Wenn ein Client Hunderte Anfragen \u00fcber eine HTTP\/2-Verbindung sendet, k\u00f6nnte der Load-Balancer diese alle an denselben Backend-Server weiterleiten, statt sie gleichm\u00e4\u00dfig zu verteilen. Konfigurationen, die Backend-Verbindungen nach einer bestimmten Anzahl Anfragen rotieren oder separate Backend-Verbindungen pro Client-Request etablieren, mildern dieses Problem.<\/p>\n","protected":false},"featured_media":0,"template":"","glossary_intl_set":[],"glossary_intl_cluster":[392],"glossary_intl_theme":[],"class_list":["post-28990","glossary_intl","type-glossary_intl","status-publish","hentry","glossary_intl_cluster-cybersecurity"],"acf":{"card_description":"Anwendungs-Load-Balancer verteilen eingehenden Netzwerkverkehr auf mehrere Server basierend auf Inhalten der HTTP\/HTTPS-Anfragen. Sie arbeiten auf der Anwendungsschicht und erm\u00f6glichen intelligentes Routing nach URL, Host-Header oder anderen Anfrageparametern.","nav_theme":"","nav_subtheme":"","dataset_version":"","term_inline":"","term_plural":false,"heading_overrides":null,"synonyms":[{"value":"ALB"},{"value":"Layer-7-Load-Balancer"},{"value":"HTTP-Load-Balancer"}],"lead_definition":"Ein Anwendungs-Load-Balancer ist ein Netzwerkger\u00e4t oder Softwaresystem, das HTTP- und HTTPS-Anfragen auf Anwendungsebene analysiert und basierend auf Inhaltsmerkmalen wie URL-Pfaden, Host-Namen oder HTTP-Headern intelligent auf mehrere Backend-Server verteilt, um Verf\u00fcgbarkeit, Skalierbarkeit und Performance von Webanwendungen zu optimieren.","at_a_glance":[{"bullet":"Anwendungs-Load-Balancer arbeiten auf Layer 7 des OSI-Modells und k\u00f6nnen HTTP-Header, Cookies und URL-Inhalte auswerten, um Routing-Entscheidungen zu treffen \u2013 im Gegensatz zu Netzwerk-Load-Balancern, die nur IP-Adressen und Ports betrachten."},{"bullet":"Sie erm\u00f6glichen URL-basiertes Routing, bei dem beispielsweise \/checkout\/*<\/code> an eine Gruppe von Servern weiterleiten, die auf Transaktionsverarbeitung spezialisiert sind, w\u00e4hrend \/statisch\/*<\/code>-Anfragen an Cache-Server geleitet werden. Diese inhaltsbasierte Verteilung erlaubt es, verschiedene Microservices oder spezialisierte Server-Pools hinter einer einzigen IP-Adresse zu betreiben.<\/p>\nSession-Persistenz und Verbindungsmanagement<\/h3>\n
Anwendungs-Load-Balancer vs. Netzwerk-Load-Balancer<\/h2>\n
Vergleich der Einsatzgebiete<\/h3>\n
\n\n
\n \nMerkmal<\/th>\n Anwendungs-Load-Balancer<\/th>\n Netzwerk-Load-Balancer<\/th>\n<\/tr>\n<\/thead>\n \n OSI-Layer<\/strong><\/td>\n Layer 7 (Anwendung)<\/td>\n Layer 4 (Transport)<\/td>\n<\/tr>\n \n Protokolle<\/strong><\/td>\n HTTP, HTTPS, WebSocket<\/td>\n TCP, UDP, TLS<\/td>\n<\/tr>\n \n Routing-Basis<\/strong><\/td>\n URL, Header, Cookies, HTTP-Methoden<\/td>\n IP-Adresse, Port<\/td>\n<\/tr>\n \n SSL-Terminierung<\/strong><\/td>\n Ja, mit Zertifikatsverwaltung<\/td>\n Optional, ohne HTTP-Inspektion<\/td>\n<\/tr>\n \n Latenz<\/strong><\/td>\n 1\u20135 ms typisch<\/td>\n < 1 ms typisch<\/td>\n<\/tr>\n \n Ideal f\u00fcr<\/strong><\/td>\n Webanwendungen, APIs, Microservices<\/td>\n Datenbanken, Gaming-Server, VoIP<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n SSL\/TLS-Terminierung und Sicherheitsfunktionen<\/h2>\n
Integrierte Web Application Firewall-Funktionen<\/h3>\n
Vorteile und typische Einsatzszenarien<\/h2>\n
\/benutzer\/*<\/code> an den Benutzerverwaltungs-Service, \/bestellungen\/*<\/code> an den Bestell-Service und \/zahlungen\/*<\/code> an den Zahlungs-Service zu routen. Externe Clients sehen eine koh\u00e4rente API-Oberfl\u00e4che, w\u00e4hrend interne Services unabh\u00e4ngig entwickelt, deployed und skaliert werden k\u00f6nnen.<\/p>\nBlue-Green- und Canary-Deployments<\/h3>\n
Konfiguration und Best Practices<\/h2>\n
\/health<\/code>-Endpunkt, der Datenbankverbindung, Cache-Verf\u00fcgbarkeit und externe API-Erreichbarkeit verifiziert, verhindert, dass nicht vollst\u00e4ndig funktionsf\u00e4hige Server Traffic erhalten. Allerdings d\u00fcrfen diese Checks nicht zu ressourcenintensiv sein, da sie in kurzen Intervallen von allen Load-Balancer-Instanzen ausgef\u00fchrt werden.<\/p>\nTimeout- und Retry-Strategien<\/h3>\n
\n
H\u00e4ufige Fehler und Einschr\u00e4nkungen<\/h2>\n
Performance-Engp\u00e4sse und Sizing<\/h3>\n
\/api\/*<\/code>-Anfragen an Microservices und \/bilder\/*<\/code>-Anfragen an Content-Server weitergeleitet werden, ohne separate IP-Adressen zu ben\u00f6tigen."},{"bullet":"Moderne Anwendungs-Load-Balancer bieten integrierte Sicherheitsfunktionen wie Web Application Firewall-Regeln, SSL\/TLS-Terminierung und Schutz vor langsamen HTTP-Angriffen, die auf Netzwerkebene nicht erkennbar w\u00e4ren."}],"intro_answer":"","steps_answer":"","steps":null,"examples":[{"example":"Ein Online-Shop nutzt einen Anwendungs-Load-Balancer, um Produktsuchen an spezialisierte Elasticsearch-Server, Bestellvorg\u00e4nge an transaktionale Datenbankserver und statische Produktbilder an einen CDN-Origin-Server zu routen \u2013 alles \u00fcber eine einzige Domain."},{"example":"Eine SaaS-Plattform verwendet Cookie-basiertes Session-Routing, bei dem der Anwendungs-Load-Balancer Nutzer anhand ihrer Session-ID immer an denselben Backend-Server weiterleitet, um persistente WebSocket-Verbindungen aufrechtzuerhalten."},{"example":"Ein Medienunternehmen setzt Host-Header-Routing ein: Anfragen an api.beispiel.de<\/code> werden an REST-API-Server geleitet, w\u00e4hrend www.beispiel.de<\/code>-Anfragen an Frontend-Rendering-Server weitergeleitet werden, obwohl beide auf derselben IP-Adresse gehostet sind."}],"misconception":null,"faq":[{"q":"Wann sollte ich einen Anwendungs-Load-Balancer statt eines Netzwerk-Load-Balancers w\u00e4hlen?","a":"W\u00e4hlen Sie einen Anwendungs-Load-Balancer, wenn Sie HTTP\/HTTPS-Verkehr verarbeiten und inhaltsbasiertes Routing, SSL-Terminierung oder Web-Application-Firewall-Funktionen ben\u00f6tigen. Netzwerk-Load-Balancer eignen sich besser f\u00fcr Nicht-HTTP-Protokolle oder wenn Sie ultra-niedrige Latenz und maximalen Durchsatz bei einfachen IP-basierten Routing-Regeln priorisieren."},{"q":"Kann ein Anwendungs-Load-Balancer SSL-Zertifikate verwalten?","a":"Ja, Anwendungs-Load-Balancer f\u00fchren typischerweise SSL\/TLS-Terminierung durch \u2013 sie entschl\u00fcsseln HTTPS-Verkehr, inspizieren den Inhalt f\u00fcr Routing-Entscheidungen und kommunizieren dann entweder verschl\u00fcsselt oder unverschl\u00fcsselt mit Backend-Servern. Dies zentralisiert Zertifikatsverwaltung und reduziert die CPU-Last auf Anwendungsservern."},{"q":"Wie erkennt ein Anwendungs-Load-Balancer fehlerhafte Server?","a":"Anwendungs-Load-Balancer f\u00fchren regelm\u00e4\u00dfige Health Checks durch, indem sie HTTP-Anfragen an definierte Endpunkte senden und auf erwartete Statuscodes pr\u00fcfen. Ein Server, der mehrfach hintereinander einen 500-Fehler zur\u00fcckgibt oder nicht innerhalb des Timeout-Fensters antwortet, wird automatisch aus dem Pool entfernt, bis er wieder gesunde Responses liefert."},{"q":"K\u00f6nnen mehrere Anwendungs-Load-Balancer gemeinsam arbeiten?","a":"Ja, h\u00e4ufig werden mehrere Anwendungs-Load-Balancer hinter einem DNS-Load-Balancer oder einem vorgelagerten Netzwerk-Load-Balancer betrieben. Diese Architektur erh\u00f6ht die Verf\u00fcgbarkeit des Load-Balancers selbst und verhindert, dass dieser zu einem Single Point of Failure wird."}],"compare_answer":"","compare":null,"variants":[{"title":"Gateway Load Balancer","inline_description":"Spezialisierte Form f\u00fcr virtuelle Netzwerkger\u00e4te und Sicherheitsappliances","description":"Ein Gateway Load Balancer ist eine spezialisierte Form des Anwendungs-Load-Balancers, die eingehenden Verkehr an virtuelle Firewalls, Intrusion-Detection-Systeme oder andere Netzwerksicherheitsger\u00e4te verteilt, bevor dieser zu den eigentlichen Anwendungsservern weitergeleitet wird \u2013 typischerweise unter Verwendung des GENEVE-Protokolls zur Kapselung.","source":"","key":""},{"title":"Global Server Load Balancer","inline_description":"DNS-basierte Verteilung zwischen geografisch verteilten Rechenzentren","description":"Ein Global Server Load Balancer ist eine erweiterte Variante, die auf DNS-Ebene arbeitet und Nutzer basierend auf geografischer N\u00e4he, Rechenzentrumsauslastung oder Failover-Szenarien an verschiedene regionale Anwendungs-Load-Balancer weiterleitet, um globale Hochverf\u00fcgbarkeit und optimale Latenz zu gew\u00e4hrleisten.","source":"","key":""}],"signals_answer":"","signals":null,"protect_answer":"","prevent":null,"incident":null,"related_terms":null,"pillar_link":null,"sources":[{"publisher":"","name":"IETF RFC 7230 - Hypertext Transfer Protocol (HTTP\/1.1): Message Syntax and Routing","url":"https:\/\/tools.ietf.org\/html\/rfc7230","doc_type":"","group":"used"},{"publisher":"","name":"IETF RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP\/2)","url":"https:\/\/tools.ietf.org\/html\/rfc7540","doc_type":"","group":"used"}],"reviewer":{"name":"M. Kubascikova","qualification":"SEO director","date":"2026-07-01"},"disclaimer":""},"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t