Aktionstypen für Listener-Regeln - Elastic Load Balancing

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Aktionstypen für Listener-Regeln

Aktionen bestimmen, wie ein Load Balancer Anfragen behandelt, wenn die Bedingungen für eine Listener-Regel erfüllt sind. Jede Regel muss mindestens eine Aktion enthalten, die festlegt, wie die entsprechenden Anfragen behandelt werden sollen. Jede Regelaktion hat einen Typ und Konfigurationsinformationen. Application Load Balancers unterstützen die folgenden Aktionstypen für Listener-Regeln.

Aktionstypen
authenticate-cognito

[HTTPS-Listener] Verwenden von Amazon Cognito zum Authentifizieren von Benutzern. Weitere Informationen finden Sie unter Konfigurieren der Benutzerauthentifizierung.

authenticate-oidc

[HTTPS-Listener] Verwenden eines Identitätsanbieters, der mit OpenID Connect (OIDC) konform ist, um Benutzer zu authentifizieren Weitere Informationen finden Sie unter Konfigurieren der Benutzerauthentifizierung.

fixed-response

Zurückgeben einer benutzerdefinierten HTTP-Antwort Weitere Informationen finden Sie unter Aktionen mit feststehender Antwort.

forward

Weiterleiten von Anforderungen an die angegebenen Zielgruppen. Weitere Informationen finden Sie unter Weiterleitungsaktionen.

redirect

Weiterleiten von Anforderungen von einer URL an eine andere Weitere Informationen finden Sie unter Weiterleitungsaktionen.

Grundlagen von Aktionen
  • Jede Regel muss genau eine der folgenden Routing-Aktionen enthalten:forward,, oder redirectfixed-response, und es muss sich um die letzte Aktion handeln, die ausgeführt werden muss.

  • Ein HTTPS-Listener kann eine Regel mit einer Benutzerauthentifizierungsaktion und einer Routing-Aktion haben.

  • Wenn es mehrere Aktionen gibt, wird die Aktion mit der niedrigsten Priorität zuerst ausgeführt.

  • Wenn die Protokollversion gRPC oder HTTP/2 ist, sind forward-Aktionen die einzigen unterstützten Aktionen.

Aktionen mit feststehender Antwort

Eine fixed-response Aktion löscht Client-Anfragen und gibt eine benutzerdefinierte HTTP-Antwort zurück. Sie können mit dieser Aktion einen 2XX-, 4XX- 5XX-Antwortcode und optional eine Nachricht zurückgeben.

Wenn eine fixed-response-Aktion ausgeführt wird, werden die Aktion und die URL des Weiterleitungsziels in den Zugriffsprotokollen aufgezeichnet. Weitere Informationen finden Sie unter Zugriffsprotokolleinträge. Die Anzahl der erfolgreichen fixed-response-Aktionen wird in der Metrik HTTP_Fixed_Response_Count erfasst. Weitere Informationen finden Sie unter Application-Load-Balancer-Metriken.

Beispiel für eine feste Antwortaktion für AWS CLI

Sie können eine Aktion angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Mit der folgenden Aktion wird mit dem angegebenen Statuscode und dem Textkörper eine festgelegte Antwort gesendet.

[ { "Type": "fixed-response", "FixedResponseConfig": { "StatusCode": "200", "ContentType": "text/plain", "MessageBody": "Hello world" } } ]

Weiterleitungsaktionen

Eine forward-Aktion leitet Anforderungen an ihre Zielgruppe weiter. Bevor Sie eine forward-Aktion hinzufügen, erstellen Sie ihre Zielgruppe und fügen Sie Ziele hinzu. Weitere Informationen finden Sie unter Erstellen Sie eine Zielgruppe für Ihren Application Load Balancer.

