Listener-Konfiguration Listener-Regeln Regelaktionstypen Regelbedingungstypen

Listener für Ihre Application Load Balancer

Ein Listener ist ein Prozess, der mit dem Protokoll und dem Port, das bzw. den Sie konfigurieren, Verbindungsanforderungen prüft. Bevor Sie Ihren Application Load Balancer verwenden können, müssen Sie mindestens einen Listener hinzufügen. Wenn Ihr Load Balancer keine Listener hat, kann er keinen Datenverkehr von Clients empfangen. Die Regeln, die Sie für Listener definieren, bestimmten, wie der Load Balancer Anforderungen an die Ziele weiterleitet, die Sie registrieren, z. B. EC2-Instances.

Inhalt

Listener-Konfiguration

Listener unterstützen die folgenden Protokolle und Ports:

Protocols (Protokolle): HTTP, HTTPS
Ports: 1-65535

Sie können einen HTTPS-Listener verwenden, um die Ver- und Entschlüsselung auf Ihren Load Balancer auszulagern, damit sich Ihre Anwendungen auf die Geschäftslogik konzentrieren können. Wenn das Listener-Protokoll HTTPS ist, müssen Sie auf dem Listener mindestens ein SSL-Serverzertifikat bereitstellen. Weitere Informationen finden Sie unter Erstellen eines HTTPS-Listeners für Ihren Application Load Balancer.

Wenn Sie sicherstellen müssen, dass die Ziele den HTTPS-Verkehr anstelle des Load Balancers entschlüsseln, können Sie einen Network Load Balancer mit einem TCP-Listener an Port 443 erstellen. Bei einem TCP-Listener leitet der Load Balancer verschlüsselten Datenverkehr an die Ziele weiter, ohne ihn zu entschlüsseln. Weitere Informationen finden Sie im Benutzerhandbuch für Network Load Balancers.

Application Load Balancers bieten native Unterstützung für WebSockets. Sie können eine bestehende HTTP/1.1-Verbindung in eine WebSocket (wsoderwss) -Verbindung umwandeln, indem Sie ein HTTP-Verbindungs-Upgrade verwenden. Wenn Sie ein Upgrade durchführen, wird die für Anfragen (sowohl zum Load Balancer als auch zum Ziel) verwendete TCP-Verbindung über den Load Balancer zu einer dauerhaften WebSocket Verbindung zwischen dem Client und dem Ziel. Sie können sie sowohl WebSockets mit HTTP- als auch mit HTTPS-Listenern verwenden. Die Optionen, die Sie für Ihren Listener auswählen, gelten sowohl für WebSocket Verbindungen als auch für HTTP-Verkehr. Weitere Informationen finden Sie unter So funktioniert das WebSocket Protokoll im Amazon CloudFront Developer Guide.

Application Load Balancer verfügen über native Unterstützung für HTTP/2 mit HTTPS-Listener. Sie können mit einer einzigen HTTP/2-Verbindung bis zu 128 Anforderungen parallel senden. Sie können die Protokollversion verwenden, um die Anforderung mit HTTP/2 an die Ziele zu senden. Weitere Informationen finden Sie unter Protokollversion. Da HTTP/2 Frontend-Verbindungen effizienter verwendet, gibt es möglicherweise weniger Verbindungen zwischen Clients und dem Load Balancer. Sie können das Server-Push-Feature von HTTP/2 nicht verwenden.

Weitere Informationen finden Sie unter Weiterleitung von Anforderungen im Benutzerhandbuch zu Elastic Load Balancing.

Listener-Regeln

Jeder Listener hat eine Standardaktion, auch als Standardregel bezeichnet. Die Standardregel kann nicht gelöscht werden und wird immer zuletzt ausgeführt. Es können zusätzliche Regeln erstellt werden, die aus einer Priorität, mindestens einer Aktion und mindestens einer Bedingung bestehen. Sie können jederzeit Regel hinzufügen oder bearbeiten. Weitere Informationen finden Sie unter Bearbeiten einer Regel.

Standardregeln

