Listener-Regeln und pfadbasiertes Routing

Ein Listener eines ALB ist ein Prozess, der anhand eines von Ihnen festgelegten Protokolls und Ports auf Verbindungsanfragen prüft (z. B. HTTP auf Port 80 oder HTTPS auf Port 443). Jeder Listener verfügt über eine oder mehrere Regeln, die anhand des Inhalts bestimmen, wohin Anfragen weitergeleitet werden.

Ein Listener muss eine Standardregel enthalten (die Auffangaktion, wenn keine andere Regel zutrifft) und kann bis zu 100 zusätzliche Regeln besitzen. Regeln werden in der Reihenfolge ihrer Priorität ausgewertet (kleinere Zahl = höhere Priorität). Wenn eine Anfrage die Bedingung einer Regel erfüllt, wird die entsprechende Aktion ausgeführt und keine weitere Regel ausgewertet.

Listener-Regeln gleichen Anfragen anhand von Bedingungen ab. Sie können mehrere Bedingungen in einer Regel kombinieren (alle Bedingungen müssen erfüllt sein, damit die Regel angewendet wird). Verfügbare Bedingungstypen:

• host-header: gleicht den HTTP-Header Host ab (z. B. api.example.com)
• path-pattern: gleicht den URL-Pfad ab (z. B. /api/*, /images/*.jpg)
• http-header: gleicht einen beliebigen HTTP-Header anhand von Name und Wertmuster ab
• http-request-method: gleicht HTTP-Methoden ab (GET, POST, DELETE usw.)
• query-string: gleicht Schlüssel-Wert-Paare im Query-String ab
• source-ip: gleicht CIDR-Bereiche von Client-IP-Adressen ab

Pfadbasiertes Routing leitet Anfragen anhand des URL-Pfads an verschiedene Zielgruppen weiter. Dies ist das häufigste Routing-Muster für Microservices hinter einem einzelnen ALB. Beispielregeln auf einem ALB:

• Pfad ist /api/* → Zielgruppe: api-service
• Pfad ist /images/* → Zielgruppe: image-processor
• Pfad ist /admin/* → Zielgruppe: admin-app
• Standard → Zielgruppe: frontend-app

So kann ein einzelner ALB mehrere eigenständige Services bereitstellen, ohne dass mehrere Load Balancer erforderlich sind. Das reduziert Kosten und die Komplexität des DNS.

Hostbasiertes Routing leitet Anfragen anhand des HTTP-Headers Host weiter. Dadurch können mehrere Domainnamen (virtuelle Hosts) über einen einzelnen ALB bereitgestellt werden. Beispiel:

• Host ist api.example.com → Zielgruppe api-service
• Host ist admin.example.com → Zielgruppe admin-app
• Host ist www.example.com → Zielgruppe frontend

Der CNAME- oder ALIAS-Eintrag jeder Domain verweist auf denselben ALB-DNS-Namen. Der ALB leitet die Anfrage jedoch anhand des Host-Headers an das jeweils passende Backend weiter. Hostbasiertes Routing eignet sich ideal für mandantenfähige SaaS-Anwendungen oder monolithische Anwendungen, die in Microservices aufgeteilt werden.

Wenn die Bedingungen einer Regel erfüllt sind, führt der ALB eine der folgenden Aktionen aus:

• forward: leitet die Anfrage an eine oder mehrere Zielgruppen weiter (optional mit Gewichtungen)
• redirect: gibt eine HTTP-Weiterleitung (301 oder 302) an eine neue URL zurück; nützlich für Weiterleitungen von HTTP zu HTTPS
• fixed-response: gibt eine statische HTTP-Antwort mit einem festgelegten Statuscode, Inhaltstyp und Body zurück – nützlich für Wartungsseiten oder einfache Health-Check-Antworten
• authenticate-cognito: authentifiziert Benutzer über einen Cognito User Pool, bevor die Anfrage weitergeleitet wird
• authenticate-oidc: authentifiziert Benutzer über einen beliebigen OIDC-kompatiblen Identity Provider

Das häufigste Muster für Listener-Regeln ist die Weiterleitung von HTTP zu HTTPS:

1. Erstellen Sie einen HTTP-Listener auf Port 80 mit einer Regel: Leiten Sie den gesamten Datenverkehr (/*) mit dem Statuscode 301 zu HTTPS weiter
2. Erstellen Sie einen HTTPS-Listener auf Port 443 mit Ihren eigentlichen Routing-Regeln, die auf Zielgruppen verweisen

So werden Benutzer, die http:// eingeben oder alten HTTP-Links folgen, transparent zu HTTPS weitergeleitet, ohne dass Änderungen auf Anwendungsebene erforderlich sind. Die Weiterleitung wird vollständig auf der Load-Balancer-Ebene verarbeitet.

Die fixed-response-Aktion gibt eine statische HTTP-Antwort direkt vom ALB zurück, ohne die Anfrage an ein Ziel weiterzuleiten. Verwenden Sie sie für:

• eine 503-Wartungsseite für bestimmte Pfade während Wartungsarbeiten
• einen schlanken Health-Check-Endpunkt direkt auf dem ALB (gibt sofort 200 OK zurück, ohne das Backend zu belasten)
• das Blockieren bestimmter Pfade mit einer 403-Forbidden-Antwort

Fixed Responses eignen sich, um Pfade vorübergehend außer Betrieb zu nehmen, ohne Anwendungscode zu ändern oder ein neues Deployment durchzuführen. Dazu passen Sie die Listener-Regeln dynamisch an.

Die authenticate-cognito-Aktion des ALB integriert Amazon Cognito User Pools, um Benutzer zu authentifizieren, bevor Anfragen an Ihre Anwendung weitergeleitet werden. Wenn ein nicht authentifizierter Benutzer eine geschützte Listener-Regel erreicht, leitet der ALB ihn zur von Cognito gehosteten Benutzeroberfläche zur Anmeldung weiter. Nach erfolgreicher Authentifizierung setzt der ALB ein verschlüsseltes Cookie und leitet die Anfrage mit Headern zur Benutzeridentität weiter.

Dadurch wird die Authentifizierungslogik vollständig aus Ihrer Anwendung ausgelagert. Ihr Backend empfängt die Header X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data und X-Amzn-Oidc-Access-Token mit den Claims des authentifizierten Benutzers.

ALB-Listener-Regeln können anhand von Query-String-Parametern und HTTP-Headern routen und ermöglichen so eine genau abgestufte Anforderungsweiterleitung:

• Mobile Clients weiterleiten, indem der Header User-Agent: *Mobile* erkannt und ein für mobile Geräte optimiertes Backend verwendet wird
• Premium-API-Anfragen weiterleiten, indem der benutzerdefinierte Header X-API-Tier: premium geprüft und eine schnellere Target-Gruppe verwendet wird
• A/B-Testvarianten weiterleiten, indem der Query-String-Parameter ?variant=beta ausgelesen wird

Header-basiertes Routing ermöglicht die Implementierung von Feature-Flags und Traffic-Aufteilung auf der Infrastrukturebene, ohne den Anwendungscode zu ändern.

Regeln werden in aufsteigender Prioritätsreihenfolge ausgewertet. Regeln mit niedrigeren Prioritätsnummern werden zuerst ausgewertet. Die Aktion der ersten passenden Regel wird angewendet, danach werden keine weiteren Regeln ausgewertet. Die Standardregel hat keine Prioritätsnummer und wird als abschließende Auffangregel immer zuletzt ausgewertet.

Best Practice: Weisen Sie Prioritätsnummern in Zehnerschritten (10, 20, 30 ...) statt als fortlaufende Ganzzahlen zu. So bleibt Raum, neue Regeln zwischen bestehenden Regeln einzufügen, ohne die Nummerierung ändern zu müssen. Spezifischere Regeln (z. B. Pfad + Host-Header) sollten niedrigere Nummern (also eine höhere Priorität) als allgemeine Regeln haben.

Ein einzelner ALB kann mithilfe von Listener-Regeln als Einstiegspunkt für eine gesamte Microservices-Plattform dienen. Ein praxisnahes Beispiel, das alle drei Bedingungstypen kombiniert:

• Priorität 10: Host=api.example.com + Pfad=/v2/* → Target-Gruppe api-v2
• Priorität 20: Host=api.example.com + Pfad=/v1/* → Target-Gruppe api-v1
• Priorität 30: Host=auth.example.com → Target-Gruppe auth-service
• Priorität 40: Host=www.example.com + Pfad=/static/* → CloudFront-Weiterleitung
• Standard: Host=www.example.com → Frontend-Target-Gruppe

Dieses Design senkt die Kosten, da keine separaten Load Balancer pro Service erforderlich sind.

Testen Sie Ihr Verständnis der Konzepte aus AWS Solutions Architect (SAA-C03) in dieser Lektion.

In dieser Lektion haben Sie gelernt: Listener-Regeln leiten Anfragen anhand von Host, Pfad, Headern, Methoden und Query-Strings weiter, Regeln werden in Prioritätsreihenfolge ausgewertet, wobei die erste Übereinstimmung entscheidet, und zu den Aktionen gehören Weiterleitung, Umleitung, Fixed Response und Cognito-Authentifizierung. Pfad- und hostbasiertes Routing ermöglichen es einem einzelnen ALB, als Einstiegspunkt für mehrere Microservices zu dienen. Als Nächstes behandeln wir SSL-Terminierung und Sticky Sessions.