Wenn Sie mehrere Zielgruppen für eine forward-Aktion angeben, müssen Sie für jede Zielgruppe eine Gewichtung angeben. Jede Zielgruppengewichtung ist ein Wert zwischen 0 und 999. Anforderungen, die einer Listener-Regel mit gewichteten Zielgruppen entsprechen, werden basierend auf ihren Gewichtungen an diese Zielgruppen verteilt. Wenn Sie beispielsweise zwei Zielgruppen mit einer Gewichtung von 10 angeben, erhält jede Zielgruppe die Hälfte der Anforderungen. Wenn Sie zwei Zielgruppen angeben, eine mit einer Gewichtung von 10 und die andere mit einer Gewichtung von 20, erhält die Zielgruppe mit der Gewichtung von 20 doppelt so viele Anforderungen wie die andere Zielgruppe.

Wenn Sie eine Regel zur Verteilung des Datenverkehrs auf gewichtete Zielgruppen konfigurieren und eine der Zielgruppen leer ist oder nur fehlerhafte Ziele hat, führt der Load Balancer nicht automatisch ein Failover zu einer Zielgruppe mit fehlerfreien Zielen durch.

Standardmäßig garantiert das Konfigurieren einer Regel für die Verteilung des Datenverkehrs zwischen gewichteten Zielgruppen nicht, dass Sticky Sessions eingehalten werden. Um sicherzustellen, dass Sticky Sessions eingehalten werden, aktivieren Sie die Klebrigkeit der Zielgruppe für die Regel. Wenn der Load Balancer eine Anfrage zum ersten Mal an eine gewichtete Zielgruppe weiterleitet, generiert er ein Cookie mit dem Namen AWSALBTG , das Informationen über die ausgewählte Zielgruppe kodiert, das Cookie verschlüsselt und das Cookie in die Antwort an den Client einbezieht. Der Client sollte das erhaltene Cookie in nachfolgende Anfragen an den Load Balancer aufnehmen. Wenn der Load Balancer eine Anforderung empfängt, die mit einer Regel mit aktivierter Zielgruppenklebrigkeit übereinstimmt und das Cookie enthält, wird die Anforderung an die im Cookie angegebene Zielgruppe weitergeleitet.

Application Load Balancer unterstützen keine Cookie-Werte, die URL-codiert sind.

Bei CORS (Cross-Origin Resource Sharing)-Anforderungen benötigen einige Browser SameSite=None; Secure zum Aktivieren von Stickiness. In diesem Fall generiert Elastic Load Balancing ein zweites Cookie AWSALBTGCORS, das dieselben Informationen wie das ursprüngliche Stickiness-Cookie plus dieses SameSite Attribut enthält. Kunden erhalten beide Cookies.

Beispiel einer Weiterleitungsaktion mit einer Zielgruppe

Sie können eine Aktion angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Die folgende Aktion leitet die Anforderungen an die angegebene Zielgruppe weiter.

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" } ] } } ]
Beispiel einer Weiterleitungsaktion mit zwei gewichteten Zielgruppen

Die folgende Aktion leitet Anforderungen an die beiden angegebenen Zielgruppen basierend auf der Gewichtung jeder Zielgruppe weiter.

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59", "Weight": 20 } ] } } ]
Beispiel einer Weiterleitungsaktion mit aktivierter Stickiness

Wenn Sie über eine Weiterleitungsaktion mit mehreren Zielgruppen verfügen und für eine oder mehrere Zielgruppen Sticky Sessions aktiviert sind, müssen Sie die Stickiness der Zielgruppe aktivieren.

Die folgende Aktion leitet Anforderungen an die beiden angegebenen Zielgruppen weiter, wobei die Klebrigkeit der Zielgruppe aktiviert ist. Anforderungen, die die Stickiness-Cookies nicht enthalten, werden basierend auf der Gewichtung jeder Zielgruppe weitergeleitet.

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59", "Weight": 20 } ], "TargetGroupStickinessConfig": { "Enabled": true, "DurationSeconds": 1000 } } } ]

Weiterleitungsaktionen

Eine redirect Aktion leitet Client-Anfragen von einer URL zu einer anderen weiter. Konfigurieren Sie Weiterleitungen je nach Bedarf entweder als temporär (HTTP 302) oder permanent (HTTP 301).

eine URI umfasst folgende Komponenten:

protocol://hostname:port/path?query