Beim Erstellen eines Listeners definieren Sie Aktionen für die Standardregel. Standardregeln können keine Bedingungen aufweisen. Wenn für die Regeln eines Listeners keine Bedingungen erfüllt werden, wird die Aktion für die Standardregel durchgeführt.

Es folgt ein Beispiel für eine Standardregel, wie in der Konsole dargestellt:

Priorität der Regel

Jede Regel hat eine Priorität. Regeln werden in der Reihenfolge ihrer Prioritäten bewertet, ausgehend vom niedrigsten Wert hin zum höchsten Wert. Die Standardregel wird zuletzt ausgewertet. Sie können die Priorität einer nicht standardmäßigen Regel jederzeit ändern. Sie können die Priorität der Standardregel nicht ändern. Weitere Informationen finden Sie unter Aktualisieren der Regelpriorität.

Regelaktionen

Jede Regelaktion verfügt über einen Typ, eine Priorität und die für die Durchführung der Aktion erforderlichen Informationen. Weitere Informationen finden Sie unter Regelaktionstypen.

Regelbedingungen

Jede Regelbedingung weist einen Typ und Bedingungsinformationen auf. Wenn die Bedingungen für eine Regel erfüllt sind, wird die dazugehörige Aktion durchgeführt. Weitere Informationen finden Sie unter Regelbedingungstypen.

Regelaktionstypen

Im Folgenden finden Sie die unterstützten Aktionstypen einer Listener-Regel:

authenticate-cognito: [HTTPS-Listener] Verwenden von Amazon Cognito zum Authentifizieren von Benutzern. Weitere Informationen finden Sie unter Authentifizieren von Benutzern mithilfe eines Application Load Balancers.
authenticate-oidc: [HTTPS-Listener] Verwenden eines Identitätsanbieters, der mit OpenID Connect (OIDC) konform ist, um Benutzer zu authentifizieren
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.

Die Aktion mit der niedrigsten Priorität wird zuerst durchgeführt. Jede Regel muss genau eine der folgenden Aktionen enthalten: forward, redirect oder fixed-response. Außerdem muss es die letzte auszuführende Regel sein.

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

Aktionen mit feststehender Antwort

Verwenden Sie fixed-response-Aktionen, um Client-Anforderungen zu verwerfen und eine benutzerdefinierte HTTP-Antwort zurückzugeben. 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 Aktion mit einer festen Antwort 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

Sie können mithilfe von forward-Aktionen Anforderungen an eine oder mehrere Zielgruppen weiterleiten. 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.

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

Mithilfe von redirect-Aktionen können Sie Client-Anforderungen von einer URL an eine andere weiterleiten. 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}".

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}".

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"
      }
  }
]

Regelbedingungstypen

Im Folgenden finden Sie die unterstützten Bedingungstypen für eine Regel:

host-header: Die Route basiert auf dem Hostnamen jeder Anforderung. Weitere Informationen finden Sie unter Hostbedingungen.
http-header: Die Route basiert auf den HTTP-Headern für jede Anforderung. Weitere Informationen finden Sie unter HTTP-Header-Bedingungen.
http-request-method: Die Route basiert auf der HTTP-Anforderungsmethode jeder Anforderung. Weitere Informationen finden Sie unter Bedingungen für HTTP-Anforderungsmethoden.
path-pattern: Die Route basiert auf den Pfadmustern in den Anforderungs-URLs. Weitere Informationen finden Sie unter Pfadbedingungen.
query-string: Die Route basiert auf Schlüssel/Wert-Paaren oder Werten in den Abfragezeichenfolgen. Weitere Informationen finden Sie unter Abfragezeichenfolgebedingungen.
source-ip: Die Route basiert auf der Quell-IP-Adresse jeder Anforderung. Weitere Informationen finden Sie unter Bedingungen für die Quell-IP-Adresse.

Jede Regel kann optional jeweils eine der folgenden Bedingungen umfassen: host-header, http-request-method, path-pattern, und source-ip. Jede Regel kann optional auch eine oder mehrere der folgenden Bedingungen enthalten: http-header und query-string.

Sie können bis zu drei Übereinstimmungsbewertungen pro Bedingung angeben. Beispiel: Für jede http-header-Bedingung können Sie bis zu drei Zeichenfolgen angeben, die mit dem Wert des HTTP-Headers in der Anforderung vergleichen werden. Die Bedingung wird erfüllt, wenn eine der Zeichenfolgen dem Wert des HTTP-Headers entspricht. Wenn alle drei Zeichenfolgen eine Übereinstimmung aufweisen sollen, erstellen Sie eine Bedingung pro Übereinstimmungsbewertung.

Sie können bis zu fünf Übereinstimmungsbewertungen pro Regel angeben. Beispiel: Sie können eine Regel mit fünf Bedingungen erstellen, wobei jede Bedingung eine Übereinstimmungsbewertung aufweist.

Sie können Platzhalterzeichen in die Übereinstimmungsbewertung für die Bedingungen http-header, host-header, path-pattern und query-string einschließen. Die Anzahl der Platzhalterzeichen pro Bedingung ist auf 5 beschränkt.

Regeln werden nur auf sichtbare ASCII-Zeichen angewendet; Steuerzeichen (0x00 bis 0x1f und 0x7f) sind ausgeschlossen.

Demos finden Sie unter Erweiterte Anfrageweiterleitung.

HTTP-Header-Bedingungen

Mit HTTP-Header-Bedingungen können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage der HTTP-Header für die Anforderung weitergeleitet werden. Sie können die Namen der standardmäßigen oder benutzerdefinierten HTTP-Header-Felder angeben. Beim Headernamen und bei der Übereinstimmungsbewertung wird nicht zwischen die Groß- und Kleinschreibung unterschieden. Die folgenden Platzhalterzeichen werden in den Vergleichszeichenfolgen unterstützt: * (findet eine Übereinstimmung mit 0 oder mehr Zeichen) und ? (findet Übereinstimmungen für genau 1 Zeichen). Platzhalterzeichen werden im Header-Namen nicht unterstützt.

Beispiel für eine HTTP-Header-Bedingung für AWS CLI

Sie können Bedingungen angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Die folgende Bedingung wird von Anforderungen mit einem User-Agent-Header erfüllt, der mindestens einer der angegeben Zeichenfolgen entspricht.