Sie müssen mindestens eine der folgenden Komponenten modifizieren, um eine Weiterleitungsschleife zu verhindern: Protokoll, Hostname, Port oder Pfad. Für alle Komponenten, an denen Sie keine Änderungen vornehmen, wird der ursprüngliche Wert beibehalten.

Protokoll

Das Protokoll (HTTP oder HTTPS). Sie können von HTTP nach HTTP, von HTTP nach HTTPS und von HTTPS nach HTTPS weiterleiten. Eine Weiterleitung von HTTPS nach HTTP ist nicht möglich.

hostname

Der Hostname Bei einem Hostnamen wird die Groß- und Kleinschreibung nicht beachtet. Er kann bis zu 128 Zeichen lang sein und aus alphanumerischen Zeichen, Platzhaltern (* und ?) und Bindestrichen (-) bestehen.

port

Der Port (1 bis 65535)

Pfad

Der absolute Pfad, beginnend mit dem vorangestellten "/" Bei einem Pfad muss die Groß- und Kleinschreibung nicht beachtet werden. Er kann 128 Zeichen lang sein und aus alphanumerischen Zeichen, Platzhaltern (* und ?), & (mittels &) sowie die Sonderzeichen _-.$/~"'@:+ bestehen.

query

Die Abfrageparameter Die maximale Länge beträgt 128 Zeichen.

Sie können URI-Komponenten der ursprünglichen URL in der Ziel-URL weiter nutzen. Verwenden Sie dazu die folgenden reservierten Schlüsselwörter:

  • #{protocol} – zur Beibehaltung des Protokolls. In den Protokoll- und Abfragekomponenten zu verwenden.

  • #{host} – Zur Beibehaltung der Domain. In den Hostnamen-, Pfad- und Abfragekomponenten zu verwenden.

  • #{port} – Zur Beibehaltung des Ports. In den Port-, Pfad- und Abfragekomponenten zu verwenden.

  • #{path} – Zur Beibehaltung des Pfads. In den Pfad- und Abfragekomponenten zu verwenden.

  • #{query} – Zur Beibehaltung der Abfrageparameter. In der Abfragekomponente zu verwenden.

Wenn eine redirect-Aktion ausgeführt wird, wird diese in den Zugriffsprotokollen aufgezeichnet. Weitere Informationen finden Sie unter Zugriffsprotokolleinträge. Die Anzahl der erfolgreichen redirect-Aktionen wird in der Metrik HTTP_Redirect_Count erfasst. Weitere Informationen finden Sie unter Application-Load-Balancer-Metriken.

Beispiel für Weiterleitungsaktionen mithilfe der Konsole

Mit der folgenden Regel wird beispielsweise eine permanente Weiterleitung auf eine URL mit dem HTTPS-Protokoll und dem festgelegten Port 40443 eingerichtet. Beibehalten werden der ursprüngliche Hostname, der Pfad und die Abfrageparameter. Dieser Bildschirm entspricht "https://#{host}:40443/#{path}?#{query}".

Eine Regel, über die die Anforderung an eine URL mit dem HTTPS-Protokoll und dem angegebenen Port 40443 weitergeleitet wird. Beibehalten werden die ursprüngliche Domain, der Pfad und die Abfrageparameter der ursprünglichen URL.

Mit der folgenden Regel wird eine permanente Weiterleitung auf eine URL mit dem ursprünglichen Protokoll, Port, Hostnamen und Abfrageparametern eingerichtet. Der Pfad wird mit dem Schlüsselwort #{path} modifiziert. Dieser Bildschirm entspricht "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

Eine Regel, über die die Anforderung an eine URL mit dem ursprünglichen Protokoll, Port, Hostnamen und Abfrageparametern weitergeleitet wird. Der Pfad wird mit dem Schlüsselwort #{path} modifiziert.
Beispiel für eine Umleitungsaktion für AWS CLI

Sie können eine Aktion angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Mit der folgenden Aktion wird eine HTTP-Anforderung an eine HTTPS-Anforderung an Port 443 weitergeleitet, die denselben Hostnamen, Pfad und die gleiche Abfragezeichenfolge wie die HTTP-Anforderung aufweist.

[ { "Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}", "StatusCode": "HTTP_301" } } ]