[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

Bedingungen für HTTP-Anforderungsmethoden

Mit Bedingungen für HTTP-Anforderungsmethoden können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage der HTTP-Anforderungsmethode der Anforderung weitergeleitet werden. Sie können standardmäßige oder benutzerdefinierte HTTP-Methoden angeben. Bei der Übereinstimmungsbewertung wird die Groß- und Kleinschreibung nicht beachtet, Platzhalterzeichen werden nicht unterstützt. Der Methodenname muss also eine genaue Übereinstimmung sein.

Wir empfehlen, dass Sie GET- und HEAD-Anforderungen auf die gleiche Weise weiterleiten, da die Antwort auf eine HEAD-Anforderung möglicherweise zwischengespeichert wird.

Beispiel für eine HTTP-Methodenbedingung für AWS CLI


[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Hostbedingungen

Mit Hostbedingungen können Sie Regeln definieren, die Anforderungen basierend auf dem Hostnamen im Host-Header weiterleiten (auch als hostbasierte Weiterleitung bezeichnet). Auf diese Weise können Sie mit einem einzigen Load Balancer mehrere Unterdomains und verschiedene Top-Level-Domains unterstützen.

Beim Hostnamen wird die Groß-/Kleinschreibung nicht berücksichtigt, er kann maximal 128 Zeichen lang sein und kann folgende Zeichen enthalten:

A-Z, a-z, 0-9
- .
* (entspricht 0 oder mehr Zeichen)
? (entspricht genau 1 Zeichen)

Sie müssen mindestens ein "."-Zeichen einschließen. Es können nur alphabethische Zeichen nach dem letzten "."-Zeichen angegeben werden.

Beispiele für Hostnamen

example.com
test.example.com
*.example.com

Die Regel *.example.com entspricht test.example.com, nicht jedoch example.com.

Beispiel für eine Host-Header-Bedingung für die AWS CLI

Sie können Bedingungen angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Die folgende Bedingung wird von Anforderungen mit einem Host-Header erfüllt, der mindestens einer der angegeben Zeichenfolgen entspricht.


[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Pfadbedingungen

Mit Pfadbedingungen können Sie Regeln definieren, mit denen Anforderungen auf Grundlage der URL in der Anforderung weitergeleitet werden (auch bekannt als pfadbasierte Weiterleitung

Das Pfadmuster wird nur auf den Pfad der URL, nicht auf dessen Abfrageparameter, angewendet. Es wird nur auf sichtbare ASCII-Zeichen angewendet; Steuerzeichen (0x00 bis 0x1f und 0x7f) sind ausgeschlossen.

Die Regelauswertung wird erst durchgeführt, nachdem die URI-Normalisierung erfolgt ist.

Beim Pfadmuster wird die Groß-/Kleinschreibung berücksichtigt, es kann maximal 128 Zeichen lang sein und kann folgende Zeichen enthalten.

A-Z, a-z, 0-9
_ - . $ / ~ " ' @ : +
& (Verwendung von &)
* (entspricht 0 oder mehr Zeichen)
? (entspricht genau 1 Zeichen)

Wenn die Protokollversion gRPC ist, können Bedingungen für ein Paket, einen Dienst oder eine Methode spezifisch sein.

Beispiel für HTTP-Pfadmuster

/img/*
/img/*/pics

Beispiel für gRPC-Pfadmuster

/paket
/paket.dienst
/paket.dienst/methode

Das Pfadmuster wird verwendet, um Anforderungen weiterzuleiten. Die Anforderungen werden bei diesem Vorgang aber nicht geändert. Wenn eine Regel beispielsweise das Pfadmuster /img/* aufweist, leitet die Regel eine Anforderung von /img/picture.jpg an die angegebene Zielgruppe als Anforderung von /img/picture.jpg weiter.

Beispiel für eine Pfadmusterbedingung für AWS CLI

Sie können Bedingungen angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Die folgende Bedingung wird von Anforderungen mit einer URL erfüllt, die die angegebene Zeichenfolge enthält.


[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Abfragezeichenfolgebedingungen

Mit Abfragezeichenfolgebedingungen können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage von Schlüssel/Wert-Paaren oder Werten in der Abfragezeichenfolge weitergeleitet werden. Bei der Übereinstimmungsbewertung wird die Groß- und Kleinschreibung nicht beachtet, Die folgenden Platzhalterzeichen werden unterstützt: * (findet Übereinstimmungen mit 0 oder mehr Zeichen) und ? (findet Übereinstimmungen für genau 1 Zeichen).

Beispiel für eine Abfragezeichenfolge für die AWS CLI

Sie können Bedingungen angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Die folgende Bedingung wird von Abfragen mit einer Abfragezeichenfolge erfüllt, die entweder ein Schlüssel/Wert-Paar oder „version=v1“ enthält oder bei der ein beliebiger Schlüssel auf „example“ festgelegt ist.


[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Bedingungen für die Quell-IP-Adresse

Mit Bedingungen für die Quell-IP-Adresse können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage der Quell-IP-Adresse der Anforderung weitergeleitet werden. Die IP-Adresse muss im CIDR-Format angegeben werden. Sie können IPv4- und IPv6-IP-Adressen verwenden. Platzhalterzeichen werden nicht unterstützt. Sie können den 255.255.255.255/32-CIDR für die Quell-IP-Regelbedingung nicht angeben.

Befindet sich ein Client hinter einem Proxy, ist dies die IP-Adresse des Proxys, nicht die des Clients.

Diese Bedingung wird nicht durch Adressen im X-Forwarded-For-Header erfüllt. Sie können mit einer http-header-Bedingung im X-Forwarded-For-Header nach Adressen suchen.

Beispiel für eine Quell-IP-Bedingung für die AWS CLI

Sie können Bedingungen angeben, wenn Sie eine Regel erstellen oder ändern. Weitere Informationen finden Sie bei den Befehlen create-rule und modify-rule. Die Folgende Bedingung wird von Anforderungen mit einer Quell-IP-Adresse in einem der angegebenen CIDR-Blöcken erfüllt.


[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Zonenverschiebung

Erstellen eines HTTP-Listeners